| Author |
Message |
|
|
Post subject: smxi
 Posted: Jul 24, 2007 - 09:28 AM
|
|
Joined: Jul 24, 2007
Posts: 5
Status: Offline
|
|
I'd like to discuss an idea I had recently when I installed the new kernel with smxi.
I think it would be possible to add an entry in grub called "sidux maintenance" which automatically starts smxi, and - after kernel install - automatically skips the kernel install question (smxi -kr option). Maybe the new grub entry could be the default after a new kernel has been installed before reboot.
Any opinions on this?
As I'm new in the forum I also want to take the oppurtunity to say a big THANK YOU to the sidux team! Keep up the good work! |
|
|
| |
|
|
|
 |
|
|
|
Post subject: RE: smxi
Posted: Jul 24, 2007 - 11:04 AM
|
|
Team Member
Joined: Nov 27, 2006
Posts: 1962
Location: underworld
Status: Offline
|
|
| Typing smxi in tty or tty in live cd will start smxi, no need for a grub entry |
_________________
.... _
... (0)>
... / / \
.. / / . )
.. V_/_sidux powered
|
| |
|
|
|
|
|
|
|
Post subject: RE: smxi
Posted: Jul 24, 2007 - 01:20 PM
|
|
Joined: Dec 02, 2006
Posts: 1046
Location: East Coast
Status: Offline
|
|
Firstly, welcome to sidux 
So the point of this idea is to run smxi everytime you boot the computer?.
I see a problem there: If you use this option as default, then you will never boot into X (init 5, since smxi runs only in init 3). Nor even giving you a login so you can check the forum and irc for any upgrade alert. Yes, the script offers you some warnings, but those warnings aren't updated 24/7. they're updated as soon as h2 learns about them and have time to post them. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 24, 2007 - 01:42 PM
|
|
Joined: Feb 22, 2007
Posts: 477
Location: The Netherlands
Status: Offline
|
|
Somehow I don't think the OP's idea is being conveyed here.
As for the option in grub, it isn't that hard to implement but it really isn't needed. If one wants to enter runlevel 3, all one needs to do is type a 3 before hitting enter. Then log in as root and run smxi.
Putting an entry into grub that would boot into runlevel 3 by default is of course possible, but one would still need to log in as root in order to run smxi. To automate this would just ask for trouble.
my $.02 |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 24, 2007 - 02:05 PM
|
|
Joined: Mar 23, 2007
Posts: 67
Status: Offline
|
|
I understand what he's saying. Something like.....
1. Choose boot menu item, "sidux Maintenence"
2. System boots to init 3 with login prompt
3. Login as root
4. smxi runs automatically
5. Do your maintenance
6. Quit or reboot
I'm sure some may not see the necessity of something like this while others may see it as adding some polish to the distro.
I have no preference but sounds interesting. The grub entry could contain a bootcode 'smxi' to manage this.
Harp, never hurts to throw ideas out there! Welcome to sidux.
Chris |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 24, 2007 - 06:47 PM
|
|
Joined: Jul 24, 2007
Posts: 5
Status: Offline
|
|
|
clivesay wrote:
I understand what he's saying. Something like.....
1. Choose boot menu item, "sidux Maintenence"
2. System boots to init 3 with login prompt
3. Login as root
4. smxi runs automatically
5. Do your maintenance
6. Quit or reboot
Thanks Chris and all others who replied to my post!
I was really just thinking about making the update process a little bit more comfortable. Of course, I know that i could always init 3 and start the script by myself after logging on as root.
Indeed, the process described by Chris is what I was after. There should NOT be an automatic update every time I boot, NEITHER should "sidux maintainence" be the default boot option. Sorry, if my post caused some confusion.
I have some reasons, why I think having such an entry is not bad
1) New users who do not already know about the smxi script could be guided to this preferred update procedure if they stuble over it in the boot menu.
2) the smxi script could be changed that the maintenance entry is selected automatically ONLY ONCE after a new kernel has been installed and the smxi script runs again automatically (this time with the -kr option) for the rest of the upgrade process (at least for users of NVIDIA/ATI drivers this is a must). After that the previous default boot configuration should be selected again.
3) One could go out of the room to get another cup of coffee while the machine is rebooting after kernel install. When I come back I would just have to log in and the update continues. Now when I do this I have to wait to type the "3" into the boot prompt.
4) For new users it's simpler to find their way if the forgot the name of the update script.
5) The name could be changed as often as necessary ( sorry, couldn't resist, but really don't want to offend anybody. For me it's absolutely no problem if things change).
clivesay wrote:
I'm sure some may not see the necessity of something like this while others may see it as adding some polish to the distro.
I agree that it is not really necessary. Neverthelss I think it's a "nice to have" feature.
Thanks again to everyone participating in the discussion & to the sidux team for this great distro.
Kind regards,
harp |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 24, 2007 - 06:56 PM
|
|
Joined: Nov 28, 2006
Posts: 4303
Status: Offline
|
|
I'm a fan of user choice, users who want to use this can, and users who don't want to don't have to. I've always tried to keep ALL operations that smxi does such that if you stopped using it one day, or start another, the system will not be altered in any way. Adding in some option like this would alter the system.
I've further felt that although I've reduced the amount of stuff users need to type to basically: smxi + y,n, [0-9] + enter, it is not at all unreasonable to expect or ask users to type in a few letters then hit enter. I tried to make it 2 letters, but that didn't work out, so now they have to type in 4 letters then hit enter.
Really, that's enough. Users who feel it's unreasonable to have to type in 4 letters plus enter are honestly just not users I'm all that interested in supporting, there are other distros and updating systems that cater to them nicely, ubuntu, debian stable running one of its update gui things that alerts you when updates are ready, etc. For users who want that type of experience, I honestly recommend they use that type of distro, not to be mean, but just because I think it will work out better for them long run.
Users should know what they are doing and why at least to some degree, not just proceed blindly, that's how you learn, and it's what I like about sidux, it attracts those types of users, consistently, and those users are what makes the community that drives sidux worth spending time on.
Paying some attention to your system etc isn't that much to ask I think, and fits in well with what I see as the overall sidux philosophy.
And besides, smxi is even in the manual now, with its own little factoid page, so it's not hard to find information about it at all. I think it's important for users to start to get familiar with the tools that make these *nix based free desktops so powerful, and those tools often are best learned via the command line, at some level or other. I've tried to drop the low end of the learning curve as far down as I can, but I think it's not good to get rid of it altogether, that doesn't help users in my opinion. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 24, 2007 - 09:17 PM
|
|
Joined: Jul 24, 2007
Posts: 5
Status: Offline
|
|
|
Quote:
I'm a fan of user choice, users who want to use this can, and users who don't want to don't have to. I've always tried to keep ALL operations that smxi does such that if you stopped using it one day, or start another, the system will not be altered in any way. Adding in some option like this would alter the system.
First of all: I'm also a fan of user choice - that's why I use Linux. 
I totally agree. Your solution causes as few changes to the system as possible.
IMHO, this is not what choice is all about. If I decided to use Postgre instead of MySql for example, I uninstall the one package and install the other. Surely, this might affect certain directories and configuration files, but that's OK if I change minds.
I agree that it is not preferable to attract users who are unable to type a few letters on the command line. I hope I didn't cause the impression that I'm such a kind of user.
I also agree that learning how the system works is an important and rewarding activity, BUT if this means that automating things is evil I would have to disagree. To be honest, I'm not sure what I could learn from waiting for reboot and typing 3 into the bootprompt after I have done so a lot of times in the past. If I do the same thing a lot of times I generally seek to automate it. That was the idea behind my proposal.
Besides, I had the impression (and I'm still convinced) that you tried to make smxi as user-friendly as you could - that's why I started the discussion to share the idea.
I didn't want to annoy anybody. It would have been enough if you said it doesn't match the sidux philosophy or that it is just too much work. That's no problem at all. Everybody can understand it. You don't have to convince me that it's unnecessary, neither do I want to convince you that it's absolutely necessary. It was an idea from a guy who is into usability and that's it. I guess we all can imagine how much time you spend on automating the update process for us and we appreciate it very much.
So don't bother anymore and let's stop the discussion on this topic at this point. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 24, 2007 - 11:58 PM
|
|
Joined: Nov 28, 2006
Posts: 4303
Status: Offline
|
|
Believe me, I've thought about ways to trigger various things on reboot from kernel install, but nothing I can think of is what I would consider safe enough for sidux standards. The problem when smxi makes the system do something outside of itself, changing the system that is, even if for only one boot, that change is then out of smxi control. If someone could show a clean, fool proof way of forcing a single reboot that would a: start in init 3 and b: then run smxi for user, I'd look at it, as long as it wasn't intrusive or was rejected as unsafe or debian improper by core devs, but they would always have final word for a question like that.
Having an autostart option is not something however that interests me, but an auto start after kernel install would be cool, the problem is however that I believe it's simply not possible. If it is, I'd be interested to hear what it is.
I guess smxi is pretty successful if it somehow gives the impression that things aren't automated, there's about 8-10k lines in it and sgfxi, give or take, that do nothing but automate things.
The question is rather what the limit of such automation should be. The further you push it, the harder it is to write, and the more code it takes, and, sadly, the less flexible, and the more error prone, I think it becomes for something like this stuff.
Personally, I like the way it is now, there's not much externally that bugs me about it, although internally the code is pretty annoying in some areas. logging, error handling, and so on, all areas that sgfxi does significantly better, so if anything major changes or is tweaked, it's going to be those areas probably, which will require a full redo of the script, although luckily not a rewrite, it's fixable.
Yes, I try to make smxi as user friendly as possible, but under one condition, the user is expected to begin to learn some things like getting to console and starting a script in console, then reading the stuff the script says, then, ideally, getting interested in what it does, to learn it. I comment the script at times internally for users to make this fairly obvious too, by the way, especially for stuff that might otherwise not make sense. Never designed to be a no brainer, just brain friendly, so to speak.
You're not being annoying, don't worry. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 25, 2007 - 09:18 AM
|
|
Joined: Jan 10, 2007
Posts: 765
Status: Offline
|
|
|
Quote:
Having an autostart option is not something however that interests me, but an auto start after kernel install would be cool, the problem is however that I believe it's simply not possible. If it is, I'd be interested to hear what it is.
It should be possible. The script "just" have to temporarily change both the menu.lst(for init 3 by default and with almost no selection time) and the bashrc(to start smxi after login).
It is also possible to chance the bashrc permanently. Then, it searches in the boot-line for a smxi-Cheatcode, and if it exists, smxi will start. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 25, 2007 - 02:05 PM
|
|
Joined: Dec 19, 2006
Posts: 1030
Status: Offline
|
|
| That proposal sounds dangerous. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 25, 2007 - 02:24 PM
|
|
Joined: Jan 10, 2007
Posts: 765
Status: Offline
|
|
Yes, it could be a bit critical(in worst case problems could be fixed with the live-cd), but that was not h2's question, he just asked if it might be possible 
But i guess it won't be more dangerous than the modification of menu.lst after smxi kernel install, or am I wrong? |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 25, 2007 - 06:24 PM
|
|
Joined: Nov 25, 2006
Posts: 2571
Status: Offline
|
|
| Everything is possible, that doesn't mean it's sane though. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 25, 2007 - 06:27 PM
|
|
Joined: Dec 02, 2006
Posts: 1909
Status: Offline
|
|
slh's answer is as succinct as it can be 
you must be crazy to try it |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jul 25, 2007 - 07:19 PM
|
|
Joined: Nov 28, 2006
Posts: 4303
Status: Offline
|
|
|
Quote:
That proposal sounds dangerous.
...
Everything is possible, that doesn't mean it's sane though.
this has also been my intuition without actually knowing if this is the case or not, and that's why I said I would go by whatever core guys like kelmo or slh said, and they have said it, so that's the end of that question.
I also felt that it would probably be unsafe/unwise/unsane to try to do that, which is why I didn't give it much further thought, and I'm glad to see that it is in fact so. So that answers that question, and we can now go back to making things work better in the ways that they should actually work. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
