Hi!

First of all, thanks for an amazing job! I am using your scripts to maintain Debian sid and it is an awesome experience! Everything just works!

However, there is one single issue that I want to address: currently, there is no way to verify the authenticity of smxi and sgfxi scripts. To make matters worse, these scripts attempt to update themselves.

I know that this feature request may seem silly to a person living in the US or Western Europe. But there are people in other places like my country that would love to use it too. Some of them may be even involved in defending human rights.

I know pros and cons of running Debian sid in production, etc. And I know that there are so many holes in IT systems that it is almost impossible to close them all, and that I don't even know who you are, etc. etc.

What I propose is decoupling scripts themselves from their update process: creating an 'smxi-updater' debian package, that will contain your GPG signature and will be responsible for downloading, updating, and _verifying authenticity_ of your scripts.

So, instead of wget -Nc smxi.org/smxi.zip, we will run aptitude install smxi-updater && smxi-updater --update.

I'd like to thank you again, your scripts are a great tool to run Debian Unstable!

P.S.
I know about Aptosid, but I don't like the attitude of people who are running it. I consider that I don't need anything more than smxi+sgfxi to run Debian sid.
Back to top

A friend of mine, who I've been asking to try out antiX core, on my recommendation has started to use smxi. In the early configuration stage, one of the series of questions asked is whether you want to use Sid and add an archive repository for it, and a similar question is asked about Liquorix sources.

The person interested in this has used Linux distributions for several years now, but always at a fairly high level, rarely going beneath the graphical presentation layer, but I've slowly and gradually introduced him to things enough so that he's actually about ready to go there, and smxi is one of the tools he is starting to explore.

He feels that when asked questions about the archive lists, it would be nice to have the option available to have the existing list displayed. Now I know that most of us can just go to the /etc/apt or /etc/apt/sources.list.d or any file or directory in that hierarchy and find out whatever it is that we need to know. But the request seemed reasonable and legitimate, and that is, if we're asking to add a new archive to the ones listed, can we at least optionally offer to list the contents of the currently listed archives as seen in the /etc/apt directory tree, as interpreted by smxi?

While I personally do not need this feature, I can see value in it, and I suppose I could even take advantage of it when I am modifying a new or updated system configuration.

Thanks for considering this request on behalf of a brand new smxi user. If you decide to add this feature, I'll mention to him that you agreed to add this. Appreciate it!
Back to top

masinick, yeah, that's somewhat reasonable, agreed.

Which exact locations did he have in mind?

It's pretty easy to find the stuff:



though that doesn't list the actual file that contains the repo, but will show all repos that are active.
Back to top

pipy, I appreciate your concern regarding security, especially out of the first world, certainly a valid issue.

Note that smxi/sgfxi are free software, and anyone is free to create a package for them, and then to find a reliable repository to place them in.

I'll cooperate with such a person, but I won't do the packaging myself, why? because I don't need it, and it would just take more time.

So the basic idea is, whoever is free to create a package, is free to communicate with me if they need some options added for packaging, or to turn off various parts if a package flag is set in the script globals, for example, and I'll leave it at that.

The best place to do such communication is either here on the forums or on irc.oftc.net channel #smxi.

But keep in mind, I have enough to do with these things, and can't take on any more volunteer tasks. So this is a case of: if there's a need, then maybe someone can fill that need. Or not.

Most of the scripts already have options to turn off wget stuff, and turn off updating, and it's not that hard to go through them to make sure everything is actually no longer grabbing stuff live, just takes some patience, and setting a global dev flag that switches all that stuff off, then the dev can update using svn, and they can track svn as well, same as the guys who package inxi do in arch, siduction, antix, etc.

Back in kanotix/sidux days, the warning system was much more active, and would form a key part of what makes smxi work, ie, actually live, to the minute, warnings and alerts delivered when you run the script, but I haven't really found anyone who will commit to updating it in real time anymore, so it is just used now and then, which is too bad, it was a good tool and still is if it's manned properly.
Back to top

Hi,

I'd like to have the script's name not hardcoded in inxi. Currently, line 423 of inxi 1.8.23-00 reads


As a non-privileged user on a compute server, I'd like to have a script "inxi-local" in my ~/bin folder, so I can quickly see hardware capabilities of the server. Note: Different servers with different hardware all mount the same /home/${USER} directory, here.

Due to the hardcoded scriptname, inxi will not work after renaming.

I suggest to replace the line with

or

Back to top

I took a look at that, and I don't think it's a good idea, it will break all sorts of little things inside.

I'd have to actually HARD CODE in the inxi script name in several areas in order to maintain functionality, particularly in -U, and in sourcing config files, and possibly some other areas that escape me at the moment.

I suggest you take advantage of the script color option to set custom colors for the instances you want to see as local, it's easy and fast to do it that way, and that's one reason those options exist.

While I like trying to accommodate specific user scenarios, I think this particular one has a high probability of negatively impacting other things for other users, so I'm going to nix it, sorry, since it actually has too many unintended consequences.

Now, I guess I can make another global that is display script name, which will show whatever file name inxi is given, without changing anything fundamental, but that also wont' work, since it would break -U and sourcing of config files. So no, the more I look at it, the more I think this is a wont' do item. The only way I can think of to work around that issue would be to symbolically link inxi-local to inxi real, then maybe the local version would show inxi-local as the display name, but I think this is getting too specific to mess with further on my end, I would say this is probably something you want to handle via customized user configuration files.

It's also worth noting that inxi already shows the system name and information, so it's pretty obvious what system you are viewing with inxi in the first place.

Also note, you are totally free to change the name yourself and then handle whatever undesirable consequences, or none, that come about because of that, just be aware it will break -U, and some other upgrade/update options, and maybe some other stuff. Changing the name in a sourced inxi.conf file is probably not a great idea since there are too many things expecting to see that name.

I'm not totally clear on your specific use case however, why not just ssh into the servers and run inxi that way, that's how I always do it.
Back to top

Oh, I would never have expected that things like -U just work if inxi's name is changed. I'm more interested in the basic functions itself.

Let me put it this way:
Currently, if I put a renamed inxi in my ~/bin and call it, I get this output:


So, inxi breaks if renamed. Well, at least a bit...

If SCRIPT_NAME=$(basename $0) would be used, is there any possibility, inxi would not work correctly as long as it is not renamed? I can't think of a negative impact as long as no one changes the name.
On the other hand, if someone has the silly idea to change the name, basic things like -bxx or -F still work really well and in fact: better than now.

A quick idea:




Absolutely. But I have to have inxi on the computer. On a compute server, where I log in with ssh, I am not root but just some unprivileged user. But I'd like to have a tool there to quickly tell me what hardware I have around.



That is exactly how I would like to do it. But I do not control the software on these SUSE-servers, so I thought I'd place the script in my ~/bin.

My problem is then: This ~/bin is the same folder on all the SUSE compute servers *and* my own Debian working machine (I really like it that way). This means, I can't symlink from /usr/bin/inxi to ~/bin/inxi-local, because this link will only work on my own machine.

Please be assured that I am really grateful for this great tool. I don't rely on this change, I just though it could not have a negative impact for anyone, as long as things like S(basename $0) are garanteed to work.
Back to top

I would suggest you simply change the SCRIPT_NAME= to what you want, since using a different name than inxi has undesirable outcomes for other cases than simple use of inxi, I can't implement something knowing it can break core functions, that isn't a good idea.

Changing names is easy:


I would say this instance is too specific to warrant any handlng on my end, and I certainly dont' want to introduce any features that makes support harder, I used to try that with smxi but stopped very soon because the support issues became impossible, after that, I forced the scripts to use their names. inxi is actually looser than smxi, smxi won't permit you to run it from anywhere other than /usr/local/bin.

You can do quite a bit however with user config files in inxi, including adding in programming or whatever else you want to add in, you can for example change the SCRIPT_NAME there, which will break a few things, but will allow a different name to show, I think anyway, I could be wrong. But this isn't a feature I think I want in general to add to inxi, anything that creates the possibility of user error I try to avoid as a general rule.
Back to top

AntiX and MX Linux have this driver for those with older machines that require it.

Thanks in advance!
Back to top

This is updated in 2.3.8

thanks

sorry it took me so long to get the issue resolved, ;)

Just to confirm:

sisimedia

that is the name of the driver?

It loads with sisimedia_drv.so

visibilbly in Xorg.0.log?

I've also updated sgfxi to support that driver name.
Back to top