smxi svmi sgfxi :: feature requests

[techAdmin]

aus9, your comments are definitely a valid bug report, things should be clear and intuitive, I'm going to think a bit how to handle this, I lean, as I told you on irc, more towards simply removing this feature for sidux users in general, then possibly using your altered wording in some form for all non sidux systems.

Just to make this clear, the server handling is a new feature, done because I got sick of installing alsa stuff on servers, then having to remove it again, so I decided that it would be a good option when you build your system to be able to tell the script that it can skip some parts safely.

But this really does not apply to sidux at all I think, not in the way it's currently distributed, everything is installed more or less, it's definitely not a server distro at all, though you can remove stuff from it to make it into one, but that's the opposite of what smxi is doing, it's building up a system to be x or y, at least when you use this part of it, which most sidux users will literally never see, at least not the desktop / x constructors.

But the bug is noted, I think I may remove that for sidux, but I'll give it a day or two to percolate, I suggest you do the same, if something pops into your head, feel free to post an update, ideas are always welcome.

[aus9]

to techAdmin

we did have a fine chat on irc.

to Anyone

I forgot to mention that I removed pic links due the chat. (They were misleading and were not the right way of reporting something.)
So if anyone is wondering what my fbgrab post is about...wonder no longer heh heh. I shall edit that fbgrab post if you prefer, techAdmin?

I am not a programmer, so do not appreciate how hard it its to write a script for normal ppl and us sidux users. ;)

But I still appreciate your patience.

[techAdmin]

So I bounced a few ideas around in my head, and finding myself unable to summon much enthusiasm in any direction, decided on the following, which you can now try:

Removed client/server question from pre package install
Added client/server question trigger as a new option in primary package install section
Show output in primary package install section showing your selection, or nothing if you haven't run it.
Added option to return to the main menu in client/server section, since it now doesn't matter.

In other words, I changed this to being an opt in only question.

Since I'm one of the few people who will probably use this, or who actually understands why it's desirable to have, it's best to just leave as an option to be manually set, rather than have it be automatically set for everyone.

[techAdmin]

ibgb, i moved your remove warning to the smxi developer forum since it's an actually functioning block of code.

I can see some utility for this with apt-get users, aptitude actually handles remove warnings better in general, and puts them at the end of the package list, but for apt-get users, I can see the utility of working around this issue in such a way.

I can also see a utility in using that trivial option, which I didn't know about, to actually log the entire dist-upgrade message as well as handling it for remove situations.

This one looks like a winner, though the message has to be significantly shorter to be viewable in consoles that do not have high resolution.

[widux]

:: techAdmin wrote ::

So I bounced a few ideas around in my head, and finding myself unable to summon much enthusiasm in any direction, decided on the following, which you can now try:

Removed client/server question from pre package install
Added client/server question trigger as a new option in primary package install section
Show output in primary package install section showing your selection, or nothing if you haven't run it.
Added option to return to the main menu in client/server section, since it now doesn't matter.

In other words, I changed this to being an opt in only question.

Since I'm one of the few people who will probably use this, or who actually understands why it's desirable to have, it's best to just leave as an option to be manually set, rather than have it be automatically set for everyone.

Good idea!

[Crust]

h2,

virtualbox 2.1.0 is now available.

Links:

Debian 5.0 ("Lenny")

i386

[link]

AMD64

[link]

Debian 4.0 ("Etch")

i386

[link]

AMD64

[link]

Debian 3.1 ("Sarge") (just in case ;) )

i386

[link]

[techAdmin]

2.1.0 is now in svmi, thanks.

[Crust]

Thank you.

[techAdmin]

widux, that is in now in smxi, v: 8.8.0: nfs, samba, and apache/mysql/php install. Light configuration on the apache stuff if you pick the 'full' option.

[aus9]

Hi Techadmin

I am on beta closed Nvidia drivers as we speak.
[link]

In the sidux smxi forum you were commenting on kernel remover issues and then mentioned graphics cards.

1) I am happy with the current k remover so can offer no requests there.

2) You may like to consider ....

a warning for those like me with old cards...that the appropiate driver is the beta?

It may assist others...not running frequent k updates....to have a tiny little bit more text to explain that the k changing to 2.6.28 no longer supports certain older drivers?


Not being a programmer, I know its trivial to allow a search of

find /usr/src/ -name NVIDIA*

but not so good at knowing how to automate a backup name change if multiple files exist.

Altho I have not tested it....the script for nvidia option 5....grabs the file already in /usr/src/.....then fails if you are running k 2.6.28...then I think exits the script.

3) Naturally I can recover from any failed beta driver test....but I realise you may have some reservations about the options in that part of the script.

Any failure will kick the user back to console mode. So maybe a warning to just run smxi again....and pick the more conservative....non-accelerated driver might suffice?

I am sure there are better posts on this change?
[link]

[link]

(I could not find a k 2.6.28 post at the forum...as yet...must be my eyes again)

< Edited by aus9 :: Dec 30, 08, 16:56 >