One is the ability to address more than 4GB of physical ram (which 32bit addressing is limited to)
32-bit addressing is limited to 4GB of physical RAM at any instant, but you can handle more than 4GB of physical memory in multiple 4GB-or-less process address spaces, or handle it by mapping pages in and out of a given address space, on a platform with 32-bit virtual addresses.
Linux already does this on alpha's.
...and there's a patch from, as I remember, Siemens, which, as I remember, was accepted for the 2.3 kernel, to do that on x86, presumably in the fashion I described.
The ability to seek more than 4GB into a file (ie: fseek takes a 64bit offset, not a 32bit one). I'm pretty sure alpha linux has this too.
...as does x86 {Free,Net,Open}BSD, versions of NetBSD and OpenBSD on other 32-bit platforms, Solaris 2.6 and Solaris 7 on x86 and 32-bit SPARC, etc., etc., etc....
...and on Linux, with the right patch; I think that patch has also been accepted for the 2.3 kernel.
A 64-bit architecture run in 64-bit mode isn't necessary for handling more than 4GB of memory, or for seeking more than 4GB into a file - fseek() may take a 32-bit offset on those platforms, but fsetpos() could take a 64-bit offset, as could llseek(), say - but it does make it a bit more convenient (no need to muck around with mapping stuff into or out of an address space, no need to use on UNIX all the extra stuff from the Large File Summit, or to use the somewhat clumsy support in Win32 for file offsets >32 bits).
The biggest advantage of 64 bit is the ability to operate on Quadwords (64 bits)
...in a single instruction. You can do 64-bit arithmetic on 32-bit platforms (for example, most if not all modern C compilers for 32-bit platforms support long long int or some equivalent 64-bit integral data type), but the operations generally have to be synthesized from multiple instructions (typically done inline for most operations, although multiplication and division, and possibly others, might be done in a subroutine), with each instruction working on 32 bits at a time, and may require more registers, as the non-floating-point registers on a 32-bit platform are typically 32 bits wide.
but you've neglected to mention that you can get (and use) a full 64 bit word from that address with a 64 bit OS
You can do that on 32-bit machines as well; most memory fetches tend to turn into cache-line fills, which can use the wider-than-32-bit data buses available on most if not all general-purpose-computer 32-bit processors these days.
You typically can't process all 64 bits of that word - at least not with integer instructions - but you at least get all 64 bits (or more, if your memory bus is wider) at once.
P6's can use various tricks to access more than 4GB, but only by using yucky segmentation techniques.
The segmentation tricks don't help much, if at all; the x86 MMU maps 48-bit segmented addresses to 32-bit linear addresses, and then maps 32-bit linear addresses to 32-bit physical addresses or, on P6, 36-bit physical addresses if that feature is being used by the OS. Thus, you can't get at more than 4GB of linear address space at any one time - you'd have to map segments into and out of the linear address space, although I guess you could do that on demand, so that it's somewhat transparent (although still potentially slow).
However, all that does is, as you note, prevent you from addressing more than 4GB at any one time; stuff can be mapped into or out of the address space (which I guess could be considered a "yucky segmentation technique" - you're an old-timer like me, so you may remember the use of that on some versions of PDP-11 UNIX and various PDP-11 OSes from Digital), and you can have more than one address space by having more than one process.
More than 4GB of physical memory is more useful on machines that let you get at it all at once, in a single address space, but it probably has some use even on platforms such as x86, SPARC V7/V8 with SPARC Reference MMU, etc. that have only 32-bit linear addresses but support more than 32 bits of physical address.
The Alpha, MIPS, and PowerPC architectures date from the era when the goal was one instruction per clock cycle
MIPS does; however, POWER and Alpha may not. The first POWER and Alpha processors were superscalar (PowerPC being a descendant of POWER).
It's worth noting that the Pentium Pro/II/III have a 48-bit segmented addressing mode, allowing physical memory beyond 4GB.
You're confusing (as per my followup to the person who responded to you) the support for 36-bit physical addresses in the P6 processors (PPro, PII, PIII) with the support for 48-bit segmented virtual addresses, which dates back to the 386 (and which is a 32-bit-segment-offset version of the 286's segmentation). You don't need to use 48-bit virtual addresses, in their full shining glory, to get more than 32 bits of physical address.
It would be a coup for some Linux vendor to support this, allowing Linux PC-type machines bigger than 4GB.
There's code in the 2.3 kernel from, if I remember correctly, Siemens, to do exactly that.
I don't know offhand whether any of the BSDs support it; I think either Solaris 2.6 or Solaris 7 do.
You do
not have to use the segmented addressing more to access more than 4GB of physical memory
That should've been "You do not have to use the segmented addressing mode".
As per my parenthetical note, you do, in a sense, have to use it to use paging, but you don't have to use it in a non-trivial fashion; most (if not all) x86 OSes don't use full 48-bit addresses, they just use 32-bit addresses with implicit segment numbers, and set up the segments to overlap so that those 32-bit addresses translate trivially to 32-bit linear addresses.
As for FreeBSD vs. NetBSD, I think none of the BSDs map the entire kernel address space into virtual memory; I don't think Solaris does, either - I think they added support for >4GB of physical memory in 2.6 or 7.
It's worth noting that the Pentium Pro/II/III have a 48-bit segmented addressing mode, allowing physical memory beyond 4GB. Nobody uses this yet, but it's in there.
Maybe FreeBSD makes use of it
Almost certainly not. You do not have to use the segmented addressing more to access more than 4GB of physical memory - you may not be able to have all of it mapped in at the same time, but you could map it in and out dynamically, or give 4GB-or-less chunks to various processes.
In fact, the x86 segmented mode - which is not new in the P6 processors (PPro, PII, PIII), but has been around in its current form since the 386, and existed with smaller addresses in the 286 - doesn't even help. The x86 MMU maps 48-bit segmented addresses (which any OS running in protected mode uses, although most of them set up "trivial" segments and, unless they're running 16-bit programs that use 286-style segmentation to boost their address space size, don't really make use of it) to 32-bit linear addresses; those 32-bit linear addresses are then translated to physical addresses through the page table, if paging has been enabled (which it is, in most x86 OSes, e.g. Windows OT and NT, OS/2, Solaris, Linux, BSD, etc., etc.).
What's new in the P6 processors is the ability to specify page tables that generate 36-bit physical addresses rather than 32-bit physical addresses (an ability that at least some other 32-bit processors, e.g. SPARCs with the SPARC Reference MMU, have had). You need that ability and you need a memory bus that puts out more than 32 bits of physical address; I think some 32-bit platforms have had that, and some high-end "PC" platforms may have it.
the GPL is strongly connected to the FSF and their gnu utilities.
Yes, the GPL is strongly connected to the FSF, given that it was originally, I think, the idea of the FSF's founder.
And, yes, the GNU utilities are, not surprisingly, licenced under the GPL.
However, what I was trying to get across is that this does not, in and of itself, demonstrate that the GPL is connected to "the creeping featurism and code bloat in GNU utils"; somebody could write, say, a GPLed cat that lacked such creeping featurism and code bloat as the -v flag (-v being, by the way, Berkeley creeping featurism, not GNU creeping featurism...)
Aren't you forgetting an important part? The part at the end where the source code is shown, that Linus didn't actually make the change, just made a comment saying that it would be nice if he could.
That part showed up after that issue of KT came out; I don't know whether it showed up after I checked it earlier today or not (I'd assumed that issues of KT are invariant after publication, and I saw that issue before the note was added).
Some stuff in the FreeBSD archive indicates that they may have decided that the unlock optimization couldn't be done that way, either, although I'd have to plow through a ton of -current code and, perhaps, CVS logs to see exactly what they did do - see this message, for example, and this message.
(And, the hypothesis in, as I remember, one of the linux-kernel messages nonwithstanding, the FreeBSD folk do have P6 machines - some of Matt's timing experiments were, as I remember, done on a Pentium III.)
The comment in the code also suggests that it might be useful to have a way of building a kernel without the lock, if it truly can be removed on all but the early PPro's to which the comment refers.
Which is somewhat amusing, as (perhaps aided and abetted by the Obligatory X10 Babe Ad on the PC Week pages) I misread "first ARPAnet node" in one of the paragraphs as "first ARPAnet nude".
So what was the first ARPAnet nude? And how soon after the first ARPAnet node appeared did the first ARPAnet nude appear?
(And, yes, I suspect you're right. Rather a lot of bits stored on, and cached by, Network Appliance boxes are probably Naughty Bits, so I probably owe some of my net worth to the human sex drive....)
and they attribute the reason this didn't happen to AT&T's not taking packet switching seriously enough.
Indeed? The part that discusses packet switching was
There were proven centralized systems before the first toylike PCs came along. What often made the PC compelling, despite its high costs of acquisition and training, was consistent response compared with centralized systems that often had sluggish and unreliable connections.
Suppose that AT&T Corp., instead of rejecting the early Internet's radical notion of packet-switched networks, had embraced this more flexible and efficient approach. If we had wired the nation correctly the first time, instead of making massive investments in circuit-switched infrastructure, we might have had high-bandwidth networks much sooner. Both business and entertainment applications would have been collaborative from the beginning, and an isolated PC would have seemed at best a hobbyist device.
which didn't seem connected to his speculation that getting "chip compilers" sooner would have gotten us "information appliances" sooner, that speculation being what the quote you gave is from.
I.e., I think the speculation on chip compilers and information appliances, and the speculation on better packet-switched networks, were unrelated, unless he's (implicitly) saying that information appliances would've made more sense if we had high-bandwidth long-haul networks sooner.
I'm not sure I see how "methods for generating chip designs from functional descriptions" being available earlier would necessarily have gotten us to "information appliances" sooner, though, so I'm a tad skeptical of Coffee's speculation there.
and they have bad associations with GPL'd code. Associations like the spaghetti mess that is gnu-tar, the overladen info/emacs help system
Are either of those due to the GPL? It seems silly to reject a license merely because some code released under that license doesn't meet your standards, unless you have solid evidence that the license somehow caused the code not to meet your standards and will cause a lot of other code not to meet your standards....
However, for applications that are either closed-source (and thus binary only), or those which are open source, but have complex library and other environmental issues (such as something like KDE or Gnat -- the GNU Ada compiler), I hope that the makers of such software will take the time to put out a BSD version. I just don't see any reason that they shouldn't.
Because, for the commercial software, it's Another Platform To Support, and they have to build it for the platform, test it on the platform, take support calls for the platform, etc.?
Some vendors do have FreeBSD ports - Applix and Perforce, for example. Linux binaries of commercial products may run on FreeBSD, as well - I seem to remember Jordan Hubbard suggesting to vendors that they port to Linux first.
As for the open-source applications, well, check out the BSD ports collection - my desktop is KDE 1.1.2, from the FreeBSD ports collection....
Since FreeBSD and Linux both use ELF binaries, any well-written application written for one should work on the other, shouldn't it?
No, not necessarily. {FreeBSD,Linux,Solaris x86,Unixware,...} ELF binaries for the platform in question expect the shared library routines they call to have particular calling sequences, with data structures having the layout of the OS on that platform, with various #defines, etc. having particular values, and so on. The mere fact that those OSes all use ELF is insufficient to arrange that binaries for a given CPU will run on all of them.
Now, there are Linux-ABI implementations for all of those OSes (Linux implements it by definition; FreeBSD has support for Linux binaries; lxrun runs on Solaris and, I think, Unixware - it may originally have been an SCO program), so some commercial Linux binaries may be able to run on all of them.
Often true (and self feeding), but it's a two-way street. For example, USB support is much better on FreeBSD than on Linux at this point.
I've heard that to be the case for USB, and plug-and-play ISA seems to work better on FreeBSD than on Linux right now as well.
Both of those will, I think, change with the 2.4 Linux kernel - but there may, in the future, be other places where FreeBSD does better than Linux, just as there are places where Linux does better than FreeBSD, when it comes to supporting hardware.
The relative state of OSes X and Y at time T doesn't necessarily indicate that the relative state will be the same at time T plus delta T; some of the Microsoft anti-Linux marketing literature may well make correct points now about stuff that NT does better than Linux, but that doesn't mean it'll always do better - and the same applies to stuff Linux does better. Of course, marketing literature is generally intended to persuade, rather than inform, so if somebody says "XXX does better than YYY at ZZZ", be careful that you don't necessarily implicitly infer from that statement that XXX will always be better than YYY at ZZZ....
Erich Boleyn, an Architect in an IA32 development group at Intel, also replied to Linus, pointing out a possible misconception in his proposed exploit...
...
There was a long clarification discussion, resulting in a complete turnaround by Linus
i.e., that Linux later accepted the change:
"Everybody has convinced me that yes, the Intel ordering rules _are_ strong enough that all of this really is legal, and that's what I wanted.
...
Thanks, guys, we'll be that much faster due to this.."
As for "others can be found elsewhere", please give references - perhaps they're also not bad implementations.
Yes, FreeBSD is more stable, but Linux is something new, something fresh, something with new ideas and innovations.
Does anybody have any data from a careful study of both the open-source BSD kernels and of the Linux kernel, or of both the open-source BSD OSes and the open-source components of Linux distributions, to indicate that "new ideas and innovations" are present in Linux to an extent significantly greater than the extent to which they're present in the open-source BSDs?
(Linux isn't very unixy)
Could you please justify that assertion with facts? When I log onto a Linux system, it sure as hell looks as much like a "Unix system" to me as do FreeBSD or Solaris or HP-UX or Digital UNIX or....
After a fresh install of FreeBSD 3.4 I could mount my dos and ntfs partitions right away.
I think he's trying to imply that they may have adopted it now, but rejected it originally.
The CVS tree seems to imply that it may have been in FreeBSD at least as far back as 2.0, however; the comment from the initial checkin, with a date of Mon Sep 19 15:41:43 1994 UTC, says "Obtained from: NetBSD", so NetBSD may have had it even longer.
Other people likely to take the isk of using the new feature, because with the source code, they can fix anything that causes a problem
...which would also be true of {Free,Open,Net}BSD, as you have the source code.
then these fixes are given back to due to the GPL and all will benefit from them
...which is also often true of {Free,Net,Open}BSD as well.
In BSD, things happen slowley because the people working on it are more concerned with sercurity and stability.
Umm, how quickly do things happen in, say, the 2.2[.x] Linux kernel tree, as opposed to the 2.3[.x] tree? You appear to get at least some choice of "bleeding-edge" vs. "stable" there...
...and you also do with FreeBSD (and possibly the other BSDs), by going with the "-current" tree if you want to be on the bleeding edge or going with a "-stable" release if you don't.
Also, if someone does make a good change or add an important feature, they could always keep it and not share it, so these features will be adopted slowly.
That has nothing to do with adopting features, it has to do with whether they're available for the open-source BSDs to adopt - and there appear to be people contributing stuff back to the BSDs, e.g. Whistle have contributed a number of things to FreeBSD.
The end result is that Linux, while more prone to problem when using the latest and greatest kernal/library/etc, it more quickely adopts features that user want and need.
Well, maybe. Perhaps the ISA PnP tools, or the ISA PnP kernel patch, for Linux can be made tow work as well as the ISA PnP support has worked for me on my box (it handles my PnP ISA sound card just fine - no, I do not want a PCI sound card, I'd rather leave my PCI slots available for cards such as networking and SCSI cards), but the PnP ISA patch didn't work very well on the 2.0[.x] kernel on my Debian partition (I could've debugged it, but didn't particularly have any interest in doing so, as it Just Worked on FreeBSD), and it wasn't clear whether I'd have to update some config file to use the ISA PnP tools (I could've dug into that, but didn't particularly have any interest in doing so, as it Just Worked on FreeBSD).
I.e., I don't think it's as clear-cut as you describe - you can do bleeding-edge stuff with FreeBSD (and perhaps the other ones) if you want, and you can do trailing-edge stable stuff with Linux if you want. (Note: "trailing-edge" is not being used as a pejorative here; heck, I don't run "-current" on my home machine, as I'm primarily using it for development of stuff for the Ethereal network analyzer, and for surfing/reading mail/etc., so I'm reasonably happy to be somewhat on the trailing edge.)
That's why people choose the stability of BSD for their embedded projects (see the Whistle InterJet, NFR's Sniffer, Secure Computing's products, etc.) as well as high end ones (Network Appliance, et al.)
Well, first of all, Network Appliance doesn't run BSD on their boxes (I joined the software engineering group at NetApp when there were about 7 or 8 people in the group, and I'm still there, so I know what I'm talking about here) - we use the BSD networking stack, and various BSD commands, but it took a fair bit of work with a chainsaw to fit them into our environment (which is a kernel-mode-only, single-address-space OS that would probably not be completely unfamiliar in its innards to a BSD developer, but which is very much not a BSD kernel).
Second of all, there are also embedded boxes that use Linux, e.g. Cobalt's boxes, and, I'm sure, plenty of others.
As for whether Linux is "flakey and not meant for real world use", there are Web sites using it, there are places (including, err, umm, Network Appliance, Inc.) where people use it on their desktops and on their compute servers (most of our compute servers are running Solaris or Digital UNIX, but there is one Linux PC, and there will probably be more over time), and so on. People seem to manage to use it in "the real world" even if it's "not meant for real world use".
um, what file system does Solaris use? what does your vfstab say?
...ufs...logging, perhaps? (I.e., UFS with journaling enabled?) To quote the Solaris 7 "mount_ufs" man page (fetched from Sun's online documentation collection; unfortunately, the URLs look suspiciously like per-session URLs, so I'm loath to put them in the article, but go to "Solaris 7", then go to "Solaris 7 Reference Manual Collection", then go to "man Pages(1M): System Administration Commands", and it's under there):
logging | nologging
If logging is specified, then logging is enabled for the duration of the mounted file system. Logging is the process of storing transactions (changes that make up a complete UFS operation) in a log before the transactions are applied to the file system. Once a transaction is stored, the transaction can be applied to the file system later. This prevents file systems from becoming inconsistent, therefore eliminating the need to run fsck. And, because fsck can be bypassed, logging reduces the time required to reboot a system if it crashes, or after an unclean halt. The default behavior is nologging.
An article over on Economic Times explains why BSD is as not as popular as Linux.
At most, they quote somebody from Novell India as saying that "The reason why it is not as popular as Linux is the lack of commercial support".
There's no place I can see where they attribute the difference in popularity to the license. I see a place where they make the factual statement that the BSDL and GPL are different, but I see nowhere anything in the article claiming that this is the reason for a difference in popularity - the sentence after the one about the license difference might, at most, be suggesting that, as a result of the license difference, "the BSD operating system" (although they don't say which particular flavor of BSD - one of the free ones, or BSD/OS) is inside some firewalls (however, there are plenty of "appliances" with Linux Inside, as well; some even have, I think, proprietary code in them, even if it's not in the kernel).
In my experience people tend to graduate from Linux to *BSD once they've gotten their feet wet. Has anyone else experienced this?
No, not particularly. I know a number of people who've been using various Linux distributions for quite a while - i.e., they haven't "graduated from Linux to *BSD" - and people who've been using BSD for a while, but haven't personally seen a significant amount of movement in either direction.
I'd like to see a very broad survey before I drew any conclusions about people moving from Linux to *BSD. The evidence people have presented seems largely anecdotal....
Personally, I use Linux. That is mainly because I am interested in kernel programming, and I like the idea of getting the source code to every app on my system.
I also am a kernel programmer, and like getting the source code to all components of my system.
The OS most often running on my home machine is FreeBSD. I have full source code to the kernel and to all components of my system.
Liking the idea of getting the source code to every app on your system is not a reason to prefer a Linux distribution to {Free,Net,Open}BSD; it's a reason to prefer an open-source OS - such as a Linux distribution or {Free,Net,Open}BSD - to a closed-source OS.
(Note also that having Linux is not only not necessary if you want source to every app on your system, it's not sufficient, either - you have to avoid installing third-party apps that aren't open-source, which are available for Linux and {Free,Net,Open}BSD as well as for closed-source OSes.)
No, he's arguing that it is not the case that it always happens and that all non-GPL'd software "is being taken proprietary and disappearing forever from public view". It is, in fact, not the case - {Free,Net,Open}BSD are still in public view, and there is no sign that they are being taken proprietary, and there's plenty of other non-GPLed software that's non-proprietary and publicly available (heck, even if The Open Group hadn't abandoned their restrictions on the distribution of X11R6.4 source, previous releases wouldn't have "disappeared forever from public view").
Yes, there is perhaps a greater risk of non-GPLed software "being taken proprietary and disappearing from public view" - although it may just be future versions that disappear from public view, allowing a fork to preserve the public version - but the mere existence of a risk doesn't amount to a certainty that the risked outcome will happen.
Slashdot Mirror
32-bit addressing is limited to 4GB of physical RAM at any instant, but you can handle more than 4GB of physical memory in multiple 4GB-or-less process address spaces, or handle it by mapping pages in and out of a given address space, on a platform with 32-bit virtual addresses.
...and there's a patch from, as I remember, Siemens, which, as I remember, was accepted for the 2.3 kernel, to do that on x86, presumably in the fashion I described.
...as does x86 {Free,Net,Open}BSD, versions of NetBSD and OpenBSD on other 32-bit platforms, Solaris 2.6 and Solaris 7 on x86 and 32-bit SPARC, etc., etc., etc....
...and on Linux, with the right patch; I think that patch has also been accepted for the 2.3 kernel.
A 64-bit architecture run in 64-bit mode isn't necessary for handling more than 4GB of memory, or for seeking more than 4GB into a file - fseek() may take a 32-bit offset on those platforms, but fsetpos() could take a 64-bit offset, as could llseek(), say - but it does make it a bit more convenient (no need to muck around with mapping stuff into or out of an address space, no need to use on UNIX all the extra stuff from the Large File Summit, or to use the somewhat clumsy support in Win32 for file offsets >32 bits).
...in a single instruction. You can do 64-bit arithmetic on 32-bit platforms (for example, most if not all modern C compilers for 32-bit platforms support long long int or some equivalent 64-bit integral data type), but the operations generally have to be synthesized from multiple instructions (typically done inline for most operations, although multiplication and division, and possibly others, might be done in a subroutine), with each instruction working on 32 bits at a time, and may require more registers, as the non-floating-point registers on a 32-bit platform are typically 32 bits wide.
You can do that on 32-bit machines as well; most memory fetches tend to turn into cache-line fills, which can use the wider-than-32-bit data buses available on most if not all general-purpose-computer 32-bit processors these days.
You typically can't process all 64 bits of that word - at least not with integer instructions - but you at least get all 64 bits (or more, if your memory bus is wider) at once.
The segmentation tricks don't help much, if at all; the x86 MMU maps 48-bit segmented addresses to 32-bit linear addresses, and then maps 32-bit linear addresses to 32-bit physical addresses or, on P6, 36-bit physical addresses if that feature is being used by the OS. Thus, you can't get at more than 4GB of linear address space at any one time - you'd have to map segments into and out of the linear address space, although I guess you could do that on demand, so that it's somewhat transparent (although still potentially slow).
However, all that does is, as you note, prevent you from addressing more than 4GB at any one time; stuff can be mapped into or out of the address space (which I guess could be considered a "yucky segmentation technique" - you're an old-timer like me, so you may remember the use of that on some versions of PDP-11 UNIX and various PDP-11 OSes from Digital), and you can have more than one address space by having more than one process.
More than 4GB of physical memory is more useful on machines that let you get at it all at once, in a single address space, but it probably has some use even on platforms such as x86, SPARC V7/V8 with SPARC Reference MMU, etc. that have only 32-bit linear addresses but support more than 32 bits of physical address.
MIPS does; however, POWER and Alpha may not. The first POWER and Alpha processors were superscalar (PowerPC being a descendant of POWER).
You're confusing (as per my followup to the person who responded to you) the support for 36-bit physical addresses in the P6 processors (PPro, PII, PIII) with the support for 48-bit segmented virtual addresses, which dates back to the 386 (and which is a 32-bit-segment-offset version of the 286's segmentation). You don't need to use 48-bit virtual addresses, in their full shining glory, to get more than 32 bits of physical address.
There's code in the 2.3 kernel from, if I remember correctly, Siemens, to do exactly that.
I don't know offhand whether any of the BSDs support it; I think either Solaris 2.6 or Solaris 7 do.
That should've been "You do not have to use the segmented addressing mode".
As per my parenthetical note, you do, in a sense, have to use it to use paging, but you don't have to use it in a non-trivial fashion; most (if not all) x86 OSes don't use full 48-bit addresses, they just use 32-bit addresses with implicit segment numbers, and set up the segments to overlap so that those 32-bit addresses translate trivially to 32-bit linear addresses.
As for FreeBSD vs. NetBSD, I think none of the BSDs map the entire kernel address space into virtual memory; I don't think Solaris does, either - I think they added support for >4GB of physical memory in 2.6 or 7.
Almost certainly not. You do not have to use the segmented addressing more to access more than 4GB of physical memory - you may not be able to have all of it mapped in at the same time, but you could map it in and out dynamically, or give 4GB-or-less chunks to various processes.
In fact, the x86 segmented mode - which is not new in the P6 processors (PPro, PII, PIII), but has been around in its current form since the 386, and existed with smaller addresses in the 286 - doesn't even help. The x86 MMU maps 48-bit segmented addresses (which any OS running in protected mode uses, although most of them set up "trivial" segments and, unless they're running 16-bit programs that use 286-style segmentation to boost their address space size, don't really make use of it) to 32-bit linear addresses; those 32-bit linear addresses are then translated to physical addresses through the page table, if paging has been enabled (which it is, in most x86 OSes, e.g. Windows OT and NT, OS/2, Solaris, Linux, BSD, etc., etc.).
What's new in the P6 processors is the ability to specify page tables that generate 36-bit physical addresses rather than 32-bit physical addresses (an ability that at least some other 32-bit processors, e.g. SPARCs with the SPARC Reference MMU, have had). You need that ability and you need a memory bus that puts out more than 32 bits of physical address; I think some 32-bit platforms have had that, and some high-end "PC" platforms may have it.
Yes, the GPL is strongly connected to the FSF, given that it was originally, I think, the idea of the FSF's founder.
And, yes, the GNU utilities are, not surprisingly, licenced under the GPL.
However, what I was trying to get across is that this does not, in and of itself, demonstrate that the GPL is connected to "the creeping featurism and code bloat in GNU utils"; somebody could write, say, a GPLed cat that lacked such creeping featurism and code bloat as the -v flag (-v being, by the way, Berkeley creeping featurism, not GNU creeping featurism...)
That part showed up after that issue of KT came out; I don't know whether it showed up after I checked it earlier today or not (I'd assumed that issues of KT are invariant after publication, and I saw that issue before the note was added).
Some stuff in the FreeBSD archive indicates that they may have decided that the unlock optimization couldn't be done that way, either, although I'd have to plow through a ton of -current code and, perhaps, CVS logs to see exactly what they did do - see this message, for example, and this message.
(And, the hypothesis in, as I remember, one of the linux-kernel messages nonwithstanding, the FreeBSD folk do have P6 machines - some of Matt's timing experiments were, as I remember, done on a Pentium III.)
The comment in the code also suggests that it might be useful to have a way of building a kernel without the lock, if it truly can be removed on all but the early PPro's to which the comment refers.
Which is somewhat amusing, as (perhaps aided and abetted by the Obligatory X10 Babe Ad on the PC Week pages) I misread "first ARPAnet node" in one of the paragraphs as "first ARPAnet nude".
So what was the first ARPAnet nude? And how soon after the first ARPAnet node appeared did the first ARPAnet nude appear?
(And, yes, I suspect you're right. Rather a lot of bits stored on, and cached by, Network Appliance boxes are probably Naughty Bits, so I probably owe some of my net worth to the human sex drive....)
Indeed? The part that discusses packet switching was
which didn't seem connected to his speculation that getting "chip compilers" sooner would have gotten us "information appliances" sooner, that speculation being what the quote you gave is from.
I.e., I think the speculation on chip compilers and information appliances, and the speculation on better packet-switched networks, were unrelated, unless he's (implicitly) saying that information appliances would've made more sense if we had high-bandwidth long-haul networks sooner.
I'm not sure I see how "methods for generating chip designs from functional descriptions" being available earlier would necessarily have gotten us to "information appliances" sooner, though, so I'm a tad skeptical of Coffee's speculation there.
Are either of those due to the GPL? It seems silly to reject a license merely because some code released under that license doesn't meet your standards, unless you have solid evidence that the license somehow caused the code not to meet your standards and will cause a lot of other code not to meet your standards....
Because, for the commercial software, it's Another Platform To Support, and they have to build it for the platform, test it on the platform, take support calls for the platform, etc.?
Some vendors do have FreeBSD ports - Applix and Perforce, for example. Linux binaries of commercial products may run on FreeBSD, as well - I seem to remember Jordan Hubbard suggesting to vendors that they port to Linux first.
As for the open-source applications, well, check out the BSD ports collection - my desktop is KDE 1.1.2, from the FreeBSD ports collection....
No, not necessarily. {FreeBSD,Linux,Solaris x86,Unixware,...} ELF binaries for the platform in question expect the shared library routines they call to have particular calling sequences, with data structures having the layout of the OS on that platform, with various #defines, etc. having particular values, and so on. The mere fact that those OSes all use ELF is insufficient to arrange that binaries for a given CPU will run on all of them.
Now, there are Linux-ABI implementations for all of those OSes (Linux implements it by definition; FreeBSD has support for Linux binaries; lxrun runs on Solaris and, I think, Unixware - it may originally have been an SCO program), so some commercial Linux binaries may be able to run on all of them.
I've heard that to be the case for USB, and plug-and-play ISA seems to work better on FreeBSD than on Linux right now as well.
Both of those will, I think, change with the 2.4 Linux kernel - but there may, in the future, be other places where FreeBSD does better than Linux, just as there are places where Linux does better than FreeBSD, when it comes to supporting hardware.
The relative state of OSes X and Y at time T doesn't necessarily indicate that the relative state will be the same at time T plus delta T; some of the Microsoft anti-Linux marketing literature may well make correct points now about stuff that NT does better than Linux, but that doesn't mean it'll always do better - and the same applies to stuff Linux does better. Of course, marketing literature is generally intended to persuade, rather than inform, so if somebody says "XXX does better than YYY at ZZZ", be careful that you don't necessarily implicitly infer from that statement that XXX will always be better than YYY at ZZZ....
Oh, you mean the discussion that includes
i.e., that Linux later accepted the change:
As for "others can be found elsewhere", please give references - perhaps they're also not bad implementations.
Does anybody have any data from a careful study of both the open-source BSD kernels and of the Linux kernel, or of both the open-source BSD OSes and the open-source components of Linux distributions, to indicate that "new ideas and innovations" are present in Linux to an extent significantly greater than the extent to which they're present in the open-source BSDs?
Could you please justify that assertion with facts? When I log onto a Linux system, it sure as hell looks as much like a "Unix system" to me as do FreeBSD or Solaris or HP-UX or Digital UNIX or....
I think he's trying to imply that they may have adopted it now, but rejected it originally.
The CVS tree seems to imply that it may have been in FreeBSD at least as far back as 2.0, however; the comment from the initial checkin, with a date of Mon Sep 19 15:41:43 1994 UTC, says "Obtained from: NetBSD", so NetBSD may have had it even longer.
The distributions of software from the University of California at Berkeley were called "Berkeley Software Distribution"(s).
A company named Berkeley Software Design, Inc. sells a commercial OS - called "BSD/OS", not "BSDI" - based on the BSD 4.4-Lite source.
...which would also be true of {Free,Open,Net}BSD, as you have the source code.
...which is also often true of {Free,Net,Open}BSD as well.
Umm, how quickly do things happen in, say, the 2.2[.x] Linux kernel tree, as opposed to the 2.3[.x] tree? You appear to get at least some choice of "bleeding-edge" vs. "stable" there...
...and you also do with FreeBSD (and possibly the other BSDs), by going with the "-current" tree if you want to be on the bleeding edge or going with a "-stable" release if you don't.
That has nothing to do with adopting features, it has to do with whether they're available for the open-source BSDs to adopt - and there appear to be people contributing stuff back to the BSDs, e.g. Whistle have contributed a number of things to FreeBSD.
Well, maybe. Perhaps the ISA PnP tools, or the ISA PnP kernel patch, for Linux can be made tow work as well as the ISA PnP support has worked for me on my box (it handles my PnP ISA sound card just fine - no, I do not want a PCI sound card, I'd rather leave my PCI slots available for cards such as networking and SCSI cards), but the PnP ISA patch didn't work very well on the 2.0[.x] kernel on my Debian partition (I could've debugged it, but didn't particularly have any interest in doing so, as it Just Worked on FreeBSD), and it wasn't clear whether I'd have to update some config file to use the ISA PnP tools (I could've dug into that, but didn't particularly have any interest in doing so, as it Just Worked on FreeBSD).
I.e., I don't think it's as clear-cut as you describe - you can do bleeding-edge stuff with FreeBSD (and perhaps the other ones) if you want, and you can do trailing-edge stable stuff with Linux if you want. (Note: "trailing-edge" is not being used as a pejorative here; heck, I don't run "-current" on my home machine, as I'm primarily using it for development of stuff for the Ethereal network analyzer, and for surfing/reading mail/etc., so I'm reasonably happy to be somewhat on the trailing edge.)
Well, first of all, Network Appliance doesn't run BSD on their boxes (I joined the software engineering group at NetApp when there were about 7 or 8 people in the group, and I'm still there, so I know what I'm talking about here) - we use the BSD networking stack, and various BSD commands, but it took a fair bit of work with a chainsaw to fit them into our environment (which is a kernel-mode-only, single-address-space OS that would probably not be completely unfamiliar in its innards to a BSD developer, but which is very much not a BSD kernel).
Second of all, there are also embedded boxes that use Linux, e.g. Cobalt's boxes, and, I'm sure, plenty of others.
As for whether Linux is "flakey and not meant for real world use", there are Web sites using it, there are places (including, err, umm, Network Appliance, Inc.) where people use it on their desktops and on their compute servers (most of our compute servers are running Solaris or Digital UNIX, but there is one Linux PC, and there will probably be more over time), and so on. People seem to manage to use it in "the real world" even if it's "not meant for real world use".
At most, they quote somebody from Novell India as saying that "The reason why it is not as popular as Linux is the lack of commercial support".
There's no place I can see where they attribute the difference in popularity to the license. I see a place where they make the factual statement that the BSDL and GPL are different, but I see nowhere anything in the article claiming that this is the reason for a difference in popularity - the sentence after the one about the license difference might, at most, be suggesting that, as a result of the license difference, "the BSD operating system" (although they don't say which particular flavor of BSD - one of the free ones, or BSD/OS) is inside some firewalls (however, there are plenty of "appliances" with Linux Inside, as well; some even have, I think, proprietary code in them, even if it's not in the kernel).
No, not particularly. I know a number of people who've been using various Linux distributions for quite a while - i.e., they haven't "graduated from Linux to *BSD" - and people who've been using BSD for a while, but haven't personally seen a significant amount of movement in either direction.
I'd like to see a very broad survey before I drew any conclusions about people moving from Linux to *BSD. The evidence people have presented seems largely anecdotal....
I also am a kernel programmer, and like getting the source code to all components of my system.
The OS most often running on my home machine is FreeBSD. I have full source code to the kernel and to all components of my system.
Liking the idea of getting the source code to every app on your system is not a reason to prefer a Linux distribution to {Free,Net,Open}BSD; it's a reason to prefer an open-source OS - such as a Linux distribution or {Free,Net,Open}BSD - to a closed-source OS.
(Note also that having Linux is not only not necessary if you want source to every app on your system, it's not sufficient, either - you have to avoid installing third-party apps that aren't open-source, which are available for Linux and {Free,Net,Open}BSD as well as for closed-source OSes.)
No, he's arguing that it is not the case that it always happens and that all non-GPL'd software "is being taken proprietary and disappearing forever from public view". It is, in fact, not the case - {Free,Net,Open}BSD are still in public view, and there is no sign that they are being taken proprietary, and there's plenty of other non-GPLed software that's non-proprietary and publicly available (heck, even if The Open Group hadn't abandoned their restrictions on the distribution of X11R6.4 source, previous releases wouldn't have "disappeared forever from public view").
Yes, there is perhaps a greater risk of non-GPLed software "being taken proprietary and disappearing from public view" - although it may just be future versions that disappear from public view, allowing a fork to preserve the public version - but the mere existence of a risk doesn't amount to a certainty that the risked outcome will happen.