AIX is full of non-standard, overengineered solutions:
The AIX linker performs symbol resolution in a way that is academically interesting and formally compliant with the ANSI C standard but in practice breaks a lot of software.
JFS sounds nice on paper, but it doesn't really help a lot in practice with system availability (among other things, it doesn't protect data, only file system structure), and its performance is lousy (JFS also has little to do with "support for databases").
IBM's LVM is a hack that may give you short term convenience, but it complicates system administration, reduces system reliability, and may adversely affect performance.
AIX's system management interface (SMIT) relies on a flaky and non-standard "system object database" and makes administration of AIX machines very different from other UNIX machines--the Linux system admin tools are as good or better.
We can't keep IBM from porting this stuff to Linux, but I hope major Linux distributions will have the good sense not to put it into the standard installations. I switched from AIX to Linux when I had the choice. There is virtue in being simpler: Linux was faster than AIX on slower hardware, it was more reliable, and it was simpler to use for server applications. If there is one thing I wouldn't mind seeing IBM contribute, it's their Fortran 90 compiler. Linux lacks a good, free, native Fortran 90 compiler right now. Beyond that, I can't think of anything in AIX that I would like in Linux.
And don't get confused about why companies like IBM and SGI are "donating" this stuff: they have a big legacy software problem, and they want to rid themselves of their albatrosses. This isn't "advanced technology" they are contributing for the good of the world, it's messy legacy functionality they want to get into a publically maintained software base so that they don't have to pay for software maintenance for their legacy customers. Most of the customers who want that stuff come from a different computing era and environment than Linux, and I suspect many of them will want to continue using proprietary software (meaning NT or Solaris).
Making software open in order to reduce development and systems integration costs is as good a motivation as any for contributing to open source software. But while it may be very attractive for a vendor to have such stuff added to the Linux kernel and OS, ultimately, the open source community may pay a steep cost in delayed releases and reduced usability as Linux gets ever more complex. Open source needs to be selective about what it accepts. Maybe Linus should start charging money for putting formerly commercial software into the kernel.
Windows GUI is simple to use (compared to X,
and I would argue GTK+ too but I haven't used GTK+ enough to pass judgement), and is much, much faster.
The simple reason for this is twofold, the first being that Windows GUI apps talk directly with the GUI system
through system calls (USER.DLL anyone?) that go straight to the device, while X requires both a netowrk layer
and then a user-space layer (although some also have a kernel-space layer).
I wish people would stop engaging in this kind of uniformed guesswork. X11 is plenty fast for rendering HTML; people have used it for much more demanding applications. If Mozilla has a slow GUI, then it's because it isn't written right. If Mozilla runs fast on Windows and slow on Linux, then perhaps its toolkit makes assumptions about the underlying Window system that apply to Windows and don't apply to X11. That doesn't make X11 slow, it makes Mozilla poorly written.
Until someone creates a GUI system under UNIX that doesn't require a network layer, UNIX GUIs will always be
slower than Windows GUIs.
That isn't really relevant to building a fast browser--both GUIs are plenty responsive and fast for that. But it is also not true in general. The X11 protocol can have a lot of advantages over the procedure-call-based approach in Win32, and it is far from clear which one ought to perform better in general. The matter gets even more complex in the presence of graphics co-processors, multiprocessors, or a networked display, where X11 can often take advantage of parallelism and asynchronous processing much better. In any case, in practice, in my experience, X11 is often as fast or faster than Win32.
Whether these keyboards have any benefit when it comes to preventing RSI remains to be seen; they still require repetitive fine motor control and may simply transfer the problem from one area to another.
Half-QWERTY, of course, is useful if, for one reason or another, you need to type one-handed.
TeX output is pretty good, and LaTeX markup is pretty good, too.
Where TeX falls way short is in the way it is programmed and extended. The TeX processor is more like a machine language, with registers, lots of side effects, hooks, and global variables. Doing non-trivial transformations in TeX is incredibly hard, and even the best macro packages often don't get it quite right.
XML's approach is both more modern and much simpler: you describe transformations on the parse tree. XSLT and XSLT:FO are what corresponds to the programmable guts of TeX.
Most likely, what is going to happen is that many documents will be authored in XML, many document styles will be described in XSLT and XML Schema, and TeX will be used not for defining macro packages, but merely for performing the last stages of physical layout.
XML isn't just "text files with tags". XML comes with standards for describing the grammar of those files, with a standard language for describing transformations, and with standards for performing physical layout. In terms of tools, there are standard libraries for many languages to read and write XML, and standard APIs for manipulating XML once it has been parsed.
XML is pretty verbose and ugly. It's not the most convenient format to type in. But, in some sense, it finally extends the traditional UNIX approach to more complex data types. UNIX used to give you scanf, printf, and plain text files with fields. XML now extends that to parsing, generating, and transforming tree-structured types. That's really great, and it is really useful.
Microsoft documents the.DOC format, probably as well as they understand it themselves, and there are reasonably good converters/readers for it, some even open source (OpenOffice contains one of them).
The problem with.DOC is the typical Microsoft problem: Microsoft beats other people to market by "just getting the job done". They hack up what needs to be done, if it works 90% it's OK, and maybe they document it later. They are even proud of that and seem to think it's the right way to go because they actually beat everybody else to market; let's hope the customers will wake up to this and stop buying.
The latest.DOC format is supposedly XML (with embedded binary). That will help somewhat, in that it will at least make the text and other important information accessible without a complex OLE infrastructure. But to take full advantage of the information found in.DOC will still not be possible. The.DOC format often contains scripting and all sorts of other extensions, and the actual semantics of those can depend heavily on the environment or a buried deep inside some MS Word module.
Note that inside Microsoft, there now seems to be another approach, NetDocs. If it delivers what it claims to, a fully XML-based standards-compliant, end-user document and information management system, I have my doubts that that will catch on--it is way out of character for Microsoft.
It's nice that Linux and NT have been ported to those processors. Many applications will benefit from that.
Having a 64bit address space available greatly changes how you can approach many problems in OS design and implementation.
To take real advantage of 64bit (and beyond) processors, we should have new approaches, not just old code widened.
It is for this and many other reasons that companies should be prohibited from keeping personal information beyond the immediate transaction between the consumer and the company. It's the law in the EU, and it should be the law here.
no advantage of .NET over Java
on
Perl and .NET
·
· Score: 2
Where Microsoft betters Sun is that while Java is the only real language that compiles to the
JVM, Microsoft intends IL to be cross-language. That is, Perl, Visual Basic and C# can be
compiled down to IL.
Microsoft may be better on public relations there but no on substance. Perl could easily be compiled into Java byte codes (in fact, there is a project around to do just that), just like Python, Smalltalk, Scheme, Basic, Modula, Pascal, and lots of other languages are. While the JVM is most natural as a target for a Java compiler, it is a pretty universal runtime for safe languages, and most of them can be compiled into it without major problems.
And when it comes down to the one area where Microsoft could genuinely differ, compilation of C++, they fail to deliver what they promise: only a restricted subset of C++ is compiled into their intermediate language; you could do the same for compiling a restricted subset of C++ into the JVM.
If you want more information on language for the Java VM, look here. It lists about 130 systems that implement existing languages based on the JVM.
You may not be able to create any video codec without infringing on some patents, but as I understand it, if you try to implement something non-trivial that is MPEG4-compliant, you will be infringing.
As far as I can tell, Microsoft didn't invent much of the typographical technology you point to--most of it came from Apple, Adobe, Bitstream, and many other sources.
As for doing antialiasing behind the scenes in an X11 server, a hack like that may work most of the time, but it deviates from the definition and may break some applications. Doubtlessly, the same thing was true when Microsoft added antialiasing to Windows, but Microsoft controlled the Windows API. Hummingbird doesn't control the X11 API and if they deviate from the specs in this way, they are simply providing you with a broken X11 implementation.
The X11 protocol gives applications bit-accurate control over drawing. The spec doesn't just say that you call XDrawText and something vaguely resembling the text will appear in the window roughly where you want it to, it defines the exact way in which the text bitmap gets combined with the window contents. Furthermore, the X11 server is not permitted to allocate extra colors (grey values) just because it feels like it; the application may require control over those values itself.
The X11 protocol and Xlib are not at the level of abstraction of the Windows GDI, Postscript, or other, similar APIs; they are lower level. Anybody dealing with them needs to write a lot of code dealing with different device classes. In X11, you get a Windows GDI-like API, with all its conveniences and limitations, more at the level of the toolkits. Such toolkits can then provide you with antialiased rendering when available without code changes. GTK, Qt, fltk, and wxWindows all have hooks for putting this functionality in.
Ah, The Onion is now a reputable source of statistics?:-)
In any case, really, I prefer riding in a comfortable train for an hour to driving a car for an hour. Most Americans would probably feel the same way if they ever had the experience. Instead, they get a rundown, dirty, and messy public transit system, and it is no surprise that they don't want more of it.
Well, I agree that methanol would bet better than gasoline. However, I don't think methanol is nearly as attractive as hydrogen.
One of the promises of hydrogen is that it can be produced in large quantities in regions that are otherwise unproductive. All you need is sun or another source of energy and water (even salt water will do). Methanol, on the other hand, needs to be produced from coal (resulting in a net release of greenhouse gasses), or various forms of agriculture (taking up arable land).
There are a bunch of advertising killers for Linux. Some of them come as easy-to-install packages. Others are hackable scripts. Yet others are research projects and use various kinds of pattern recognition.
Yes, none of them are as consumer oriented as the Windows product, but then Linux users aren't average consumers. That doesn't invalidate my original point.
As for your suggestion that Windows applications are generally easier to install, that's pretty laughable. Windows installers require human interaction as a rule and perform very unpredictable changes to the system. RPM and other Linux package systems are much more efficient and easy to use.
Actually, technologically, Windows and Linux are pretty similar. They are both stuck somewhere in the 1970's. The difference is that with Windows you pay for that old stuff over and over again, while with Linux, at least you get it free after all these years.
Slater is asking the wrong question. The fact is that most cities in the US today need a good public transit system and that the old system was dismantled because of short-sighted economic concerns. I don't think people then were so stupid as not to foresee the long-term consequences of their actions, and in that sense, they are responsible.
Slater's claim that streetcars are obsolete and declined in the rest of the world also flies in the face of fact. Most European cities have excellent systems of streetcars, lightrail, trains, and subways.
The upshot: we could genuinely discuss a conspiracy only if GM pursued its course of action and dismantled
the nation's systems in spite of the fact that streetcars offered more benefits than buses. Ridership peaked
in the late 1920s, and had been falling off consistently for over a decade by the time the systems were
dismantled in the 1940s and 1950s.
Optimal individual choices do not add up to optimal long-term societal choices. Taking cars or buses is, of course, more convenient compared to streetcars when there are few buses and cars around, even if they become unattractive choices once lots of people have adopted them. The only way to counter such market failures is through long-term government planning. That is exactly what failed in this case.
The issue is not whether, as Slater states, "the buses that replaced the streetcars were [emphasis added] economically superior", the question is whether they represented sound long-term public policy. And the answer is that they clearly did not. Realistically, both GM and the government have to take the blame for the lousy public transit infrastructure in the US today, for impossibly long commute times, traffic fatalities, and other inefficiencies. The outcome was entirely predictable, and the whole process was motivated by short-term greed.
Just think: we'd have to ship poisonous organic compounds in huge quantities all across the country and maybe even across the oceans. This stuff would have to be handled by people without training. It might leak into ground water and cause cancer. If a tanker bursts, it could contaminate miles of shoreline. And if people smoke around it, the whole "pumping station" might explode.
I think we should stick with horses: they are pretty harmless and they eat grass that's available everywhere.
Seriously, logistically, oil-based fuels are just about the worst you can imagine. Yes, it costs money to retool, but probably less than the medical costs related to burning gasoline alone. And the retooling creates job and economic opportunities anyway.
Bug reports and feature suggestions are immensely valuable. In fact, arguably, much of the value and enhancements to MS Office and similar products are the result of such feedback. And a good way of getting such feedback is by releasing binaries.
It's bad enough that companies so often copy the ideas developed by free UNIX/Linux software and release proprietary Windows versions. Then recommending such software back to UNIX/Linux users just seems insulting.
How many things advertised in banner ads can people really buy? Perhaps they aren't clicking because they just don't want to buy that stuff right now. Making the ads more prominent is just going to annoy people more.
Do you really believe that Einstein, Churchill, Gates, Jobs, Ellison, Ford, Clinton, and other "successful" people are models of good socialization, happiness, and well-adjusted behavior? What you learn on the playground may be helpful in figuring out how to influence other people and appear "charismatic", but there are many other ways of influencing people and getting what you want. Besides, the 2.5 children, public education, be-a-child, play-within-your-age-group upbringing is historically a pretty recent phenomenon, and the US results are, shall we say, not overwhelmingly convincing.
More likely, many really smart people figure out pretty quickly that a good life is not about taking the biggest risks, driving the biggest cars, or having the largest number of people grovel at your feet. They live just the way they like, doing what they enjoy, and they can easily figure out how to do it. And, you know, for some that means a pretty excentric life style. So what?
Slashdot Mirror
We can't keep IBM from porting this stuff to Linux, but I hope major Linux distributions will have the good sense not to put it into the standard installations. I switched from AIX to Linux when I had the choice. There is virtue in being simpler: Linux was faster than AIX on slower hardware, it was more reliable, and it was simpler to use for server applications. If there is one thing I wouldn't mind seeing IBM contribute, it's their Fortran 90 compiler. Linux lacks a good, free, native Fortran 90 compiler right now. Beyond that, I can't think of anything in AIX that I would like in Linux.
And don't get confused about why companies like IBM and SGI are "donating" this stuff: they have a big legacy software problem, and they want to rid themselves of their albatrosses. This isn't "advanced technology" they are contributing for the good of the world, it's messy legacy functionality they want to get into a publically maintained software base so that they don't have to pay for software maintenance for their legacy customers. Most of the customers who want that stuff come from a different computing era and environment than Linux, and I suspect many of them will want to continue using proprietary software (meaning NT or Solaris).
Making software open in order to reduce development and systems integration costs is as good a motivation as any for contributing to open source software. But while it may be very attractive for a vendor to have such stuff added to the Linux kernel and OS, ultimately, the open source community may pay a steep cost in delayed releases and reduced usability as Linux gets ever more complex. Open source needs to be selective about what it accepts. Maybe Linus should start charging money for putting formerly commercial software into the kernel.
I wish people would stop engaging in this kind of uniformed guesswork. X11 is plenty fast for rendering HTML; people have used it for much more demanding applications. If Mozilla has a slow GUI, then it's because it isn't written right. If Mozilla runs fast on Windows and slow on Linux, then perhaps its toolkit makes assumptions about the underlying Window system that apply to Windows and don't apply to X11. That doesn't make X11 slow, it makes Mozilla poorly written.
That isn't really relevant to building a fast browser--both GUIs are plenty responsive and fast for that. But it is also not true in general. The X11 protocol can have a lot of advantages over the procedure-call-based approach in Win32, and it is far from clear which one ought to perform better in general. The matter gets even more complex in the presence of graphics co-processors, multiprocessors, or a networked display, where X11 can often take advantage of parallelism and asynchronous processing much better. In any case, in practice, in my experience, X11 is often as fast or faster than Win32.
Half-QWERTY, of course, is useful if, for one reason or another, you need to type one-handed.
Where TeX falls way short is in the way it is programmed and extended. The TeX processor is more like a machine language, with registers, lots of side effects, hooks, and global variables. Doing non-trivial transformations in TeX is incredibly hard, and even the best macro packages often don't get it quite right.
XML's approach is both more modern and much simpler: you describe transformations on the parse tree. XSLT and XSLT:FO are what corresponds to the programmable guts of TeX.
Most likely, what is going to happen is that many documents will be authored in XML, many document styles will be described in XSLT and XML Schema, and TeX will be used not for defining macro packages, but merely for performing the last stages of physical layout.
XML is pretty verbose and ugly. It's not the most convenient format to type in. But, in some sense, it finally extends the traditional UNIX approach to more complex data types. UNIX used to give you scanf, printf, and plain text files with fields. XML now extends that to parsing, generating, and transforming tree-structured types. That's really great, and it is really useful.
The problem with .DOC is the typical Microsoft problem: Microsoft beats other people to market by "just getting the job done". They hack up what needs to be done, if it works 90% it's OK, and maybe they document it later. They are even proud of that and seem to think it's the right way to go because they actually beat everybody else to market; let's hope the customers will wake up to this and stop buying.
The latest .DOC format is supposedly XML (with embedded binary). That will help somewhat, in that it will at least make the text and other important information accessible without a complex OLE infrastructure. But to take full advantage of the information found in .DOC will still not be possible. The .DOC format often contains scripting and all sorts of other extensions, and the actual semantics of those can depend heavily on the environment or a buried deep inside some MS Word module.
Note that inside Microsoft, there now seems to be another approach, NetDocs. If it delivers what it claims to, a fully XML-based standards-compliant, end-user document and information management system, I have my doubts that that will catch on--it is way out of character for Microsoft.
It's nice that Linux and NT have been ported to those processors. Many applications will benefit from that. Having a 64bit address space available greatly changes how you can approach many problems in OS design and implementation. To take real advantage of 64bit (and beyond) processors, we should have new approaches, not just old code widened.
It is for this and many other reasons that companies should be prohibited from keeping personal information beyond the immediate transaction between the consumer and the company. It's the law in the EU, and it should be the law here.
Microsoft may be better on public relations there but no on substance. Perl could easily be compiled into Java byte codes (in fact, there is a project around to do just that), just like Python, Smalltalk, Scheme, Basic, Modula, Pascal, and lots of other languages are. While the JVM is most natural as a target for a Java compiler, it is a pretty universal runtime for safe languages, and most of them can be compiled into it without major problems.
And when it comes down to the one area where Microsoft could genuinely differ, compilation of C++, they fail to deliver what they promise: only a restricted subset of C++ is compiled into their intermediate language; you could do the same for compiling a restricted subset of C++ into the JVM.
If you want more information on language for the Java VM, look here. It lists about 130 systems that implement existing languages based on the JVM.
You may not be able to create any video codec without infringing on some patents, but as I understand it, if you try to implement something non-trivial that is MPEG4-compliant, you will be infringing.
As for doing antialiasing behind the scenes in an X11 server, a hack like that may work most of the time, but it deviates from the definition and may break some applications. Doubtlessly, the same thing was true when Microsoft added antialiasing to Windows, but Microsoft controlled the Windows API. Hummingbird doesn't control the X11 API and if they deviate from the specs in this way, they are simply providing you with a broken X11 implementation.
The X11 protocol and Xlib are not at the level of abstraction of the Windows GDI, Postscript, or other, similar APIs; they are lower level. Anybody dealing with them needs to write a lot of code dealing with different device classes. In X11, you get a Windows GDI-like API, with all its conveniences and limitations, more at the level of the toolkits. Such toolkits can then provide you with antialiased rendering when available without code changes. GTK, Qt, fltk, and wxWindows all have hooks for putting this functionality in.
In any case, really, I prefer riding in a comfortable train for an hour to driving a car for an hour. Most Americans would probably feel the same way if they ever had the experience. Instead, they get a rundown, dirty, and messy public transit system, and it is no surprise that they don't want more of it.
One of the promises of hydrogen is that it can be produced in large quantities in regions that are otherwise unproductive. All you need is sun or another source of energy and water (even salt water will do). Methanol, on the other hand, needs to be produced from coal (resulting in a net release of greenhouse gasses), or various forms of agriculture (taking up arable land).
Yes, none of them are as consumer oriented as the Windows product, but then Linux users aren't average consumers. That doesn't invalidate my original point.
As for your suggestion that Windows applications are generally easier to install, that's pretty laughable. Windows installers require human interaction as a rule and perform very unpredictable changes to the system. RPM and other Linux package systems are much more efficient and easy to use.
Actually, technologically, Windows and Linux are pretty similar. They are both stuck somewhere in the 1970's. The difference is that with Windows you pay for that old stuff over and over again, while with Linux, at least you get it free after all these years.
Well, according to their FAQ, they don't use wavelets. That was one of my points.
Slater's claim that streetcars are obsolete and declined in the rest of the world also flies in the face of fact. Most European cities have excellent systems of streetcars, lightrail, trains, and subways.
Optimal individual choices do not add up to optimal long-term societal choices. Taking cars or buses is, of course, more convenient compared to streetcars when there are few buses and cars around, even if they become unattractive choices once lots of people have adopted them. The only way to counter such market failures is through long-term government planning. That is exactly what failed in this case.
The issue is not whether, as Slater states, "the buses that replaced the streetcars were [emphasis added] economically superior", the question is whether they represented sound long-term public policy. And the answer is that they clearly did not. Realistically, both GM and the government have to take the blame for the lousy public transit infrastructure in the US today, for impossibly long commute times, traffic fatalities, and other inefficiencies. The outcome was entirely predictable, and the whole process was motivated by short-term greed.
I think we should stick with horses: they are pretty harmless and they eat grass that's available everywhere.
Seriously, logistically, oil-based fuels are just about the worst you can imagine. Yes, it costs money to retool, but probably less than the medical costs related to burning gasoline alone. And the retooling creates job and economic opportunities anyway.
Bug reports and feature suggestions are immensely valuable. In fact, arguably, much of the value and enhancements to MS Office and similar products are the result of such feedback. And a good way of getting such feedback is by releasing binaries.
Any good vendor of space technology will just send them replacement parts overnight by FEDEX.
It's bad enough that companies so often copy the ideas developed by free UNIX/Linux software and release proprietary Windows versions. Then recommending such software back to UNIX/Linux users just seems insulting.
How many things advertised in banner ads can people really buy? Perhaps they aren't clicking because they just don't want to buy that stuff right now. Making the ads more prominent is just going to annoy people more.
More likely, many really smart people figure out pretty quickly that a good life is not about taking the biggest risks, driving the biggest cars, or having the largest number of people grovel at your feet. They live just the way they like, doing what they enjoy, and they can easily figure out how to do it. And, you know, for some that means a pretty excentric life style. So what?