- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Linus fires latest shot in GNOME Wars
|
|
|
Comments (74)
54 earlier comments in the full thread.
> my google-fu is powerful.
We bow before your magnificence, oh wise one. :)
Link marked for future reference.
We bow before your magnificence, oh wise one. :)
Link marked for future reference.
TC -
Upstart is interesting, but I don't see anything about running on different "runlevels".
For most people this won't make a difference, but I know it's saved my bacon more than once.
Edited: There is a small blurb in the ReplacementInit wiki about preserving the compatibility with the sysvinit so that "init 3" will supposedly work like before. I'm not using Edgy Eft, so I'll defer to others about whether or not this holds true.
Upstart is interesting, but I don't see anything about running on different "runlevels".
For most people this won't make a difference, but I know it's saved my bacon more than once.
Edited: There is a small blurb in the ReplacementInit wiki about preserving the compatibility with the sysvinit so that "init 3" will supposedly work like before. I'm not using Edgy Eft, so I'll defer to others about whether or not this holds true.
DarrenR114-
>set your runlevel to "3" instead of the default "5"
Yes, that is what I do, in RH-based dists. For any lurkers that aren't following, the file is /etc/inittab and the line is "id:x:initdefault:" where x may be 0-6. All newbies should set x to 6.
Wait, ignore that last bit.
The Ubuntu conversation is interesting: In Debian only "2" is a legit runlevel to use the system, last I read. The (extremely elegant) 3/5 trick does not work in Debian-based dists' I'm told, unless those dists have diverged from The Path.
Bob_Robertson- >Ah. You missunderstand. The consoles tty1-6 are already running.
OK, I'm just weird: I spend way too much time watching ps, top, tcpdump, iostat, etc. Maybe it has to do with my job.
Oh wait, it all has to do with jobs. :-)
Compare a Debian Sid system in GUI (the one I'm using now):
ps ax|wc -l 152
And another Debian Sid system launched with no DM, logged in to a text mode console:
ps ax|wc -l 125
This is the thing: Those 27 other processes represent what I don't want or need in non-GUI mode: Processes that are supporting multimedia, and polling removable devices, processes that are busily rendering and updating a graphical desktop that I'm not looking at, etc, etc. Most importantly, processes that can cause resource conflicts that I don't need.
The exercise is "headache reduction" or KISS. MS Windows, X, KDE, GNOME, etc. are the greatest KISS violators I know.
It is also a form of perfectionism that I get to indulge myself personally far more than professionally.
Yes, that is what I do, in RH-based dists. For any lurkers that aren't following, the file is /etc/inittab and the line is "id:x:initdefault:" where x may be 0-6. All newbies should set x to 6.
Wait, ignore that last bit.
The Ubuntu conversation is interesting: In Debian only "2" is a legit runlevel to use the system, last I read. The (extremely elegant) 3/5 trick does not work in Debian-based dists' I'm told, unless those dists have diverged from The Path.
Bob_Robertson- >Ah. You missunderstand. The consoles tty1-6 are already running.
OK, I'm just weird: I spend way too much time watching ps, top, tcpdump, iostat, etc. Maybe it has to do with my job.
Oh wait, it all has to do with jobs. :-)
Compare a Debian Sid system in GUI (the one I'm using now):
ps ax|wc -l 152
And another Debian Sid system launched with no DM, logged in to a text mode console:
ps ax|wc -l 125
This is the thing: Those 27 other processes represent what I don't want or need in non-GUI mode: Processes that are supporting multimedia, and polling removable devices, processes that are busily rendering and updating a graphical desktop that I'm not looking at, etc, etc. Most importantly, processes that can cause resource conflicts that I don't need.
The exercise is "headache reduction" or KISS. MS Windows, X, KDE, GNOME, etc. are the greatest KISS violators I know.
It is also a form of perfectionism that I get to indulge myself personally far more than professionally.
Can't fault your choice in distributions. Hmmm... Both up-to-date Debian Sid:
server$ ps ax|wc -l 45
laptop$ ps ax|wc -l 109
Golly, you're running a LOT of stuff I'm not running. That laptop number is what I'm doing right now, with KDE in full bloom, 6 tabs in Konsole, 4 tabs in Konqueror, stuff in the system tray, HPLIP, Kmail, xpdf, hald and logged in with BitTornado running on the server too.
You do know that if you're not logged in to the GUI, those processes... "that are supporting multimedia, and polling removable devices, processes that are busily rendering and updating a graphical desktop that I'm not looking at, etc, etc..." are not running. Even hald, the removable hardware detection daemon, is running so low that they all show 0.0 on my ps aux right now.
But then, I also had Win95 down to two running processes, one of which was "explorer", and it was very reliable and fast.
You and I are doing very different things with our systems, obviously. It would be interesting to know how you, with your drive for simplicity, and I with little to no effort in that direction, still end up with such different numbers of processes running. Hmm...
server$ ps ax|wc -l 45
laptop$ ps ax|wc -l 109
Golly, you're running a LOT of stuff I'm not running. That laptop number is what I'm doing right now, with KDE in full bloom, 6 tabs in Konsole, 4 tabs in Konqueror, stuff in the system tray, HPLIP, Kmail, xpdf, hald and logged in with BitTornado running on the server too.
You do know that if you're not logged in to the GUI, those processes... "that are supporting multimedia, and polling removable devices, processes that are busily rendering and updating a graphical desktop that I'm not looking at, etc, etc..." are not running. Even hald, the removable hardware detection daemon, is running so low that they all show 0.0 on my ps aux right now.
But then, I also had Win95 down to two running processes, one of which was "explorer", and it was very reliable and fast.
You and I are doing very different things with our systems, obviously. It would be interesting to know how you, with your drive for simplicity, and I with little to no effort in that direction, still end up with such different numbers of processes running. Hmm...
> hald, the removable hardware detection daemon, is running so low that they all show 0.0 on my ps aux right now.
Lol, hal is an abortion anyway. I've just removed it.
Lol, hal is an abortion anyway. I've just removed it.
Runlevels 2-5 are meant to be user-configurable. Different distributions use them differently. Red Hat has one way, Debian another, and Slackware yet another. Don't touch 0,1, or 6 unless you really really REALLY know what you're doing.
Debian defaults to runlevel 2, which is either a console or X windows depending on what you selected during installation.
(shameless plug, my excellent Linux Cookbook tells all about these things.)
The init command still works on Edgy Eft. So far Upchuck has only replaced /etc/inittab.
Debian defaults to runlevel 2, which is either a console or X windows depending on what you selected during installation.
(shameless plug, my excellent Linux Cookbook tells all about these things.)
The init command still works on Edgy Eft. So far Upchuck has only replaced /etc/inittab.
>You and I are doing very different things with our systems, obviously. It would be interesting to know how you, with your drive for simplicity, and I with little to no effort in that direction, still end up with such different numbers of processes running. Hmm...
Point conceded.
Point conceded.
I think hald has some dependencies that cause trouble. I like putting in a CD and having a "open in new window?" option come up. I think it's an improvement for a single-user system like this laptop. Unless that's not hald, which I guess I'll find out some day. It's not in the way.
My desktop install has consisted of "throw everything on that KDE has", then add more stuff as needed. :^) Hald came with it, so there it is. Debian's dependency resolution works quite well for such "kill them all and let God sort them out" kinds of installs. But I do _NOT_ like "tasksel". If tasksel had a "full KDE desktop" or "full GNOME desktop" option, I might use it, but it doesn't.
However, I did find out over the weekend that my problems with the hp-toolbox in hplip was because hplip and hpoj _conflict_. Oh sure, it prints just fine, but xsane comes up with two different entries at the same time for the same printer, one from hplip and the other from hpoj.
So, since the hp-toolbox is in hplip package, I purged the other and now scanning works better. Silly. But it does demonstrate that I'm not making much of an effort to minimize the system overheard on this wondervaio.
My desktop install has consisted of "throw everything on that KDE has", then add more stuff as needed. :^) Hald came with it, so there it is. Debian's dependency resolution works quite well for such "kill them all and let God sort them out" kinds of installs. But I do _NOT_ like "tasksel". If tasksel had a "full KDE desktop" or "full GNOME desktop" option, I might use it, but it doesn't.
However, I did find out over the weekend that my problems with the hp-toolbox in hplip was because hplip and hpoj _conflict_. Oh sure, it prints just fine, but xsane comes up with two different entries at the same time for the same printer, one from hplip and the other from hpoj.
So, since the hp-toolbox is in hplip package, I purged the other and now scanning works better. Silly. But it does demonstrate that I'm not making much of an effort to minimize the system overheard on this wondervaio.
Counting processes isn't the best manner to detect bloat.
For example, Firefox opens 9 procs, but Konqueror opens 5, both do about the same.
SVChost at a WinXP is a proc-container, which may contain subprocesses (It took me more than five year to find out, but anyway). It may contain 18 virusus/malware processes, but only between one to four svchosts appear in the process list. No, Linux isn't Windows, but it just doesn't mean that much.
BTW my box only runs 60 procs (ps|wc) in GUI mode, of which 8 are Firefox. Not bad, eh? Usability on the other hand is a whole different story.
BTW my box only runs 60 procs (ps|wc) in GUI mode, of which 8 are Firefox. Not bad, eh? Usability on the other hand is a whole different story.
> I think hald has some dependencies that cause trouble. I like putting in a CD and having a "open in new window?" option come up. I think it's an improvement for a single-user system like this laptop. Unless that's not hald, which I guess I'll find out some day. It's not in the way.
My bitch with hal is that it pretty much eliminates a standard mount of removable media, and, between hal and udev defalts all the removable media to 'system://dev/virtual file' or some such garbage. Although n00bs are probably gonna love it, that's just unacceptable to me.
My bitch with hal is that it pretty much eliminates a standard mount of removable media, and, between hal and udev defalts all the removable media to 'system://dev/virtual file' or some such garbage. Although n00bs are probably gonna love it, that's just unacceptable to me.
"Although n00bs are probably gonna love it, that's just unacceptable to me."
Yeah, there's a decades-long-standard /mnt directory for a reason.
Yeah, there's a decades-long-standard /mnt directory for a reason.
The issue with hal as installed on pretty much all systems is that it mounts USB sticks without sync,dirsync options. The 'standard way' of using a USB stick is to copy files to it, and pull it out as soon as the copy completes, no unmounting required, as people do in Windows. Net result is people using Linux often corrupt their USB sticks. They really should be mounted sync,dirsync unless specifically configured otherwise by the user (an experienced user might trade off having to manually unmount with faster access times).
> They really should be mounted sync,dirsync
They are here :)
They are here :)
" sync,dirsync" is a great ticket to open. I couldn't agree more. What's the command to tell? Since it's not in fstab, I don't know how to find it.
Since my USB mount/unmount experience goes way back before hal, I am always paranoid about unmounting the USB before removing it. Making entries in /etc/fstab by hand has given me some good habits.
The memory card reader that I have has two LEDs, one of which actually shows the mount status. When I umount the card, or more usually use the KDE "safely remove" option on the card's desktop icon, it will go out. _Very_ nice to have that visual confirmation. It also blinks while reading/writing, so I can watch its progress.
Almost as lazy as a Windows user! Oh Dear!
Since my USB mount/unmount experience goes way back before hal, I am always paranoid about unmounting the USB before removing it. Making entries in /etc/fstab by hand has given me some good habits.
The memory card reader that I have has two LEDs, one of which actually shows the mount status. When I umount the card, or more usually use the KDE "safely remove" option on the card's desktop icon, it will go out. _Very_ nice to have that visual confirmation. It also blinks while reading/writing, so I can watch its progress.
Almost as lazy as a Windows user! Oh Dear!
>What's the command to tell?
I think it is a reference to mount. man mount -> Options -> -o -> sync, dirsync. States
sync All I/O to the file system should be done synchronously.
dirsync All directory updates within the file system should be done synchronously. This affects the following system calls: creat, link, unlink, symlink, mkdir, rmdir, mknod and rename.
man mount -> Options states
Options are specified with a -o flag followed by a comma sepa- rated string of options. Some of these options are only useful when they appear in the /etc/fstab file. The following options apply to any file system that is being mounted (but not every file system actually honors them - e.g., the sync option today has effect only for ext2, ext3 and ufs)
So these should be available to specify in /etc/fstab as I read it.
I think it is a reference to mount. man mount -> Options -> -o -> sync, dirsync. States
sync All I/O to the file system should be done synchronously.
dirsync All directory updates within the file system should be done synchronously. This affects the following system calls: creat, link, unlink, symlink, mkdir, rmdir, mknod and rename.
man mount -> Options states
Options are specified with a -o flag followed by a comma sepa- rated string of options. Some of these options are only useful when they appear in the /etc/fstab file. The following options apply to any file system that is being mounted (but not every file system actually honors them - e.g., the sync option today has effect only for ext2, ext3 and ufs)
So these should be available to specify in /etc/fstab as I read it.
This is pretty good for understanding fstab : http://www.humbug.org.au/talks/fstab/fstab.html
Also, 'lshw' is a wonderful utility for finding the device names for usb and other devices to add to your fstab.
Also, 'lshw' is a wonderful utility for finding the device names for usb and other devices to add to your fstab.
Quoting:The 'standard way' of using a USB stick is to copy files to it, and pull it out as soon as the copy completes,
My boss was a bit surprised when I explained to him why his files sometimes disappeared from his USB stick after copying them on it...
Why put it in fstab when you can use AutoFS?
AutoFS is especially great when you combine it with udev-rulewriting, but anyway, here my AutoFS misc file:
dvdr -fstype=iso9660,ro :/dev/hda dvd -fstype=iso9660,ro :/dev/hdb mp3 -fstype=vfat,rw,noauto,gid=10,uid=100,users :/dev/sdc1
This makes directories on the fly (note my non-root user owns all files on the mp3-usb-stick), and especially, AutoFS has a command to automatically unmount not used filesystems:
alias rem="sudo /usr/bin/killall -USR1 automount"
Here's the sudo line which makes sure my 'rem' commando doesn't ask for a password, because of sudo:
Cmnd_Alias AUTOMNT= /usr/bin/killall -USR1 automount kwint ALL = NOPASSWD: AUTOMNT
So, if I think the transfer is done, or I don't need my DVD mounted anymore, I just type 'rem', and then mount -l to check.
dvdr -fstype=iso9660,ro :/dev/hda dvd -fstype=iso9660,ro :/dev/hdb mp3 -fstype=vfat,rw,noauto,gid=10,uid=100,users :/dev/sdc1
This makes directories on the fly (note my non-root user owns all files on the mp3-usb-stick), and especially, AutoFS has a command to automatically unmount not used filesystems:
alias rem="sudo /usr/bin/killall -USR1 automount"
Here's the sudo line which makes sure my 'rem' commando doesn't ask for a password, because of sudo:
Cmnd_Alias AUTOMNT= /usr/bin/killall -USR1 automount kwint ALL = NOPASSWD: AUTOMNT
So, if I think the transfer is done, or I don't need my DVD mounted anymore, I just type 'rem', and then mount -l to check.
> Why put it in fstab when you can use AutoFS?
Cause some of us prefer fstab mounting...
Cause some of us prefer fstab mounting...
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
Where they messed up, as they always do, was not drawing more attention to the change, like putting a placeholder in /etc/inittab with a bit of information. Ubuntu is absolutely the worst distribution for documenting changes. They have release notes on ubuntu.com, but just try to find the damned things. I guess all the hype links don't leave room for useful stuff. Fortunately, my google-fu is powerful: http://www.ubuntu.com/download/releasenotes/610