The problem with BeOS isn't technology, it is long-term availability: why would anyone invest a lot of time and effort in learning its APIs and developing applications for it if there is no guarantee that it will be around in the long term?
Be apparently never understood this, so they continued on with their dreams of challenging the world with yet another proprietary OS. The only way BeOS could have attracted more of a following is if they had either put their source in escrow, to be released under BSD in case the company failed (like it did), or if they had pursued an open source strategy from the start. Otherwise, a developer or manager with any brains just wouldn't touch the thing.
Neither BeOS, nor Linux, nor Windows, nor MacOS win the crown for the most advanced technology. They are all compromises between backwards compatibility and functionality. Again, it's not about the greatest technology.
but what about those who want to be free of the shackles of X?
What about them? There is nothing in Linux that prevents non-X window systems to be implemented, even in the kernel if you like. In fact, there have been a bunch over the years. I suspect they haven't caught on because when all is said and done, X11 ends up being a much better window system after all, no matter how much some people whine about it.
In addition, there are numerous open source operating systems that do not use X; if you don't like Linux, you can use any of those.
Linux types always get mean about BeOS. My theory is that BeOS is the only thing out there that could possibly challenge Linux for technological supremacy.
You are quite right: BeOS could have challenged Linux technologically. That would have been a dreadful outcome. While BeOS may or may not be technically a little nicer than Linux for desktop applications, it is a proprietary, closed-source system. The last thing the world needs is more fragmentation among the non-Microsoft operating systems. If a significant number of Linux developers had switched to BeOS, they would now be stranded. Let's count our blessings that this hasn't happened.
Let Be's failure be a lesson: software vendors must take steps to assure their customers long-term availability of their software. If they can't do that through open source for some reason, they need to come up with some other strategy, otherwise, they'll not attract developers.
The license specifies that any machine which includes a Microsoft operating system must not also offer a nonMicrosoft operating system as a boot option.
That's funny, because a lot of Linux hardware vendors offer dual-boot machines. The simple fact is that most people don't want to dual-boot and vendors have little economic incentive to preinstall Linux. The people who do want to dual-boot can.
Getting Linux may be a little easier in the future with FireWire disks: people can buy them after market, with Linux preinstalled. That removes most installation hassles and should make dual booting feasible, at worst with a floppy/CD.
From the brief summary, it looks like this would be very useful to protect a Linux system against malicious code, worms, and many other forms of attacks. For example, rather than trying to find and fix every buffer overrun in sendmail, you could keep sendmail from becoming destructive even if it is compromised. And you don't have to blindly trust every RPM and Debian package you install anymore, you can instead define policies for what the executables in that package may and may not do (e.g., an audio player probably has not business accessing/dev/hda).
Of course, the largest percentage of the Web is going to be corporate propaganda and porn. So what? In absolute numbers, the Web still contains more authors, more diverse viewpoints, and a larger volume of intelligent content than any medium before it. The Web has been living up to its promise.
However, as a good first step, to avoid the kind of mundane web sites the NYT article is complaining about, you might stop reading the New York Times itself.
People at Caltech were publishing papers on this sort of thing more than 15 years ago. The main thing that may be new this time around is the means by which the patterns themselves are deposited. However, I don't think that has been the limiting factor in applying these techniques in the past.
By your definition, Windows is UNIX, too, since it runs almost all those applications and tools as well. The simple fact is that MacOS X shares little with either the traditional codebase or the traditional philosophy of UNIX.
You might, however, call MacOS X "UNIX compatible", "mostly POSIX compliant", or "an operating system with a UNIX personality".
And how would you know that the original UNIX tools aren't as good as the GNU tools?
Well, because I started using UNIX in 1981 and have used pretty much every major version starting with V7, including Bell Labs internal versions. I have also lived through the evolution of the GNU tools and reported many bugs in them over the years (it's pointless to report bugs in the UNIX tools--they never get fixed by commercial vendors) and used them side-by-side with the UNIX tools.
The GNU utilities were written from the ground up with the idea of imposing no fixed size limits, being able to deal with binary inputs, and being backwards compatible with the UNIX utilities, and they have largely succeeded. The GNU tools often also use better algorithms and better data structures internally.
UNIX utilities used to just dump core on commands like "grep foo/vmunix", although much of that has at least been fixed. They often still have arbitrary limits and other problems. Try something like the following on Solaris:
$ perl -e 'print "x" x 1000000,"\n";' | awk '{$i++}'
awk: record `xxxxxxxxxxxxxxxxxxxx...' too long
Broken Pipe
$
I still have scripts from the early 1980's, and they run fine with the GNU utilities; that was a major goal of GNU. I shudder at the thought of having to go back to the commercial UNIX equivalents of the GNU tools.
The problem with UNIX is an LCD (lowest common denominator) and designed by committee problem.
UNIX was not the first OS, nor was it designed by committee. In fact, it was designed by a small research group in reaction to the excesses of systems like MULTICS (hence the name). Today, Windows NT follows in the MULTICS footsteps, with excessive APIs, redundant functionality, and a special-purpose API for any conceivable application. The lessons of UNIX are as relevant today as they were 30 years ago.
Compared to Win2K, Linux's technical advantages are pretty minor.
The advantage of UNIX (and to a more limited degree, Linux) is absence of features. Microsoft cannot catch up with that because they are moving in the wrong direction.
Microsoft has moved on, it's important for the UNIX community to do so as well. ACLs (implemented on NT) are FAR more flexible than users/groups.
How naive can you be? Do you think people at Bell Labs didn't consider ACL-like mechanisms? Don't you think they would have added them by now to Research Version 10 or Plan 9 if they thought this was the right thing to do? The creators of UNIX have never been constrained by committees or backwards compatibility: they have always done what they thought was right, and they changed things when they believed they had done something wrong. ACLs, so far, haven't cut it for them. You may disagree with their technical judgement, but don't attribute that disagreement to some nebulous notion of being outdated or old-fashioned.
HOWEVER, the system of making things conveniently obvious for the CLI results in engineering decisions that give the OS less flexibilities. GUIs can provide TREMENDOUS ammounts of information BECAUSE the user decides when to get that information.
As the Windows NT file properties dialog shows, GUIs don't help one bit with this problem. Yes, you can present lots of information in a GUI, but users can't process it any better than they could with any other method of displaying it. In practice, if you actually allow users to maintain their own ACLs, you end up with a complete mess of permissions on your hands.
Let's get back to the overall point. Of course, there is a need in the world for systems like MULTICS and Windows NT. There has always been, and there always will be. That's not because they are any better designed or any more modern, but because such systems satisfy the preferences and tastes of the masses of programmers. But that doesn't make such systems well-designed. As far as I'm concerned, systems like UNIX and Plan 9 are the systems for the thinking programmer, and MULTICS and Windows NT are the "lowest common denominator", catering to the masses who don't know any better. Which is also why I observe with a lot of concern the attempts to turn Linux into Windows and add all that Windows junk to Linux. As far as I'm concerned, that's not progress.
The Mac scheme is great for a desktop system. It makes no sense for most of the applications that UNIX and Linux have been used for traditionally. Quite to the contrary: the Mac "forks" and "types" cause constant headaches for such uses.
Linux isn't following Windows. Linux is following UNIX. UNIX deliberately has flat, simple, unadorned files. This isn't out of ignorance, it is out of careful consideration of the alternatives. If you want to build some metadata scheme on top of that, you can. Many applications do.
The most common scheme for metadata support under Linux is to treat directories and directory trees as units of information; Linux end-user applications unfortunately don't take enough advantage of this. Another common scheme now is to use XML. Yet another approach is to use a relational database for metadata.
What UNIX/Linux is missing is file change notifications and efficient support for lots of small files. ReiserFS looks to change that.
Windows NT and its successors have, in fact, database-like functionality and multiple forks in their files. I very much hope Linux will not be following either MacOS or Windows down this path. UNIX was in part created as a rebellion against that kind of creeping featurism.
Sorry, but at this point, I view SCO's/Caldera's UNIX source code as contamination and a distraction. The GNU utilities and other free software utilities are much better written, much more robust, and often much more efficient. In fact, the reason why the GNU utilities were so mature and widely used by the time Linux came around was because many people had already been running almost all open source systems on their proprietary workstations for years: MIT X11, GNU utilities and compilers, and a few non-GNU free software packages. That's also what O'Reilly got started on.
The original UNIX source code is best relegated to the historical archives. If you are considering packaging that stuff up for an open source distribution, you should get your fingers slapped:-)
That may or may not be the actual current legal situation. But I find it unacceptable to attempt to protect every kind of incompetence by service providers under computer crime statutes.
Hotmail's actions are negligent and show a callous disregard for the privacy and security of their user's data. This particular security hole is not even an acciedental mistake, it is plain incompetence. That kind of incompetence must be exposed and Hotmail and its officers should be held liable under civil and possibly criminal statutes.
Under your kind of reasoning, institutions like Consumer Union would not be able to point out security defects in commonly marketed devices or services. This is simply not acceptable, and if your statements represent current legal theory, the law needs to change. Consumers need this kind of information.
bad for AIX customers, bad for Linux
on
IBM Wants Linux
·
· Score: 2, Insightful
AIX is designed with a completely different mindset and for a completely different user population that Linux. I doubt AIX customers would be happy with Linux in anything like its current form, and I doubt Linux users would be happy if all the stuff added to AIX to make IBM's mainframe customers happy were added to Linux.
I was using AIX workstations until a couple of years ago. Here are some of the things that drove me up the wall about them:
Lousy file system performance. IBM's JFS is a dog when it comes to file operations. In side-by-side comparisons at the time, a low-end IDE PC running Linux 1.* would be 3-4 times faster than an PowerPC IBM workstation with high performance SCSI disks on file system structure operations (creating lots of small files, removing lots of small files, etc.).
Very slow booting. This is actually not an AIX problem, but a problem with the way IBM's workstations handle the SCSI bus. No matter what, workstations and servers would take from minutes to hours (!) to get through the boot process (I hope this has gotten fixed over the last couple of years). I mainly mention it because journalling is often advocated in order to make servers boot faster; well, on AIX systems, it didn't make much of a difference because booting was so slow anyway.
Logical volume management. LVM potentially degrades system performance because linear block addresses do not correspond to physical block location anymore. It also complicates system management, introducing another layer of indirection. And it potentially reduces system reliability when it is used to spread file systems across multiple disks.
System management objects and SMIT. System configuration information is stored in binary databases. That makes it inaccessible to scripting languages. Furthermore, if the file system runs out of space during a management operation, the database gets corrupted.
Non-standard linker semantics. The AIX linker does not behave at all like a regular UNIX linker. Among other things, it loads all symbols into memory at once and then does garbage collection. The end result is a linker that fails to give meaningful diagnostics about multiply defined symbols, fails in subtle ways on standard UNIX software, and consumes a lot of time and memory doing so.
Many of the system-level commands you may be used to from other versions of UNIX just don't exist at all or behave completely differently.
AIX is so un-UNIXy that the
Unix System Administrator Handbook kept making fun of it throughout its pages as the odd-man-out (it also deals with Solaris, Irix, HP/UX, and others), comments they removed in later editions presumably not to upset AIX users too much.
In defense of AIX workstations and servers, they are very reliable machines, and people who work only in the AIX world and don't deal with other UNIX systems probably never notice and don't care about the idiosyncracies.
Altogether, I see a big culture clash if IBM tries to move AIX users to Linux. And I think that clash may well end up harming Linux if it causes stuff like JFS and LVM to be adopted more widely in Linux. Let's not fall into the Microsoft mindset where everybody must run the same software; there is nothing wrong with having Linux, AIX, Windows, Solaris, and other systems co-exist. We don't need an OS monoculture.
I was only stating that D3D is winning by its accessibility (being installed on every Windows system and being usable by everyone from actual graphics programmers to VB junkies.)
Yes, and I am pointing out that this is classic Microsoft strategy. It is particularly galling in this case because OpenGL already existed, was working, and was available on Microsoft platforms. Microsoft replaced a mature, open, working standard with their own immature proprietary system solely to further their own market position.
Like the orderly standardization process for Lisp, or C++, or C? How well do those implementations generally work together?
ANSI standard Lisp, C++, and C are useful, well-defined languages and libraries. I write most of my code in ANSI standard C++. System dependencies (like for Windows) are kept to a minimum and well-encapsulated.
The last I heard of the OpenGL standards body, there was some serious fighting going on over the direction of the programming interface.
Sure there is, as there should be. Standardization is never easy or quick or painless; that doesn't make it any less useful. Quite to the contrary: the output of standards bodies is in my experience much more consistent and complete than the ad-hoc interfaces produced by a single vendor.
OpenGL might not live much longer.
I fully agree. The question is: how did we get to this miserable state of affairs and what can we do about it. Quietly giving into Microsoft's corporate strategy is not the right thing to do, because once they have eliminated competitors, they control content and prices, and they stop improving their products.
The best solution I can see is to go through portable, cross-platform intermediate libraries and API like SDL and OpenGL. In fact, this makes financial sense as well, since it makes software products more portable and less dependent on Microsoft's idiosyncratic strategic directions.
Sure they are: Fortran does not have a concept of "objects" or "pointers". The only way you can make COM work under Fortran is via non-standard language extensions or obscure glue libraries.
The point is that it's not implemented
The point is that if COM really mattered in this application, Microsoft didn't have to invent a whole new API, they could have simply done the obvious COM binding to OpenGL.
"Gaming" is not the primary purpose of DirectX
Well, of course, it isn't anymore. After Microsoft tried to move everybody to DirectX, people didn't have much of a choice. And DirectX has accreted other functionality, like some audio I/O and multimedia stuff.
How much Windows software have you written, exactly?
Too much.
Can you provide some specific examples of "fragmented" APIs?
Just look at the range of graphics APIs Windows supports. Even if you look at DirectX itself, it is evolving so rapidly that it is very difficult to provide an independent implementation on other platforms. Contrast that with OpenGL, which goes through an orderly standardization process and has multiple, independent implementations.
I'm not quite sure why this is so hard to grasp. Look at the long term evolution of Direct3D. It started off as complete junk, when OpenGL was already a mature 3D graphics API. Microsoft worked hard at replacing OpenGL, and they worked hard on improving Direct3D. The end result is that many years later, Direct3D is now almost as good as OpenGL was a few years ago, but it is a proprietary system completely controlled by Microsoft. This is not a desirable outcome for anybody but Microsoft stock holders.
Graphics card vendors currently *do* support OpenGL
You misunderstood. Game developers can pretty much count on DirectX support for all graphics cards. You are not guaranteed to get OpenGL support for all graphics cards, even though some vendors still supply it. That's why game developers really don't have much of a choice but to develop to DirectX/Direct3D.
Microsoft forced this situation by declaring their own, proprietary, inferior API the standard long after OpenGL support for Windows had come out. In doing so, they really didn't leave graphics card vendors a choice but to support DirectX. Once they did that, there was little incentive to develop support for OpenGL, and the smaller vendors stopped doing it. It's quite analogous to the bundling agreements: Microsoft makes you pay for something through bundling, and that removes the incentive to buy something better or from another vendor.
I don't give a damn about "fair use" of Disney or RIAA content. In my opinion, most of their content is junk, and they are just shooting themselves in the foot by restricting the ability of people to use it.
What really matters is the ability of people who aren't caught up in the IP hysteria to publish and disseminate information. And that is what these laws really threaten. The reason is that if you must use devices and formats sanctioned and patented by a few large corporations to distribute and access content, your ability to publish is artificially controlled.
And that is what all of this is really about. Publishers and "content providers" had a nice, cushy world in which the high cost of entry for things like transmitters, spectrum, printing presses, tape replication, and CD/DVD authoring kept the small fry out of their market. Now that the cost of authoring and distribution has gone to nearly zero, these interests feel threatened, and they are trying to erect artificial barriers to entry.
Under Windows, OpenGL is just a transformation layer for DirectX calls.
OpenGL used to be self-sufficient drivers on Windows, independent of DirectX, and implemented directly by hardware vendors. OpenGL on Windows, in fact, predates DirectX. OpenGL was relegated to second class status by Microsoft when they wanted to push their own proprietary APIs. Of course, once that happened, OpenGL became less attractive, which was just what Microsoft intended.
Another nice thing about the DirectX interfaces (issues of overhead aside) is that you can access dispatch interfaces on each DX object.
The OpenGL API is trivial, and easily bound to any language; that was part of its design goals. Microsoft's COM/DirectX interfaces are much less portable and much more difficult to bind to many languages (try accessing them from Fortran). Even wrapping OpenGL in a COM interface is something anybody (including Microsoft) could do in a couple of hours. Furthermore, you can, in fact, write efficient 3D graphics applications using OpenGL even from a scripting language, because all the compute-intensive stuff is handled by the OpenGL implementation; the scripting language only needs to manipulate the high level structures.
Because it's a preemptive multitasking system. The same thing would be necessary under Linux to shut down any running subsystems that hog valuable time-slices. DX doesn't provide "real-time" access either (whatever you meant by that,) but it does let you shut down most of the monolithic systems in Windows that get in your way and talk to the computer at one level of abstraction above the hardware.
You are missing the point here as well. I was asking (rhetorically) "why does an operating system need a separate set of game APIs to get real-time networking and audio I/O". The facilities DirectX provides are useful for many applications, and they shouldn't be designed around gaming (of course, you can use DirectX with other applications, but that's not their primary purpose). This is classic Microsoft: fragment the market, fragment the APIs, and achieve quick time-to-market with specialized solutions. It is also clasically bad software engineering.
No, it's because you can guarantee that someone has a DirectX-supporting graphics card. You can't guarantee that someone has an OpenGL-supporting graphics card.
That's my point. Think about why you don't get OpenGL drivers. It's because Microsoft stopped supporting OpenGL and basically forced graphics card vendors to support Direct3D.
The FSF has done, and continues to do so much good, but more and more tension continues to grow between the extreme free speech faction and the more moderate folks.
This is classic PR strategy: label one position as extreme and position yourself as middle-of-the-road. In fact, these are simply a few different positions among a wide variety of possibilities; which one looks more extreme depends on where you happen to sit yourself. Let's please stop borrowing this propagandistic language and stick to the facts.
Now, what about this specific case? We don't really know RMS's position, but if RMS has more specific concerns, he should communicate them publically. For now, I think Ulrich's recommendation is a pretty good one: consider carefully whether you sign your projects over to the FSF, and consider deleting the "any later version" clause from the (L)GPL. For now, it looks to me like Ulrich is doing the right thing with glibc.
Actually, there is. From the article: "it was found that the computer game only stimulated activity in the parts of the brain associated with vision and movement." [emphasis mine] Assuming that normal activity produces at least some stimulation and that stimulation causes development, that conclusion seems completely reasonable.
Even if the data is correct (it seems implausible given the nature of the task), it is the rule, not the exception, for activities to stimulate only a subset of all brain areas. There is nothing odd or unusual about that. And while some children may spend hours playing video games every day, they also spend hours doing other activities, likely providing sufficient stimulation for their frontal lobes to develop normally even if there were a causative relation.
The study does provide a plausible basis for causality.
The problem is not with a lack of plausibility for one possibility, but that the other possibilities are equally plausible.
By the sheer amount of DX games out there, isn't it obvious that the game industry doesn't find DX clunky
<sarcasm>Yes, and Windows is an innovative, easy-to-use operating system: just look at how many people are using it and developing for it. In fact, why doesn't everybody else just go away?</sarcasm>
The simple fact is that DirectX is heavily promoted and Microsoft is pushing development tools for it. Furthermore, you can bet that DirectX is preinstalled on just about every modern system while OpenGL is a pain to get working on a significant fraction of Windows machines.
People are picking DirectX because that's what Microsoft has decreed to be the standard, what they are pushing, and what they are supporting. Technically, DirectX still sucks; it's another one of a long line of Microsoft "me-too" products that Microsoft pushed on the market using their near-monopoly power.
It also does sound, input and networking.
Well, and there are excellent alternatives to DirectX in those areas as well. Besides, one might ask: why does an operating system need a separate set of game APIs to get real-time networking and audio I/O?
The Newton ended up offering a form factor and an input method that was mostly a flop. The PARCTAB, on the other hand, was a device with the Palm form factor and the Palm input method (it also offered ubiquitous wireless connectivity). So, Apple spent from 1988 to 1993 developing a device that turned out to be a dead end, while PARC spent from 1992 to 1993 developing a device that is pretty much representative of the kind of PDA everybody is carrying around. I think you can see the difference in terms of "innovation".
There is no basis to conclude from that data that playing video games interferes with frontal lobe development. All sorts of activities we engage in stimulate only a small part of the brain, and yet they don't cause problems. Even if it were conclusively demonstrated that the frontal lobes in people who play video games are less developed, whether there is causation and which way it goes would be very hard to decide (maybe people like playing video games in preference to social interaction because that's the way their brains are wired).
And any of this assumes that the study was done correctly. In fact, there are serious questions about normalization: very high activity in the visual and motor areas might simply have caused "normal" frontal lobe activity to be normalized away.
Between playing video games and watching television, I think kids are a lot better off playing video games.
Slashdot Mirror
The problem with BeOS isn't technology, it is long-term availability: why would anyone invest a lot of time and effort in learning its APIs and developing applications for it if there is no guarantee that it will be around in the long term?
Be apparently never understood this, so they continued on with their dreams of challenging the world with yet another proprietary OS. The only way BeOS could have attracted more of a following is if they had either put their source in escrow, to be released under BSD in case the company failed (like it did), or if they had pursued an open source strategy from the start. Otherwise, a developer or manager with any brains just wouldn't touch the thing.
Neither BeOS, nor Linux, nor Windows, nor MacOS win the crown for the most advanced technology. They are all compromises between backwards compatibility and functionality. Again, it's not about the greatest technology.
but what about those who want to be free of the shackles of X?
What about them? There is nothing in Linux that prevents non-X window systems to be implemented, even in the kernel if you like. In fact, there have been a bunch over the years. I suspect they haven't caught on because when all is said and done, X11 ends up being a much better window system after all, no matter how much some people whine about it.
In addition, there are numerous open source operating systems that do not use X; if you don't like Linux, you can use any of those.
Linux types always get mean about BeOS. My theory is that BeOS is the only thing out there that could possibly challenge Linux for technological supremacy.
You are quite right: BeOS could have challenged Linux technologically. That would have been a dreadful outcome. While BeOS may or may not be technically a little nicer than Linux for desktop applications, it is a proprietary, closed-source system. The last thing the world needs is more fragmentation among the non-Microsoft operating systems. If a significant number of Linux developers had switched to BeOS, they would now be stranded. Let's count our blessings that this hasn't happened.
Let Be's failure be a lesson: software vendors must take steps to assure their customers long-term availability of their software. If they can't do that through open source for some reason, they need to come up with some other strategy, otherwise, they'll not attract developers.
That's funny, because a lot of Linux hardware vendors offer dual-boot machines. The simple fact is that most people don't want to dual-boot and vendors have little economic incentive to preinstall Linux. The people who do want to dual-boot can.
Getting Linux may be a little easier in the future with FireWire disks: people can buy them after market, with Linux preinstalled. That removes most installation hassles and should make dual booting feasible, at worst with a floppy/CD.
From the brief summary, it looks like this would be very useful to protect a Linux system against malicious code, worms, and many other forms of attacks. For example, rather than trying to find and fix every buffer overrun in sendmail, you could keep sendmail from becoming destructive even if it is compromised. And you don't have to blindly trust every RPM and Debian package you install anymore, you can instead define policies for what the executables in that package may and may not do (e.g., an audio player probably has not business accessing /dev/hda).
What's the point of sticking new hardware into old cases if the old case doesn't look like an old case anymore?
However, as a good first step, to avoid the kind of mundane web sites the NYT article is complaining about, you might stop reading the New York Times itself.
People at Caltech were publishing papers on this sort of thing more than 15 years ago. The main thing that may be new this time around is the means by which the patterns themselves are deposited. However, I don't think that has been the limiting factor in applying these techniques in the past.
You might, however, call MacOS X "UNIX compatible", "mostly POSIX compliant", or "an operating system with a UNIX personality".
Well, because I started using UNIX in 1981 and have used pretty much every major version starting with V7, including Bell Labs internal versions. I have also lived through the evolution of the GNU tools and reported many bugs in them over the years (it's pointless to report bugs in the UNIX tools--they never get fixed by commercial vendors) and used them side-by-side with the UNIX tools.
The GNU utilities were written from the ground up with the idea of imposing no fixed size limits, being able to deal with binary inputs, and being backwards compatible with the UNIX utilities, and they have largely succeeded. The GNU tools often also use better algorithms and better data structures internally.
UNIX utilities used to just dump core on commands like "grep foo /vmunix", although much of that has at least been fixed. They often still have arbitrary limits and other problems. Try something like the following on Solaris:
$ perl -e 'print "x" x 1000000,"\n";' | awk '{$i++}'
awk: record `xxxxxxxxxxxxxxxxxxxx...' too long
Broken Pipe
$
I still have scripts from the early 1980's, and they run fine with the GNU utilities; that was a major goal of GNU. I shudder at the thought of having to go back to the commercial UNIX equivalents of the GNU tools.
UNIX was not the first OS, nor was it designed by committee. In fact, it was designed by a small research group in reaction to the excesses of systems like MULTICS (hence the name). Today, Windows NT follows in the MULTICS footsteps, with excessive APIs, redundant functionality, and a special-purpose API for any conceivable application. The lessons of UNIX are as relevant today as they were 30 years ago.
Compared to Win2K, Linux's technical advantages are pretty minor.
The advantage of UNIX (and to a more limited degree, Linux) is absence of features. Microsoft cannot catch up with that because they are moving in the wrong direction.
Microsoft has moved on, it's important for the UNIX community to do so as well. ACLs (implemented on NT) are FAR more flexible than users/groups.
How naive can you be? Do you think people at Bell Labs didn't consider ACL-like mechanisms? Don't you think they would have added them by now to Research Version 10 or Plan 9 if they thought this was the right thing to do? The creators of UNIX have never been constrained by committees or backwards compatibility: they have always done what they thought was right, and they changed things when they believed they had done something wrong. ACLs, so far, haven't cut it for them. You may disagree with their technical judgement, but don't attribute that disagreement to some nebulous notion of being outdated or old-fashioned.
HOWEVER, the system of making things conveniently obvious for the CLI results in engineering decisions that give the OS less flexibilities. GUIs can provide TREMENDOUS ammounts of information BECAUSE the user decides when to get that information.
As the Windows NT file properties dialog shows, GUIs don't help one bit with this problem. Yes, you can present lots of information in a GUI, but users can't process it any better than they could with any other method of displaying it. In practice, if you actually allow users to maintain their own ACLs, you end up with a complete mess of permissions on your hands.
Let's get back to the overall point. Of course, there is a need in the world for systems like MULTICS and Windows NT. There has always been, and there always will be. That's not because they are any better designed or any more modern, but because such systems satisfy the preferences and tastes of the masses of programmers. But that doesn't make such systems well-designed. As far as I'm concerned, systems like UNIX and Plan 9 are the systems for the thinking programmer, and MULTICS and Windows NT are the "lowest common denominator", catering to the masses who don't know any better. Which is also why I observe with a lot of concern the attempts to turn Linux into Windows and add all that Windows junk to Linux. As far as I'm concerned, that's not progress.
The Mac scheme is great for a desktop system. It makes no sense for most of the applications that UNIX and Linux have been used for traditionally. Quite to the contrary: the Mac "forks" and "types" cause constant headaches for such uses.
The most common scheme for metadata support under Linux is to treat directories and directory trees as units of information; Linux end-user applications unfortunately don't take enough advantage of this. Another common scheme now is to use XML. Yet another approach is to use a relational database for metadata.
What UNIX/Linux is missing is file change notifications and efficient support for lots of small files. ReiserFS looks to change that.
Windows NT and its successors have, in fact, database-like functionality and multiple forks in their files. I very much hope Linux will not be following either MacOS or Windows down this path. UNIX was in part created as a rebellion against that kind of creeping featurism.
The original UNIX source code is best relegated to the historical archives. If you are considering packaging that stuff up for an open source distribution, you should get your fingers slapped :-)
Hotmail's actions are negligent and show a callous disregard for the privacy and security of their user's data. This particular security hole is not even an acciedental mistake, it is plain incompetence. That kind of incompetence must be exposed and Hotmail and its officers should be held liable under civil and possibly criminal statutes.
Under your kind of reasoning, institutions like Consumer Union would not be able to point out security defects in commonly marketed devices or services. This is simply not acceptable, and if your statements represent current legal theory, the law needs to change. Consumers need this kind of information.
I was using AIX workstations until a couple of years ago. Here are some of the things that drove me up the wall about them:
AIX is so un-UNIXy that the Unix System Administrator Handbook kept making fun of it throughout its pages as the odd-man-out (it also deals with Solaris, Irix, HP/UX, and others), comments they removed in later editions presumably not to upset AIX users too much.
In defense of AIX workstations and servers, they are very reliable machines, and people who work only in the AIX world and don't deal with other UNIX systems probably never notice and don't care about the idiosyncracies.
Altogether, I see a big culture clash if IBM tries to move AIX users to Linux. And I think that clash may well end up harming Linux if it causes stuff like JFS and LVM to be adopted more widely in Linux. Let's not fall into the Microsoft mindset where everybody must run the same software; there is nothing wrong with having Linux, AIX, Windows, Solaris, and other systems co-exist. We don't need an OS monoculture.
Yes, and I am pointing out that this is classic Microsoft strategy. It is particularly galling in this case because OpenGL already existed, was working, and was available on Microsoft platforms. Microsoft replaced a mature, open, working standard with their own immature proprietary system solely to further their own market position.
Like the orderly standardization process for Lisp, or C++, or C? How well do those implementations generally work together?
ANSI standard Lisp, C++, and C are useful, well-defined languages and libraries. I write most of my code in ANSI standard C++. System dependencies (like for Windows) are kept to a minimum and well-encapsulated.
The last I heard of the OpenGL standards body, there was some serious fighting going on over the direction of the programming interface.
Sure there is, as there should be. Standardization is never easy or quick or painless; that doesn't make it any less useful. Quite to the contrary: the output of standards bodies is in my experience much more consistent and complete than the ad-hoc interfaces produced by a single vendor.
OpenGL might not live much longer.
I fully agree. The question is: how did we get to this miserable state of affairs and what can we do about it. Quietly giving into Microsoft's corporate strategy is not the right thing to do, because once they have eliminated competitors, they control content and prices, and they stop improving their products.
The best solution I can see is to go through portable, cross-platform intermediate libraries and API like SDL and OpenGL. In fact, this makes financial sense as well, since it makes software products more portable and less dependent on Microsoft's idiosyncratic strategic directions.
Sure they are: Fortran does not have a concept of "objects" or "pointers". The only way you can make COM work under Fortran is via non-standard language extensions or obscure glue libraries.
The point is that it's not implemented
The point is that if COM really mattered in this application, Microsoft didn't have to invent a whole new API, they could have simply done the obvious COM binding to OpenGL.
"Gaming" is not the primary purpose of DirectX
Well, of course, it isn't anymore. After Microsoft tried to move everybody to DirectX, people didn't have much of a choice. And DirectX has accreted other functionality, like some audio I/O and multimedia stuff.
How much Windows software have you written, exactly?
Too much.
Can you provide some specific examples of "fragmented" APIs?
Just look at the range of graphics APIs Windows supports. Even if you look at DirectX itself, it is evolving so rapidly that it is very difficult to provide an independent implementation on other platforms. Contrast that with OpenGL, which goes through an orderly standardization process and has multiple, independent implementations.
I'm not quite sure why this is so hard to grasp. Look at the long term evolution of Direct3D. It started off as complete junk, when OpenGL was already a mature 3D graphics API. Microsoft worked hard at replacing OpenGL, and they worked hard on improving Direct3D. The end result is that many years later, Direct3D is now almost as good as OpenGL was a few years ago, but it is a proprietary system completely controlled by Microsoft. This is not a desirable outcome for anybody but Microsoft stock holders.
You misunderstood. Game developers can pretty much count on DirectX support for all graphics cards. You are not guaranteed to get OpenGL support for all graphics cards, even though some vendors still supply it. That's why game developers really don't have much of a choice but to develop to DirectX/Direct3D.
Microsoft forced this situation by declaring their own, proprietary, inferior API the standard long after OpenGL support for Windows had come out. In doing so, they really didn't leave graphics card vendors a choice but to support DirectX. Once they did that, there was little incentive to develop support for OpenGL, and the smaller vendors stopped doing it. It's quite analogous to the bundling agreements: Microsoft makes you pay for something through bundling, and that removes the incentive to buy something better or from another vendor.
What really matters is the ability of people who aren't caught up in the IP hysteria to publish and disseminate information. And that is what these laws really threaten. The reason is that if you must use devices and formats sanctioned and patented by a few large corporations to distribute and access content, your ability to publish is artificially controlled.
And that is what all of this is really about. Publishers and "content providers" had a nice, cushy world in which the high cost of entry for things like transmitters, spectrum, printing presses, tape replication, and CD/DVD authoring kept the small fry out of their market. Now that the cost of authoring and distribution has gone to nearly zero, these interests feel threatened, and they are trying to erect artificial barriers to entry.
OpenGL used to be self-sufficient drivers on Windows, independent of DirectX, and implemented directly by hardware vendors. OpenGL on Windows, in fact, predates DirectX. OpenGL was relegated to second class status by Microsoft when they wanted to push their own proprietary APIs. Of course, once that happened, OpenGL became less attractive, which was just what Microsoft intended.
Another nice thing about the DirectX interfaces (issues of overhead aside) is that you can access dispatch interfaces on each DX object.
The OpenGL API is trivial, and easily bound to any language; that was part of its design goals. Microsoft's COM/DirectX interfaces are much less portable and much more difficult to bind to many languages (try accessing them from Fortran). Even wrapping OpenGL in a COM interface is something anybody (including Microsoft) could do in a couple of hours. Furthermore, you can, in fact, write efficient 3D graphics applications using OpenGL even from a scripting language, because all the compute-intensive stuff is handled by the OpenGL implementation; the scripting language only needs to manipulate the high level structures.
Because it's a preemptive multitasking system. The same thing would be necessary under Linux to shut down any running subsystems that hog valuable time-slices. DX doesn't provide "real-time" access either (whatever you meant by that,) but it does let you shut down most of the monolithic systems in Windows that get in your way and talk to the computer at one level of abstraction above the hardware.
You are missing the point here as well. I was asking (rhetorically) "why does an operating system need a separate set of game APIs to get real-time networking and audio I/O". The facilities DirectX provides are useful for many applications, and they shouldn't be designed around gaming (of course, you can use DirectX with other applications, but that's not their primary purpose). This is classic Microsoft: fragment the market, fragment the APIs, and achieve quick time-to-market with specialized solutions. It is also clasically bad software engineering.
That's my point. Think about why you don't get OpenGL drivers. It's because Microsoft stopped supporting OpenGL and basically forced graphics card vendors to support Direct3D.
This is classic PR strategy: label one position as extreme and position yourself as middle-of-the-road. In fact, these are simply a few different positions among a wide variety of possibilities; which one looks more extreme depends on where you happen to sit yourself. Let's please stop borrowing this propagandistic language and stick to the facts.
Now, what about this specific case? We don't really know RMS's position, but if RMS has more specific concerns, he should communicate them publically. For now, I think Ulrich's recommendation is a pretty good one: consider carefully whether you sign your projects over to the FSF, and consider deleting the "any later version" clause from the (L)GPL. For now, it looks to me like Ulrich is doing the right thing with glibc.
Even if the data is correct (it seems implausible given the nature of the task), it is the rule, not the exception, for activities to stimulate only a subset of all brain areas. There is nothing odd or unusual about that. And while some children may spend hours playing video games every day, they also spend hours doing other activities, likely providing sufficient stimulation for their frontal lobes to develop normally even if there were a causative relation.
The study does provide a plausible basis for causality.
The problem is not with a lack of plausibility for one possibility, but that the other possibilities are equally plausible.
<sarcasm>Yes, and Windows is an innovative, easy-to-use operating system: just look at how many people are using it and developing for it. In fact, why doesn't everybody else just go away?</sarcasm>
The simple fact is that DirectX is heavily promoted and Microsoft is pushing development tools for it. Furthermore, you can bet that DirectX is preinstalled on just about every modern system while OpenGL is a pain to get working on a significant fraction of Windows machines.
People are picking DirectX because that's what Microsoft has decreed to be the standard, what they are pushing, and what they are supporting. Technically, DirectX still sucks; it's another one of a long line of Microsoft "me-too" products that Microsoft pushed on the market using their near-monopoly power.
It also does sound, input and networking.
Well, and there are excellent alternatives to DirectX in those areas as well. Besides, one might ask: why does an operating system need a separate set of game APIs to get real-time networking and audio I/O?
The Newton ended up offering a form factor and an input method that was mostly a flop. The PARCTAB, on the other hand, was a device with the Palm form factor and the Palm input method (it also offered ubiquitous wireless connectivity). So, Apple spent from 1988 to 1993 developing a device that turned out to be a dead end, while PARC spent from 1992 to 1993 developing a device that is pretty much representative of the kind of PDA everybody is carrying around. I think you can see the difference in terms of "innovation".
And any of this assumes that the study was done correctly. In fact, there are serious questions about normalization: very high activity in the visual and motor areas might simply have caused "normal" frontal lobe activity to be normalized away.
Between playing video games and watching television, I think kids are a lot better off playing video games.