TENEX? Multics? That was back in NCP days--the ARPANET didn't use TCP/IP until the mid-'80s.
I'd have thought they still had TENEX and Multics machines on the ARPANET then. Multics, at least, wasn't, I think, as lively as it was in the '70's, so maybe they had them, but its networking stuff wasn't cutting-edge. Perhaps the same was true of TENEX/TOPS-20. (When did Digital shoot the 10's/20's in the head?)
( Tom Van Vleck's Multics Web siteclaims that TCP/IP was introduced in the late '70's, but, given that RFC 791 says "September 1981" on the cover, he's off by a bit, I think.)
but the first full implementation was done at Berkeley and incorporated into the Berkeley Standard Distibution for VAX and then PDP-11
I'd heard that BBN had a stack for BSD before the 4.1aBSD stack, and that the BSD stack was derived from it, with a lot of changes by Bill Joy; I don't know if that's the case, though.
(I also vaguely remember hearing of older stacks for UNIX, but those may have been NCP stacks.)
(Gee, I wonder if your appearance here will further surprise the guy who was surprised to see me show up on Slashdot; this article seems to have brought out the old folks, for some reason.:-))
Ummm... what? So you're saying that the performance of the TCP/IP stack will in no way affect the performance of snipping packets
coming off the stack Uh, OK...
At least in the BSDs, packets being sniffed "come off the stack" from the network interface driver, and get handed directly to the BPF code; I suspect it may be similar in other UNIX-flavored OSes.
They don't come from the TCP/IP stack; they only pass through that stack if they're IP datagrams intended for that machine or broadcast/multicast to that machine; for sniffing, the interface may be in promiscuous mode, and the bulk of the traffic being seen may not be intended for the sniffing machine, and thus wouldn't go through the stack.
Who wants to bet that this article was commisioned by Microsoft to help stifle the Linux buzz by sewing confusion in the minds of the public and IT management about free Unix systems?
I seem to remember several MSNBC articles, which were somewhat Linux-positive, pointed to by other Slashdot threads, so I wouldn't take the "sneaky Microsoft trick" side of that bet right now.
Perhaps, at that time, they were trying to support their "see, we have plenty of OS competition" argument, and are now trying to sow doubts about Linux.
However, I tend to expand "never explain by malice that which can be adequately explained by stupidity" to "never explain by malice that which can be adequately explained by other means", and, absent further evidence, I find "some journalist at MSNBC thought this might be interesting" an adequate explanation.
I just call it Linux; there are those who, by being either pedantic or sycophantic, depending on your personal beliefs (I do not share the personal beliefs of those who consider it sycophantic), insist on it being called GNU/Linux.
The person to whom was replying said "Linux is GNU!", which could be viewed as saying "it's GNU/Linux", i.e., "a lot of userland code in the OS is from GNU"; as I noted, however, a lot of the userland code isn't from GNU, so calling it "GNU/Linux" doesn't give credit to the authors of much of the stuff in a typical Linux distribution.
Linux has nothing to do with Free Unix. Linux is GNU!
Linux - or, to be pedantic, "a GNU/Linux system", although a pile of the userland stuff in such a system doesn't come from GNU - is a UNIX-compatible operating system that's free software.
As far as I'm concerned, that's enough for me to call it a "free UNIX".
Besides, the BSDs have some GNU userland code as well. Hell, I think some commercial UNIXes have some GNU userland code....
Oh, and I thought "Berkeley Software Distribution"....
You thought entirely correctly. It was originally a distribution of software from Berkeley (until Berkeley stopped doing BSD); a company called Berkeley Software Design, Inc. made a commercial OS out of the Net-2 and later 4.4-Lite BSD releases (with source available; I think the original releases may have come standard with source, for about USD 1000, although a quick look at their site suggests that you pay extra for it now).
(BTW, BSDI's release was originally called BSD/386; it was renamed to BSD/OS when, I think, a SPARC port was made available. They never sold an OS called BSDI....)
duh. if linux wasnt under the GPL all of us GPL developers wouldnt release apps for it..
You are not necessarily representative of all "GPL developers"; the fact that you would prefer to release applications only for GPLed OSes doesn't mean that all developers of GPLed applications would prefer to release them only for GPLed OSes.
In the parenthentical note in the side comment he makes at the end:
...if memory serves, the original IP stacks weren't produced on Unix, but on DEC machines. (eg, PDP-11, VAX)
I think his memory doesn't serve; I think it's more like "(e.g., PDP-10)", although I don't know which OS had the first TCP/IP stack - Multics probably had one fairly early on, too. (We shall ignore the fact that UNIX originally ran on DEC machines - he may have meant "on DEC operating systems", although I wouldn't be surprised to hear that the first PDP-10 TCP/IP stack was on a non-DEC OS, TENEX; yes, I think it eventually became the DEC operating system TOPS-20, but it was originally developed by BBN.)
I wouldn't necessarilly say that BeOS is reusing Linux code, but they do ship their OS with a number of GNU tools
Yes, but I suspect they don't consider whatever changes they made to them to be Corporate Crown Jewels(TM). Had they, say, used the Linux kernel, they would have had to make available any changes they made (although they could perhaps have made some stuff loadable modules and avoided that), which they might not have wanted to do.
Although I don't know anything about Intel's internal simulation tools and methodologies, I'd be surprised if they've even been able to boot an operating system on their simulated design.
I infer from "simulated design" that you mean a simulation of the Merced implementation of the IA-64 architecture, not just a simulation of the IA-64 architecture; other followups have said "they booted {NT, HP-UX} on a simulator", but that might have been a simulation of the IA-64 instruction architecture, rather than simulating Merced at, say, the gate level, and such a simulation wouldn't have tested the Merced design, it'd just have tested the software changes needed to make the OS run on an IA-64 processor.
(I.e., I'm actually replying, in bulk, to the folks who said "but they booted XXX on a simulator" in response to you; booting some OS on an IA-64 simulator doesn't necessarily test the design of a particular implementation of IA-64, and thus doesn't necessarily ferret out bugs in that implementation.)
Linux is the perfect geek OS. We can do with it whatever we want and tailor it to our needs.
Then you can take the a "Linux for the masses" distribution and "tailor it to [your] needs" by adding power options back, etc..
Alternatively, you can run a "Linux for the geeks" distribution; if by
1.Linux for the masses will be consistent across all platforms. No multiple distributions or window managers. One and only one of each.
Todd meant that there should be only one Linux distribution, period, I really don't expect that'll ever happen, I don't think it should happen, and I don't think it's a requirement that it happen in order for there to be a Linux distribution usable by the mass market.
Now, if the distribution you're using is in some way incompatible with the Linux for the Masses distribution, that may mean some application written to run on that distribution won't run on your machine - but that just means you get to choose whether you want to run an incompatible distribution or whether you want to run that application....
How often do "XXX killers" actually kill XXX?
on
Microsoft Janus
·
· Score: 1
I'm curious how many times something touted as an "XXX killer" actually managed to kill XXX, and how many times it didn't. (NOTE: this applies as much to, say, Linux as a Windows killer as it does to, say, NT as a *n*x killer; i.e., don't assume that your favorite technology is "doomed to success", no matter what your favorite technology is....)
A coworker of mine was trying to get this to work a little while back. We tried AcceleratedX and all kinds of wacky settings, but it never seemed to work correctly.
That's odd - the Accelerated-X server (4.1.2, perhaps with an update to add RevIV-FP support, and 5.0) works fine for me on Debian 2.1, Red Hat 5.2, FreeBSD 3.1, and Solaris 7 (except for a couple of glitches).
I would think Caldera would be a much bigger company than both Redhat and SuSE combined. Noorda's personal wealth alone is over $2 Billion last time I heard.
The latter doesn't necessarily imply the former; Noorda's personal wealth may have come from other sources - Novell, say, to pick a hypothetical source at random.:-)
The Nortel equipment (which is rock solid, BTW) could be based on g.lite, but I don't know.
I infer from a brochure they have on it that it might be, at least, similar technology. Unfortunately, their name for it doesn't include the string "DSL", so it took a bit of work to find info about it under Nortel's "Products & Services" page - they call it the "1-Meg Modem" - but I finally found their home page for it; under it is The 1-Meg Modem Bulletin (which is a PDF document, so you'll need a PDF reader to read it), which says, on page 7, in a sidebar:
As an 'early' G.Lite product, the 1-Meg Modem supports the UAWG value proposition of a splitterless solution optimized for the consumer marketplace. This product will naturally evolve to G.Lite compatibility as that standard solidifies.
Re:Little arguments..Re:Bad arguments
on
Feature:GPL vs BSD
·
· Score: 1
And I don't consider FreeBSD/OpenBSD/NetBSD forks. I consider them to be different projects with different goals.
And I don't see how, had they (or 4.4-Lite) been GPLed, that would somehow magically have kept us from having three different free software BSDs (which, as they're free software, can pick up work from the others).
Perhaps their real argument is that, had the BSD code been GPLed, the non-free BSD-derived systems wouldn't hae existed, and are confusing those systems with {Free,Net,Open}BSD, all of which are free software - I've seen no solid reason why GPLing BSD would magically have kept those from coming about, so if people want to offer credible pro-GPL arguments, they should either demonstrate why the GPL would magically have ensure that we have only one BSD that's free software, or stop citing the existence of three of them as an example of the Bad Consequences of the BSDL (of course, others might debate whether that Consequence is, in fact, Bad...).
Hmm, I read on their web-site that the PII backend is 28% faster than M$ VisualC++ and compares with the Intel Proton compiler. So, gcc is now the fastest x86 compiler on the planet
...although that appears to be the GCC-based compiler Cygnus sells; those changes aren't yet in the main GCC code base, if I read the announcement correctly.
Not all that "micro"; file systems, networking stacks, and the device drivers atop which they reside all live in kernel-mode code (even if Microsoft says they're in the "executive" rather than in the "kernel").
but performance was so poor that the clean design was broken, allowing direct access to the hardware. This happened with version 4.0
If you're referring here to moving the GDI subsystem into the kernel, yes, NT 3.x had that in the Win32 subsystem process...
...but it's not the only OS/window system combination that did that; if that was sufficient to render it a microkernel, every UNIX-flavored system with an X server is a microkernel.
Re:After SunView -- XView, Sun's first open source
on
Fifteen Years of X
·
· Score: 1
Actually, if I remember correctly, the ONC RPC library was made available in source form before XView was (just the RPC library, not NFS server or client code), so it wasn't Sun's first opened source.
Well, IRIX ships with a version of sar. I'm not sure what relationship it has with the sar that SCO is donating
They may both be derived, ultimately, from the same chunk of code - the "sar" that came with various SV releases from AT&T, as noted elsewhere. It's not a SCOism....
s to your first question, baggage is all the layers you have in a Linux system. Kernal->libraries->shell->X Windows->Windows Manager->GUI toolkit->Desktop Enviroment->Corba. When Unix was still young, there was only the first three or four layers.
You must've been using X10 (X Version 10, not the X10 home-appliance control system), rather than X11, then; X11 has almost always had window managers and GUI toolkits.
Are you saying that there's too much code there, or that it's too layered, or that there's too much code because it's too layered?
Firstly, the directory structure and PATH argument assume you are typing commands from the command line. There is no standard way of registering applications to the system.
"Registering" in what sense?
Putting them into your desktop environment's menus? If so, that seems to me to argue more for a better way of standardizing root/panel menus (the only reason there's a standardized way of doing that in "Windows 4.0" systems - W95, W98, NT 4.0 and later - is that they came with a single standard desktop environment).
Or registering them as installed applications? If so, that's more a "UNIX diversity" issue - not every commercial UNIX system was SVR4-based, so not all of them had the SVR4 package system, and the free UNIXes ended up rolling their own (multiple ones, in the case of Linux distributions).
Secondly, common Unix things like piping and standard input have no equivalence in a GUI shell.
...which seems to me to argue more that either
UNIX GUI shell developers haven't worked hard enough at trying to develop equivalents or
the concept can't apply in a GUI shell, in which case that's not a bad consequence, it just means that UNIX systems provide facilities convenient to more people than just to GUI users. (For that matter, MS Windows systems - the NT command line, and perhaps the OT command line, let you construct pipelines (which is convenient given that NT's "more" command can't be given a file name argument, it reads only its standard input, unless I've missed something), and let you redirect the standard input and output of command lines.)
But how far can you stretch Unix until it snaps?
Good question. I'm not sure I think anybody knows the answer yet; I suspect you won't find out until it does snap.
And I know some people hate to hear it, but GUIs are the way of the future.
I think they're a way of the future; I often find GUI-based packet capture and analysis program more convenient than text-based ones like "snoop", for example.
I don't think the elimination of CLIs is necessary, however.
E-Mail is for text. Period. If you want to share files, use FTP.
Shipping non-text around was not the (sole) cause of this problem.
I might be tempted to summarize the problem (or, at least, what I see as the key part of the problem) as "self-extracting archives considered harmful" - yes, it's convenient to be able to send somebody a self-extracting zip archive, as you don't have to worry about whether they have an unzipper, but, to unpack it, they then run the archive as a program, and perhaps get in the habit of running binaries that come in the mail.
Mail readers that include unzippers, or unzippers bundled with mail readers, might make it less likely that one would have to mail around self-extracting executables. Unzippers that (if possible) could extract the zip-archive part out of a self-extracting executable, and unzip it directly, rather than running the executable, might help as well.
I know I may think harder before unpacking a shell archive now.... (And they're just text.)
A port of the Linux kernel has been started. It compiles. Some things work, most things don't. System calls seem to work. Context switching works as long as you can avoid sneezing near it. It can mount a file system on a good day...
The Palm port (or, rather, the MMUless microcontroller port, which includes the Palm port) appears to be further along, but I don't know if it's something one could usefully run on a Palm yet or not.
Slashdot Mirror
I'd have thought they still had TENEX and Multics machines on the ARPANET then. Multics, at least, wasn't, I think, as lively as it was in the '70's, so maybe they had them, but its networking stuff wasn't cutting-edge. Perhaps the same was true of TENEX/TOPS-20. (When did Digital shoot the 10's/20's in the head?)
( Tom Van Vleck's Multics Web site claims that TCP/IP was introduced in the late '70's, but, given that RFC 791 says "September 1981" on the cover, he's off by a bit, I think.)
I'd heard that BBN had a stack for BSD before the 4.1aBSD stack, and that the BSD stack was derived from it, with a lot of changes by Bill Joy; I don't know if that's the case, though.
(I also vaguely remember hearing of older stacks for UNIX, but those may have been NCP stacks.)
(Gee, I wonder if your appearance here will further surprise the guy who was surprised to see me show up on Slashdot; this article seems to have brought out the old folks, for some reason. :-))
At least in the BSDs, packets being sniffed "come off the stack" from the network interface driver, and get handed directly to the BPF code; I suspect it may be similar in other UNIX-flavored OSes.
They don't come from the TCP/IP stack; they only pass through that stack if they're IP datagrams intended for that machine or broadcast/multicast to that machine; for sniffing, the interface may be in promiscuous mode, and the bulk of the traffic being seen may not be intended for the sniffing machine, and thus wouldn't go through the stack.
I seem to remember several MSNBC articles, which were somewhat Linux-positive, pointed to by other Slashdot threads, so I wouldn't take the "sneaky Microsoft trick" side of that bet right now.
Perhaps, at that time, they were trying to support their "see, we have plenty of OS competition" argument, and are now trying to sow doubts about Linux.
However, I tend to expand "never explain by malice that which can be adequately explained by stupidity" to "never explain by malice that which can be adequately explained by other means", and, absent further evidence, I find "some journalist at MSNBC thought this might be interesting" an adequate explanation.
Much of the same thing I did, once upon a time, on USENET. :-)
I just call it Linux; there are those who, by being either pedantic or sycophantic, depending on your personal beliefs (I do not share the personal beliefs of those who consider it sycophantic), insist on it being called GNU/Linux.
The person to whom was replying said "Linux is GNU!", which could be viewed as saying "it's GNU/Linux", i.e., "a lot of userland code in the OS is from GNU"; as I noted, however, a lot of the userland code isn't from GNU, so calling it "GNU/Linux" doesn't give credit to the authors of much of the stuff in a typical Linux distribution.
Linux - or, to be pedantic, "a GNU/Linux system", although a pile of the userland stuff in such a system doesn't come from GNU - is a UNIX-compatible operating system that's free software.
As far as I'm concerned, that's enough for me to call it a "free UNIX".
Besides, the BSDs have some GNU userland code as well. Hell, I think some commercial UNIXes have some GNU userland code....
You thought entirely correctly. It was originally a distribution of software from Berkeley (until Berkeley stopped doing BSD); a company called Berkeley Software Design, Inc. made a commercial OS out of the Net-2 and later 4.4-Lite BSD releases (with source available; I think the original releases may have come standard with source, for about USD 1000, although a quick look at their site suggests that you pay extra for it now).
(BTW, BSDI's release was originally called BSD/386; it was renamed to BSD/OS when, I think, a SPARC port was made available. They never sold an OS called BSDI....)
You are not necessarily representative of all "GPL developers"; the fact that you would prefer to release applications only for GPLed OSes doesn't mean that all developers of GPLed applications would prefer to release them only for GPLed OSes.
In the parenthentical note in the side comment he makes at the end:
I think his memory doesn't serve; I think it's more like "(e.g., PDP-10)", although I don't know which OS had the first TCP/IP stack - Multics probably had one fairly early on, too. (We shall ignore the fact that UNIX originally ran on DEC machines - he may have meant "on DEC operating systems", although I wouldn't be surprised to hear that the first PDP-10 TCP/IP stack was on a non-DEC OS, TENEX; yes, I think it eventually became the DEC operating system TOPS-20, but it was originally developed by BBN.)
Yes, but I suspect they don't consider whatever changes they made to them to be Corporate Crown Jewels(TM). Had they, say, used the Linux kernel, they would have had to make available any changes they made (although they could perhaps have made some stuff loadable modules and avoided that), which they might not have wanted to do.
To get their NUMA work?
I infer from "simulated design" that you mean a simulation of the Merced implementation of the IA-64 architecture, not just a simulation of the IA-64 architecture; other followups have said "they booted {NT, HP-UX} on a simulator", but that might have been a simulation of the IA-64 instruction architecture, rather than simulating Merced at, say, the gate level, and such a simulation wouldn't have tested the Merced design, it'd just have tested the software changes needed to make the OS run on an IA-64 processor.
(I.e., I'm actually replying, in bulk, to the folks who said "but they booted XXX on a simulator" in response to you; booting some OS on an IA-64 simulator doesn't necessarily test the design of a particular implementation of IA-64, and thus doesn't necessarily ferret out bugs in that implementation.)
Then you can take the a "Linux for the masses" distribution and "tailor it to [your] needs" by adding power options back, etc..
Alternatively, you can run a "Linux for the geeks" distribution; if by
Todd meant that there should be only one Linux distribution, period, I really don't expect that'll ever happen, I don't think it should happen, and I don't think it's a requirement that it happen in order for there to be a Linux distribution usable by the mass market.
Now, if the distribution you're using is in some way incompatible with the Linux for the Masses distribution, that may mean some application written to run on that distribution won't run on your machine - but that just means you get to choose whether you want to run an incompatible distribution or whether you want to run that application....
I'm curious how many times something touted as an "XXX killer" actually managed to kill XXX, and how many times it didn't. (NOTE: this applies as much to, say, Linux as a Windows killer as it does to, say, NT as a *n*x killer; i.e., don't assume that your favorite technology is "doomed to success", no matter what your favorite technology is....)
That's odd - the Accelerated-X server (4.1.2, perhaps with an update to add RevIV-FP support, and 5.0) works fine for me on Debian 2.1, Red Hat 5.2, FreeBSD 3.1, and Solaris 7 (except for a couple of glitches).
The latter doesn't necessarily imply the former; Noorda's personal wealth may have come from other sources - Novell, say, to pick a hypothetical source at random. :-)
I infer from a brochure they have on it that it might be, at least, similar technology. Unfortunately, their name for it doesn't include the string "DSL", so it took a bit of work to find info about it under Nortel's "Products & Services" page - they call it the "1-Meg Modem" - but I finally found their home page for it; under it is The 1-Meg Modem Bulletin (which is a PDF document, so you'll need a PDF reader to read it), which says, on page 7, in a sidebar:
And I don't see how, had they (or 4.4-Lite) been GPLed, that would somehow magically have kept us from having three different free software BSDs (which, as they're free software, can pick up work from the others).
Perhaps their real argument is that, had the BSD code been GPLed, the non-free BSD-derived systems wouldn't hae existed, and are confusing those systems with {Free,Net,Open}BSD, all of which are free software - I've seen no solid reason why GPLing BSD would magically have kept those from coming about, so if people want to offer credible pro-GPL arguments, they should either demonstrate why the GPL would magically have ensure that we have only one BSD that's free software, or stop citing the existence of three of them as an example of the Bad Consequences of the BSDL (of course, others might debate whether that Consequence is, in fact, Bad...).
...although that appears to be the GCC-based compiler Cygnus sells; those changes aren't yet in the main GCC code base, if I read the announcement correctly.
Not all that "micro"; file systems, networking stacks, and the device drivers atop which they reside all live in kernel-mode code (even if Microsoft says they're in the "executive" rather than in the "kernel").
If you're referring here to moving the GDI subsystem into the kernel, yes, NT 3.x had that in the Win32 subsystem process...
...but it's not the only OS/window system combination that did that; if that was sufficient to render it a microkernel, every UNIX-flavored system with an X server is a microkernel.
Actually, if I remember correctly, the ONC RPC library was made available in source form before XView was (just the RPC library, not NFS server or client code), so it wasn't Sun's first opened source.
They may both be derived, ultimately, from the same chunk of code - the "sar" that came with various SV releases from AT&T, as noted elsewhere. It's not a SCOism....
You must've been using X10 (X Version 10, not the X10 home-appliance control system), rather than X11, then; X11 has almost always had window managers and GUI toolkits.
Are you saying that there's too much code there, or that it's too layered, or that there's too much code because it's too layered?
"Registering" in what sense?
Putting them into your desktop environment's menus? If so, that seems to me to argue more for a better way of standardizing root/panel menus (the only reason there's a standardized way of doing that in "Windows 4.0" systems - W95, W98, NT 4.0 and later - is that they came with a single standard desktop environment).
Or registering them as installed applications? If so, that's more a "UNIX diversity" issue - not every commercial UNIX system was SVR4-based, so not all of them had the SVR4 package system, and the free UNIXes ended up rolling their own (multiple ones, in the case of Linux distributions).
...which seems to me to argue more that either
Good question. I'm not sure I think anybody knows the answer yet; I suspect you won't find out until it does snap.
I think they're a way of the future; I often find GUI-based packet capture and analysis program more convenient than text-based ones like "snoop", for example.
I don't think the elimination of CLIs is necessary, however.
Shipping non-text around was not the (sole) cause of this problem.
I might be tempted to summarize the problem (or, at least, what I see as the key part of the problem) as "self-extracting archives considered harmful" - yes, it's convenient to be able to send somebody a self-extracting zip archive, as you don't have to worry about whether they have an unzipper, but, to unpack it, they then run the archive as a program, and perhaps get in the habit of running binaries that come in the mail.
Mail readers that include unzippers, or unzippers bundled with mail readers, might make it less likely that one would have to mail around self-extracting executables. Unzippers that (if possible) could extract the zip-archive part out of a self-extracting executable, and unzip it directly, rather than running the executable, might help as well.
I know I may think harder before unpacking a shell archive now.... (And they're just text.)
I'd say that, at present, it "limps" rather than "runs" on IBM mainframes; the Web page for S/390 porting efforts says:
The Palm port (or, rather, the MMUless microcontroller port, which includes the Palm port) appears to be further along, but I don't know if it's something one could usefully run on a Palm yet or not.