I believe that's part of the problem too. Linux has no "feel". Thats the Unix way--has been since the start. Nothing is absolute (or a true/single method of doing something).
Examples? Do you mean "there's no single API to do (graphics, menus, sound, etc.)?" (Presumably not, as you're talking about end-users.)
Or do you mean "there's no single desktop metaphor"? If so, then why need there be a desktop metaphor for Linux, rather than for Linux and other UNIX-flavored OSes? Or are you thinking about the configuration issues where it might be impossible to use the exact same metaphor for configuring all those OSes (although perhaps end-users won't want to configure things at the levels where that's an issue, and what should be done, instead, if possible, is to let them configure the system at a sufficiently high level that said differences go away - or have the system configure itself automatically wherever possible)?
GNOME/KDE neither take/extend the Unix feel. They more or less transform a Unix feel into a Windows feel. Once end-users of either KDE or GNOME branch off into knowledgable users I believe they will be confused once they see a bash prompt and have to deal with pipes and other Unixish things.
"Knowledgable users" in what sense? If they're sufficiently knowledgable, that stuff won't be unfamiliar. If they're not that knowledgable, they might be equally confused if they see a "command.exe" prompt and have to deal with pipes (which the DOS and Windows NT shells have, although the DOS one, and perhaps the one in Windows OT, may not run multiple commands with a pipe between them; I'm curious whether the NT shell does implement command-line pipes with Win32 pipes), or other such things.
Depending on how knowledgable "knowledgable" is, the "knowledgable" users might or might not have to use a shell prompt; it may be that "knowledgable" users, in the sense of "not novices", would just use some of the less common utilities, less commonly-looked at control panel items, etc. (and I'm not one of those who think this would necessarily be a Great Loss, as long as you can use the command line, edit configuration files yourself, etc. if you're so inclined - heck, when running NT I've used the command line, manually edited the Registry, blah blah blah).
Let's face it-- most linux people don't need tech support-- and that is the only thing Redhat -really- sells.
I have the impression that Red Hat expects (and, presumably, hopes) for that to change. In their S-1, they say things such as
Operating systems based on the Linux kernel are some of the better known open source products. Linux-based operating systems represented 17% of new license shipments of server operating systems in 1998, according to IDC. Despite strong initial market acceptance, these operating systems have been slow to penetrate large corporations at the enterprise level due in part to the lack of viable open source industry participants to offer technical support and other services on a long-term basis.
and
OUR STRATEGY
We seek to enhance our position as a leading provider of open source software and services by:
...
- expanding our professional services capabilities to capture large corporate business on an enterprise basis;
...
and (in the list of risks)
WE MAY NOT REALIZE ANY BENEFIT FROM THE PLANNED EXPANSION OF OUR SERVICES BUSINESS
We have recently begun to expand our strategic focus to place additional emphasis on consulting, custom development, education and support services. Historically, we have derived virtually all of our revenue from software product sales. Although we intend to continue to develop and sell Official Red Hat Linux, we anticipate that product sales will represent a declining percentage of our total revenue if our strategy is successful. We cannot be certain that our customers will engage our professional services organization to assist with support, consulting, custom development, training and implementation of our products....
Whether the bubble will burst or not is an interesting question. I could imagine it bursting (although it's not the only stock market bubble I could imagine bursting...), but I wouldn't assume that it'll necessarily burst because Linux will necessarily remain the province of those who "don't need tech support".
A Unix operating system is typically named for its kernel. FreeBSD runs the FreeBSD kernel, OpenBSD runs the OpenBSD kernel, Solaris runs the solaris and Linux runs the Linux kernel.
Umm, the reason why "{Free,Net,Open}BSD runs the {Free,Net,Open}BSD kernel" is that the {Free,Net,Open}BSD kernel is called the {Free,Net,Open}BSD kernel because it's part of {Free,Net,Open}BSD - i.e., the kernel, in those cases, is named for the operating system.
As for Solaris, well, "uname -s" seems to think it's running the SunOS kernel.:-) (And regardless of where you sit on the "SunOS vs. Solaris" debate, the kernel is called the {SunOS,Solaris} kernel because it's part of {SunOS,Solaris}, so the same point applies there.
Linux systems are a bit different, as they've been assembled from pieces constructed and maintained by different groups; there's no One True Linux System, whose entire source can be found under "ftp://ftp.linuxsystem.org/src"; there's no single complete OS from which the kernel takes its name.
If you took all the files associated with FreeBSD, and replaced it's kernel (and support programs like ps, lsof, etc) with the Linux kernel (&etc), you would be running Linux. Wouldn't you?
No. You'd be running a BSD/Linux hybrid; it would feel different from many Linux systems, as the APIs would be a bit different, the administrative commands would be a bit different, the twisty little maze of "/etc/rc" files would be a bit different, etc. - and it's not at all clear that it'd be less different from a Linux distribution using one of the usual collection of Linux-distribution userlands than those distributions are from one another.
(If you took all the files associated with Windows NT, and replaced its kernel with a Linux kernel, and wrote an "ntdll.dll" that implemented all the NT system calls atop a possibly-extended Linux API, would you be running Linux?:-))
And I'm sorry, Mr. Raymond, but Cathedrals are things of beauty.
...but it's not necessarily the case that every piece of software built in the "cathedral" fashion is necessarily a thing of beauty.
Your bazaar vision, well... the peasants can roll up the tents and booths and move on when the weather goes bad. 200 years later there is still a beautiful Cathedral standing. There's a bare patch of dirt over there were the bazaar once sat.
But how many pieces of software will last for 200 years? If technology, desires, etc. change sufficiently quickly, building something for the ages may be a waste of time.
Let me explain why KDE/GNOME will fail. They are aiming for portability. They aren't designing FOR Linux. They are designing for an abstract computer which does not exist (and never will). GNOME will never take full ability of Linux, nor will KDE.
To what sort of things are you referring here? How would "word processors, office applications and so fort" work better if they "[took] full ability [presumably meaning "took full advantage"] of Linux", rather than merely using, by and large, an API common to all modern UNIXes (plus APIs supplied by the desktop environment they use, those APIs being, in turn, implemented, ultiplately, atop an API common to all modern UNIXes).
Or are you referring to the desktop environment components themselves (window manager, file manager, panel, applets, etc.)?
They will feel so foreign compared to how Linux runs.
How does Linux "run" in this context, and what are examples of how they'd feel "foreign"?
BTW, if Linux is as fragmented as you say, would not even "designing FOR Linux" be designing for "an abstract computer", even if it's less abstract than designing for modern UNIXes?
I suppose the fact that 90% of the computer users out there can't get anything to run on Linux is a figment of your imagination too.
I assume that's rhetorical, as I suspect "90% of the computer users out there" have never tried Linux, and not just because they think it'd be too hard to make it work. If 90% of the computer users out there wouldn't be able to get anything to run on Linux were they to try, then, as you note, Linux wouldn't make a better desktop, at least for that 90%.
How do you think all the original Unices got fragmented? All of these companies got a copy, hid their source, and released their own proprietary versions. They cannot do that with Linux (or at least not the core parts of it.) With the *BSDs, they can.
The answer to the poster's question is "because the bulk of the UNIX-system-vendor interest in open-source Unix appears to be in Linux, not in any of the BSDs, and that's why Raymond spoke of Linux as being the cause of the re-unification"; there's no need to ascribe this to Slashdot not giving enough emphasis to the other open-source Unixes.
One can speculate on why the bulk of that interest is in Linux; I've not heard anything to convince me that it has anything to do with the GPL preventing fragmentation (I've even heard people argue that BSD not being GPLed is the reason why all the different open-source BSD projects have appeared; those arguments are especially unconvincing, given that they are all, err, umm, open-source projects, so it's not as if XBSD could add something and keep YBSD and ZBSD from ever picking it up...).
One could imagine companies thinking the way you describe, but that doesn't necessarily imply that they are thinking that way ("plausible" doesn't imply "true").
The blank between "p_type=" and "chill" in the URL you put in (as text; why don't more people post HTML-formatted articles and put real links in?) doesn't belong there; this is the article, which quotes Hank Shiffman of SGI as saying
"We have not closed the door finally on [Irix, SGI's version of Unix, on Intel], but the current feeling from an applications standpoint is that Linux is the right answer. Given the resources we have, we have to focus on just one [operating system] and that one is Linux.
(In this context, "on Intel" presumably means "on IA-64", not "on x86".)
But there is no dispute that the Unix world is slowing unifying.
It sounds as if you meant "slowly unifying" here; "slowing unifying" sounds, at least to me, as if it would mean "slowing down the process of unifying", i.e. unifying less, rather than more.
There's also the User Interface Hall of Shame, with various UI design mistakes (in the view of the authors) in various UIs, including but not limited to Windows (they alo have a User Interface Hall of Fame, for stuff they deem sufficiently praiseworthy).
The FAA is still the largest purchaser of vacuum tubes in the US. Guess why? Dinosaur computing hardware.
Assuming this isn't a troll (in the sense of "troll" I saw in something alt.folklore.urban-related, wherein a "troll" was, as I remember, a known-to-be-bogus outrageous claim posted in the hopes of drawing out heated rebuttals - as opposed to just Boring Old Flamebait, which often gets described as a "troll" on/.), I doubt that - even the crufty old 90whatever machines were based on System/360s, and those were transistorized (the first transistorized machines came out in the mid-to-late '50's, e.g. IBM 7090's).
...or they might design an API that would be implemented by a library separate from Xlib and not specific to KDE, E, etc., so that an application doesn't have to be linked with some particular desktop environment's or window manager's library.
Now, it might be nice if that library became a part of Standard X, so that one could, in theory, count on it being on every system that has X; I don't see why it would matter whether the routines were in Xlib itself or in some other library that's part of Standard X.
Unfortunately, "in theory" doesn't mean "in practice"; regardless of whether those routines went into Xlib, or into a separate library, in X11R6.5, or X11R7, or whatever, that wouldn't help people who had Boring Old X11R6.4 or Boring Old X11R6.whatever-Based CDE or whatever.
Putting it into a separate library might make it slightly easier to add it to a system with an old version of X - you wouldn't have to replace Xlib, you could just add the library.
So perhaps it should become part of the X11.whatever specifications, but that doesn't mean it should necessarily become part of the Xlib specifications.
...which would presumably be threatened by the same patent. (Could we please have no more "use xfstt instead" postings unless they contain a good reason why the patent won't affect xfstt?)
I assume you're replying to a comment in this thread, not to the original article, given that the original article wasn't discussing free fonts, it was discussing patent encumbrance of font rasterizing software.
Since xfstt is working so great for me. Why, bother worrying about freetype?
Because xfstt, being another TrueType rasterizer, would presumably be hit by the same patent.
If your system has a driver that lets you get at raw packets (the moral equivalent of raw DLPI access on Solaris, SOCK_PACKET or packet filter access on Linux, BPF access on BSD, etc.), the driver could provide a way to enable or disable promiscuous mode on cards that support it, read and write raw packets, etc..
Unfortunately, NT either doesn't come with such a driver by default, or doesn't document it (NT Server comes, I think, with Network Monitor, which includes such a driver, although the version that comes with NT is claimed not to support promiscuous mode; you need the version that comes with System Management Server to get that).
The Microsoft Developer Network stuff comes with sample driver and userland code to do that, at least on NT, and PCAUSA sells the Win32 NDIS Framework, which includes a driver and a userland library to let you do that on W9x and WNT (complete with a BPF interpreter in the driver, so you can do BPF-style packet filtering when capturing).
I've not used either of them, so I can't say one way or the other how well they work.
I'd be particularly alert for bias in articles put out by this company, and would love to know who owns them.;^)=
Unfortunately, the corporate fact sheet page on the Dow Jones Web site doesn't seem to say anything about ownership of their shares by other corporations, although the shares are publicly traded on the New York Stock Exchange.
(I.e., if you were just jumping on the "MS" part of "MSNBC", and inferring that this was some Evil Microsoft FUD Plot, note that the article looks as if it might be a re"print" of a Wall Street Journal article, not something put out directly by MSNBC.)
Sun have had processors around for a while now which have been designed to execute Java bytecodes directly...
...such as picoJava.
The interesting stuff is the VLIW aspect...
...but with an allegedly-VLIW (assuming VLIW isn't just being used as a marketing-speak alias for "buy this, it's c00l", as e.g. RISC appears sometimes to be used) instruction set, it appears that this chip isn't designed to "execute Java bytecodes directly".
...lending itself to bytecode environments in general (not just Java)
In what fashion does an underlying VLIWish instruction set lend itself to bytecode environments better than does a non-VLIWish instruction set?
Basically it looks like they're making a stab at a new *style* chip architecture, not just overclocking some knackered design a la Intel.
Well, to be fair, Intel are also working on what they consider a new style of instruction-set architecture, even if it appears that many of the basic ideas for it came from HP.
The EE Times article suggests that MAJC won't interpret Java bytecodes; bytecodes would have to be interpreted, or compiled into native machine code, as on most other platforms. (It also suggests that other languages could be compiled into its native instruction set as well.)
And maybe the HP 72x-series as well
on
LinModems?
·
· Score: 1
stay away from the 7xx series of HP printers, every one that I have seen is a software printer....
The PPA For The Masses page says it has some GPLed software to drive at least some of the 7xx-series HP printers (with the help of Ghostscript).
I've not used it, so I can't say one way or the other how well it works.
Never mind, the TTL exceeded or port unreachable reply would still get hit if ICMP packets are dropped, even though the outgoing UDP might not get hit.
"traceroute" sends packets to a UDP port it hopes isn't in use; it doesn't send ICMP Echo packets. (Perhaps those discussing ICMP packets being dropped or restricted are thinking of NT's "tracert"?)
Slashdot Mirror
Examples? Do you mean "there's no single API to do (graphics, menus, sound, etc.)?" (Presumably not, as you're talking about end-users.)
Or do you mean "there's no single desktop metaphor"? If so, then why need there be a desktop metaphor for Linux, rather than for Linux and other UNIX-flavored OSes? Or are you thinking about the configuration issues where it might be impossible to use the exact same metaphor for configuring all those OSes (although perhaps end-users won't want to configure things at the levels where that's an issue, and what should be done, instead, if possible, is to let them configure the system at a sufficiently high level that said differences go away - or have the system configure itself automatically wherever possible)?
"Knowledgable users" in what sense? If they're sufficiently knowledgable, that stuff won't be unfamiliar. If they're not that knowledgable, they might be equally confused if they see a "command.exe" prompt and have to deal with pipes (which the DOS and Windows NT shells have, although the DOS one, and perhaps the one in Windows OT, may not run multiple commands with a pipe between them; I'm curious whether the NT shell does implement command-line pipes with Win32 pipes), or other such things.
Depending on how knowledgable "knowledgable" is, the "knowledgable" users might or might not have to use a shell prompt; it may be that "knowledgable" users, in the sense of "not novices", would just use some of the less common utilities, less commonly-looked at control panel items, etc. (and I'm not one of those who think this would necessarily be a Great Loss, as long as you can use the command line, edit configuration files yourself, etc. if you're so inclined - heck, when running NT I've used the command line, manually edited the Registry, blah blah blah).
If by that you mean "moderated up to 1", the answer is "because he didn't post as an Anonymous Coward"; see this Q in the Slashdot FAQ, which says
I have the impression that Red Hat expects (and, presumably, hopes) for that to change. In their S-1, they say things such as
and
and (in the list of risks)
Whether the bubble will burst or not is an interesting question. I could imagine it bursting (although it's not the only stock market bubble I could imagine bursting...), but I wouldn't assume that it'll necessarily burst because Linux will necessarily remain the province of those who "don't need tech support".
Umm, the reason why "{Free,Net,Open}BSD runs the {Free,Net,Open}BSD kernel" is that the {Free,Net,Open}BSD kernel is called the {Free,Net,Open}BSD kernel because it's part of {Free,Net,Open}BSD - i.e., the kernel, in those cases, is named for the operating system.
As for Solaris, well, "uname -s" seems to think it's running the SunOS kernel. :-) (And regardless of where you sit on the "SunOS vs. Solaris" debate, the kernel is called the {SunOS,Solaris} kernel because it's part of {SunOS,Solaris}, so the same point applies there.
Linux systems are a bit different, as they've been assembled from pieces constructed and maintained by different groups; there's no One True Linux System, whose entire source can be found under "ftp://ftp.linuxsystem.org/src"; there's no single complete OS from which the kernel takes its name.
No. You'd be running a BSD/Linux hybrid; it would feel different from many Linux systems, as the APIs would be a bit different, the administrative commands would be a bit different, the twisty little maze of "/etc/rc" files would be a bit different, etc. - and it's not at all clear that it'd be less different from a Linux distribution using one of the usual collection of Linux-distribution userlands than those distributions are from one another.
(If you took all the files associated with Windows NT, and replaced its kernel with a Linux kernel, and wrote an "ntdll.dll" that implemented all the NT system calls atop a possibly-extended Linux API, would you be running Linux? :-))
...but it's not necessarily the case that every piece of software built in the "cathedral" fashion is necessarily a thing of beauty.
But how many pieces of software will last for 200 years? If technology, desires, etc. change sufficiently quickly, building something for the ages may be a waste of time.
(I.e., don't mistake a metaphor for reality.)
To what sort of things are you referring here? How would "word processors, office applications and so fort" work better if they "[took] full ability [presumably meaning "took full advantage"] of Linux", rather than merely using, by and large, an API common to all modern UNIXes (plus APIs supplied by the desktop environment they use, those APIs being, in turn, implemented, ultiplately, atop an API common to all modern UNIXes).
Or are you referring to the desktop environment components themselves (window manager, file manager, panel, applets, etc.)?
How does Linux "run" in this context, and what are examples of how they'd feel "foreign"?
BTW, if Linux is as fragmented as you say, would not even "designing FOR Linux" be designing for "an abstract computer", even if it's less abstract than designing for modern UNIXes?
I assume that's rhetorical, as I suspect "90% of the computer users out there" have never tried Linux, and not just because they think it'd be too hard to make it work. If 90% of the computer users out there wouldn't be able to get anything to run on Linux were they to try, then, as you note, Linux wouldn't make a better desktop, at least for that 90%.
The answer to the poster's question is "because the bulk of the UNIX-system-vendor interest in open-source Unix appears to be in Linux, not in any of the BSDs, and that's why Raymond spoke of Linux as being the cause of the re-unification"; there's no need to ascribe this to Slashdot not giving enough emphasis to the other open-source Unixes.
One can speculate on why the bulk of that interest is in Linux; I've not heard anything to convince me that it has anything to do with the GPL preventing fragmentation (I've even heard people argue that BSD not being GPLed is the reason why all the different open-source BSD projects have appeared; those arguments are especially unconvincing, given that they are all, err, umm, open-source projects, so it's not as if XBSD could add something and keep YBSD and ZBSD from ever picking it up...).
One could imagine companies thinking the way you describe, but that doesn't necessarily imply that they are thinking that way ("plausible" doesn't imply "true").
(In this context, "on Intel" presumably means "on IA-64", not "on x86".)
It sounds as if you meant "slowly unifying" here; "slowing unifying" sounds, at least to me, as if it would mean "slowing down the process of unifying", i.e. unifying less, rather than more.
There's also the User Interface Hall of Shame, with various UI design mistakes (in the view of the authors) in various UIs, including but not limited to Windows (they alo have a User Interface Hall of Fame, for stuff they deem sufficiently praiseworthy).
Assuming this isn't a troll (in the sense of "troll" I saw in something alt.folklore.urban-related, wherein a "troll" was, as I remember, a known-to-be-bogus outrageous claim posted in the hopes of drawing out heated rebuttals - as opposed to just Boring Old Flamebait, which often gets described as a "troll" on /.), I doubt that - even the crufty old 90whatever machines were based on System/360s, and those were transistorized (the first transistorized machines came out in the mid-to-late '50's, e.g. IBM 7090's).
The Dell press release on this quotes the owner as saying
so maybe he'd upgraded it to 64K or something (or whatever the maximum was on that machine) at some point in its life.
...or they might design an API that would be implemented by a library separate from Xlib and not specific to KDE, E, etc., so that an application doesn't have to be linked with some particular desktop environment's or window manager's library.
Now, it might be nice if that library became a part of Standard X, so that one could, in theory, count on it being on every system that has X; I don't see why it would matter whether the routines were in Xlib itself or in some other library that's part of Standard X.
Unfortunately, "in theory" doesn't mean "in practice"; regardless of whether those routines went into Xlib, or into a separate library, in X11R6.5, or X11R7, or whatever, that wouldn't help people who had Boring Old X11R6.4 or Boring Old X11R6.whatever-Based CDE or whatever.
Putting it into a separate library might make it slightly easier to add it to a system with an old version of X - you wouldn't have to replace Xlib, you could just add the library.
So perhaps it should become part of the X11.whatever specifications, but that doesn't mean it should necessarily become part of the Xlib specifications.
...which would presumably be threatened by the same patent. (Could we please have no more "use xfstt instead" postings unless they contain a good reason why the patent won't affect xfstt?)
I assume you're replying to a comment in this thread, not to the original article, given that the original article wasn't discussing free fonts, it was discussing patent encumbrance of font rasterizing software.
Because xfstt, being another TrueType rasterizer, would presumably be hit by the same patent.
If your system has a driver that lets you get at raw packets (the moral equivalent of raw DLPI access on Solaris, SOCK_PACKET or packet filter access on Linux, BPF access on BSD, etc.), the driver could provide a way to enable or disable promiscuous mode on cards that support it, read and write raw packets, etc..
Unfortunately, NT either doesn't come with such a driver by default, or doesn't document it (NT Server comes, I think, with Network Monitor, which includes such a driver, although the version that comes with NT is claimed not to support promiscuous mode; you need the version that comes with System Management Server to get that).
The Microsoft Developer Network stuff comes with sample driver and userland code to do that, at least on NT, and PCAUSA sells the Win32 NDIS Framework, which includes a driver and a userland library to let you do that on W9x and WNT (complete with a BPF interpreter in the driver, so you can do BPF-style packet filtering when capturing).
I've not used either of them, so I can't say one way or the other how well they work.
The Ethereal site is here. (I shan't say what the best sniffer is, as I'm not exactly a neutral observer.... :-))
(Note also that Ethereal isn't Linux-only.)
Unfortunately, the corporate fact sheet page on the Dow Jones Web site doesn't seem to say anything about ownership of their shares by other corporations, although the shares are publicly traded on the New York Stock Exchange.
(I.e., if you were just jumping on the "MS" part of "MSNBC", and inferring that this was some Evil Microsoft FUD Plot, note that the article looks as if it might be a re"print" of a Wall Street Journal article, not something put out directly by MSNBC.)
...such as picoJava.
...but with an allegedly-VLIW (assuming VLIW isn't just being used as a marketing-speak alias for "buy this, it's c00l", as e.g. RISC appears sometimes to be used) instruction set, it appears that this chip isn't designed to "execute Java bytecodes directly".
In what fashion does an underlying VLIWish instruction set lend itself to bytecode environments better than does a non-VLIWish instruction set?
Well, to be fair, Intel are also working on what they consider a new style of instruction-set architecture, even if it appears that many of the basic ideas for it came from HP.
Make that
The EE Times article suggests that MAJC won't interpret Java bytecodes; bytecodes would have to be interpreted, or compiled into native machine code, as on most other platforms. (It also suggests that other languages could be compiled into its native instruction set as well.)
The PPA For The Masses page says it has some GPLed software to drive at least some of the 7xx-series HP printers (with the help of Ghostscript).
I've not used it, so I can't say one way or the other how well it works.
Never mind, the TTL exceeded or port unreachable reply would still get hit if ICMP packets are dropped, even though the outgoing UDP might not get hit.
"traceroute" sends packets to a UDP port it hopes isn't in use; it doesn't send ICMP Echo packets. (Perhaps those discussing ICMP packets being dropped or restricted are thinking of NT's "tracert"?)