So can someone install sgfxi without smxi now?
Back to top

sgfxi has always been a standalone script, since the first days it was written, in fact, it was developed to be a standalone module of smxi. Like svmi.

just put it in /usr/local/bin

That's the only requirement.

It updates itself every time it runs, so usually it's install once and that's it.

The only difference between smxi starting it and user starting it is smxi offers only default drivers, and smxi sends sgfxi some data to tell it not to update itself, and to use the smxi script colors, and a few other little things.

Stand alone sgfxi has more options available than the limited set smxi sends it, but the set smxi sends it are generally for almost all users the right ones.
Back to top

I've been using smxi for ages now and I hadn't realised that sgfxi was a standalone script.

Just to let you know, that many MEPIS users are using smxi and more so sgfxi. Some are pushing for Warren to include it in his next release.
Back to top

wow, really? Amazing. I had no idea. What does smxi ID the mepis stuff as? Debian?

sgfxi is VERY complex, and for driver debugging requires advanced testing options and features, it's not really possible to do that in sync with smxi, although even there, I have a bunch of testing flags that will make smxi think it's running an ati card say instead of an nvidia, then send sgfxi a testing flag, etc...

This stuff is so hard to use that I don't run it much, but it does all work, more or less.

sgfxi was just vastly improved in this area though.
Back to top

I think smxi identifies it as Debian. I'll check.
The latest MEPIS 8 (undergoing testing) changes the /etc/issue comment to remove the word Ubuntu so MEPIS users/testers could use the smxi script.
Despite a whole load of myths out there, MEPIS has always been Debian compliant (apart from the Ubuntu adventure/mistake which didn't last a year).
Oh and Warren is finally opening up the MEPIS tools and installer, using the Apache licence (GPL3 compliant according to the FSF). No longer a promise, but a reality.

antiX-M8-test2 is out for testing so hopefully I'll get more feedback about smxi, sgfxi and inxi
Back to top

good for him. We all make mistakes, the real test is showing that you are fixing them. I'm more impressed with someone who makes a mistake fixing them than with someone who believes they never make mistakes then never fixing them....

Anyway, sgfxi stuff is all on code.google.com/p/sgfxi now, that is fully open, and is also open to serious possible contributors, but they have to be competent to deal with that code, it's hard to understand, but it's as clear as I can make it structurally.

Open as in everything that sgfxi uses is in the svn, patches, etc, but anyone with a google account can post a new 'issues' thing, and I think I set it to let anyone at all comment on code changes.

I've set up branches/one and branches/two for future use, that's going to be the preferred mode for all testing and development, and will be the only allowed thing for contributors for a long time, unless someone really kicks butt....

smxi is gpl 2, because I used some code from sidux
sgfxi is gpl 2, because at one point the idea was for sidux to use it, and it has some hacks from them.
svmi is gpl 2
inxi is gpl 3, because that's what infobash 3.02 was, and I like it.
Back to top

A bit off topic, but about gpl2 gpl3 as I am confused.

If someone uses code that is gpl2, does that mean the result has also to be gpl2 and cannot be gpl3?
Back to top

yes, more or less.

gpl 2 code shouldn't be used in gpl 3 code, and gpl 3 code shouldn't be used in gpl 2 code. That's unfortunate, but to fix the loopholes in gpl 2 code, which allowed a truly incorrect reading of gpl 2 intentions to become legally permissable, gpl 3 was forced to close those.

Of course we all know that the code is going to drift back and forth no matter what, but that's the way it works.

Only the license / copy right owners can change the license terms. That's more or less how it works. I initially had smxi, sgfxi, and svmi as gpl 3, but then I realized that, even though I'd only used at most 50 lines of sidux gpl 2 code, out of a total of almost 20k lines, that still meant that the license of the whole needed to fit with the license of of the lowest strength used, the gpl 2 in this case.

And of course, people can't take gpl 3 code and downgrade it to gpl 2, because that's not allowed unless they hold both copy rights of both works. I can, for example, and do, take my own gpl 2 code, and use it in gpl 3 stuff., and vica versa, because I am copy right holder of both works, and as long as I don't use the chunks that I didn't author, that's fine.

Kind of a pain, but that's how free software of the gpl variety works. bsd, mit, apache license, is totally free, no restrictions, anyone can use it for anything, basically, period. That's also a good option for many things.
Back to top

However, there is one magic line in the GPL default template, the one most people use without thinking, or to solve such issues, that totally fixes this problem re upgrading to next license:



This protects all future users from exactly this problem.

All my code uses this, by the way, for this very reason: all future users will be free to take my code, and use it in whatever version of the GPL they wanted to use, as long as it's later.

It's my opinion that people who remove this line are doing a major disservice to all future GPL users.
Back to top