Recent RH kernels do in fact create a new initrd and add a new kernel config to the appropriate boot loader. lilo isn't rerun, AFAIK, but then, running lilo with a bad config is a good way to break a machine.
Linux is an interesting contradiction. On the one hand, the GNU philosophy is that everything should be extended and made easier to use, unlike the purist, spartan BSD tools; on the other hand, we put up with crap like lilo for years and years. FreeBSD's boot system kicks ass all over lilo-who-can't-read-fstab-and-figure-out-what-to-d o.
Linux-2.4 has been managed poorly, but if you care about stability, you should have been running a distro kernel anyway. What kind of stability do you *expect* from kernels that are released every few weeks, with little testing? Normal users should consider "stable" -linus kernels the bleeding edge, despite what the version number says! If you need your server to be regression-tested, you really should be running a RedHat/SuSE/etc. kernel. At least RedHat runs formal regression tests on their kernels before releasing them, which I can't say for Linus.
ext3 doesn't journal everything by default. Rather, it makes the guarantee that data will reach the disk before metadata, which for most applications is Good Enough(tm) to guarantee data integrity after a crash.
If this machine is often powered off improperly, I would install ext3 on it rather than xfs. xfs has quite a few advantages over ext3, but "not losing data after hitting reset" is definitely not one of them.
Basically, in ext3-speak, there are two kinds of metadata journaling. Writeback mode, supported by all the linux jfses, will guarantee that your directory and file structure is consistent after a hard crash, but it doesn't make any guarantees re: file data. This level of protection is about the same as ext2 + a really fast fsck on boot -- so you might see files with blocks from other files in reiserfs, for example. However, xfs is worse than that -- with its delayed allocation feature, you'll see entire files zeroed out after a crash. (See their mailing list archives for details.)
ext3 supports this mode too, but the default is ordered mode, which forces stricter ordering on data writes. Data always goes to disk before file metadata is updated, so you'll either see the "right" data after a crash or the old data -- but never damaged data.
AFAIK, ext3 is the only linux jfs with working ordered-mode support, though reiserfs apparently has patches in the works.
>The fsck on a softupdates volume is blazingly
>fast. To be sure, ext3 is a nice file system, but
>that doesn't mean all the other ones are crap.
Where did I say "all the other ones are crap?" I run both Linux and FreeBSD boxes, and they both have their strong and weak points. I do have a problem with FreeBSD zealots bashing Linux as a toy or newbie Unix when they're really the same damned thing.
>I don't know much about NAT (except that my
>coworker got it running without recompiling), but
>quotas are already in the shipping kernel.
Um, no. The -GENERIC kernel doesn't have IPFIREWALL, IPDIVERT or QUOTA enabled, which illustrates my point: the Red Hat philosophy is to give as much functionality as possible with their default setup, while FreeBSD would rather install a bare system and provide proper documentation. Just as another example, out of the box RH can mount UFS filesystems, while fbsd cannot mount ext2fs without a kernel recompile.
Both systems are pretty good in some ways and suck badly in others. It's just a matter of philosophy (and personal taste.)
Many of these points are pretty subjective, but I'll shoot down the obviously wrong ones:
>2. a robust filesystem and SOFTUPDATES
ext3 is just as robust, and doesn't require a fsck at all after a power cycle. Better yet, it protects metadata *and* data in the default (ordered) mode.
>3. linux binary compatibility
OpenOffice for Linux doesn't run, and native AbiWord in 4.4-release doesn't start. Koffice import filters for.doc don't seem to be working either. Whoops... no word processing!
>5. no rpm dependencies
up2date takes care of all that for in-distro packages.
>10. Nothing beats cvsup to update your src tree
Except maybe just doing a half-hour upgrade and getting back to work, rather than compiling all day...
If you're looking for a desktop and server that just runs out of the box, Linux is better than FreeBSD. Nautilus, f.e., doesn't even start in 4.4's GNOME distribution, and the latest Mozilla binaries lag behind. On the server side, you can't just install fbsd and use it as a NAT or enable quotas without recompiling the kernel. What a pain.
That's not to say that "works-out-of-the-box" is synonymous with "works poorly." I find that Linux and FreeBSD are pretty much equals these days for everything that matters, at least server-side -- FreeBSD just takes more work.
For one, Apple has a number of patents relating to the SVG standard. While not strictly necessary for implementation, these patents left the standard in a position where some OSS advocates were advocating forking the standard to route around the threat. It's good to see Apple make it clear which Web they want, and that that future is the more inclusive one.
[SVG is a vector image format used by Nautilus, and probably a number of other applications I'm not aware of.]
For a long time, Watcom was the best commercial compiler for writing 32-bit DOS games. It had a superb (if occasionally buggy) optimizer, a freely-redistributable 32-bit DOS Extender, and it had an excellent toolset -- Watcom's profiler, debugger and disassembler blew Borland and Microsoft's weak DOS tools (heh... toys) out of the water.
(Non-x86 readers: a DOS Extender is basically a hack of an operating system running on top of DOS to allow 32-bit DOS programs access to 16-bit DOS and BIOS services, such as file I/O, video setup, etc.)
Anyway, the alternative compilers just didn't compare. Borland took years to finally ship a 32-bit compiler, and with Microsoft's offerings you could either write 16-bit DOS/Windows code or 32-bit Windows code. (There was a way to run Microsoft 32-bit executables on DOS, but you needed to buy PharLap's expensive runtime and libraries, which had the added bonus of requiring per-copy royalties.)
Watcom wasn't especially well-known until id shipped DOOM, but after that, pretty much every game-programming book used wcc386 as the reference compiler. Watcom filled a pretty big niche that was largely ignored by the big compiler vendors. Their toolset was excellent for writing games, and at $199, it was a steal.
DJGPP (GCC for DOS) didn't have nearly as good a debugger or profiler as Watcom, but GCC was the superior (less buggy, more standards-compliant) compiler. DJGPP also had the better libc (memory allocation was *much* faster than under Watcom's DOS Extender, for instance.) id went with DJGPP for their DOS port of Quake I, and suddenly everyone noticed that DJGPP was a useful compiler. Next, id will fly off a cliff...
In summary, these compilers were a big deal at the time because they filled needs that were pretty much completely ignored by the big vendors: namely, the need for 32-bit code under DOS, and the need for royalty-free distribution.
KDE vs. GNOME. Microsoft vs. Linux vs. FreeBSD. The nebulous "big-hairy-anti-civil-rights-entity" versus the "red-blooded-programmer." These are the pointless battles waged by the world's geeks. Our lives are so boring in front of our computers that we need to act like these things have thoughts and feelings and motives... it's all a pretty daft soap opera, if you ask me, and we all really need to get out more. Who's with me?
Well said, except for the RedHat bashing. It's fashionable to say such things on slashdot, but isn't it a little silly? Not really any better than bashing Microsoft, IMO...
RedHat's Xconfigurator works flawlessly on all the supported hardware I've tried. It does hardware detection and it even sets up the mouse wheel if you choose the right mouse type. Best of all, it does all this in a simple ncurses interface.
As for alpha-blended mouse cursors, Xrender will make those and more possible in the future.
You can modify and freely redistribute RPM, apt, linuxconf, and others under the GPL. You cannot do this with YaST -- this is why there are no SuSE-based distros.
Of course, "better journaling filesystem" isn't as simple as who uses trees and tails and whatnot. Maturity of tools is more practical than buzzword compliance, and at this point reiserfsck can't touch e2fsck. This is probably as big as reason as any for RedHat going ext3 over reiserfs.
That, and the fact that ext3 is more stable now than reiserfs was when SuSE shipped it to its guinea p^W^Wusers... this is why I no longer use that particular distro.
Furthermore, the popular alternative being pushed by rabid SuSE fans still doesn't have a working fsck. ("It's being worked on," says Hans invariably when asked about it.) It's amazing how anti-RedHat sentiment blinds people to obvious flaws in their own preferred technology.
If I were RedHat, I'd have done the same thing. If reiserfs screws up or is corrupted by a hardware problem, that's the end of the game -- time to mkreiserfs and restore from backup.
The IDE driver on Linux may block interrupts for long periods of time, especially if you're not running in DMA mode. If you're doing something swap-intensive like opening Mozilla, your audio app won't be scheduled until the disk driver is done spinning, and it will skip.
Things are alot better with DMA enabled, but latency can still be bad. There are lots of other areas in the kernel that can do bad things to scheduling, but IDE and vesafb are by far the worst, IMO.
Docs... hm. Do a search for 'enabling DMA' or something similar. Or do 'man hdparm.'
The article said something about Linux performing much better after hand-tuning the VM, which begs the question, seeing as how FreeBSD tunes its own VM for good default settings, why can't Linux do the same? This is just like the IDE DMA situation on BSD vs. Linux -- FreeBSD has had autodma working forever on VIA chipsets, and Linux, even in 2.4, defaults to PIO mode on IDE disks unless you enable 'highly dangerous' code. Oddly, the I/O elevator in 2.2 has a sensible out-of-the-box setting, but 2.4 requires tuning with an arcane tool called 'elvtune' or something if you want an elevator at all. Seems like a step backwards to me, regardless of how technically superior the 2.4 way is.
Unix purists go on about how the kernel should never set policy, but that's rather silly. Really, the kernel-'enforced' policy is whatever the defaults are, as most users expect the default behavior to be intelligent. People install Linux all the time and complain about how they can't do anything without getting choppy audio and mouse movement, because IDE defaults to PIO. It's rather sad that people get bad impressions of Linux because of its braindead default settings for so many things, when it's capable of doing much more.
Maybe this is work for the distros to be doing, I don't know. I suspect most of them would prefer to pass the buck as well.
Raleigh, the default gtk theme in the RH 7.1 beta, looks quite nice. They've cleaned up the worst of the default widgets, and there was a rumor that this might become the default for the stable gtk series.
Slashdot Mirror
com1-com9 are the names of your serial ports.
Recent RH kernels do in fact create a new initrd and add a new kernel config to the appropriate boot loader. lilo isn't rerun, AFAIK, but then, running lilo with a bad config is a good way to break a machine.
d o.
Linux is an interesting contradiction. On the one hand, the GNU philosophy is that everything should be extended and made easier to use, unlike the purist, spartan BSD tools; on the other hand, we put up with crap like lilo for years and years. FreeBSD's boot system kicks ass all over lilo-who-can't-read-fstab-and-figure-out-what-to-
Linux-2.4 has been managed poorly, but if you care about stability, you should have been running a distro kernel anyway. What kind of stability do you *expect* from kernels that are released every few weeks, with little testing? Normal users should consider "stable" -linus kernels the bleeding edge, despite what the version number says! If you need your server to be regression-tested, you really should be running a RedHat/SuSE/etc. kernel. At least RedHat runs formal regression tests on their kernels before releasing them, which I can't say for Linus.
Red Hat now ships with grub as the default bootloader, which is smart enough to boot without rerunning the stub installer after every kernel upgrade.
blows up my FreeBSD 4.4 server pretty quickly (it panics and reboots.) Yes, I'm running softupdates.
...
Anyone gotten this to run on linux? After I fixed the (silly) division by zero error, it still dies with an mmap: Invalid argument error
ext3 doesn't journal everything by default. Rather, it makes the guarantee that data will reach the disk before metadata, which for most applications is Good Enough(tm) to guarantee data integrity after a crash.
If this machine is often powered off improperly, I would install ext3 on it rather than xfs. xfs has quite a few advantages over ext3, but "not losing data after hitting reset" is definitely not one of them.
Basically, in ext3-speak, there are two kinds of metadata journaling. Writeback mode, supported by all the linux jfses, will guarantee that your directory and file structure is consistent after a hard crash, but it doesn't make any guarantees re: file data. This level of protection is about the same as ext2 + a really fast fsck on boot -- so you might see files with blocks from other files in reiserfs, for example. However, xfs is worse than that -- with its delayed allocation feature, you'll see entire files zeroed out after a crash. (See their mailing list archives for details.)
ext3 supports this mode too, but the default is ordered mode, which forces stricter ordering on data writes. Data always goes to disk before file metadata is updated, so you'll either see the "right" data after a crash or the old data -- but never damaged data.
AFAIK, ext3 is the only linux jfs with working ordered-mode support, though reiserfs apparently has patches in the works.
>The fsck on a softupdates volume is blazingly
>fast. To be sure, ext3 is a nice file system, but
>that doesn't mean all the other ones are crap.
Where did I say "all the other ones are crap?" I run both Linux and FreeBSD boxes, and they both have their strong and weak points. I do have a problem with FreeBSD zealots bashing Linux as a toy or newbie Unix when they're really the same damned thing.
>I don't know much about NAT (except that my
>coworker got it running without recompiling), but
>quotas are already in the shipping kernel.
Um, no. The -GENERIC kernel doesn't have IPFIREWALL, IPDIVERT or QUOTA enabled, which illustrates my point: the Red Hat philosophy is to give as much functionality as possible with their default setup, while FreeBSD would rather install a bare system and provide proper documentation. Just as another example, out of the box RH can mount UFS filesystems, while fbsd cannot mount ext2fs without a kernel recompile.
Both systems are pretty good in some ways and suck badly in others. It's just a matter of philosophy (and personal taste.)
Many of these points are pretty subjective, but I'll shoot down the obviously wrong ones:
.doc don't seem to be working either. Whoops ... no word processing!
...
>2. a robust filesystem and SOFTUPDATES
ext3 is just as robust, and doesn't require a fsck at all after a power cycle. Better yet, it protects metadata *and* data in the default (ordered) mode.
>3. linux binary compatibility
OpenOffice for Linux doesn't run, and native AbiWord in 4.4-release doesn't start. Koffice import filters for
>5. no rpm dependencies
up2date takes care of all that for in-distro packages.
>10. Nothing beats cvsup to update your src tree
Except maybe just doing a half-hour upgrade and getting back to work, rather than compiling all day
If you're looking for a desktop and server that just runs out of the box, Linux is better than FreeBSD. Nautilus, f.e., doesn't even start in 4.4's GNOME distribution, and the latest Mozilla binaries lag behind. On the server side, you can't just install fbsd and use it as a NAT or enable quotas without recompiling the kernel. What a pain.
That's not to say that "works-out-of-the-box" is synonymous with "works poorly." I find that Linux and FreeBSD are pretty much equals these days for everything that matters, at least server-side -- FreeBSD just takes more work.
For one, Apple has a number of patents relating to the SVG standard. While not strictly necessary for implementation, these patents left the standard in a position where some OSS advocates were advocating forking the standard to route around the threat. It's good to see Apple make it clear which Web they want, and that that future is the more inclusive one.
[SVG is a vector image format used by Nautilus, and probably a number of other applications I'm not aware of.]
The Apple patent in question is arguably stupid, but it's not required to write a standard-compliant implementation of SVG 1.0.
For a long time, Watcom was the best commercial compiler for writing 32-bit DOS games. It had a superb (if occasionally buggy) optimizer, a freely-redistributable 32-bit DOS Extender, and it had an excellent toolset -- Watcom's profiler, debugger and disassembler blew Borland and Microsoft's weak DOS tools (heh ... toys) out of the water.
...
(Non-x86 readers: a DOS Extender is basically a hack of an operating system running on top of DOS to allow 32-bit DOS programs access to 16-bit DOS and BIOS services, such as file I/O, video setup, etc.)
Anyway, the alternative compilers just didn't compare. Borland took years to finally ship a 32-bit compiler, and with Microsoft's offerings you could either write 16-bit DOS/Windows code or 32-bit Windows code. (There was a way to run Microsoft 32-bit executables on DOS, but you needed to buy PharLap's expensive runtime and libraries, which had the added bonus of requiring per-copy royalties.)
Watcom wasn't especially well-known until id shipped DOOM, but after that, pretty much every game-programming book used wcc386 as the reference compiler. Watcom filled a pretty big niche that was largely ignored by the big compiler vendors. Their toolset was excellent for writing games, and at $199, it was a steal.
DJGPP (GCC for DOS) didn't have nearly as good a debugger or profiler as Watcom, but GCC was the superior (less buggy, more standards-compliant) compiler. DJGPP also had the better libc (memory allocation was *much* faster than under Watcom's DOS Extender, for instance.) id went with DJGPP for their DOS port of Quake I, and suddenly everyone noticed that DJGPP was a useful compiler. Next, id will fly off a cliff
In summary, these compilers were a big deal at the time because they filled needs that were pretty much completely ignored by the big vendors: namely, the need for 32-bit code under DOS, and the need for royalty-free distribution.
KDE vs. GNOME. Microsoft vs. Linux vs. FreeBSD. The nebulous "big-hairy-anti-civil-rights-entity" versus the "red-blooded-programmer." These are the pointless battles waged by the world's geeks. Our lives are so boring in front of our computers that we need to act like these things have thoughts and feelings and motives ... it's all a pretty daft soap opera, if you ask me, and we all really need to get out more. Who's with me?
Well said, except for the RedHat bashing. It's fashionable to say such things on slashdot, but isn't it a little silly? Not really any better than bashing Microsoft, IMO ...
"quiet time between 2.4.0 and 2.5.0?" Linux 2.4 has hardly been a "stable" kernel, in the sense that 2.2 and 2.0 were ...
RedHat's Xconfigurator works flawlessly on all the supported hardware I've tried. It does hardware detection and it even sets up the mouse wheel if you choose the right mouse type. Best of all, it does all this in a simple ncurses interface.
As for alpha-blended mouse cursors, Xrender will make those and more possible in the future.
You can modify and freely redistribute RPM, apt, linuxconf, and others under the GPL. You cannot do this with YaST -- this is why there are no SuSE-based distros.
Linux 2.4 has no such file size restriction. ext2 on 2.4 supports large files just as well as reiserfs and all the rest.
Of course, "better journaling filesystem" isn't as simple as who uses trees and tails and whatnot. Maturity of tools is more practical than buzzword compliance, and at this point reiserfsck can't touch e2fsck. This is probably as big as reason as any for RedHat going ext3 over reiserfs. ... this is why I no longer use that particular distro.
That, and the fact that ext3 is more stable now than reiserfs was when SuSE shipped it to its guinea p^W^Wusers
Furthermore, the popular alternative being pushed by rabid SuSE fans still doesn't have a working fsck. ("It's being worked on," says Hans invariably when asked about it.) It's amazing how anti-RedHat sentiment blinds people to obvious flaws in their own preferred technology.
If I were RedHat, I'd have done the same thing. If reiserfs screws up or is corrupted by a hardware problem, that's the end of the game -- time to mkreiserfs and restore from backup.
file(1) looks at the contents of the file to determine what type of file it is.
The IDE driver on Linux may block interrupts for long periods of time, especially if you're not running in DMA mode. If you're doing something swap-intensive like opening Mozilla, your audio app won't be scheduled until the disk driver is done spinning, and it will skip.
... hm. Do a search for 'enabling DMA' or something similar. Or do 'man hdparm.'
Things are alot better with DMA enabled, but latency can still be bad. There are lots of other areas in the kernel that can do bad things to scheduling, but IDE and vesafb are by far the worst, IMO.
Docs
The article said something about Linux performing much better after hand-tuning the VM, which begs the question, seeing as how FreeBSD tunes its own VM for good default settings, why can't Linux do the same? This is just like the IDE DMA situation on BSD vs. Linux -- FreeBSD has had autodma working forever on VIA chipsets, and Linux, even in 2.4, defaults to PIO mode on IDE disks unless you enable 'highly dangerous' code. Oddly, the I/O elevator in 2.2 has a sensible out-of-the-box setting, but 2.4 requires tuning with an arcane tool called 'elvtune' or something if you want an elevator at all. Seems like a step backwards to me, regardless of how technically superior the 2.4 way is.
Unix purists go on about how the kernel should never set policy, but that's rather silly. Really, the kernel-'enforced' policy is whatever the defaults are, as most users expect the default behavior to be intelligent. People install Linux all the time and complain about how they can't do anything without getting choppy audio and mouse movement, because IDE defaults to PIO. It's rather sad that people get bad impressions of Linux because of its braindead default settings for so many things, when it's capable of doing much more.
Maybe this is work for the distros to be doing, I don't know. I suspect most of them would prefer to pass the buck as well.
Raleigh, the default gtk theme in the RH 7.1 beta, looks quite nice. They've cleaned up the worst of the default widgets, and there was a rumor that this might become the default for the stable gtk series.