What is "true"? The claim that "all non-GPL'd software is being taken proprietary and disappearing forever from public view", as per the statement of the person to whom you're responding:
the FUD that Linux folks love to spread about how all non-GPL'd software is being taken proprietary and disappearing forever from public view is getting a bit old.
or the claim that said noise is, in fact, getting a bit old?
If you're asserting that the first claim is "true", then this is a use of "true" to which I was previously unacquainted; the use of "true" with which I'm familiar has connotations such as "in accordance with reality". It is NOT true that "all non-GPL'd software is being taken proprietary and disappearing forever from public view" (unless this is a use of "all" with which I was previously unacquainted, e.g. "all" meaning "some"); the code to FreeBSD, OpenBSD, NetBSD, and X11 are not "proprietary", and are still in public view. Proprietary derivatives of said code have been made, but that doesn't mean the code from which they're derived has been taken public; the attempt of The Open Group to impose restrictions on the redistribution of X11R6.4 source was, fortunately, beaten back - yes, there is the risk that this might happen with other software, and, yes, the GPL would make that more difficult, although note that XFree86's response was to say "we're not upgrading to X11R6.4", as the existing X source releases were still free. Even were one of the BSD groups to decide to impose those sorts of restrictions on the distribution of their OSes - something I consider unlikely, given that, unlike The Open Group, which was composed largely of commercial organizations, they're just collections of developers working on free OSes - earlier releases would continue to be available.
Yes, there is a risk that, by making certain programs open-source, somebody could make use of the information made so available to, for example, commit fraud.
However, it's not clear that this possibility exists with all software that is sold commercially - yes, you could perhaps modify a digitized photograph to show Bill Clinton or Newt Gingrich having sex with Scary Spice by using the GIMP, but you could, as far as I know, do the same with the closed-source Photoshop.
If there were some mechanism to prevent tampering with digitized photographs, or to make such tampering detectable (e.g., some sort of digital signature), then there might be more of a risk with an open-source image editor that implements such a mechanism - but I don't know one way or the other whether no such mechanism can be implemented without keeping it secret. (And, no, that doesn't ipso facto mean that any company doing an image editor would be too afraid to do so - "I don't know one way or the other..." doesn't mean "nobody knows, it'll forever be a fear", it means "I don't know".)
Furthermore, it won't necessarily be the case that the cost of the sort of fraud, etc. that could be committed with an open-source program (or any other source of openness, e.g. published protocols, published file formats, published algorithms; this isn't just a question of open source vs. closed source) will be deemed greater than the benefits of openness. Yes, there have been cases where that sort of fear has dominated - see, for example, the policy of some governments, including but not limited to the US government, towards freely-available encryption technology - but that doesn't prove conclusively that this sort of fear will, of necessity, be dominant.
I.e., I've seen no evidence to suggest that the fear of misuse of a program must be so strong as to prevent any software developer from ever making their source available, so, whilst a more limited version of your conclusion might be valid, I see nothing to suggest that your quite sweeping conclusion ("this is going to be one of the main reasons that open source is most probably never going to take off as a major commercial model") is, of necessity, valid.
but it looks a hell of a lot like MS is getting ready to produce MS linux
Precisely what in the Microsoft page in question would lead one to believe that? (The fact that they're telling you how to uninstall it doesn't mean they plan to offer it to you to install; there are plenty of other places you can get Linux....)
he whole structure of the web page seems to be how to uninstall linux, not how to install Win 2k or Win NT over it.
Presumably they figured that if you had 2K or NT, you also had documentation on how to install it.
Notably WinNT 4.0 better not be a beta, or MS has some answering to do.
NT 4.0 isn't a beta.
Windows 2000, however, is (they only sent the final version to manufacturing a short while ago, and, as I remember, it won't be available until February). That's the "Beta release of a Microsoft product" that they're "discussing" (to the extent that they mention its existence); perhaps they're paranoid that the final release of W2K will require you to do something different as part of the uninstallation procedure of Linux in order to leave the machine in a state in which you can install it.
If you want to install a new package, you tell apt-get to install it, and it figures out what other packages you need.
...and, presumably, gets, or can be told to get, them for you. (FreeBSD pkg_add does that, at least when run with the -r flag to fetch stuff over the Internet - I've not run it in any other mode; I don't know whether the packaging systems in the other BSDs do so, but they might.)
Which packaging systems, if any, keep track of which installed packages are needed by which other installed packages, so that, at minimum, they can tell you "careful, package XXX depends on that" if you try to un-install some package and, potentially, will automatically uninstall any package if it wasn't explicitly installed and if the last package that caused it to be installed as a dependency has been uninstalled?
A lot of drivers are being turned into KLDs, I'm able to load and unload nfs, msdos, vesa, various ethernet cards, USB (doesn't work too well yet), netgraph, cd9660, yadda yadda yadda.
Presumably you mean "a lot more drivers"; I've been running with the VFAT and ISO 9660 file systems as loadable modules for a while, under 3.x.
The ports tree is the best part of FreeBSD: cd/usr/ports/type/port && make install clean makes installing software hassle free.
Or just use pkg_add if you don't care about having the source around. (pkg_add -r is nice for installing from the Internet; Debian has a similar mechanism for downloading and installing, I don't know whether any of the RPM-based package installers do.)
Re:Let's have more integration between *BSD and Li
on
Intel using FreeBSD
·
· Score: 2
For example, the high grade NFS stuff (caching, etc.) should be compatible between Linux and *BSD so that you can run a Linux client with a BSD server, or the other way around.
The NFS stuff should be written as implementations of the NFS v2 and v3 protocols, so that you can run an XXX client with a YYY server, or the other way around. If the Linux server can't work with non-Linux clients, or the Linux client can't work with non-Linux servers, or a BSD server can't work with clients not running that BSD, or a BSD client can't work with servers not running that BSD, that's a bug, and should be fixed. Some day, that client or server may find itself talking to Solaris, or HP-UX, or IRIX, or Digital UNIX, or AIX, or....
If there is some interoperatiblity problem with Linux and other systems, or some BSD and other systems, please let the developers know, so that they can fix it. (Is there, in fact, some interoperability problem to which you're alluding? Or, by the "caching, etc." stuff, are you referring to protocols such as NQNFS, which, as the name suggests, is Not Quite NFS, but is, instead, an NFS-derived protocol with additions above and beyond what's in NFS?)
The implication seems to be that FreeBSD is not optimal for servers.
The implication seems to be that FreeBSD, out of the box, isn't "optimized specifically for file serving"; neither are, as far as I know, Linux, Solaris, HP-UX, Digital UNIX, Windows NT,.... This doesn't ipso facto mean that their performance is "not very good(!!)", it just means that they're at least intended to be reasonably good, out of the box, at a variety of functions, even if this might be at the expense of performance for any particular application.
...to manage the FreeBSD systems used by Hotmail (who were, I suspect, using FreeBSD and Solaris before being bought by Microsoft).
and Intel using FreeBSD
...on a machine that, according to some posts here, comes from another company.
Neither of those are sufficient evidence (except to the excessively suggestible) that this is in any way part of some Grand Plan by Microsoft and Intel to implement a future version of Windows atop FreeBSD (Windows NT, at least, *already* contains "BSD technology" - the FTP client is based on the BSD one - although I've seen no supporting evidence for the claim that NT's Internet protocol stack is based on the BSD one).
Re:This article description is very misleading.
on
Intel using FreeBSD
·
· Score: 2
Have Intel invested in a development effort for FreeBSD on Merced? I don't think so...
"Invested", perhaps not, but I seem to remember reading, in a USENET post from Jordan Hubbard a while back, that Intel would provide them with machines, at least (I infer, perhaps incorrectly, that this means "machines before we publish the entire IA-64 spec and start selling them").
I've never heard of anybody switching from Microsoft to a Linux
No, I said that the person who responded to you, who is the person to whom I was responding, said that, which they DID.
Re:Asynchronous Logging
on
RMS The Coder
·
· Score: 2
Oh, you mean like
O_EXLOCK?
Not exactly - the open(2) man page on my machine says that O_SHLOCK and O_EXLOCK give you locks "with flock(2) semantics", but the flock(2) man page says that they're advisory locks. The "deny {read,write,read+write}" locks on DOS and Windows are mandatory locks - if you deny read access, nobody can open the file for reading, period (I'm not certain whether even privileged users can override that), and if you deny write access, nobody can open the file for writing, period.
Re:Asynchronous Logging
on
RMS The Coder
·
· Score: 2
You can't run tail -f on NT?
You couldn't run a program to do something such as tail -fif whoever was writing to the file opened it with a mode that prohibited other processes from opening the file for reading.
Programs aren't obliged to do that, but they might do that to prevent other programs from reading the file until they're done writing it (so that they don't get incomplete data - of course, the whole point of tail -f is that it should be able to read an incomplete file...).
I don't know whether fopen(file, "w"), say, opens with "deny read" on Windows; CreateFile(), as I remember, lets you specify the "share modes" as an argument, so you can deny read, deny write, deny read or write, or deny nothing to other processes. (CreateFile() is the Win32 equivalent of open(); instead of UNIX/POSIX, where you can create a new file with open(), you can open an existing file with CreateFile() in Win32.)
I'd thin *inux would take care of *edHat, *uSE, *MS (there's an R there, not a Bill)
Then you presumably mean *ebian *NU/*inux, not *MS. *MS is an operating system developed by *igital *quipment *orporation (now a part of *ompaq), running on *axes and, in its *pen*MS incarnation, on *lpha-based systems as well. (Not to be confused with *VS - formerly known as, I think, *S/*S2 *VS, or whatever, and now called *S/390 - a descendant of *S/360, running on *BM mainframes.)
I've never heard of anybody switching from Microsoft to a Linux.
...but that's insufficient reason to believe that nobody's done it. Most users of Microsoft OSes on the desktop may still be using a Microsoft OS on their desktop, but I would not be in the least surprised to hear that at least one member of the Slashdot audience dumped it in favor of Linux (which does notipso facto mean that people will ever do so en masse - I don't expect to see any such move, at least in the short term, and possibly not in the long term - it just means that it's probably foolish to take the fact that nobody you've met has done so as an indication that nobody's done so).
Unlikely, given that the free-software BSDs tend to use as their window system, err, umm, XFree86.
This is largely not a Linux issue, it's an X server issue; Accelerated-X, say, might do better, but, given that my monitor accepts a bit stream rather than an analog signal, I can't really say, based on my experience with Accelerated-X on my monitor, how it handles glass-bottle displays.
What is a mainframe from the point of view of linux? What sort of changes are required to port to a mainframe, particularly to a S390? Folks talk about stuff like IO channels and VMs but what are the salient features that I don't know about?
I/O channels: at least on System/3x0, I/O is done by constructing a "channel program", which is a series of commands whose opcodes tell the channel, and the peripheral attached to it, to perform some operation (read data, write data, search a disk track for a block whose "key" has a certain value, rewind a tape, etc.) - there's also a branch instruction (Transfer in Channel) and, as I remember, some ability to do conditional skips over channel commands. The CPU just issues instructions such as "start I/O" to start a channel program; the channel program does the data transfer.
VMs: one "meta-OS" running on S/3x0 mainframes provides, to the OSes running atop it, a "virtual machine", that looks much like a real S/3x0, and whose disks might be subpartitions of the real machine's disks, whose communications controllers might be part or all of the real machine's communications controllers, whose system console might be the terminal on which the operator of that virtual machine is logged in, etc.. (VMware is somewhat like this.) Linux could run on one of those "virtual machines", and one of the other OSes for S/3x0 could run in another one, so that you can run applications for Linux and applications for, say, OS/390 on the same machine, without having to port a UNIX application from Linux to OS/390 (which has a UNIX environment - but it's not completely like the UNIX environment to which most UNIX programmers might be used, e.g. it doesn't use ASCII as its native character set, it uses IBM's EBCDIC).
Assuming I'm familiar with von Neuman architecures, stack machines, microprocessors, minicomputers, memory mapped memory, memory mapped devices, IO ports, interrupts, and the unix concepts of streams, char devices, block devices, etc... what don't I know about mainframes?
Well, IBM mainframes have a fairly conventional von Neumann-architecture instruction set (CISC, 16 32-bit general-purpose registers, variable-length instructions, memory-to-memory character/decimal arithmetic instructions, memory-to-register and register-to-register binary arithmetic instructions) with some specialized add-ons. The CPUs in them are, these days, microprocessors implementing that instruction set.
I don't know if OS/390 implements memory-mapped files, but the hardware certainly permits it - it has a fairly convention in-memory-page-table MMU.
I/O devices aren't memory-mapped, however; you tell them to do things by telling a channel to send them commands. The channel program can interrupt the CPU either to say that it's finished or, as I remember, to notify it that it's reached a certain point in the program.
The UNIX I/O model isn't what OS/3x0 has traditionally implemented, although the UNIX environment atop it implements that, and a Linux port would implement such an I/O model.
One thing I *do* know from using them briefly, is that IBM "terminals" (3270s? something like that) are really weird: they are not simply connected via a serial cable. They have these extra control signals that light up indicators that say "you can't type now, I'm busy" and the text editors seem to do their editing on the "screen" locally and then send the changes back when you are done. I realize this has nothing to do with the kernel, but it would seem to make the whole experience quite surreal.
How surreal was your experience posting your article? You presumably filled in the text in the "Comment" box, doing any editing locally, and then sent the changes to Slashdot's server when you were done by pressing the "Submit" button.
I remember, several years ago, reading some magazine in which somebody described much of the Web as "3270 for the '90's". A lot of the stuff with HTML forms and HTTP POST operations resembles the way I think 3270's work.
The core instruction set isn't particularly exotic (32-bit, 16 general-purpose registers - although R0, when used as an index or base register, means "use 0 as the value" even though R0 isn't a RISC-style always-zero register; the POWER-family instruction sets may have picked up that idea from S/3x0 - a smaller number of floating-point registers, variable-length-instruction CISC with memory-to-memory string/decimal instructions and memory-to-register arithmetic instructions), although it does have some fairly fancy add-ons, and has an I/O architecture oriented towards handing "programs" to channel controllers to do I/O data transfers.
At least in the case of Linux (not sure about *BSD, I've never seen the source code),
The BSDs are definitely the same in this regard - and, I suspect, most of the commercial UNIXes (definitely true of SunOS 4.x and 5.x, true although to a lesser degree in pre-4.x SunOS which didn't abstract the MMU to the degree 4.x did), and Windows NT, and BeOS, and a pile of other relatively modern OSes are the same in this regard as well.
the reason for this is that very little is actually written in machine-dependent assembler...basically just enough to get the thing booted.
I wouldn't put it in exactly that fashion - the assembler-language code is also used to manipulate things not directly manipulatable from C (e.g., flushing caches and TLBs; no, writing assembler-language code using "asm"s does not let you manipulate that stuff from C, it lets you include in the midst of C code non-C code to manipulate them - "asm"s are no more portable than assembler-language subroutines, in fact they could be thought of as inline assembler-language subroutines) at times other than just when you're booting.
In addition, there may be C code that is machine-dependent as well, in that it might e.g. construct page tables.
However, the point remains that the bulk of the code running in kernel mode isn't that sort of machine-dependent code - file systems, process manipulation above the low-level code for stuff such as context switching, network protocol implementations, and even a lot of drivers are largely machine-independent code, as you noted:
Most of the rest of the kernel is written in highly-portable C code.
Depends if the S/390 support is for their PowerPC-based CMOS boxes or not.. the CMOS boxes are pretty efficient (about the size of a RS6000 990)
...and aren't PowerPC-based. The System/3xx instruction set isn't the same as PowerPC; it's a 16-general-register CISC instruction set, with variable-length instructions, memory-to-memory instructions, and register-to-memory arithmetic instructions.
Perhaps you're thinking of the AS/400's, which moved from an apparently 3x0-ish CISC instruction set to an extended PowerPC instruction set - but the ABI for S/38 and AS/400 boxes isn't the native instruction set, it's a higher-level "virtual" instruction set, that gets translated to the native instruction set by low-level OS code; the ABI for S/3x0 is the S/3x0 instruction set plus the OS calls.
I think Oracle does as well, but their Web site requires Javascript and, as I'm currently running a UNIX version of Communicator, there's no way I'm turning Javacrash^H^H^H^H^Hscript on.
The reason a microkernel based OS is easier to port is that there's less there to port.
...in the sense that there's less kernel code to port.
However. rather a lot of kernel code (in the sense of "code running in kernel mode") doesn't need to be ported, it just needs recompilation; is the amount of code that has to be changed to run on a different platform actually significantly smaller on microkernel-based OSes? (If you answer "yes", please back up the assertion with figures for several "traditional" OSes and at least one microkernel-based OS.)
He says that they had a Y2K test a few months ago that caused the gate to misbehave
See my other comment on something that sounded like this story (except that, if I remember correctly, the sewage was dumped into a park, not into a lake or river); was it a Y2K problem that caused the gate to misbehave, or was it some other problem that showed up because, as part of their testing, they shut power off? (Which means that the problem, as per my other comment, is arguably worse than a Y2K problem, as power can go away for other reasons....)
Anyone remember a few months ago the story about a town that was doing Y2K tests on their sewage system and raw sewage shot up from the sewers and flooded the streets?
Yes. The news article I saw recently (it was an old article, but I think it was linked to from the Jon Katz article here) didn't indicate, as I remember, whether the problem was that a not-Y2K-ready system got confused and dumped raw sewage, or that, when they shut the power off to simulate a power failure, the system got confused and dumped raw sewage - in which case the system
isn't necessarily not Y2K-ready;
has what's arguably a worse problem, given that there are reasons why power could go out other than a not-Y2K-ready system in some electricity supplier.
If that's the case, one hopes they've fixed the problem by now - for reasons having nothing to do with Y2K....
I'm also curious whether part of the problem being reported involved, for example, no testing or contingency plans having been completed by June 1999 (as per the article saying
The report said fewer than half of the drinking water utilities had completed all phases of Y2K preparations, including contingency planning and testing, as of June 1999, the date of the last industry survey.
in which case the systems might not actually be broken, or there might not be a need for the contingency plans.
On the other hand, testing doesn't ipso facto guarantee that the systems won't have a problem, so that particular knife cuts both ways; there may well be systems that passed their testing but fail anyway.
(My personal suspicion is that many optimists will be surprised by problems occurring that they didn't expect to happen, and many pessimists will be surprised by problems not occurring that they did expect to happen. I suspect we've evolved not to like uncertainty, and tend to become sure of things even when the evidence is equivocal....)
Slashdot Mirror
What is "true"? The claim that "all non-GPL'd software is being taken proprietary and disappearing forever from public view", as per the statement of the person to whom you're responding:
or the claim that said noise is, in fact, getting a bit old?
If you're asserting that the first claim is "true", then this is a use of "true" to which I was previously unacquainted; the use of "true" with which I'm familiar has connotations such as "in accordance with reality". It is NOT true that "all non-GPL'd software is being taken proprietary and disappearing forever from public view" (unless this is a use of "all" with which I was previously unacquainted, e.g. "all" meaning "some"); the code to FreeBSD, OpenBSD, NetBSD, and X11 are not "proprietary", and are still in public view. Proprietary derivatives of said code have been made, but that doesn't mean the code from which they're derived has been taken public; the attempt of The Open Group to impose restrictions on the redistribution of X11R6.4 source was, fortunately, beaten back - yes, there is the risk that this might happen with other software, and, yes, the GPL would make that more difficult, although note that XFree86's response was to say "we're not upgrading to X11R6.4", as the existing X source releases were still free. Even were one of the BSD groups to decide to impose those sorts of restrictions on the distribution of their OSes - something I consider unlikely, given that, unlike The Open Group, which was composed largely of commercial organizations, they're just collections of developers working on free OSes - earlier releases would continue to be available.
Yes, there is a risk that, by making certain programs open-source, somebody could make use of the information made so available to, for example, commit fraud.
However, it's not clear that this possibility exists with all software that is sold commercially - yes, you could perhaps modify a digitized photograph to show Bill Clinton or Newt Gingrich having sex with Scary Spice by using the GIMP, but you could, as far as I know, do the same with the closed-source Photoshop.
If there were some mechanism to prevent tampering with digitized photographs, or to make such tampering detectable (e.g., some sort of digital signature), then there might be more of a risk with an open-source image editor that implements such a mechanism - but I don't know one way or the other whether no such mechanism can be implemented without keeping it secret. (And, no, that doesn't ipso facto mean that any company doing an image editor would be too afraid to do so - "I don't know one way or the other..." doesn't mean "nobody knows, it'll forever be a fear", it means "I don't know".)
Furthermore, it won't necessarily be the case that the cost of the sort of fraud, etc. that could be committed with an open-source program (or any other source of openness, e.g. published protocols, published file formats, published algorithms; this isn't just a question of open source vs. closed source) will be deemed greater than the benefits of openness. Yes, there have been cases where that sort of fear has dominated - see, for example, the policy of some governments, including but not limited to the US government, towards freely-available encryption technology - but that doesn't prove conclusively that this sort of fear will, of necessity, be dominant.
I.e., I've seen no evidence to suggest that the fear of misuse of a program must be so strong as to prevent any software developer from ever making their source available, so, whilst a more limited version of your conclusion might be valid, I see nothing to suggest that your quite sweeping conclusion ("this is going to be one of the main reasons that open source is most probably never going to take off as a major commercial model") is, of necessity, valid.
Precisely what in the Microsoft page in question would lead one to believe that? (The fact that they're telling you how to uninstall it doesn't mean they plan to offer it to you to install; there are plenty of other places you can get Linux....)
Presumably they figured that if you had 2K or NT, you also had documentation on how to install it.
NT 4.0 isn't a beta.
Windows 2000, however, is (they only sent the final version to manufacturing a short while ago, and, as I remember, it won't be available until February). That's the "Beta release of a Microsoft product" that they're "discussing" (to the extent that they mention its existence); perhaps they're paranoid that the final release of W2K will require you to do something different as part of the uninstallation procedure of Linux in order to leave the machine in a state in which you can install it.
...and, presumably, gets, or can be told to get, them for you. (FreeBSD pkg_add does that, at least when run with the -r flag to fetch stuff over the Internet - I've not run it in any other mode; I don't know whether the packaging systems in the other BSDs do so, but they might.)
Which packaging systems, if any, keep track of which installed packages are needed by which other installed packages, so that, at minimum, they can tell you "careful, package XXX depends on that" if you try to un-install some package and, potentially, will automatically uninstall any package if it wasn't explicitly installed and if the last package that caused it to be installed as a dependency has been uninstalled?
Presumably you mean "a lot more drivers"; I've been running with the VFAT and ISO 9660 file systems as loadable modules for a while, under 3.x.
Or just use pkg_add if you don't care about having the source around. (pkg_add -r is nice for installing from the Internet; Debian has a similar mechanism for downloading and installing, I don't know whether any of the RPM-based package installers do.)
The NFS stuff should be written as implementations of the NFS v2 and v3 protocols, so that you can run an XXX client with a YYY server, or the other way around. If the Linux server can't work with non-Linux clients, or the Linux client can't work with non-Linux servers, or a BSD server can't work with clients not running that BSD, or a BSD client can't work with servers not running that BSD, that's a bug, and should be fixed. Some day, that client or server may find itself talking to Solaris, or HP-UX, or IRIX, or Digital UNIX, or AIX, or....
If there is some interoperatiblity problem with Linux and other systems, or some BSD and other systems, please let the developers know, so that they can fix it. (Is there, in fact, some interoperability problem to which you're alluding? Or, by the "caching, etc." stuff, are you referring to protocols such as NQNFS, which, as the name suggests, is Not Quite NFS, but is, instead, an NFS-derived protocol with additions above and beyond what's in NFS?)
The implication seems to be that FreeBSD, out of the box, isn't "optimized specifically for file serving"; neither are, as far as I know, Linux, Solaris, HP-UX, Digital UNIX, Windows NT, .... This doesn't ipso facto mean that their performance is "not very good(!!)", it just means that they're at least intended to be reasonably good, out of the box, at a variety of functions, even if this might be at the expense of performance for any particular application.
...to manage the FreeBSD systems used by Hotmail (who were, I suspect, using FreeBSD and Solaris before being bought by Microsoft).
...on a machine that, according to some posts here, comes from another company.
Neither of those are sufficient evidence (except to the excessively suggestible) that this is in any way part of some Grand Plan by Microsoft and Intel to implement a future version of Windows atop FreeBSD (Windows NT, at least, *already* contains "BSD technology" - the FTP client is based on the BSD one - although I've seen no supporting evidence for the claim that NT's Internet protocol stack is based on the BSD one).
"Invested", perhaps not, but I seem to remember reading, in a USENET post from Jordan Hubbard a while back, that Intel would provide them with machines, at least (I infer, perhaps incorrectly, that this means "machines before we publish the entire IA-64 spec and start selling them").
No, I said that the person who responded to you, who is the person to whom I was responding, said that, which they DID .
Not exactly - the open(2) man page on my machine says that O_SHLOCK and O_EXLOCK give you locks "with flock(2) semantics", but the flock(2) man page says that they're advisory locks. The "deny {read,write,read+write}" locks on DOS and Windows are mandatory locks - if you deny read access, nobody can open the file for reading, period (I'm not certain whether even privileged users can override that), and if you deny write access, nobody can open the file for writing, period.
You couldn't run a program to do something such as tail -f if whoever was writing to the file opened it with a mode that prohibited other processes from opening the file for reading.
Programs aren't obliged to do that, but they might do that to prevent other programs from reading the file until they're done writing it (so that they don't get incomplete data - of course, the whole point of tail -f is that it should be able to read an incomplete file...).
I don't know whether fopen( file , "w"), say, opens with "deny read" on Windows; CreateFile(), as I remember, lets you specify the "share modes" as an argument, so you can deny read, deny write, deny read or write, or deny nothing to other processes. (CreateFile() is the Win32 equivalent of open(); instead of UNIX/POSIX, where you can create a new file with open(), you can open an existing file with CreateFile() in Win32.)
Then you presumably mean *ebian *NU/*inux, not *MS. *MS is an operating system developed by *igital *quipment *orporation (now a part of *ompaq), running on *axes and, in its *pen*MS incarnation, on *lpha-based systems as well. (Not to be confused with *VS - formerly known as, I think, *S/*S2 *VS, or whatever, and now called *S/390 - a descendant of *S/360, running on *BM mainframes.)
...but that's insufficient reason to believe that nobody's done it. Most users of Microsoft OSes on the desktop may still be using a Microsoft OS on their desktop, but I would not be in the least surprised to hear that at least one member of the Slashdot audience dumped it in favor of Linux (which does not ipso facto mean that people will ever do so en masse - I don't expect to see any such move, at least in the short term, and possibly not in the long term - it just means that it's probably foolish to take the fact that nobody you've met has done so as an indication that nobody's done so).
Or Mainsoft is, with MainWin for Linux (Mainsoft's MainWin is what Microsoft used to port IE5 to UNIX (and IE4 before that).
Unlikely, given that the free-software BSDs tend to use as their window system, err, umm, XFree86.
This is largely not a Linux issue, it's an X server issue; Accelerated-X, say, might do better, but, given that my monitor accepts a bit stream rather than an analog signal, I can't really say, based on my experience with Accelerated-X on my monitor, how it handles glass-bottle displays.
I/O channels: at least on System/3x0, I/O is done by constructing a "channel program", which is a series of commands whose opcodes tell the channel, and the peripheral attached to it, to perform some operation (read data, write data, search a disk track for a block whose "key" has a certain value, rewind a tape, etc.) - there's also a branch instruction (Transfer in Channel) and, as I remember, some ability to do conditional skips over channel commands. The CPU just issues instructions such as "start I/O" to start a channel program; the channel program does the data transfer.
VMs: one "meta-OS" running on S/3x0 mainframes provides, to the OSes running atop it, a "virtual machine", that looks much like a real S/3x0, and whose disks might be subpartitions of the real machine's disks, whose communications controllers might be part or all of the real machine's communications controllers, whose system console might be the terminal on which the operator of that virtual machine is logged in, etc.. (VMware is somewhat like this.) Linux could run on one of those "virtual machines", and one of the other OSes for S/3x0 could run in another one, so that you can run applications for Linux and applications for, say, OS/390 on the same machine, without having to port a UNIX application from Linux to OS/390 (which has a UNIX environment - but it's not completely like the UNIX environment to which most UNIX programmers might be used, e.g. it doesn't use ASCII as its native character set, it uses IBM's EBCDIC).
Well, IBM mainframes have a fairly conventional von Neumann-architecture instruction set (CISC, 16 32-bit general-purpose registers, variable-length instructions, memory-to-memory character/decimal arithmetic instructions, memory-to-register and register-to-register binary arithmetic instructions) with some specialized add-ons. The CPUs in them are, these days, microprocessors implementing that instruction set.
I don't know if OS/390 implements memory-mapped files, but the hardware certainly permits it - it has a fairly convention in-memory-page-table MMU.
I/O devices aren't memory-mapped, however; you tell them to do things by telling a channel to send them commands. The channel program can interrupt the CPU either to say that it's finished or, as I remember, to notify it that it's reached a certain point in the program.
The UNIX I/O model isn't what OS/3x0 has traditionally implemented, although the UNIX environment atop it implements that, and a Linux port would implement such an I/O model.
How surreal was your experience posting your article? You presumably filled in the text in the "Comment" box, doing any editing locally, and then sent the changes to Slashdot's server when you were done by pressing the "Submit" button.
I remember, several years ago, reading some magazine in which somebody described much of the Web as "3270 for the '90's". A lot of the stuff with HTML forms and HTTP POST operations resembles the way I think 3270's work.
The instruction set and I/O architecture of S/390 is described by ESA/390 Principles of Operation. Links to that and some other manuals can be found on the Linux on the IBM ESA/390 Mainframe Architecture page.
And, for people curious what instruction set S/3x0's implement, read the ESA/390 Principles of Operation.
The core instruction set isn't particularly exotic (32-bit, 16 general-purpose registers - although R0, when used as an index or base register, means "use 0 as the value" even though R0 isn't a RISC-style always-zero register; the POWER-family instruction sets may have picked up that idea from S/3x0 - a smaller number of floating-point registers, variable-length-instruction CISC with memory-to-memory string/decimal instructions and memory-to-register arithmetic instructions), although it does have some fairly fancy add-ons, and has an I/O architecture oriented towards handing "programs" to channel controllers to do I/O data transfers.
The BSDs are definitely the same in this regard - and, I suspect, most of the commercial UNIXes (definitely true of SunOS 4.x and 5.x, true although to a lesser degree in pre-4.x SunOS which didn't abstract the MMU to the degree 4.x did), and Windows NT, and BeOS, and a pile of other relatively modern OSes are the same in this regard as well.
I wouldn't put it in exactly that fashion - the assembler-language code is also used to manipulate things not directly manipulatable from C (e.g., flushing caches and TLBs; no, writing assembler-language code using "asm"s does not let you manipulate that stuff from C, it lets you include in the midst of C code non-C code to manipulate them - "asm"s are no more portable than assembler-language subroutines, in fact they could be thought of as inline assembler-language subroutines) at times other than just when you're booting.
In addition, there may be C code that is machine-dependent as well, in that it might e.g. construct page tables.
However, the point remains that the bulk of the code running in kernel mode isn't that sort of machine-dependent code - file systems, process manipulation above the low-level code for stuff such as context switching, network protocol implementations, and even a lot of drivers are largely machine-independent code, as you noted:
...and aren't PowerPC-based. The System/3xx instruction set isn't the same as PowerPC; it's a 16-general-register CISC instruction set, with variable-length instructions, memory-to-memory instructions, and register-to-memory arithmetic instructions.
Perhaps you're thinking of the AS/400's, which moved from an apparently 3x0-ish CISC instruction set to an extended PowerPC instruction set - but the ABI for S/38 and AS/400 boxes isn't the native instruction set, it's a higher-level "virtual" instruction set, that gets translated to the native instruction set by low-level OS code; the ABI for S/3x0 is the S/3x0 instruction set plus the OS calls.
S/390 Linux, or S/390 OS/390? In either case, there are links from the Linux on the ESA/390 Mainframe Architecture page.
Yeah, it's so nice that, now that Linux will be running on S/390, they'll finally be able to run SAP on OS/390's.
Oh, wait, they already can.
I think Oracle does as well, but their Web site requires Javascript and, as I'm currently running a UNIX version of Communicator, there's no way I'm turning Javacrash^H^H^H^H^Hscript on.
...in the sense that there's less kernel code to port.
However. rather a lot of kernel code (in the sense of "code running in kernel mode") doesn't need to be ported, it just needs recompilation; is the amount of code that has to be changed to run on a different platform actually significantly smaller on microkernel-based OSes? (If you answer "yes", please back up the assertion with figures for several "traditional" OSes and at least one microkernel-based OS.)
See my other comment on something that sounded like this story (except that, if I remember correctly, the sewage was dumped into a park, not into a lake or river); was it a Y2K problem that caused the gate to misbehave, or was it some other problem that showed up because, as part of their testing, they shut power off? (Which means that the problem, as per my other comment, is arguably worse than a Y2K problem, as power can go away for other reasons....)
Yes. The news article I saw recently (it was an old article, but I think it was linked to from the Jon Katz article here) didn't indicate, as I remember, whether the problem was that a not-Y2K-ready system got confused and dumped raw sewage, or that, when they shut the power off to simulate a power failure, the system got confused and dumped raw sewage - in which case the system
If that's the case, one hopes they've fixed the problem by now - for reasons having nothing to do with Y2K....
I'm also curious whether part of the problem being reported involved, for example, no testing or contingency plans having been completed by June 1999 (as per the article saying
in which case the systems might not actually be broken, or there might not be a need for the contingency plans.
On the other hand, testing doesn't ipso facto guarantee that the systems won't have a problem, so that particular knife cuts both ways; there may well be systems that passed their testing but fail anyway.
(My personal suspicion is that many optimists will be surprised by problems occurring that they didn't expect to happen, and many pessimists will be surprised by problems not occurring that they did expect to happen. I suspect we've evolved not to like uncertainty, and tend to become sure of things even when the evidence is equivocal....)