As my old American gov't teacher used to say, the citizens of United States constitute about 5% of the total world population (?) while consuming *one third* of the world's resources.
What are the figures for Europe? (Probably better, but are they enough better, or is the European way of life still a threat to mankind's future on earth, just a less serious one?)
The US has a long history of going their own way as far as telecom is concerned. TV signal (analog and digital) is one of them
Are you referring (for the "analog" part) to NTSC vs. PAL? If so, are you saying then that mean that PAL came out first, and the US developed NTSC instead of adopting PAL? If so, the Why Do Different TV Standards Exist? page on the Worldwide TV Standards - A Web Guide site seems to disagree - it says
Beyond the initial divide between 50 and 60Hz based systems, further sub-divisions have appeared within both camps since the inception of Colour broadcasting. The majority of 60Hz based countries use a technique known as NTSC originally developed in the United States by a committee called the National Television Standards Committee. NTSC (often scurrilously refered to as Never Twice the Same Colour) works perfectly in a video or closed ciruit environment but can exhibit problems of varying hue when used in a broadcast environment.
This hue change problem is caused by shifts in the colour sub-carrier phase of the signal. A modified version of NTSC soon appeared which differed mainly in that the sub-carrier phase was reversed on each second line; this is known as PAL, standing for Phase Alternate Lines (it has a wide range of facetious acronyms including Pictures At Last, Pay for Added Luxury (re: cost of delay line), and People Are Lavendar). PAL has been adopted by a few 60Hz countries, most notably Brazil.
Or are you saying that the US "went their own way" because they didn't dump NTSC in favor of PAL?
(That page also says
Amongst the countries based on 50Hz systems, PAL has been the most widely adopted. PAL is not the only colour system in widespread use with 50Hz; the French designed a system of their own - primarily for political reasons to protect their domestic manufacturing companies - which is known as SECAM, standing for SEquential Couleur Avec Memoire. The most common facetious acronym is System Essentially Contrary to American Method, SECAM was widely adopted in Eastern Block countries to encourage incompatibility with Western transmissions - again a political motive.
It does to me; when I log into a Linux box, it feels about the same to me as any other box running a UNIX-flavored OS (not all of which feel exactly the same as one another, so it's not as if there's a "UNIX" that everything but Linux looks exactly like).
Yeah, maybe the GNU "ls" that Linux distributions use does color (I don't normally have an "xterm" that does color, so it doesn't make any difference to me), but some systems have an "ls" that shows the user and group names with "ls -l", others have one that shows only the user name, etc..
On many Linux distributions, the twisty little maze of "rc" files, all different, looks more like that of, say, SunOS 5.x/Solaris 2.x/Solaris 7 than like that of BSD systems.
So, from where I stand, Linux distributions aren't any more noticeably different from other UNIX-flavored OSes, either as a user or as somebody writing code to run atop them, than are any other UNIX-flavored OS (i.e., UNIX-flavored OSes aren't all exactly like each other, and Linux distributions don't seem any more divergent from any "norm" than do any other UNIX-flavored OSes).
The OS source itself, e.g. the kernel and the C library, might be more different from any such "norm" than is the source to other UNIX-flavored OSes - but, given the number of vendors, etc. who've been hacking on the code they got from AT&T, Berkeley, etc., it might not be that much more different. The kernel source, say, is less familiar to me in organization than is, say, the FreeBSD source - but, not having seen the SunOS 5.x kernel source in several years, I don't know how alien it would seem to me.
FreeBSD is more of a standard *NIX, than Linux is.
In what sense?
I was recently informed that Hotmail which is owned by M$ runs FreeBSD. I originaly thought that Hotmail ran Solaris and HP, which was why M$ ported its IE to thoses platforms
I'd not heard that Hotmail ran HP-UX, just a mixture of Solaris and FreeBSD.
I'd also not heard that this had anything whatsoever to do with Microsoft's choice of platforms to which to port IE; the impression I had was that some customers wanted to standardize on one browser for all platforms in the company, including their UNIX boxes, and that they ported IE to the platforms that would help them the most in getting those customers to choose IE.
The choice of platforms probably also depended on the platforms for which Mainsoft's MainWin "Win32-atop-UNIX" platform was available, as that's how they did the port; it doesn't appear to be available on any x86 UNIX, just AIX on RS/6000's, HP-UX on PA-RISC machines, IRIX on SGI MIPS machines, Solaris on SPARC machines, and Digital^H^H^H^H^H^H^HTru64 UNIX on Alpha. Whether this is the result of Microsoft not wanting competition on PCs or not is an interesting question, to which I don't know the answer.
may be you'll know about people like Bill Joy and the great work he did on the original AT&T Unix creating the BSD branch, and Kirk McKusik too, he did the FFS, and all worldwide contributors before the Internet that helped to make BSD the best Unix in 1980
Bill Joy and Kirk McKusick were at Berkeley when they did their work, so they're not counterexamples to the allegation that the BSD people didn't accept outside contributions.
Robert Elz of (if I remember correctly) the University of Melbourne may be a better example - he (and perhaps other people there) did the disc quota code that got into 4.2BSD.
SLIP was another external contribution - Rick Adams at Computer Consoles, Inc. did an implementation of the IP-over-serial-lines encapsulation that 3Com's UNET product (a non-BSD-based TCP/IP stack for UNIX) used, as we needed it for a project we were doing at CCI for the US Naval Surface Weapons Center, and sent it back to Berkeley.
e2fs is a great fs but was not adopted by any vendor/project, why?
Vendors didn't want to drop a GPLed file system amidst their non-GPLed software?
A number of vendors have, in a sense, adopted ext2fs - Red Hat, SuSE, Pacific HiTech, Caldera, etc. provide it as part of their operating system offerings.:-) (I.e., I suspect vendors tend to pick up the Linux kernel, or a Linux distribution, in its entirety, rather than picking up pieces of it.)
I'm sorry, but `my' definition is the standard, accepted definition of an operating system in computer science.
Funny, when I was in school, I seem to remember people including more than just kernel-mode code - in particular, one operating system partially developed at the school where I went, namely Multics, had very little code running in "kernel mode" (called "master mode" on the GE 6xx machines and their Honeywell successors) - most of it ran in "slave mode", with some running in "ring 0" (no, this was not an x86 processor, so "ring 0" was not equivalent to master mode - even in ring 0 you couldn't execute the instructions to e.g. start an I/O operation), some running in "ring 1", and some running in "ring 4", which was the ring in which user-written code mainly ran.
Please show some hard evidence that your definition is "the standard, accepted definition of an operating system in computer science".
If the kernel is the OS, then I'd appreciate it if you start referring to the "Win32 OS" from now on.
Win32 isn't actually implemented by the NT kernel - the NT kernel implements its own programming interface, which is used by the libraries and Win32 subsystem process that implement Win32.
This, arguably, even more strongly emphasizes the point that the OS isn't ipso facto the kernel, if the kernel of some system doesn't directly implement any of its API, unlike UNIX-flavored systems where at least some of the API tends to be direct system calls, even though a lot of it isn't.
In short, the operating system is the software that runs in system space (aka kernel space). Anything that runs in user space is, by definition, not a part of the OS.
That may be your definition of OS.
It is not my definition of OS.
Yes, any application running on a system with a UNIX-flavored system call interface and APIs implemented atop that could, in theory, be written solely using system calls by replacing all the non-system-call APIs by reimplementations of those APIs.
However:
it's not clear whether this would, in general, be a useful undertaking;
the rewritten application (or, for that matter, a statically-linked application not rewritten in that fashion) might not function entirely as desired when run on a later version of that system (consider, for example, a system in which "gethostbyname()" merely read "/etc/hosts" - if somebody wrote their own "gethostbyname()" into their application, and a later release of the OS replaced that "gethostbyname()" with one that determined from a "/etc/nsswitch.conf" file whether to use "/etc/hosts" or NIS or NIS+ or DNS or... to look up host names, an application dynamically linked with "gethostbyname()" would automatically pick up the new behavior, but a statically-linked application, or one that used only system calls and read "/etc/hosts" itself, wouldn't;
so I don't consider "an OS is the software that runs in kernel mode" a particularly useful definition (especially given that there may well be machines that have a more fine-grained privilege level than just kernel vs. user).
I'm not sure what the right definition of "OS" is, but I tend to consider anything that, if removed, would keep the system from running usefully to be part of the OS, which means that, at a minimum, that includes, on a modern UNIX-flavored system, init, the shell that runs the "rc" files, the commands run from the "rc" files as distributed and configured by system installation, and the shared libraries with which those programs are linked - and if that brings in "libc", well, the "libc" in most Linux distributions is either derived from a GNU "libc" or is a GNU "libc", so....
Yes, some of the stuff that falls into that category may also run on other systems, but I don't consider that sufficient reason to consider it "not part of the OS" on a system where it's a standard component of that system - GNU "libc" isn't "part of the OS" if the system has its own "libc", but if the system's "libc" is GNU "libc", I consider that a different matter.
...didn't the *bsd flavors of unix had what, 20 years to get their act together and yet let windows and proprietary unix os's come in without a care in the world
20 years ago, you had to get a license from AT&T to get BSD, as large parts of the code in BSD were based on AT&T UNIX code that hadn't been replaced. They weren't out for World Domination at that point - but, then, Linus Torvalds wasn't our for World Domination when he started working on his kernel, either, as far as I know....
and now the *bsd hackers are pissed at linux users and the whole computer world for ignoring them.
There may well be *BSD hackers who are pissed at Linux users and the whole computer world for appearing to ignore them, but
not all BSD hackers are;
not all Linux users are ignoring BSD and much of the computer world isn't ignoring BSD, either, as the Wall Street Journal article this thread started out with shows.
They screwed up bad on marketing it, selling it, creating hype about it, and giving it to users.
To what extent did the Linux community "market it, sell it, and create hype about it"? And where did the "marketing, selling, and hype" about Linux come from? I'm not sure it all came from "the Linux hackers".
Linus invented linux because he couldn't get a unix os for his 386 pc. freebsd either couldn't run on it or it was accessible at the time.
FreeBSD (and the other freely-available BSDs) have always run on PCs, as I think FreeBSD and NetBSD both came from 386BSD which was a port of Net-2 to, err, umm, the PC.
IF I am correct (I could be wrong). The group of *bsd hackers bickered among themselves and fragmented and made a terrible mistake. THe mistake was it wasn't involved with the IBM pc when it first came out.
The first attempt at a completely-free BSD (with all the AT&T code either replaced or blessed as "OK to give out") was, I think, 386BSD, whence came FreeBSD and NetBSD; the "386" in "386BSD" referred to the 80386, because it was a BSD port to the PC.
The *bsd group didn't let outsiders contribute code so users who wanted a more powerful OS had to buy a separate OS more proprietary OS like sun os, irix, aix. The fragmentation in unix itself began.
"The *bsd group" of those days was the Computer Systems Research Group at the University of California, Berkeley, and they certainly did accept contributions from outsiders. However, not all the stuff Sun, SGI, IBM, etc. did with either AT&T UNIX code or BSD code was necessarily sent back to Berkeley by those companies, and not because the Berkeley folk wouldn't accept it. You can't solely blame Berkeley for the existence of N different flavors of UNIX....
Unix was crazed by the IS departments until the early 1990's when unix completely became fragmented, proprietary, expensive, and unix companies began bickering among themselves
That all happened well before the early 1990's; UNIX was well-fragmented by the mid 1980's, with several different proprietary variants, from vendors who largely sold it on their own boxes rather than on, say, IBM-compatible PCs - UNIXes for PCs had existed for a long time, but I don't know how well IN/ix ran on 8088-based PC's (yes, 8088, the one with segmentation but no memory protection), but I suspect it may not have run well enough to push DOS out of the way, and I suspect the same may have been true of the UNIXes for 286-based PCs, although I think Xenix (yes, the Borg's own UNIX, later handed to SCO) may have had a decent market share for small business computers and the like.
The *bsd crowd ignored bill totally instead of pointing out there fallacies and marketing there OS and they still haven't learned from there mistakes and the source code was still closed and the users ignored average users and were real snotty.
"The *bsd crowd", if by that you mean the folks at Berkeley and their successors on the {Free,Net,Open}BSD projects, weren't spearheading the commercial UNIX movement - as far as I know, they were building free OSes for their own purposes, which I think was largely what the Linux community was also doing when they started.
Guess what! Windows took over everything and NT 3.51 came out next and began to steal the unix market.
Said market was the commercial UNIX market, not the free UNIX "market"....
Linux has buzz
Linux has software companies distributing it; for whatever reason, there's no equivalent of Red Hat or SuSE or Caldera or Pacific HiTech or... filling that role for {Free,Net,Open}BSD (no, Walnut Creek CD-ROM isn't in that position, as far as I know), although there is BSDI selling BSD/OS.
"The *bsd community", if, by that, you mean the developers of {Free,Net,Open}BSD is probably more like the Debian community than like Red Hat or SuSE or... in that regard (although the Debian folk aren't necessarily the official "owners" of all the components that go into their distribution - they're the official source of versions of the kernel, libraries, utilities, etc. that go into a Debian release, but they're not the official home of the Linux kernel or GNU "libc" or...).
Linux said that linux is made up of 30 full time and over 1,000 part time programmers who work on the kernel while freebsd has only 15 guys.
The FreeBSD Core Team does have 16 members, but the core team, as the list linked to say, "constitutes the project's ``Board of Directors'', responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape" - they're not the sole developers of FreeBSD code. The same probably applies to NetBSD and OpenBSD. There are 151 additional "FreeBSD Developers" "who have commit privileges and do the engineering work on the FreeBSD source tree", and, according to the Contributing to FreeBSD page in the FreeBSD Handbook
Contrary to what some people might also have you believe, you do not need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors whose ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it.
Again, the same may be true of NetBSD and OpenBSD; I'm less familiar with those projects.
I don't know how many of the core team or the development team work full-time on FreeBSD, so I can't say that FreeBSD has 167 full-time and (some unknown number of) part-time developers (the latter being those who don't have commit privileges but who do contribute code) - and note that this does not say that FreeBSD has more people working on it than are working on Linux systems, as I don't know if those "30 full time people" counts only people working on the kernel or also counts people working on GNU "libc", GNU utilities that aren't also used in the BSDs, etc..
However, it does suggest that "freebsd has only 15 guys" is a big oversimplification.
There could well be more people working on the stuff that goes into a Linux distribution and that doesn't also go into the BSDs or that isn't also available for BSD (people working on XFree86 aren't "Linux developers", as their stuff goes into the BSDs as well, and the folks working on KDE, at least, aren't "Linux developers", either, as binary packages of KDE 1.1.1 are available for FreeBSD and possibly the other BSDs) than are working on FreeBSD, but this doesn't mean that FreeBSD, or any of the other BSDs, are ipso facto doomed.
I believe freebsd had the unix code already and was around over 12 years longer then linux
12 years before today is 1987; FreeBSD didn't exist then, and Linux didn't just show up today, so FreeBSD wasn't around 12 years longer than Linux. Much of the BSD code was around before Linux existed, but much of the GNU and other code that goes into a Linux distribution was around before Linux existed as well, so I'm not sure {Free,Net,Open}BSD had as big a head start as you seem to think (it did have one, as far as I know, but not a 12 year head start).
I am not implying that a flawed belif should be spread merely that people should be allowed to keep their icons.
...but that doesn't ipso facto mean others are obliged not to say anything that would make it more difficult for those people to hold onto their beliefs. (You may believe it does, but I and I suspect many others don't, and aren't willing just to accept your belief that it does.)
If not for this myth of Linus Linux would never have made it into the lime light
Do you have any solid evidence to support this belief? Did the "myth of Linux" spring up prior to corporate/media/etc. interest in Linux, and help lead to that interest, or did it spring up as, or after, that interest started growing, with the myth being a hook on which journalists could hang their stories about Linux?
(I don't care whether people call it "Linux" or "GNU/Linux" or "Roland the headless Thomson gunner" - and there's a lot of stuff in a Linux distribution that doesn't come from the GNU project, so, if somebody insists that it be called "GNU/Linux" to give credit where credit is due, they should note that even "GNU/Linux" doesn't fully give credit where credit is due - but I've yet to see any solid evidence that the mere use of "GNU/Linux" somehow shatters a fragile myth upon which much of the popularity of Linux is based.)
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
But then Compaq's compiler beats intel's pants down on the FP benchmarks.
Compaq's x86 compiler beats Intel's x86 compiler, or Compaq's Alpha compiler beats Intel's Alpha compiler?
(If the answer is "Compaq's Alpha compiler beats Intel's x86 compiler", that should read as "an Alpha system with an XXX MHz 21X64 and a YYY memory subsystem, running code compiled with Compaq's compiler, beat an x86 system with an XXX Mhz Pentium/Pentium Pro/Pentium II/Xeon Warrior Princess and a YYY memory subsystem, running code compiled with Intel's compiler" - crediting that win solely to the compiler requires some evidence to justify it.)
No, it doesn't. It just has a 32-bit base linear address, a 20-bit length (which can either be in units of bytes or 4K pages), and a bunch of other flags. A 48-bit far address gets translated to a 32-bit linear address, and that is what gets translated to a 32-bit or 36-bit physical address via the page table.
The enterprise edition of Windows NT Server does make use of this.
NT 4.0, or NT 5.0^H^H^H^H^H^HW2K? I don't think NT 4.0 supports more than 4GB of physical memory, but W2K, at least in the DataCenter Server edition, will.
See, for example, this note on "Address Windows Extensions and Windows 2000 DataCenter Server", and this press-release-like document which indicates that this is new in W2K and not in NT 4.0, but also seems to imply that memory above 4GB will be available to the page pool (I'd seen stuff that gave me the impression that it would be wired-down memory that had to be specially mapped into a process's address space, but perhaps that's not the case).
You don't need to use segmentation to get at >4GB of physical memory.
In fact, segmentation doesn't even help, given that the x86 MMU maps 48-bit segmented addresses to 32-bit linear addresses before running said addresses through the page table and translating them to 32-bit or 36-bit physical addresses.
However, for any single process to access more than 4GB, it does have to do something that amounts to bank switching, i.e. map stuff into and out of its no-more-than-4GB linear address space as necessary; the same applies to kernel-mode code and the kernel-mode portion of the address space.
No, that's what Linux has supported all along, and it limits you to 2 GB of _physical_ RAM.
Yes, NT (unless you turn on the right boot flag, which might work even in non-enterprise editions) has 2GB of the virtual address space of the machine available to user-mode code and 2GB for kernel-mode code, just as had been the case for Linux all along.
However, I'm not sure that limited you to 2GB of physical RAM on NT, as NT might not require that all of physical memory be mapped into the kernel's address space.
The new Linux patch supports 4 GB of physical RAM and unlimited user space.
Linux has, for a long time, supported "unlimited user space" in the sense that user-mode code can map stuff into and out of its address space, so that the no-more-than-4GB window you get on a processor with 32-bit linear addresses (e.g., an x86 processor) can be moved around a more-than-4GB set of data. The patch doesn't change that.
However, that's true of most OSes that run on x86 processors, these days.
The issue may be one of whether the extra 4 physical-address lines are actually connected to the world off the chip; that might not be the case on all P6-series processors, even though the processor on the die might contain all the hardware necessary to put non-zero values on those lines.
Logical addressing (program addresses) is still limited to 2GB or 3GB or whatever. So if you put 64G on your quad Xeon factory heater (tm), programs still max out at 4G.
True, in the sense that at any given instant of time, the linear address space of a process can be no larger than 4GB (and, as segmented addresses get translated to 32-bit linear addresses before being run through the page table, segmentation doesn't help).
However, as I noted in another post, a process could, if the OS lets it (and most OSes you'd run on big machines do, these days), map stuff into and out of its address space, and more than one process could exist on the machine, so you can use it for userland code, userland data, kernel code, kernel data, mapped files, buffer cache, whatever, just as you can use the first 4GB - it's just a question of what the OS does or lets applications do.
Not in the case of P6-core machines; segmentation turns a 48-bit segmented address into a 32-bit linear address. They're using paging, instead, i.e. the page table entries, in one of the 36-bit-physical-address modes, generate more than 32 bits of physical address from 32 bits of (linear) virtual address.
Any one process would have to map stuff into and out of its address space to use more than 4GB (or 4GB minus what kernel-mode code takes) of physical memory, but
the OSes that run on the sorts of machines that would have that much physical memory probably let processes do that (NT, and most, if not all, UNIX-flavored OSes, definitely do);
those OSes also probably support more than one process.
Kernel-mode code could also map stuff into and out of its part of the address space.
Offhand I don't know about Solaris, SCO, or anyone else. I'd be a little surprised if Sun didn't do it, although I'd also understand if they left it out to encourage UltraSparc sales.
I vaguely remember reading that Solaris now supports it, although finding detailed technical information on Sun's shiny new Marketing-Driven(TM) Web site looks as if it'd demand more patience than I have.
It's probably a question of whether any "commodity" x86 machines support it; if not, then Solaris for Intel, and UnixWare, may not support it either.
I'm not sure, given that the "enterprise" edition lets it use only 1GB, but note that this is virtual memory, not physical memory - this doesn't mean NT is consuming 2GB of physical memory.
and using almost half of your machine's memory as page cache (in Linux terms, I'm sure NT has an equivalent that's calle dsomething else)
I infer from the stuff I've seen in the "Inside Windows NT" books that it has a common page/buffer cache; the first edition of Inside Windows NT says
8.1.2.4 Mapped File I/O and File Caching
...
...When a thread opens and uses a file, the file system tells the cache manager to create an unnamed section object and maps the caller's file into it. As the caller uses the file, the VM manager brings accessed pages into the section object from disk and flushes them back to disk during paging....
which is similar to what some UNIX systems (e.g., SunOS 4.x, SVR4-based systems, FreeBSD, etc.) do; I have the impression that if the Linux kernel doesn't yet have a unified page/buffer cache in a stable kernel, it's going into the 2.3[.x] line.
Most of memory is, in effect, a page cache on these systems, unless you count only pages not currently being used as cached, in which case most of memory not used by pages currently being used is a page cache. In addition, the buffer cache (in the sense of the cache of pages read in from files) is just part of the page cache.
Well, in general, to set up any type of hardware under any operating system requires either that the OS in question include support for that device (whether it supports the device in its "native" mode, or because it can be run in a fashion compatible with a supported device), or that a driver exist that can be added to the OS; that's as true of non-plug-and-play device as of plug-and-play devices.
Redhat's betas now have code names, Microsoft betas have always had code names.
Yes, and plenty of other organizations (commercial and otherwise) give code names to products/software releases/etc. under development; this hardly constitutes grounds for considering this a sign that Red Hat is now "think[ing] more like their competition".
I just find it interesting that they would beta something other than a completely new version.
And what indicates that this is "something other than a completely new version"?
Slashdot Mirror
What are the figures for Europe? (Probably better, but are they enough better, or is the European way of life still a threat to mankind's future on earth, just a less serious one?)
Are you referring (for the "analog" part) to NTSC vs. PAL? If so, are you saying then that mean that PAL came out first, and the US developed NTSC instead of adopting PAL? If so, the Why Do Different TV Standards Exist? page on the Worldwide TV Standards - A Web Guide site seems to disagree - it says
Or are you saying that the US "went their own way" because they didn't dump NTSC in favor of PAL?
(That page also says
for those curious about PAL vs. SECAM.)
It does to me; when I log into a Linux box, it feels about the same to me as any other box running a UNIX-flavored OS (not all of which feel exactly the same as one another, so it's not as if there's a "UNIX" that everything but Linux looks exactly like).
Yeah, maybe the GNU "ls" that Linux distributions use does color (I don't normally have an "xterm" that does color, so it doesn't make any difference to me), but some systems have an "ls" that shows the user and group names with "ls -l", others have one that shows only the user name, etc..
On many Linux distributions, the twisty little maze of "rc" files, all different, looks more like that of, say, SunOS 5.x/Solaris 2.x/Solaris 7 than like that of BSD systems.
So, from where I stand, Linux distributions aren't any more noticeably different from other UNIX-flavored OSes, either as a user or as somebody writing code to run atop them, than are any other UNIX-flavored OS (i.e., UNIX-flavored OSes aren't all exactly like each other, and Linux distributions don't seem any more divergent from any "norm" than do any other UNIX-flavored OSes).
The OS source itself, e.g. the kernel and the C library, might be more different from any such "norm" than is the source to other UNIX-flavored OSes - but, given the number of vendors, etc. who've been hacking on the code they got from AT&T, Berkeley, etc., it might not be that much more different. The kernel source, say, is less familiar to me in organization than is, say, the FreeBSD source - but, not having seen the SunOS 5.x kernel source in several years, I don't know how alien it would seem to me.
In what sense?
I'd not heard that Hotmail ran HP-UX, just a mixture of Solaris and FreeBSD.
I'd also not heard that this had anything whatsoever to do with Microsoft's choice of platforms to which to port IE; the impression I had was that some customers wanted to standardize on one browser for all platforms in the company, including their UNIX boxes, and that they ported IE to the platforms that would help them the most in getting those customers to choose IE.
The choice of platforms probably also depended on the platforms for which Mainsoft's MainWin "Win32-atop-UNIX" platform was available, as that's how they did the port; it doesn't appear to be available on any x86 UNIX, just AIX on RS/6000's, HP-UX on PA-RISC machines, IRIX on SGI MIPS machines, Solaris on SPARC machines, and Digital^H^H^H^H^H^H^HTru64 UNIX on Alpha. Whether this is the result of Microsoft not wanting competition on PCs or not is an interesting question, to which I don't know the answer.
Bill Joy and Kirk McKusick were at Berkeley when they did their work, so they're not counterexamples to the allegation that the BSD people didn't accept outside contributions.
Robert Elz of (if I remember correctly) the University of Melbourne may be a better example - he (and perhaps other people there) did the disc quota code that got into 4.2BSD.
SLIP was another external contribution - Rick Adams at Computer Consoles, Inc. did an implementation of the IP-over-serial-lines encapsulation that 3Com's UNET product (a non-BSD-based TCP/IP stack for UNIX) used, as we needed it for a project we were doing at CCI for the US Naval Surface Weapons Center, and sent it back to Berkeley.
Vendors didn't want to drop a GPLed file system amidst their non-GPLed software?
A number of vendors have, in a sense, adopted ext2fs - Red Hat, SuSE, Pacific HiTech, Caldera, etc. provide it as part of their operating system offerings. :-) (I.e., I suspect vendors tend to pick up the Linux kernel, or a Linux distribution, in its entirety, rather than picking up pieces of it.)
I may well have typed a full URL to pkg_add once, but, most of the time, I just use the -r flag and give pkg_add the package name.
That was the point I was making.
Funny, when I was in school, I seem to remember people including more than just kernel-mode code - in particular, one operating system partially developed at the school where I went, namely Multics, had very little code running in "kernel mode" (called "master mode" on the GE 6xx machines and their Honeywell successors) - most of it ran in "slave mode", with some running in "ring 0" (no, this was not an x86 processor, so "ring 0" was not equivalent to master mode - even in ring 0 you couldn't execute the instructions to e.g. start an I/O operation), some running in "ring 1", and some running in "ring 4", which was the ring in which user-written code mainly ran.
Please show some hard evidence that your definition is "the standard, accepted definition of an operating system in computer science".
Win32 isn't actually implemented by the NT kernel - the NT kernel implements its own programming interface, which is used by the libraries and Win32 subsystem process that implement Win32.
This, arguably, even more strongly emphasizes the point that the OS isn't ipso facto the kernel, if the kernel of some system doesn't directly implement any of its API, unlike UNIX-flavored systems where at least some of the API tends to be direct system calls, even though a lot of it isn't.
That may be your definition of OS.
It is not my definition of OS.
Yes, any application running on a system with a UNIX-flavored system call interface and APIs implemented atop that could, in theory, be written solely using system calls by replacing all the non-system-call APIs by reimplementations of those APIs.
However:
so I don't consider "an OS is the software that runs in kernel mode" a particularly useful definition (especially given that there may well be machines that have a more fine-grained privilege level than just kernel vs. user).
I'm not sure what the right definition of "OS" is, but I tend to consider anything that, if removed, would keep the system from running usefully to be part of the OS, which means that, at a minimum, that includes, on a modern UNIX-flavored system, init, the shell that runs the "rc" files, the commands run from the "rc" files as distributed and configured by system installation, and the shared libraries with which those programs are linked - and if that brings in "libc", well, the "libc" in most Linux distributions is either derived from a GNU "libc" or is a GNU "libc", so....
Yes, some of the stuff that falls into that category may also run on other systems, but I don't consider that sufficient reason to consider it "not part of the OS" on a system where it's a standard component of that system - GNU "libc" isn't "part of the OS" if the system has its own "libc", but if the system's "libc" is GNU "libc", I consider that a different matter.
20 years ago, you had to get a license from AT&T to get BSD, as large parts of the code in BSD were based on AT&T UNIX code that hadn't been replaced. They weren't out for World Domination at that point - but, then, Linus Torvalds wasn't our for World Domination when he started working on his kernel, either, as far as I know....
There may well be *BSD hackers who are pissed at Linux users and the whole computer world for appearing to ignore them, but
To what extent did the Linux community "market it, sell it, and create hype about it"? And where did the "marketing, selling, and hype" about Linux come from? I'm not sure it all came from "the Linux hackers".
FreeBSD (and the other freely-available BSDs) have always run on PCs, as I think FreeBSD and NetBSD both came from 386BSD which was a port of Net-2 to, err, umm, the PC.
The first attempt at a completely-free BSD (with all the AT&T code either replaced or blessed as "OK to give out") was, I think, 386BSD, whence came FreeBSD and NetBSD; the "386" in "386BSD" referred to the 80386, because it was a BSD port to the PC.
"The *bsd group" of those days was the Computer Systems Research Group at the University of California, Berkeley, and they certainly did accept contributions from outsiders. However, not all the stuff Sun, SGI, IBM, etc. did with either AT&T UNIX code or BSD code was necessarily sent back to Berkeley by those companies, and not because the Berkeley folk wouldn't accept it. You can't solely blame Berkeley for the existence of N different flavors of UNIX....
That all happened well before the early 1990's; UNIX was well-fragmented by the mid 1980's, with several different proprietary variants, from vendors who largely sold it on their own boxes rather than on, say, IBM-compatible PCs - UNIXes for PCs had existed for a long time, but I don't know how well IN/ix ran on 8088-based PC's (yes, 8088, the one with segmentation but no memory protection), but I suspect it may not have run well enough to push DOS out of the way, and I suspect the same may have been true of the UNIXes for 286-based PCs, although I think Xenix (yes, the Borg's own UNIX, later handed to SCO) may have had a decent market share for small business computers and the like.
"The *bsd crowd", if by that you mean the folks at Berkeley and their successors on the {Free,Net,Open}BSD projects, weren't spearheading the commercial UNIX movement - as far as I know, they were building free OSes for their own purposes, which I think was largely what the Linux community was also doing when they started.
Said market was the commercial UNIX market, not the free UNIX "market"....
Linux has software companies distributing it; for whatever reason, there's no equivalent of Red Hat or SuSE or Caldera or Pacific HiTech or... filling that role for {Free,Net,Open}BSD (no, Walnut Creek CD-ROM isn't in that position, as far as I know), although there is BSDI selling BSD/OS.
"The *bsd community", if, by that, you mean the developers of {Free,Net,Open}BSD is probably more like the Debian community than like Red Hat or SuSE or... in that regard (although the Debian folk aren't necessarily the official "owners" of all the components that go into their distribution - they're the official source of versions of the kernel, libraries, utilities, etc. that go into a Debian release, but they're not the official home of the Linux kernel or GNU "libc" or...).
The FreeBSD Core Team does have 16 members, but the core team, as the list linked to say, "constitutes the project's ``Board of Directors'', responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape" - they're not the sole developers of FreeBSD code. The same probably applies to NetBSD and OpenBSD. There are 151 additional "FreeBSD Developers" "who have commit privileges and do the engineering work on the FreeBSD source tree", and, according to the Contributing to FreeBSD page in the FreeBSD Handbook
Again, the same may be true of NetBSD and OpenBSD; I'm less familiar with those projects.
I don't know how many of the core team or the development team work full-time on FreeBSD, so I can't say that FreeBSD has 167 full-time and (some unknown number of) part-time developers (the latter being those who don't have commit privileges but who do contribute code) - and note that this does not say that FreeBSD has more people working on it than are working on Linux systems, as I don't know if those "30 full time people" counts only people working on the kernel or also counts people working on GNU "libc", GNU utilities that aren't also used in the BSDs, etc..
However, it does suggest that "freebsd has only 15 guys" is a big oversimplification.
There could well be more people working on the stuff that goes into a Linux distribution and that doesn't also go into the BSDs or that isn't also available for BSD (people working on XFree86 aren't "Linux developers", as their stuff goes into the BSDs as well, and the folks working on KDE, at least, aren't "Linux developers", either, as binary packages of KDE 1.1.1 are available for FreeBSD and possibly the other BSDs) than are working on FreeBSD, but this doesn't mean that FreeBSD, or any of the other BSDs, are ipso facto doomed.
12 years before today is 1987; FreeBSD didn't exist then, and Linux didn't just show up today, so FreeBSD wasn't around 12 years longer than Linux. Much of the BSD code was around before Linux existed, but much of the GNU and other code that goes into a Linux distribution was around before Linux existed as well, so I'm not sure {Free,Net,Open}BSD had as big a head start as you seem to think (it did have one, as far as I know, but not a 12 year head start).
...but that doesn't ipso facto mean others are obliged not to say anything that would make it more difficult for those people to hold onto their beliefs. (You may believe it does, but I and I suspect many others don't, and aren't willing just to accept your belief that it does.)
Do you have any solid evidence to support this belief? Did the "myth of Linux" spring up prior to corporate/media/etc. interest in Linux, and help lead to that interest, or did it spring up as, or after, that interest started growing, with the myth being a hook on which journalists could hang their stories about Linux?
(I don't care whether people call it "Linux" or "GNU/Linux" or "Roland the headless Thomson gunner" - and there's a lot of stuff in a Linux distribution that doesn't come from the GNU project, so, if somebody insists that it be called "GNU/Linux" to give credit where credit is due, they should note that even "GNU/Linux" doesn't fully give credit where credit is due - but I've yet to see any solid evidence that the mere use of "GNU/Linux" somehow shatters a fragile myth upon which much of the popularity of Linux is based.)
Compaq's x86 compiler beats Intel's x86 compiler, or Compaq's Alpha compiler beats Intel's Alpha compiler?
(If the answer is "Compaq's Alpha compiler beats Intel's x86 compiler", that should read as "an Alpha system with an XXX MHz 21X64 and a YYY memory subsystem, running code compiled with Compaq's compiler, beat an x86 system with an XXX Mhz Pentium/Pentium Pro/Pentium II/Xeon Warrior Princess and a YYY memory subsystem, running code compiled with Intel's compiler" - crediting that win solely to the compiler requires some evidence to justify it.)
No, it doesn't. It just has a 32-bit base linear address, a 20-bit length (which can either be in units of bytes or 4K pages), and a bunch of other flags. A 48-bit far address gets translated to a 32-bit linear address, and that is what gets translated to a 32-bit or 36-bit physical address via the page table.
See (this page that has a link to the PDF document) Intel Architecture Software Developers Manual Volume 3: System Programming for the full story.
NT 4.0, or NT 5.0^H^H^H^H^H^HW2K? I don't think NT 4.0 supports more than 4GB of physical memory, but W2K, at least in the DataCenter Server edition, will.
See, for example, this note on "Address Windows Extensions and Windows 2000 DataCenter Server", and this press-release-like document which indicates that this is new in W2K and not in NT 4.0, but also seems to imply that memory above 4GB will be available to the page pool (I'd seen stuff that gave me the impression that it would be wired-down memory that had to be specially mapped into a process's address space, but perhaps that's not the case).
You don't need to use segmentation to get at >4GB of physical memory.
In fact, segmentation doesn't even help, given that the x86 MMU maps 48-bit segmented addresses to 32-bit linear addresses before running said addresses through the page table and translating them to 32-bit or 36-bit physical addresses.
However, for any single process to access more than 4GB, it does have to do something that amounts to bank switching, i.e. map stuff into and out of its no-more-than-4GB linear address space as necessary; the same applies to kernel-mode code and the kernel-mode portion of the address space.
Yes, NT (unless you turn on the right boot flag, which might work even in non-enterprise editions) has 2GB of the virtual address space of the machine available to user-mode code and 2GB for kernel-mode code, just as had been the case for Linux all along.
However, I'm not sure that limited you to 2GB of physical RAM on NT, as NT might not require that all of physical memory be mapped into the kernel's address space.
Linux has, for a long time, supported "unlimited user space" in the sense that user-mode code can map stuff into and out of its address space, so that the no-more-than-4GB window you get on a processor with 32-bit linear addresses (e.g., an x86 processor) can be moved around a more-than-4GB set of data. The patch doesn't change that.
However, that's true of most OSes that run on x86 processors, these days.
The issue may be one of whether the extra 4 physical-address lines are actually connected to the world off the chip; that might not be the case on all P6-series processors, even though the processor on the die might contain all the hardware necessary to put non-zero values on those lines.
True, in the sense that at any given instant of time, the linear address space of a process can be no larger than 4GB (and, as segmented addresses get translated to 32-bit linear addresses before being run through the page table, segmentation doesn't help).
However, as I noted in another post, a process could, if the OS lets it (and most OSes you'd run on big machines do, these days), map stuff into and out of its address space, and more than one process could exist on the machine, so you can use it for userland code, userland data, kernel code, kernel data, mapped files, buffer cache, whatever, just as you can use the first 4GB - it's just a question of what the OS does or lets applications do.
Not in the case of P6-core machines; segmentation turns a 48-bit segmented address into a 32-bit linear address. They're using paging, instead, i.e. the page table entries, in one of the 36-bit-physical-address modes, generate more than 32 bits of physical address from 32 bits of (linear) virtual address.
Any one process would have to map stuff into and out of its address space to use more than 4GB (or 4GB minus what kernel-mode code takes) of physical memory, but
Kernel-mode code could also map stuff into and out of its part of the address space.
I vaguely remember reading that Solaris now supports it, although finding detailed technical information on Sun's shiny new Marketing-Driven(TM) Web site looks as if it'd demand more patience than I have.
It's probably a question of whether any "commodity" x86 machines support it; if not, then Solaris for Intel, and UnixWare, may not support it either.
I'm not sure, given that the "enterprise" edition lets it use only 1GB, but note that this is virtual memory, not physical memory - this doesn't mean NT is consuming 2GB of physical memory.
I infer from the stuff I've seen in the "Inside Windows NT" books that it has a common page/buffer cache; the first edition of Inside Windows NT says
which is similar to what some UNIX systems (e.g., SunOS 4.x, SVR4-based systems, FreeBSD, etc.) do; I have the impression that if the Linux kernel doesn't yet have a unified page/buffer cache in a stable kernel, it's going into the 2.3[.x] line.
Most of memory is, in effect, a page cache on these systems, unless you count only pages not currently being used as cached, in which case most of memory not used by pages currently being used is a page cache. In addition, the buffer cache (in the sense of the cache of pages read in from files) is just part of the page cache.
Well, in general, to set up any type of hardware under any operating system requires either that the OS in question include support for that device (whether it supports the device in its "native" mode, or because it can be run in a fashion compatible with a supported device), or that a driver exist that can be added to the OS; that's as true of non-plug-and-play device as of plug-and-play devices.
Yes, and plenty of other organizations (commercial and otherwise) give code names to products/software releases/etc. under development; this hardly constitutes grounds for considering this a sign that Red Hat is now "think[ing] more like their competition".
And what indicates that this is "something other than a completely new version"?