We've added Compaq's beta FORTRAN for Alpha Linux to this website and it's getting rave reviews from test drivers! Register for the test drive today and check it out! COMING SOON: SuSe Linux on Alpha and Proliant and Compaq's beta C Compiler--optimized for Alpha Linux
...(acc. to reports now circulating) Intergraph has thrown in the towel. No more PC's --no workstatiuons, no servers.
This press release (it's also on Intergraph's Web site, but the version there appears to be infested with non-ISO-8859/1 Windows characters) says that they will "Exit the PC and generic server business, which suffered irreparable harm from Intel's actions.", but that they'll "Strengthen the high-end workstation and graphics accelerator businesses by seeking partners with complementary technology and sales channels for Intergraph Computer Systems' ViZual Computing and Intense3D units.", although I don't know whether the bit about "Focus[sing] on Software and Services" means they'll eventually sell the hardware business off to a partner.
One sign the Linus does not thought big enough is the 2 GB File limitation Linux has/had on 32 Bit systems, BSD never had them.
Define "never" and "BSD". It wasn't until 4.4 (or maybe Net-2) that 64-bit file offsets were supported in BSD; 4.2BSD, 4.3BSD, and 4.3-Tahoe didn't have 64-bit file offsets.
...presumably referring to binary-only software, or to sourceware that uses Linux-specific features or otherwise requires tweaking to make it run on other UNIX-compatible systems; if some software was written by somebody using a Linux box, but "accidentally" happens to be generic UNIX-compatible software, it's not really Linux software, it's generic UNIX-compatible software.
FreeBSD kernel is monolithic this way effectively preventing hardware support by manufacturer without the manufacturer supplying the source code.
Eh? The Linux kernel is "monolithic" as well, if loadable kernel modules don't imply "non-monolithic", and Linux and FreeBSD (and possibly the other BSDs) both have loadable kernel modules. Even if the driver isn't a loadable module, they could supply a ".o" to be linked with the kernel.
These days, thanks to *BSD's package system, it is very easy to download and run software; it takes longer than just getting the binary RPM's and DEB's, but it's often more likely to work because you're compiling it for _your_ system.
If you're using packages rather than ports, you're not compiling it for your system, you're just downloading a binary package. (I.e., FreeBSD, and, I think, at least some of the other BSDs, also offer a system for downloading and installing binaries, as well as a system for grabbing source.)
What does this deal mean for other thin-client productivity software, such as Applixware? This office suite was completely written in Java(afaik)
Applix's office software antedates Java, and I hadn't heard that it'd been rewritten in Java; where had you heard that it had? (I assume that you were calling it "thin-client" software as you thought it'd been written in Java.)
and Applix has opened the source code.
Unless I missed something on their site, the only thing they've open-sourced is their extension language; they haven't open-sourced Applixware as a whole.
UID 0 is superuser on Unix, true. It is *not* necessarily root. You should, and on real Unixen you safely can, be able to rename UID 0, say, bofh, and have root be a non-privileged, non-uid 0 user.
Umm, that sounds like a non-kernel issue, unless there's some place in the kernel that cares about the name assigned to an account so I'm not sure what the complaints about UFS and NFS, both of which live in the kernel in FreeBSD, involved.
If you want UID 0 to be privileged, regardless of whether it's named "root" or not, and want only UID 0 to be privileged, regardless of whether some other UID has the name "root", a check for UID == 0 (or, to be precise, for effective UID == 0) would be the correct test.
(I hope you're complaint isn't about the fact that nfs_access() speaks of "root" in the comment right before it checks whether ap->a_cred->cr_uid == 0, given that it could have said "Roland the Headless Thompson Gunner" instead of "root" in the comment without changing the behavior of the code - which is checking to make sure that it doesn't tell code running as UID 0 that it has access to a file when, in fact, it doesn't have access because the server has mapped client UID 0 to some other UID on the server; this is for NFS V2, where there's no RPC to ask "how much access do I really have?").
(As for suser(), well, I seem to remember that in the UNIXes of long ago, it checked whether, err, umm, the effective UID was 0; the main reason it existed was to set the "super-user privileges were used" accounting flag. Perhaps Shiny New Modern real UNIXes it does something else.)
My cablemodem works just fine in Linux. Why shouldn't it? All I need is for Linux to recognize my ethernet card and do DHCP properly.
Perhaps the original poster meant, by "USB scanner and cablemodem", "(USB) (scanner and cablemodem)", i.e. "USB scanner and USB cable modem", not "USB scanner and (Ethernet) cable modem". The GVC Corporation has a USB cable modem, and the Intel Architecture Labs have a reference design for USB cable modems.
(I make no comments about the relative merits of USB and Ethernet cable modems, nor am I saying anything about how easy or hard it is to get USB cable modems to work on FreeBSD or Linux, I'm just noting that USB cable modems are being designed, and some appear to already exist.)
His original question was very specific about BSD ports for VAX machines
Assuming that's a serious statement, his original question could either be interpreted with the subject line being "(Improvements since BSD4.*) (on Vaxen)", i.e., "what improvements, on the VAX platform, have there been since BSD 4.*", with "that scene" in "I'd quite like to delve back into that scene" being "BSD on VAXes", or with the subject line being "(Improvements since BSD4.* on Vaxen)", i.e. "what improvements have there been in BSD since the days when BSD4.* ran mainly on VAXes", with "that scene" being "BSD in general".
I infer from "back in the days of the good o' Vax machines" that the original poster sees the days of the VAX as gone, and that the second interpretation of the question is valid; I'm unlikely to accept the first interpretation unless the original poster says that's what he or she intended.
I have the impression that many Win32 APIs are implemented in NT as user-mode library code atop the NT system call interface, i.e. not all calls to Win32 system services involve the Win32 subsystem process (the first edition of Inside Windows NT says that "In addition to a flexible, optimized message-passing facility, the Windows NT developers established some 'tricks' that reduce the number of interactions a client [e.g., a Win32 application, or an OS/2 application, or a POSIX application] must make with a server [e.g., the Win32, OS/2, or POSIX subsystem processes]:... Using client-side DLLs to implement the API routines that don't use or modify global data.").
Microsoft made numerous commitments to the OS/2 project and denied continuing Windows development (and fledgling NT development)
Umm, at the time, wasn't "fledgling NT development" the development of OS/2 NT? (The article even says as much.) I had the impression that the original intent was to build the Next Generation of OS/2 on top of New Technology, and that Microsoft turned OS/2 NT into Windows NT when they decided that Windows, not OS/2, was the wave of the future.
Now, the fact that Linux did pretty well at that despite its x86-originated design is largely a matter of emulating the design of UNIX -- which had been designed for portability back in about 1970.
Not exactly. UNIX was originally done in PDP-7 assembler (for the benefit of the younger members of the audience, that "7" is not a typo), redone in PDP-11 assembler, and then redone in C, but that wasn't for portability; the first porting work at AT&T, at least, was done in the mid-to-late '70's with a port to the Interdata 8/32 (various ports had been done by other folk outside AT&T) - V7 was, I think, the first UNIX released outside AT&T that included the results of that work.
Linux's API was a UNIX API, and the UNIXes of that day (and of the present) have an API that's basically a V7 superset (the V7 API fixed a pile of somewhat ugly non-portable bits, e.g. stat() filled in a structure rather than an array of ints), so at the API level perhaps it inherited portability from UNIX, but the kernel implementation, at least, wasn't based on an AT&T implementation - and I have the impression that the original Linux kernel directly used a number of x86isms.
Dave Cutler was the chief architect of VMS, so your view that he stole his own design concepts is rather odd.
Yeah, that seems pretty bogus to me; much of the I/O subsystem seems similar between the two OSes (down to some of the data structures such as I/O request packets having the same name), but to infer from this that Microsoft stole VMS code, as some have seemed to do, is a bit extreme - reusing ideas from previous projects hardly qualifies as "theft" to me.
At any rate, NT is very different to VMS. NT was designed as a portable client/server (microkernel) OS. VMS was designed as a hardware-dependent monolithic OS.
Which of the two OSes in question had file system code running in userland, and which runs it in kernel mode?:-)
(Hint: the answer to the first question is "VMS, at least at one point" - I have the impression they moved the file system code for Files-11 ODS-2 from the Files-11 Ancillary Control Process, or whatever it was called, into kernel-mode code at some point - and the answer to the second question is "Microsoft(R) Windows(R) NT(TM)".)
Yes, NT does move some of the part of various APIs not implemented in userland libraries out to subsystem processes, but, at least from reading the two editions of Inside Windows NT, it appears that a lot of it lives inside kernel-mode code (e.g., device drivers, file systems, the networking stack).
NT is an interesting design, but I'm not sure I'd call it a "microkernel" - more of a hybrid.
Any how those germans love linux, they come in at a staggering 46 contributers compared to a measly runner up 16 for.uk, though wales did produce alan, so all is forgiven.
I'd love to see some statistics on the contributions of people from various countries to various free software projects, relative to the populations of those countries - or to the number of people involved in software development in those countries. I suspect that there are some that have significantly higher per-capita contributions than others (and that Germany'd be one of the ones with higher levels of contributions); if so, I'd be curious what the reason(s) are....
To which sample are you referring? The "90%" sample? Yes, it'd be random, in which case, as I said, I suspect that 90% of them have never tried to get anything to run on Linux, as they've never tried Linux.
If you took a newbie windows user and a newbie linux user and had each to install the same cd burner in an existing machine who would burn the first cd? If you guessed the windows newbie then you probably guessed right. I'll let our cohost tell you what prize you've won.
Spiffy. Do I win the two-week vacation in New York? (If the fact that I guessed the Windows user would probably burn the first CD, at least with the current state of Linux, comes as a surprise to you, you might want to think about checking your prejudices at the door next time. Hint: just because I indicated that your statement about "90% of computer users can't get anything to run on Linux" was rhetorical rather than realistic, because "90% of computer users" haven't tried Linux, that doesn't mean I think they'd find Linux a snap at present. That doesn't mean that this will never change, although I suspect that, as a mass-market OS, Linux is unlikely to be more than a runner-up in the near to medium-term future, and may never be more than a runner-up - but that may be sufficient to let it be a reasonable desktop OS.)
If you support the newer ALSA and end-user doesn't have it they will be required to download it to use your program.
...which suggests either that distributions aimed at end-users should offer all the APIs likely to be used by applications (OSS and ALSA, for example), or application writers should limit themselves to APIs present in all distributions, or application writers should bundle an implementation of said API with their application, if possible, and install it with the application if it's missing, or that they should do something such as trying to load up the API libraries at run-time with "dlopen()" and find symbols in them with "dlsym()", and fall back on other APIs or disable the feature that uses the API if they fail (I have the impression Windows apps use the latter two strategies).
What I meant by implementing OS features was if someone working on GNOME or whatever wanted to implement a Linux feature into GNOME it would be a hack to the system to make it work.
To what are you referring here? What do you mean by "implement a Linux feature into GNOME"? Providing support for a Linux feature, e.g. having a tool that shows what hardware you have by scanning the appropriate parts of "/proc"? If so, why sould that be "a hack to the system to make it work"?
...say you have an office application. This application wants to use plug-ins. Well plug-ins (dlopen) work on Linux, but don't on certain other OSes.
To which modern UNIXes are you referring here when you say "certain other OSes"? SunOS 4.0 doesn't have "dlopen()", but it's not "modern"; SunOS 4.1 has it (it may have been the first OS to implement "dlopen()", although it was originally an AT&T invention - I think 4.1 came out before the first SVR4 release, which also had "dlopen()"; no, "dlopen()" wasn't a Linux invention). SVR4-flavored UNIXes have it, the open-source BSDs have it, Digital UNIX has it, sufficiently-recent AIX's have it; HP-UX has its own shared library mechanism, with its own equivalent of "dlopen()", but may now have a "dlopen()"/"dlsym()"/etc. wrapper.
You can create a x86 glibc GNOME binary but it's not going to run on x86 libc5 GNOME system.
Yes, that's a problem; that's why some applications are distributed as libc5 binaries. I suspect that, over time, there will be few systems with only "libc5", and vendors will probably choose some flavor of glibc. (How many apps these days are distributed as a.out binaries for systems with Linux 1.x kernels?)
Microsoft gained end-users by just using x86
...if you don't count the non-x86 ports of NT (and the non-x86 ports of Windows CE). However, I have the impression that relatively few app vendors supported/support those platforms...
...and the same may end up being the case for Linux, so, for better or worse, any mass-market end-user base for Linux may end up running it only on PC's.
The GPL means that companies who adopt linux have to be very public about it, because the GPL requires them to make their source & changes publically available.
"Publically" doesn't necessarily mean "put out a big press release"; it could just mean "put the text of the GPL in your documentation, along with a URL people can go to download the source". I have the impression that one or the other of TiVo or Replay use Linux in their box, but, if so, I haven't seen either of them announcing this broadly (which cannot in any way be taken as a certain indication that they don't use Linux).
Yes, the GPL does require you not to keep it a complete secret that you're running Linux inside your box, unlike the BSDL. However:
a lot of the interest in Linux is from general-purpose computer companies, who might have to work harder to hide the Linux or *BSD derivation of their systems (and note that Apple is touting that a lot of MacOS X Server comes from BSD, albeit not so vigorously as those touting their moves to Linux);
as I said, the GPL doesn't require press releases saying "Linux Inside(TM)".
Perhaps you would call them both Linux, but I wouldn't; were somebody (perhaps Microsoft, to squelch irrelevant "you can't do that, the source isn't available" arguments) to implement a full-blown Windows environment atop a Linux kernel, without providing a userland that looks anything like that of a Linux distribution, I wouldn't call the resulting system "Linux", because it wouldn't feel like Linux, either to a programmer or to a user - I'd call the kernel a Linux kernel, but that's it.
Yeah, perhaps you could then add a Linux userland atop it - that'd be the moral equivalent of Interix, which provides an environment with a UNIX API atop the NT kernel. Once you added the Linux userland, I'd be willing to call the resulting system a Linux system (just as an NT system with Interix is still an NT system)...
...but that's not solely because it has a Linux kernel; it includes all the other code that makes a Linux system look like a Linux system.
Similarly, a FreeBSD userland atop a Linux kernel wouldn't be a Linux system to me unless the Linux userland was present as well.
Of course, in some cases the userlands would collide - would the FreeBSD-and-Linux userlands atop a Linux kernel have, say, a FreeBSD-style or a Linux SV-style or a Linux BSD-style "init"? Were the system to present both flavors of userland where it was possible to do so, but chose one particular flavor of userland for the stuff where it wasn't, if that was a Linux flavor, I'd call the system "Linux with an XXX compatibility package", and if that was a FreeBSD flavor (or an NT flavor), I'd call it "a hybrid, neither fish nor fowl".
There are multiple ways to do everything. Just chosing which API to use can be frustrating. On top of that there is no common way to access multimedia systems such as sound and video. The kernel provides OSS.. but there is also ALSA. Not everyone uses X either.
"End-users", in the sense you appear to be using them, don't use OSS or ALSA; they use applications. If the OS can support applications written either to the OSS or the ALSA API, and you don't have to know which API an application uses, why does the availability of multiple APIs make any difference to the end user? (The same applies to any other situation where you have multiple APIs; OSS vs. ALSA is just an example.)
Back to the problem of GNOME/KDE and other GUI abstractions. No matter what GNOME abstracts it will never be fully in touch with Linux. Abstractions are generalizations. You can call an apple and an orange fruit. But a fruit is a fruit. See my point? No differences can be made with that abstraction. If animal_X likes apples and animal_Y likes oranges and you feed animal_X a "fruit" (which just happens to be an orange) animal_X will die (crash).
To what exactly is your metaphor referring? To repeat the question I asked in a previous message - a question you didn't bother to answer - in what way would, say, an office application be an "animal" that "likes oranges" or "likes apples", i.e., in what way would it want to use Linux-specific features in a way that can't be abstracted away? (Don't just assert that it would - without an example, I have no reason whatsoever to believe such an assertion.)
Since GNOME/KDE do not implement OS-specific features they will not take full ability of the OS. And when OS-specific features are implemented they will be mere hacks to the metaphor system.
Presumably by "they will not take full ability of the OS" you mean "they do not currently make full use of the OS's facilities", given that you say, right after that, "and when OS-specific features are implemented", i.e. that it's not impossible for them to implement OS-specific features.
By "they will be mere hacks to the metaphor system" do you mean that the UI would have to hide necessarily platform-dependent details because the entire desktop environment will be providing a completely platform-independent metaphor? I have no reason to believe that the desktop environment is obliged to do so; the bulk of the desktop environment may do so - just as the bulk of the Windows desktop environment may provide a metaphor independent of whether you're using Windows OT or Windows NT - but there's stuff under the Control Panel, say, that's not the same in the two OSes (if Windows had this wonderful metaphor that completely hides the differences between Windows OT and Windows NT, you wouldn't have control over power-saving stuff in Windows OT, because NT doesn't have that yet).
Also, I meant "knowledgable" as in confortable with the metaphors presented by the GUI system. Once they get beyond that and get deeper "into" the system I believe they will get confused since the metaphors are invalid.
In what way is this any different from the problems a Windows user might have if they "get beyond" the desktop and start playing with Your Friend Mr. MS-DOS Prompt? If the answer is "you don't have to fire up a DOS prompt in Windows", then perhaps the answer, for those users, is to arrange that they not have to do so in Linux, either.
Linux calls a pipe a pipe, but a GUI system might use "pathway" or some other terminology to make it portable.
"Portable" to what? Pipes are called pipes in all UNIX-flavored OSes (and in Win32, for that matter...), so why would a GUI system have to use "pathway" to make it portable to multiple flavors of UNIX?
KDE/GNOME are basically making an operating system in an operating system. They are creating object sharing systems and using virtual file systems and various other operating system ideas. But why? Why can't we just use Linux's VFS?
For one thing, because, for better or worse, most UNIX-flavored OSes, including Linux, don't generally have file systems plugged into their VFSes to support things such as HTTP or FTP access, which, if the "virtual file systems" to which you're referring are the ones I suspect they are, the VFSes of KDE and GNOME offer. There are some who argue that HTTP and FTP access should be provided through the OS's file system API, and implementations of that do exist (often done as, e.g., user-mode NFS servers, or other types of user-mode file systems, so that you're not obliged to shove FTP or HTTP client code into the kernel).
Why can't Linux have object sharing at the kernel level?
What do you mean by "object sharing"? Are you referring to the object models like KOM and Bonobo? If so, why should Linux have it at the kernel level? There's nothing Magically Wonderful about implementing stuff in kernel mode; I think the bulk of Windows' COM runs in userland.
One might reasonably argue why the object model should be part of a desktop environment, rather than being a thing unto itself (which could be provided as part of a Linux distribution, say), to encourage non-desktop stuff to use it (COM isn't, as far as I can tell, desktop-only in Windows).
Why libraries for GUI?
The alternative to a library being? All the APIs offered, at least to programs written in compiled languages, on UNIX-flavored OSes and Windows, come from libraries (or code loaded at run time) - even system calls are called as library routines that contain a trap stub.
First of all, that's irrelevant to the point I was making, which is that the kernel doesn't provide all the personality of the OS - userland code contributes as well.
Second of all, it's conceivable that somebody could reverse-engineer the system call interface of a particular version of NT, and implement said "ntdll.dll" from that.
Slashdot Mirror
The original poster said
not "they should take GPL their OS in its entirety".
...but the original poster didn't suggest that they do so. (Note that much of the code behind the GUI on most Linux systems isn't GPLed.)
I haven't heard anything about that; do you have a reference?
That appears to be in progress; this page says:
This press release (it's also on Intergraph's Web site, but the version there appears to be infested with non-ISO-8859/1 Windows characters) says that they will "Exit the PC and generic server business, which suffered irreparable harm from Intel's actions.", but that they'll "Strengthen the high-end workstation and graphics accelerator businesses by seeking partners with complementary technology and sales channels for Intergraph Computer Systems' ViZual Computing and Intense3D units.", although I don't know whether the bit about "Focus[sing] on Software and Services" means they'll eventually sell the hardware business off to a partner.
They still exist; are you implying that their recent change of direction constitutes death, or that it means they're doomend?
Define "never" and "BSD". It wasn't until 4.4 (or maybe Net-2) that 64-bit file offsets were supported in BSD; 4.2BSD, 4.3BSD, and 4.3-Tahoe didn't have 64-bit file offsets.
OK, let's see how many people aren't familiar with Scott Pakin's automatic complaint-letter generator, and start counter-flaming....
...presumably referring to binary-only software, or to sourceware that uses Linux-specific features or otherwise requires tweaking to make it run on other UNIX-compatible systems; if some software was written by somebody using a Linux box, but "accidentally" happens to be generic UNIX-compatible software, it's not really Linux software, it's generic UNIX-compatible software.
Eh? The Linux kernel is "monolithic" as well, if loadable kernel modules don't imply "non-monolithic", and Linux and FreeBSD (and possibly the other BSDs) both have loadable kernel modules. Even if the driver isn't a loadable module, they could supply a ".o" to be linked with the kernel.
If you're using packages rather than ports, you're not compiling it for your system, you're just downloading a binary package. (I.e., FreeBSD, and, I think, at least some of the other BSDs, also offer a system for downloading and installing binaries, as well as a system for grabbing source.)
Applix's office software antedates Java, and I hadn't heard that it'd been rewritten in Java; where had you heard that it had? (I assume that you were calling it "thin-client" software as you thought it'd been written in Java.)
Unless I missed something on their site, the only thing they've open-sourced is their extension language; they haven't open-sourced Applixware as a whole.
Umm, that sounds like a non-kernel issue, unless there's some place in the kernel that cares about the name assigned to an account so I'm not sure what the complaints about UFS and NFS, both of which live in the kernel in FreeBSD, involved.
If you want UID 0 to be privileged, regardless of whether it's named "root" or not, and want only UID 0 to be privileged, regardless of whether some other UID has the name "root", a check for UID == 0 (or, to be precise, for effective UID == 0) would be the correct test.
(I hope you're complaint isn't about the fact that nfs_access() speaks of "root" in the comment right before it checks whether ap->a_cred->cr_uid == 0, given that it could have said "Roland the Headless Thompson Gunner" instead of "root" in the comment without changing the behavior of the code - which is checking to make sure that it doesn't tell code running as UID 0 that it has access to a file when, in fact, it doesn't have access because the server has mapped client UID 0 to some other UID on the server; this is for NFS V2, where there's no RPC to ask "how much access do I really have?").
(As for suser(), well, I seem to remember that in the UNIXes of long ago, it checked whether, err, umm, the effective UID was 0; the main reason it existed was to set the "super-user privileges were used" accounting flag. Perhaps Shiny New Modern real UNIXes it does something else.)
Perhaps the original poster meant, by "USB scanner and cablemodem", "(USB) (scanner and cablemodem)", i.e. "USB scanner and USB cable modem", not "USB scanner and (Ethernet) cable modem". The GVC Corporation has a USB cable modem, and the Intel Architecture Labs have a reference design for USB cable modems.
(I make no comments about the relative merits of USB and Ethernet cable modems, nor am I saying anything about how easy or hard it is to get USB cable modems to work on FreeBSD or Linux, I'm just noting that USB cable modems are being designed, and some appear to already exist.)
Assuming that's a serious statement, his original question could either be interpreted with the subject line being "(Improvements since BSD4.*) (on Vaxen)", i.e., "what improvements, on the VAX platform, have there been since BSD 4.*", with "that scene" in "I'd quite like to delve back into that scene" being "BSD on VAXes", or with the subject line being "(Improvements since BSD4.* on Vaxen)", i.e. "what improvements have there been in BSD since the days when BSD4.* ran mainly on VAXes", with "that scene" being "BSD in general".
I infer from "back in the days of the good o' Vax machines" that the original poster sees the days of the VAX as gone, and that the second interpretation of the question is valid; I'm unlikely to accept the first interpretation unless the original poster says that's what he or she intended.
Presumably meaning machines administered by the university; there exists at least one FreeBSD box in the "cs.berkeley.edu" domain:
I have the impression that many Win32 APIs are implemented in NT as user-mode library code atop the NT system call interface, i.e. not all calls to Win32 system services involve the Win32 subsystem process (the first edition of Inside Windows NT says that "In addition to a flexible, optimized message-passing facility, the Windows NT developers established some 'tricks' that reduce the number of interactions a client [e.g., a Win32 application, or an OS/2 application, or a POSIX application] must make with a server [e.g., the Win32, OS/2, or POSIX subsystem processes]: ... Using client-side DLLs to implement the API routines that don't use or modify global data.").
Umm, at the time, wasn't "fledgling NT development" the development of OS/2 NT? (The article even says as much.) I had the impression that the original intent was to build the Next Generation of OS/2 on top of New Technology, and that Microsoft turned OS/2 NT into Windows NT when they decided that Windows, not OS/2, was the wave of the future.
This might get you to some Win64 information (assuming it doesn't just tell you you have to register for MSDN Online, or something such as that).
Not exactly. UNIX was originally done in PDP-7 assembler (for the benefit of the younger members of the audience, that "7" is not a typo), redone in PDP-11 assembler, and then redone in C, but that wasn't for portability; the first porting work at AT&T, at least, was done in the mid-to-late '70's with a port to the Interdata 8/32 (various ports had been done by other folk outside AT&T) - V7 was, I think, the first UNIX released outside AT&T that included the results of that work.
Linux's API was a UNIX API, and the UNIXes of that day (and of the present) have an API that's basically a V7 superset (the V7 API fixed a pile of somewhat ugly non-portable bits, e.g. stat() filled in a structure rather than an array of ints), so at the API level perhaps it inherited portability from UNIX, but the kernel implementation, at least, wasn't based on an AT&T implementation - and I have the impression that the original Linux kernel directly used a number of x86isms.
Yeah, that seems pretty bogus to me; much of the I/O subsystem seems similar between the two OSes (down to some of the data structures such as I/O request packets having the same name), but to infer from this that Microsoft stole VMS code, as some have seemed to do, is a bit extreme - reusing ideas from previous projects hardly qualifies as "theft" to me.
Which of the two OSes in question had file system code running in userland, and which runs it in kernel mode? :-)
(Hint: the answer to the first question is "VMS, at least at one point" - I have the impression they moved the file system code for Files-11 ODS-2 from the Files-11 Ancillary Control Process, or whatever it was called, into kernel-mode code at some point - and the answer to the second question is "Microsoft(R) Windows(R) NT(TM)".)
Yes, NT does move some of the part of various APIs not implemented in userland libraries out to subsystem processes, but, at least from reading the two editions of Inside Windows NT, it appears that a lot of it lives inside kernel-mode code (e.g., device drivers, file systems, the networking stack).
NT is an interesting design, but I'm not sure I'd call it a "microkernel" - more of a hybrid.
I'd love to see some statistics on the contributions of people from various countries to various free software projects, relative to the populations of those countries - or to the number of people involved in software development in those countries. I suspect that there are some that have significantly higher per-capita contributions than others (and that Germany'd be one of the ones with higher levels of contributions); if so, I'd be curious what the reason(s) are....
To which sample are you referring? The "90%" sample? Yes, it'd be random, in which case, as I said, I suspect that 90% of them have never tried to get anything to run on Linux, as they've never tried Linux.
Spiffy. Do I win the two-week vacation in New York? (If the fact that I guessed the Windows user would probably burn the first CD, at least with the current state of Linux, comes as a surprise to you, you might want to think about checking your prejudices at the door next time. Hint: just because I indicated that your statement about "90% of computer users can't get anything to run on Linux" was rhetorical rather than realistic, because "90% of computer users" haven't tried Linux, that doesn't mean I think they'd find Linux a snap at present. That doesn't mean that this will never change, although I suspect that, as a mass-market OS, Linux is unlikely to be more than a runner-up in the near to medium-term future, and may never be more than a runner-up - but that may be sufficient to let it be a reasonable desktop OS.)
...which suggests either that distributions aimed at end-users should offer all the APIs likely to be used by applications (OSS and ALSA, for example), or application writers should limit themselves to APIs present in all distributions, or application writers should bundle an implementation of said API with their application, if possible, and install it with the application if it's missing, or that they should do something such as trying to load up the API libraries at run-time with "dlopen()" and find symbols in them with "dlsym()", and fall back on other APIs or disable the feature that uses the API if they fail (I have the impression Windows apps use the latter two strategies).
To what are you referring here? What do you mean by "implement a Linux feature into GNOME"? Providing support for a Linux feature, e.g. having a tool that shows what hardware you have by scanning the appropriate parts of "/proc"? If so, why sould that be "a hack to the system to make it work"?
To which modern UNIXes are you referring here when you say "certain other OSes"? SunOS 4.0 doesn't have "dlopen()", but it's not "modern"; SunOS 4.1 has it (it may have been the first OS to implement "dlopen()", although it was originally an AT&T invention - I think 4.1 came out before the first SVR4 release, which also had "dlopen()"; no, "dlopen()" wasn't a Linux invention). SVR4-flavored UNIXes have it, the open-source BSDs have it, Digital UNIX has it, sufficiently-recent AIX's have it; HP-UX has its own shared library mechanism, with its own equivalent of "dlopen()", but may now have a "dlopen()"/"dlsym()"/etc. wrapper.
Yes, that's a problem; that's why some applications are distributed as libc5 binaries. I suspect that, over time, there will be few systems with only "libc5", and vendors will probably choose some flavor of glibc. (How many apps these days are distributed as a.out binaries for systems with Linux 1.x kernels?)
...if you don't count the non-x86 ports of NT (and the non-x86 ports of Windows CE). However, I have the impression that relatively few app vendors supported/support those platforms...
...and the same may end up being the case for Linux, so, for better or worse, any mass-market end-user base for Linux may end up running it only on PC's.
"Publically" doesn't necessarily mean "put out a big press release"; it could just mean "put the text of the GPL in your documentation, along with a URL people can go to download the source". I have the impression that one or the other of TiVo or Replay use Linux in their box, but, if so, I haven't seen either of them announcing this broadly (which cannot in any way be taken as a certain indication that they don't use Linux).
Yes, the GPL does require you not to keep it a complete secret that you're running Linux inside your box, unlike the BSDL. However:
Perhaps you would call them both Linux, but I wouldn't; were somebody (perhaps Microsoft, to squelch irrelevant "you can't do that, the source isn't available" arguments) to implement a full-blown Windows environment atop a Linux kernel, without providing a userland that looks anything like that of a Linux distribution, I wouldn't call the resulting system "Linux", because it wouldn't feel like Linux, either to a programmer or to a user - I'd call the kernel a Linux kernel, but that's it.
Yeah, perhaps you could then add a Linux userland atop it - that'd be the moral equivalent of Interix, which provides an environment with a UNIX API atop the NT kernel. Once you added the Linux userland, I'd be willing to call the resulting system a Linux system (just as an NT system with Interix is still an NT system)...
...but that's not solely because it has a Linux kernel; it includes all the other code that makes a Linux system look like a Linux system.
Similarly, a FreeBSD userland atop a Linux kernel wouldn't be a Linux system to me unless the Linux userland was present as well.
Of course, in some cases the userlands would collide - would the FreeBSD-and-Linux userlands atop a Linux kernel have, say, a FreeBSD-style or a Linux SV-style or a Linux BSD-style "init"? Were the system to present both flavors of userland where it was possible to do so, but chose one particular flavor of userland for the stuff where it wasn't, if that was a Linux flavor, I'd call the system "Linux with an XXX compatibility package", and if that was a FreeBSD flavor (or an NT flavor), I'd call it "a hybrid, neither fish nor fowl".
"End-users", in the sense you appear to be using them, don't use OSS or ALSA; they use applications. If the OS can support applications written either to the OSS or the ALSA API, and you don't have to know which API an application uses, why does the availability of multiple APIs make any difference to the end user? (The same applies to any other situation where you have multiple APIs; OSS vs. ALSA is just an example.)
To what exactly is your metaphor referring? To repeat the question I asked in a previous message - a question you didn't bother to answer - in what way would, say, an office application be an "animal" that "likes oranges" or "likes apples", i.e., in what way would it want to use Linux-specific features in a way that can't be abstracted away? (Don't just assert that it would - without an example, I have no reason whatsoever to believe such an assertion.)
Presumably by "they will not take full ability of the OS" you mean "they do not currently make full use of the OS's facilities", given that you say, right after that, "and when OS-specific features are implemented", i.e. that it's not impossible for them to implement OS-specific features.
By "they will be mere hacks to the metaphor system" do you mean that the UI would have to hide necessarily platform-dependent details because the entire desktop environment will be providing a completely platform-independent metaphor? I have no reason to believe that the desktop environment is obliged to do so; the bulk of the desktop environment may do so - just as the bulk of the Windows desktop environment may provide a metaphor independent of whether you're using Windows OT or Windows NT - but there's stuff under the Control Panel, say, that's not the same in the two OSes (if Windows had this wonderful metaphor that completely hides the differences between Windows OT and Windows NT, you wouldn't have control over power-saving stuff in Windows OT, because NT doesn't have that yet).
In what way is this any different from the problems a Windows user might have if they "get beyond" the desktop and start playing with Your Friend Mr. MS-DOS Prompt? If the answer is "you don't have to fire up a DOS prompt in Windows", then perhaps the answer, for those users, is to arrange that they not have to do so in Linux, either.
"Portable" to what? Pipes are called pipes in all UNIX-flavored OSes (and in Win32, for that matter...), so why would a GUI system have to use "pathway" to make it portable to multiple flavors of UNIX?
For one thing, because, for better or worse, most UNIX-flavored OSes, including Linux, don't generally have file systems plugged into their VFSes to support things such as HTTP or FTP access, which, if the "virtual file systems" to which you're referring are the ones I suspect they are, the VFSes of KDE and GNOME offer. There are some who argue that HTTP and FTP access should be provided through the OS's file system API, and implementations of that do exist (often done as, e.g., user-mode NFS servers, or other types of user-mode file systems, so that you're not obliged to shove FTP or HTTP client code into the kernel).
What do you mean by "object sharing"? Are you referring to the object models like KOM and Bonobo? If so, why should Linux have it at the kernel level? There's nothing Magically Wonderful about implementing stuff in kernel mode; I think the bulk of Windows' COM runs in userland.
One might reasonably argue why the object model should be part of a desktop environment, rather than being a thing unto itself (which could be provided as part of a Linux distribution, say), to encourage non-desktop stuff to use it (COM isn't, as far as I can tell, desktop-only in Windows).
The alternative to a library being? All the APIs offered, at least to programs written in compiled languages, on UNIX-flavored OSes and Windows, come from libraries (or code loaded at run time) - even system calls are called as library routines that contain a trap stub.
First of all, that's irrelevant to the point I was making, which is that the kernel doesn't provide all the personality of the OS - userland code contributes as well.
Second of all, it's conceivable that somebody could reverse-engineer the system call interface of a particular version of NT, and implement said "ntdll.dll" from that.