take scientific bigotry there are States in the US (esp Kansas) where Evolution isn't accepted.
Ummmm... I think you are a mite confused. Whatever do you mean by "isn't accepted"? You seem to be implying that discussion of evolution is against the law or something.
If you believe that, you've been had.
What actually happened is that the Kansas Board of Education voted to remove evolution as a mandatory component in the high school curriculum. Individual local school boards can decide whether or not to teach evolution, and whether or not to teach competing theories.
Think of it as increasing freedom of speech for high school science teachers. (:
Also, you would do well to think about possible ulterior motives or socio-political agenda of anyone who tries to tell you Kansas "outlawed evolution" or any such. In other words -- they're lying to you -- why might they do that?
Linus needs to stop adding these relatively radical changes into the so called stable kernel reserved only for drivers and bug fixes.
Think of ext3 as "only a driver" -- which in your book is OK for a stable kernel. In terms of how much the code disturbs the rest of the kernel if you don't compile it in -- it really doesn't, just like a driver.
The VM change in 2.4.10 -- there I agree with you. (As does Linus, apparently, as he later admitted.)
I really can't understand why especially redhat was ignoring ReiserFS all the time, claiming (IMHO you can't otherwise say so!) it was "unstable". This must be some kind of weird "political" or strategic question.
Yeah, maybe it's a Red Hat conspiracy, or just maybe we can believe what they actually say about this: they run a lot of kernel stress tests before releasing their kernels, and apparently at the time of release of RH7.2, reiserfs was still giving them a few weird errors. Not the sort of thing you want to sell to corporate America.
These glitches weren't imaginary, either - around the same time Chris Mason was doing what someone termed his "reiserfs patch of the week" to fix various odd corner cases as they came up. There were several bugs related to tail merging, as I recall. This can all be verified via the linux-kernel archives, or you can see what went into kernels 2.4.2 through 2.4.5 or so.
Why Linus chose ext3 over the more proven technology, XFS?
This is a FAQ, but it bears repeating: XFS requires a lot of changes to other parts of the kernel, since it was designed for IRIX which has a completely different design philosophy from Linux. Since the necessary changes are rather invasive, it is best not to drop XFS straight into a stable kernel.
ext3, on the other hand, pretty much drops right in. (Oh yes, there is the common journalling layer, but that doesn't disturb the rest of the kernel much either.)
instead they use OSS.. which releases only half-assed free drivers, then expects you to pay for the good drivers.
I've never had much trouble with OSS drivers. What problems have you had with them, or is this just hearsay?
The kernel OSS drivers are maintained by kernel people, they're not just the original OSS drivers as put out by 4front.com.
ALSA is not yet ready for primetime. At least, they weren't ready a year ago when the 2.4 kernel was getting ready for release. Again, we must ask - is it a good idea to swap out the whole sound driver technology right before or during a stable release period?
I had my hopes that ALSA would replace OSS in the 2.3 cycle - but it didn't happen because they weren't ready. It probably will happen in 2.5.
Locking the kernel to a compiler is a BAD THING[tm].
Have you looked to see what extensions are used, and why? I have.
The most common one is __asm__, which allows inline assembly language in a C file. Sure, other compilers support asm statements, but they usually do not have the flexibility of gcc in terms of communicating to the compiler which variables to load in which registers, which registers to store back to variables, and which registers your inline code will clobber (very important for the compiler to know, for optimisation purposes).
Then there is the structure initialiser code which someone else already brought up. This makes structure initialisers much easier to read and maintain. (Recently the ANSI people came up with a competing syntax to do the same thing, but the kernel was using gcc syntax long before that - there's been talk of switching over. I personally find the gcc syntax much clearer anyway.)
If you look at how the kernel uses assembly language, you would see that it would be very cumbersome indeed to have to separate out all asm statements into their own files, to be assembled rather than compiled. And it would hinder inlining, which brings us to...
...kernel usage of inline. Would you rather have a kernel with no inline code at all? Because until recently, there was no C standard for what inline was supposed to mean. (C++ has such a keyword, but not C.) I'm not sure, but I believe ANSI has now said something about inline -- but again, the kernel has been around much longer than that.
One of my favorite gcc extensions is varargs macros. I recently had to port a small application to MSVC from gcc, and I really felt the pain of not having this! The kernel doesn't use this too much.
Anyway, to answer your accusation, the kernel is not, in fact, locked into one compiler! This is not the first time a different compiler was found to be better than gcc on a given Linux platform - two examples I know of are the Compaq compiler for Alpha and the Metrowerks CodeWarrior compiler for PowerPC. At least one of these (I don't remember which) was given gcc extensions for the express purpose of allowing it to compile the kernel. There is no reason Intel couldn't do the same with icc.
so all compilers have a compile-time option of some sort specifying whether the program is C or C++
Pedantically, this is not true of gcc. The C and C++ compilers are separate programs, named cc1 and cc1plus.
(Sure, they can both be driven by the compiler drivers, which are named gcc and g++....)
And I don't believe there is anything in the ANSI C++ standard that dictates that a conforming compiler must have C-compiler mode -- although it must accept C function prototypes when you use extern"C".
What if there were no other tire vendors? If Firestone had a monopoly on tires for SUVs, and it became known that their tires could blow out on occasion, would you as an SUV owner want to know about it, or would you want to have Firestone wait until they had new tires available and could swap out your old ones?
For that matter - given that there are different tire vendors out there, apparently you believe Firestone has the responsibility to tell customers how bad their current tires are, so the customer can, if he wants, go invest in an alternative brand. So... why doesn't the same thing apply to Microsoft? I think they have a responsibility to tell us: "Our product is now known to be unsafe. We expect to have a patch out in a few days; if that's not good enough for you, you may wish to deploy Linux or OpenBSD or Solaris web servers."
Obviously that would never happen. But really - how is the analogy flawed?
RedHat has release more bulletins about security vulnerabilities this year than Microsoft has.
Ah, but you see, you're not necessarily comparing apples to apples. The following could be an interesting exercies:
How many vulnerabilities from each company...
are exploitable with the default install of the OS?
are exploitable with the default configuration, assuming you installed the vulnerable component?
are remotely exploitable, i.e. you don't need a local account to use them?
are locally exploitable?
are local DoS attacks (Joe User, logged in locally, can reboot the machine, or crash it, or kill a system service, or hang a service so that it no longer works properly)?
are remote DoS attacks (same, but without need for a local login)?
I haven't done this exercise, but I strongly suspect that it would show that MS and RH have very different views of what constitutes a "security problem" that needs to be reported & patched. I'm guessing most if not all of the MS bulletins are remotely-exploitable holes, and that most are probably not mere DoS holes. The RH bulletins, on the other hand, will have a lot of temp file vulnerabilities -- which, in the MS world, would not even be considered bugs, much less security holes.
Thus the reply was to address the issue that FreeBSD is not a desktop OS.
...and as evidence to back this up, claimed that Mac OS is derived from FreeBSD.
...which is completely beside the point, because although FreeBSD has had LBA48 support for a month, Mac OS has not. So whether or not Mac OS is a desktop OS is not relevent.
If you actually followed the thread, you'd know what was going on.
Of course I followed the thread.... But there I go again, feeding trolls. Dang it.
Granted, this is currently achieved through a hack/kludge that bypasses ATA spec,
Actually, I believe they did this using the exact interface we are discussing today, LBA-48. Sure, they have a fancy marketing name for it, but don't worry, it really is the same thing.
Why do you care what the BIOS thinks? Set it to NONE and be done with it.
...So do you boot off a floppy, or off a CD, or via PXE, or off that disk the BIOS doesn't think exists? Or do you have a second, small drive in the machine for the sole purpose of booting it?
Keep in mind that booting from PXE or CD is probably a non-starter if your BIOS is old enough to have trouble with drive geometries.
FreeBSD is core to Mac OS X. How many people claim Mac OS X is NOT a desktop OS?
How many people claim Mac OS X had 48-bit IDE addressing on October 6 of this year?
Oh, sorry. What was your point again?
Seriously, if we're now talking about people who patch their own systems (i.e. upgraded the FreeBSD kernel back on Oct 6), the Linux ATA48 patch was available some time ago too. Granted, I don't remember if it was before October 6... I didn't pay all that much attention at the time, as I don't have any 128+ gig disks.
I*d also like to see memory mapped IO extended to allow direct use to be made of entire large scale disks in a single address space using a VM-like strategy * but I guess this will only be deemed practicable once we*re all using 64 bit processors.
Yeah, that deal where pointers are assumed not to need segments or offsets - that kind of puts a damper on the ability to provide userspace with more than 32 bits of space at a time. Even though the Pentium Pro supports 36-bit addresses, there's no way you could use these directly in user space in Linux, due to this assumption.
Are there any projects to approximate this on 32 bit architectures?
I'd be rather surprised - at least if anyone is trying to do this with Linux. It's not like 64-bit CPUs are either expensive or hard to find these days - MIPS R1x000, Alpha, SPARCv9, POWER3, PA-RISC-2.0w, take your pick, or IA-64 if you swing that way. Of these, at least the R10000, Alpha and UltraSPARC have been out for several years.
For applications where you really need to be able to address more than 32 bits at a time, there is really no excuse to use a 32-bit CPU. Application compatibility? Nah, we're talking specialised stuff, not off-the-shelf. OS availability? Choose any major Unix brand, or OpenVMS. Money? Your memory and secondary storage requirements will dwarf your investment in the CPU and mobo. Company politics / policy? Not a good enough reason IMHO, which of course is easy for me to say....
Seriously though...Isn't there a better place for someone who has the time to contribute? I'd rather see a better desktop environment, a better E-mail package, etc...
It's not really about having N petabytes of storage. It's about allowing a drive larger than 128 gigabytes (or 133 gigs as the drive mfrs would say), the current limit due to IDE's 28-bit addressing. Sure, we don't have multi-terabyte disks yet, but 160-gig disks are not so far off.
this will bring linux one step closer to being ready for primetime on the desktop.
What is it with you people? Does everything have to do with "Linux being ready for the desktop"?
How does having two competing VM subsystems make Linux less "desktop-ready"? Since when did the average desktop user compile his own kernel anyway? He installs a kernel pre-tested and pre-built by Red Hat or SuSE or Debian or Mandrake and never has a clue whose VM is under the hood.
For that matter, this only affects Linux 2.4.x and beyond. What features of 2.4, exactly, make Linux more suitable for the desktop market as compared to 2.2?
Or were you saying that Linux needed an improved VM to compete with the "don't try to open more than four applications at once or you might run out of memory and the machine will go into a tailspin" VMs of other popular desktop systems?
MS, Apple, and Oracle, who are built from the ground up to never admit deficiency or the need for change
Actually, they do admit the need for change, but only after the new version is a fait accompli. Then it's all about why the old version needs to be upgraded. (:
One might think that vaporware hype would talk about the need for change, but for some odd reason they always seem to stress glitzy new features rather than glitzy new bugfixes. Come to think of it, for some companies this is the case even after the new version ships. (Remember BillG - getting bugs fixed is the "stupidest reason I can think of" to upgrade software.)
But the real question is - if RvR's VM was so broken, how did it get in there in the first place ?
Something had to get there. Let me explain.
Back in 2.3.7, Linus merged a huge change that moved most file I/O from a buffer cache (caching of device blocks) to a page cache (caching based on virtual memory mappings). The VM was severely affected by this, and it never quite recovered.
So the Riel VM was not something wholly new, although it has some bits Rik put in late in the 2.3 cycle. -- But to answer your question, the "new" part of the 2.4 Riel VM was only accepted because the 2.3.7 VM was even worse.
The real question is, why did Linus stop merging Rik's VM patches back in early 2.4? At least according to Rik, Linus's VM between 2.4.5 and 2.4.9 stayed the same even though Rik was still tweaking it and submitting patches.
And you can do most of the same in Linux, with good old-fashioned chroot plus capabilities. No need for a separate system call.
Restricting to a specific IP address is a nice touch, and one thing Linux capabilities can't do, but it seems rather application-specific. It only allows one IP alias to the jailed process, and doesn't seem to cover any non-IPv4 addressing. And WTF do you have to specify a hostname? The kernel needs this information? (Or does the (2) in jail(2) not actually mean it's a syscall, like it doesn't in AIX?)
I'm also not sure if Linux capabilities are fine-grained enough to keep root from escaping a chroot without totally crippling it - but then again, jail() seems pretty crippling too. A virtual host server really shouldn't need root privs, other than bind-to-low-ports, and Linux capabilities do have that granularity.
have a parallel-computing library which your applications already use (PVM and MPI are the two popular APIs for such libraries), and configure it to share the load over your cluster. I think this is what Beowulf does.
sometimes used for 3d rendering - have a compute-intensive server program that can do any fraction of the total work (say, render frames x through y) running on each machine and a controller program which hands out and collects work to do. This is also how seti@home works.
serving - as in web, database, etc. Have multiple server processes, one on each machine, and they are basically independent of each other. (How to coordinate database updates between multiple database servers is left as an exercise to your DB vendor.) To get clients to use "any available machine" when they think they're pointed at a single box, you can either use a proxy server or round-robin DNS.
To answer your question, a web server can use either proxying or round-robin DNS without any special support from the main web server software. Of course, you have to have the proxy / DNS server running correctly. (Also, you obviously have to have either a shared or a synced filestore for your actual web site.)
Most of quelling of useful technology is done by: the old boys club not wanting to give up on the profits
You mean because they are not heavily investing in what you consider to be more desirable energy production technologies, they are "quelling" the state of the art? Since when was it their responsibility to R&D this stuff?
Anyway, as other posters have said, others are indeed doing plenty of R&D in "alternative energy" fields - but until you reach a particular cost/benefit ratio you can't expect consumers to just switch.
Coal and Utility companies are lobbying the ever-environment-hating White House to reduce the clean air rules on power plants.
And that's a bad thing? Think of it this way: every government regulation, including EPA regulations, is a tax on whoever has to comply with it. It costs real businesses real money. You may think that "conventional power plants are Evil so who cares if we Stick It To Them" - but that's pretty shortsighted. It's another way of saying "less pollution is an absolute good which justifies any cost to consumers whatsoever". With which I assert that most consumers do not agree.
Back to the "tax" analogy: even when you agree with a tax, it is reasonable to say "___ raised it too much, let's lower it back to a previous level". I feel that way about income taxes - the Clinton administration raised them too high - even though I agree that it is reasonable, in principle, for the Federal government to collect income taxes. I haven't studied the issue with EPA regulations, but it wouldn't surprise me one bit if that same administration went overboard there as well.
In other words, advocating relaxed clean-air standards does not necessarily mean that one "hates the environment". It may just mean that one thinks the power plant companies are having to spend too much money for too little marginal clean-air benefit.
Slashdot Mirror
Ummmm ... I think you are a mite confused. Whatever do you mean by "isn't accepted"? You seem to be implying that discussion of evolution is against the law or something.
If you believe that, you've been had.
What actually happened is that the Kansas Board of Education voted to remove evolution as a mandatory component in the high school curriculum. Individual local school boards can decide whether or not to teach evolution, and whether or not to teach competing theories.
Think of it as increasing freedom of speech for high school science teachers. (:
Also, you would do well to think about possible ulterior motives or socio-political agenda of anyone who tries to tell you Kansas "outlawed evolution" or any such. In other words -- they're lying to you -- why might they do that?
Think of ext3 as "only a driver" -- which in your book is OK for a stable kernel. In terms of how much the code disturbs the rest of the kernel if you don't compile it in -- it really doesn't, just like a driver.
The VM change in 2.4.10 -- there I agree with you. (As does Linus, apparently, as he later admitted.)
Yeah, maybe it's a Red Hat conspiracy, or just maybe we can believe what they actually say about this: they run a lot of kernel stress tests before releasing their kernels, and apparently at the time of release of RH7.2, reiserfs was still giving them a few weird errors. Not the sort of thing you want to sell to corporate America.
These glitches weren't imaginary, either - around the same time Chris Mason was doing what someone termed his "reiserfs patch of the week" to fix various odd corner cases as they came up. There were several bugs related to tail merging, as I recall. This can all be verified via the linux-kernel archives, or you can see what went into kernels 2.4.2 through 2.4.5 or so.
This is a FAQ, but it bears repeating: XFS requires a lot of changes to other parts of the kernel, since it was designed for IRIX which has a completely different design philosophy from Linux. Since the necessary changes are rather invasive, it is best not to drop XFS straight into a stable kernel.
ext3, on the other hand, pretty much drops right in. (Oh yes, there is the common journalling layer, but that doesn't disturb the rest of the kernel much either.)
I've never had much trouble with OSS drivers. What problems have you had with them, or is this just hearsay?
The kernel OSS drivers are maintained by kernel people, they're not just the original OSS drivers as put out by 4front.com.
ALSA is not yet ready for primetime. At least, they weren't ready a year ago when the 2.4 kernel was getting ready for release. Again, we must ask - is it a good idea to swap out the whole sound driver technology right before or during a stable release period?
I had my hopes that ALSA would replace OSS in the 2.3 cycle - but it didn't happen because they weren't ready. It probably will happen in 2.5.
Because you're not really converting the filesystem. The process consists of:
That's the beauty of ext3 - it is essentially ext2 with journaling, no more no less.
In fact, since this is the case, you can mount an ext3 filesystem as ext2 if you ever need to - the compatibility goes both forward and backward.
glibc requires gcc - and a relatively recent gcc at that.
So - no, for the same reason you can't compile a Linux kernel with it.
Yet. (I agree with the poster who said "probably by the next version icc will support at least some gcc extensions".)
Have you looked to see what extensions are used, and why? I have.
The most common one is __asm__, which allows inline assembly language in a C file. Sure, other compilers support asm statements, but they usually do not have the flexibility of gcc in terms of communicating to the compiler which variables to load in which registers, which registers to store back to variables, and which registers your inline code will clobber (very important for the compiler to know, for optimisation purposes).
Then there is the structure initialiser code which someone else already brought up. This makes structure initialisers much easier to read and maintain. (Recently the ANSI people came up with a competing syntax to do the same thing, but the kernel was using gcc syntax long before that - there's been talk of switching over. I personally find the gcc syntax much clearer anyway.)
If you look at how the kernel uses assembly language, you would see that it would be very cumbersome indeed to have to separate out all asm statements into their own files, to be assembled rather than compiled. And it would hinder inlining, which brings us to...
...kernel usage of inline. Would you rather have a kernel with no inline code at all? Because until recently, there was no C standard for what inline was supposed to mean. (C++ has such a keyword, but not C.) I'm not sure, but I believe ANSI has now said something about inline -- but again, the kernel has been around much longer than that.
One of my favorite gcc extensions is varargs macros. I recently had to port a small application to MSVC from gcc, and I really felt the pain of not having this! The kernel doesn't use this too much.
Anyway, to answer your accusation, the kernel is not, in fact, locked into one compiler! This is not the first time a different compiler was found to be better than gcc on a given Linux platform - two examples I know of are the Compaq compiler for Alpha and the Metrowerks CodeWarrior compiler for PowerPC. At least one of these (I don't remember which) was given gcc extensions for the express purpose of allowing it to compile the kernel. There is no reason Intel couldn't do the same with icc.
Pedantically, this is not true of gcc. The C and C++ compilers are separate programs, named cc1 and cc1plus.
(Sure, they can both be driven by the compiler drivers, which are named gcc and g++....)
And I don't believe there is anything in the ANSI C++ standard that dictates that a conforming compiler must have C-compiler mode -- although it must accept C function prototypes when you use extern"C".
What if there were no other tire vendors? If Firestone had a monopoly on tires for SUVs, and it became known that their tires could blow out on occasion, would you as an SUV owner want to know about it, or would you want to have Firestone wait until they had new tires available and could swap out your old ones?
For that matter - given that there are different tire vendors out there, apparently you believe Firestone has the responsibility to tell customers how bad their current tires are, so the customer can, if he wants, go invest in an alternative brand. So ... why doesn't the same thing apply to Microsoft? I think they have a responsibility to tell us: "Our product is now known to be unsafe. We expect to have a patch out in a few days; if that's not good enough for you, you may wish to deploy Linux or OpenBSD or Solaris web servers."
Obviously that would never happen. But really - how is the analogy flawed?
Ah, but you see, you're not necessarily comparing apples to apples. The following could be an interesting exercies:
How many vulnerabilities from each company...
I haven't done this exercise, but I strongly suspect that it would show that MS and RH have very different views of what constitutes a "security problem" that needs to be reported & patched. I'm guessing most if not all of the MS bulletins are remotely-exploitable holes, and that most are probably not mere DoS holes. The RH bulletins, on the other hand, will have a lot of temp file vulnerabilities -- which, in the MS world, would not even be considered bugs, much less security holes.
Well so it does. I learn something new every day. I still can't figure out why something like a hostname isn't 100% a figment of user-space. Anyone?
...and as evidence to back this up, claimed that Mac OS is derived from FreeBSD.
...which is completely beside the point, because although FreeBSD has had LBA48 support for a month, Mac OS has not. So whether or not Mac OS is a desktop OS is not relevent.
Of course I followed the thread. ... But there I go again, feeding trolls. Dang it.
(Yes, sometimes I feed trolls.)
So you're saying you believe it is useless to be able to use a 160GB disk, such as those Maxtor started selling about a month or two ago?
ATA-48 is not a "someday someone might build something big enough to benefit from this" thing. It is needed today.
Actually, I believe they did this using the exact interface we are discussing today, LBA-48. Sure, they have a fancy marketing name for it, but don't worry, it really is the same thing.
...So do you boot off a floppy, or off a CD, or via PXE, or off that disk the BIOS doesn't think exists? Or do you have a second, small drive in the machine for the sole purpose of booting it?
Keep in mind that booting from PXE or CD is probably a non-starter if your BIOS is old enough to have trouble with drive geometries.
How many people claim Mac OS X had 48-bit IDE addressing on October 6 of this year?
Oh, sorry. What was your point again?
Seriously, if we're now talking about people who patch their own systems (i.e. upgraded the FreeBSD kernel back on Oct 6), the Linux ATA48 patch was available some time ago too. Granted, I don't remember if it was before October 6 ... I didn't pay all that much attention at the time, as I don't have any 128+ gig disks.
Yeah, that deal where pointers are assumed not to need segments or offsets - that kind of puts a damper on the ability to provide userspace with more than 32 bits of space at a time. Even though the Pentium Pro supports 36-bit addresses, there's no way you could use these directly in user space in Linux, due to this assumption.
I'd be rather surprised - at least if anyone is trying to do this with Linux. It's not like 64-bit CPUs are either expensive or hard to find these days - MIPS R1x000, Alpha, SPARCv9, POWER3, PA-RISC-2.0w, take your pick, or IA-64 if you swing that way. Of these, at least the R10000, Alpha and UltraSPARC have been out for several years.For applications where you really need to be able to address more than 32 bits at a time, there is really no excuse to use a 32-bit CPU. Application compatibility? Nah, we're talking specialised stuff, not off-the-shelf. OS availability? Choose any major Unix brand, or OpenVMS. Money? Your memory and secondary storage requirements will dwarf your investment in the CPU and mobo. Company politics / policy? Not a good enough reason IMHO, which of course is easy for me to say....
<flame>Oh - ever heard of demoronizer?</flame>
It's not really about having N petabytes of storage. It's about allowing a drive larger than 128 gigabytes (or 133 gigs as the drive mfrs would say), the current limit due to IDE's 28-bit addressing. Sure, we don't have multi-terabyte disks yet, but 160-gig disks are not so far off.
What is it with you people? Does everything have to do with "Linux being ready for the desktop"?
How does having two competing VM subsystems make Linux less "desktop-ready"? Since when did the average desktop user compile his own kernel anyway? He installs a kernel pre-tested and pre-built by Red Hat or SuSE or Debian or Mandrake and never has a clue whose VM is under the hood.
For that matter, this only affects Linux 2.4.x and beyond. What features of 2.4, exactly, make Linux more suitable for the desktop market as compared to 2.2?
Or were you saying that Linux needed an improved VM to compete with the "don't try to open more than four applications at once or you might run out of memory and the machine will go into a tailspin" VMs of other popular desktop systems?
Actually, they do admit the need for change, but only after the new version is a fait accompli. Then it's all about why the old version needs to be upgraded. (:
One might think that vaporware hype would talk about the need for change, but for some odd reason they always seem to stress glitzy new features rather than glitzy new bugfixes. Come to think of it, for some companies this is the case even after the new version ships. (Remember BillG - getting bugs fixed is the "stupidest reason I can think of" to upgrade software.)
Something had to get there. Let me explain.
Back in 2.3.7, Linus merged a huge change that moved most file I/O from a buffer cache (caching of device blocks) to a page cache (caching based on virtual memory mappings). The VM was severely affected by this, and it never quite recovered.
So the Riel VM was not something wholly new, although it has some bits Rik put in late in the 2.3 cycle. -- But to answer your question, the "new" part of the 2.4 Riel VM was only accepted because the 2.3.7 VM was even worse.
The real question is, why did Linus stop merging Rik's VM patches back in early 2.4? At least according to Rik, Linus's VM between 2.4.5 and 2.4.9 stayed the same even though Rik was still tweaking it and submitting patches.
And you can do most of the same in Linux, with good old-fashioned chroot plus capabilities. No need for a separate system call.
Restricting to a specific IP address is a nice touch, and one thing Linux capabilities can't do, but it seems rather application-specific. It only allows one IP alias to the jailed process, and doesn't seem to cover any non-IPv4 addressing. And WTF do you have to specify a hostname? The kernel needs this information? (Or does the (2) in jail(2) not actually mean it's a syscall, like it doesn't in AIX?)
I'm also not sure if Linux capabilities are fine-grained enough to keep root from escaping a chroot without totally crippling it - but then again, jail() seems pretty crippling too. A virtual host server really shouldn't need root privs, other than bind-to-low-ports, and Linux capabilities do have that granularity.
Two common uses for a cluster:
To answer your question, a web server can use either proxying or round-robin DNS without any special support from the main web server software. Of course, you have to have the proxy / DNS server running correctly. (Also, you obviously have to have either a shared or a synced filestore for your actual web site.)
You mean because they are not heavily investing in what you consider to be more desirable energy production technologies, they are "quelling" the state of the art? Since when was it their responsibility to R&D this stuff?
Anyway, as other posters have said, others are indeed doing plenty of R&D in "alternative energy" fields - but until you reach a particular cost/benefit ratio you can't expect consumers to just switch.
And that's a bad thing? Think of it this way: every government regulation, including EPA regulations, is a tax on whoever has to comply with it. It costs real businesses real money. You may think that "conventional power plants are Evil so who cares if we Stick It To Them" - but that's pretty shortsighted. It's another way of saying "less pollution is an absolute good which justifies any cost to consumers whatsoever". With which I assert that most consumers do not agree.
Back to the "tax" analogy: even when you agree with a tax, it is reasonable to say "___ raised it too much, let's lower it back to a previous level". I feel that way about income taxes - the Clinton administration raised them too high - even though I agree that it is reasonable, in principle, for the Federal government to collect income taxes. I haven't studied the issue with EPA regulations, but it wouldn't surprise me one bit if that same administration went overboard there as well.
In other words, advocating relaxed clean-air standards does not necessarily mean that one "hates the environment". It may just mean that one thinks the power plant companies are having to spend too much money for too little marginal clean-air benefit.
You mean so you can play it on your pencil?
Oh, I get it. For a one-line calculator display.