If you consider the makeup of the board, only IBM has any kind of direct interest in Linux and I really don't think they want Linux for it's amazing leaps forward in GUI design.
If they don't, then they should. While Windows and MacOS have monolithic, unwieldy GUIs that are constraint by a need to cater to legacy tastes, Linux and X11 neatly modularize the major functions of a window system: 2D graphics, input methods, window management, inter client communications, network transparency, resources, authentication, etc.
In Linux, you can actually try out new window management styles, new input methods, or new kinds of widgets without having to start from scratch.
The real problem is that almost nobody is doing research in human-computer interaction anymore--everybody just keeps tinkering around with the same old paradigms.
GPL is a license for copyrighted materials--it doesn't apply to standards, only to code. Standards are potentially affected by patents.
In order to leverage similar to the GPL in these kinds of situations, organizations like the FSF must start applying for patents. Then, they have bargaining chips.
[Microsoft is] offering to license their IP under reasonable and nondiscriminatory terms; will license rights to the extent necessary, provided a reciprocal license is granted to MS.
RAND, of course, means commercial cross-licensing. Microsoft is using this as a tactic for excluding open source. They know they can kill companies like Apple in the market, but they are deathly afraid of Linux and open source. OpenGL is a particular thorn in their side since it just won't go away, and Microsoft's own junky 3D interface hasn't been able to kill the competition. So, Microsoft is now trying underhanded legal maneuvres
I think the only way for open source to play will be to have an open source patent portfolio and to bring that to the table. Open source needs its own bargaining chips at the table.
You have two processors: the CPU and the GPU. You partition execution of the graphics code between them in a variety of ways and you standardize that. What, exactly, is the invention supposed to be?
Microsoft may well be aiming to use this to exclude open source from the table--commercial vendors that are part of the consortium cross-license their patent portfolios related to OpenGL and Linux is out in the cold. That is, after all, what Microsoft really wants. They know they can beat down Apple and SGI, it's Linux they are afraid of.
Just wondering, but have you ever used OS X? I own a new iMac G4,
I own two Macs: a PowerBook and a desktop. More importantly, perhaps, my parents have also used all three systems, Windows, OSX, and KDE, so I know what kinds of problems non-computer folks run into. Windows is bad. KDE and OSX have both been OK for them, with different strengths and weaknesses and no clear winner.
Aqua is so far superior to KDE or Gnome, its almost a laughing matter.
I don't see much functional difference. The biggest differences are that Aqua leaves out a lot of options, which makes it easier to use for beginners, and that Aqua has a much nicer graphical design. And Aqua and the Mac UI have their share of rough spots, too (e.g., printing, finder defaults, wireless configuration, software installers).
OS X plain works. Always. Smoothly.
OS X works very well indeed, and I heartily recommend it. But that derives not from some kind of amazingly superior engineering, but simply because Apple has a much simpler problem than Linux: they need to support only a very limited range of hardware, they get to preinstall OSX, and they have full say in what ships. Specific Linux distributions on specific hardware work just as well.
Anyone can use OS X, but your average day user cannot vi XF86Config and fix their settings.
You are comparing apples and oranges (no pun intended). If you buy a PC with Linux-supported hardware and Linux pre-installed, it works just as well and just as easily as OSX.
Isn't it possible that pushing Linux to the average user's desktop is like pushing a round peg into a square hole?
Linux with Gnome or KDE is roughly the same as MacOSX with the Mac GUI: a UNIX-like kernel and command line environment with a nice GUI on top of it. I don't see why that should work any less well for Linux than for MacOSX. If anything, the Linux kernel and GUIs are faster, smaller, and more efficient than what Apple is shipping.
Isn't is possible that an OSS-type BeOS is a better option? It provides an environment that is ground-up designed for desktop users.
But what concretely does it do better? Yes, people were thinking "desktop" while writing BeOS, but I have not seen any feature in BeOS that I can't get on Linux, Windows, or MacOSX just as well. And from a programming point of view, an operating system through-and-through based on C++ seems a bit old fashioned and constraining.
Also, I like the fact that Linux and MacOSX are POSIX-based and have a complete server environment integrated as well. And that's not just useful for programmers, it also means that artists and grandmothers get good, free software like web servers and FTP servers.
TeX fonts are not PostScript or TrueType fonts. That causes all sorts of practical problems.
For example, there are lots and lots of LaTeX papers out there in PDF format that were created with dvips and pstopdf, and the results are just awful. Papers with embedded TeX fonts are also very large.
In fact, many people nowadays just use PDFTeX, and it would be good to have fonts that go with that natively.
Now, you could convert TeX fonts to PostScript or TrueType. But typographically, they are not really all that nice.
The Ford Th!nk and DaimlerChrysler Smart car may be feasible choices. They are small, reach highway speeds (barely), and have a range of more than 50 miles (again, barely). They are easy to park, too.
Another choice might be the Toyota Electric RAV 4, an electric SUV for commuters.
I would not consider a parallel drive hybrid: the mechanical complexity of having both the electric and the gasoline motor drive the car must be high, and you can get pure gasoline cars with equivalent mileage. Unfortunately, most (all?) current choice for gas/electric hybrids are parallel drive.
BeOS was a reasonably nicely engineered system, but it was yet another variation on one of the traditional kernel architectures written in C++, with a bunch of C++ libraries for one of the traditional GUI architectures. Maybe OpenBeOs will also be well engineered, maybe not, but do we really need it?
I suppose in a world where people spend a lot of time writing PDP-10 and game console emulators, another nostaliga-driven software effort won't matter much. But just imagine if all that effort were directed towards doing something new and original: coming up with new kinds of user interaction, figuring out entirely new ways of organizing kernels, rethinking the way kernels are implemented.
If it has to be a clone of a system that has been done before, why not clone and create a better implementation of something that differs more from what we already have than BeOS?
Quite to the contrary: a JIT has the complete program available for optimization (even dynamically loaded modules) and, in addition, can collect detailed runtime statistics. For compute-intensive programs, it can also spend lots of time optimizing inner loops. Furthermore, that optimization doesn't happen at load time at all (it would be stupid if it did, since the compiler has no runtime statistics yet). In contrast, a C++ compiler can perform no optimization between compilation units and it has no information about which code needs to be optimized. Batch compilers are very limited in the kinds of optimizations they can perform.
In any case, the reason why systems written in languages like Java are often much more efficient than systems written in C/C++ is not because Java can be compiled well (which it can) but because Java is safe. In something like Gnome or KDE, every single desk accessory is its own process, using some inefficient IPC or DO mechanism for communicating with the rest of the system. In something like Java, all those can run in the same process and just pass data structures. Using C++ for such applications is penny-wise and pound-foolish; the resulting software systems are ridiculously inefficient.
C and C++ have their uses and they are great languages for some problems. But 95% of all C/C++ applications would be faster, smaller, and work better if they were written in something else.
Copyright was created to encourage the dissemination of creative works, works that would fall into the public domain after some period.
Copy-protected CDs don't hold up their end of the bargain because the work can't go into the public domain (more likely, it will simply become inaccessible after a few years as the DRM technology changes). Therefore, any content published on copy-protected CDs should not be subject to copyright protection: if people break the copy protection, they should be able to redistribute the content freely.
The legal power and protection of copyright should be reserved for content that is actually published and that will eventually be able to fall into the public domain.
in short, the alarmists don't know what they're talking about--a classic case of junk science.
I suggest you read E. O. Wilson's book "The Future of Life". Wilson is one of the top biologists in the world.
As for your points, we are clearly not running out of oil, and Americans are at no risk of starving. What we are running out of is habitats and species. 10 billion people may be able to eke out a living on earth, but it won't be much of a life, and it won't be much of an earth either. And at some point, growth has to stop anyway--why not now?
The predictions were right: the world is overpopulated, and the world is experiencing the dire consequences right now.
Perhaps what is confusing you is the way in which those consequences play out. People who can't feed themselves where they live don't just quietly die, they move around, they burn down rain forest, they overgraze their land, they settle in mosquito-infested areas, they fight wars, they become economic refugees, etc.
The consequences for the planet have been devastating. Foremost, the number of species going extinct is unprecedented in earth's history. We are consuming resources far in excess of sustainable levels. And human activities have already had profound influences on weather and the environment, and this will only get worse.
As long as the West has a strong military and know-how, we will be able to continue to live comfortably. Deterioration of our environment happens slowly enough that we don't really notice it day-to-day and don't really miss much. Global warming won't kill you or me, although it may start making life uncomfortable in half a century. We're well separated from the starving and sick masses of the third world. Well, at least it's a fairly comfortable way to go to hell.
There is no place to go. If we can't live sustainably on earth, how could we colonize another planet, a place where the slightest mistake or waste means instant death? We either make it here on earth or we don't make it at all.
No, it isn't. I made a specific claim about execution speed.
While I've done no Java work
So, what do you base your opinions on, then? I use both Java and C++ for my work.
more than edify the reader...
Your edification is your own responsibility; you can hardly expect a free education from Slashdot. What you can get, however, is people challenging your assumptions and sharing their own experience. And my experience is that, properly used, Java can be nearly as fast as C++ for compute-intensive stuff, and it can be a lot more responsive and a lot less resource intensive than a C++ GUI environment. Think for yourself. Think about why Windows and Gnome/KDE are so huge. Try to find some fast Java apps and pick them apart. Etc.
Java cannot be faster since it is still executing the same thing it would be were it native C++.
Java gets translated into byte code, and the byte code gets translated into machine code. The machine code is then executed. C++ isn't involved in the execution at all.
Think of it this way: the JIT compiler is like someone who gives you directions. How fast you get to your destination doesn't depend on what kind of car the guy giving you directions has, but it depends on how fast your car is and how good the directions are.
I didn't claim Java was free, merely that Sun's compiler produces good code.
performs equally on memory and speed to a myriad of equal C and C++ programs
On microbenchmarks (which is what you are thinking of), Java is a little slower than C/C++ because of mandatory error checking, but not significantly. Properly written, large systems are orders of magnitude faster and smaller in Java than in C/C++ because they don't need separate processes or IPC.
If this sort of retardation wants to adopt Java, all the power to them.
It is your sort of retardation that keeps people developing open source 300M desktops in C or C++ and live in the blissfully ignorant belief that it is "efficient".
Comparing Java performance to C is ludicrous, even with just-in-time native compilation of java byte code. The root cause is the extensive logical error checking in the VM's and the libraries.
Java requires array bounds checking, some null pointer checking, and a very small number of runtime type checks, roughly the same as most other high level languages. That does not impose a lot of overhead, in particular with dynamic compilation and optimization techniques. And, in practice, Java code written for efficiency runs close to C/C++ performance.
What is true is that writing efficient Java code is cumbersome--the language does not make it easy, and most people don't know how to do it.
Java requires extensive and neverending twiddling aroung with your path.
So does Perl, and so do most other languages that load libraries at runtime. The only reason why you don't see it in Perl is because people usually put all libraries into the system directory.
One has to wonder about the relative success of Java, given its horrific performance and obscene installation complexity.
Java performance is excellent--very close to C and C++. What gives Java a reputation for being slow is that it takes a long time to start up.
Java is also one of the easiest systems to install: all you need to do is untar the archive somewhere, or run the installer (on Windows). Perhaps what you mean is that the Java runtime is big--but it isn't really if you compare it to other runtimes.
However, ultimately Java's success comes down to the lack of choices in the language syntax and a strong networking library
Initially, Java succeeded because it was simple and promised that people could deliver software as applets. Today, Java is widely used because it is well-supported, runs fast, has a huge library, and because it beats the alternatives for server applications.
I wish there was a shell with the simple grace of C, the libraries and idiot proof installing packages of Perl, and the portability of bash.
Seeing how given you are to snap judgements, I doubt you would recognize such a shell if it bit you in the behind.
makes me glad I'm cutting back on Perl
on
Perl 6 Synopsis 5
·
· Score: 5, Insightful
I used to write a lot of Perl scripts and libraries. But I've been cutting back and using other scripting languages instead. Perl6 looks like it would not be a pleasant transition from Perl5; I don't want to have to learn a new, idiosyncratic language every major release. If some of the features in Perl6 turn out to be useful (like the new regex syntax), they will make it as libraries into other languages.
I have run this, and it's a reasonably nice server. But I would find something like this mainly useful for easying Windows users into the UNIX/Linux/X11 world. For that, I found the installation too complex last I tried it.
I think what XFree86 really needs to become mainstream on Windows is a simpler install process and a smaller installation. There really isn't any reason why an X server install should be more than a couple of megabytes. Even better would be a simple drag-and-drop install: you drag over a directory containing the server, and you can double click on the server to start it.
Both the Mac and the Windows version also would benefit from GDI calls. They are usably fast without it (on the Mac, the X11 rendering hack seems actually faster than OSX's Quartz engine), but window redrawing just doesn't look right with the off-screen rendering.
How's this for an idea: you wanna break the speed limits or travel tens of thousands of kilometers, you buy your own car, and quit using someone else's car.
If I rent your property, I have use of that property; that's what I pay you money for. For most purposes, the property is mine, to use as I please, during the duration of the contract. Of course, it is also (by default) my responsibility should it get damaged. Any additional restrictions on use must be clearly spelled out in our contract.
There are also legal restrictions on what you can put into the rental contract and when you can put it in there. It is not in general OK to tell a customer that walks up to a rental counter after a long flight that you are going to impose some unusual or costly provisions.
In short, I get your property (car) for giving you my property (money). We both have property and contractual rights. Neither of us gets to do arbitrary things to the other person because of the exchange. Now, is that so hard to understand?
Slashdot Mirror
If they don't, then they should. While Windows and MacOS have monolithic, unwieldy GUIs that are constraint by a need to cater to legacy tastes, Linux and X11 neatly modularize the major functions of a window system: 2D graphics, input methods, window management, inter client communications, network transparency, resources, authentication, etc.
In Linux, you can actually try out new window management styles, new input methods, or new kinds of widgets without having to start from scratch.
The real problem is that almost nobody is doing research in human-computer interaction anymore--everybody just keeps tinkering around with the same old paradigms.
In order to leverage similar to the GPL in these kinds of situations, organizations like the FSF must start applying for patents. Then, they have bargaining chips.
RAND, of course, means commercial cross-licensing. Microsoft is using this as a tactic for excluding open source. They know they can kill companies like Apple in the market, but they are deathly afraid of Linux and open source. OpenGL is a particular thorn in their side since it just won't go away, and Microsoft's own junky 3D interface hasn't been able to kill the competition. So, Microsoft is now trying underhanded legal maneuvres
I think the only way for open source to play will be to have an open source patent portfolio and to bring that to the table. Open source needs its own bargaining chips at the table.
You have two processors: the CPU and the GPU. You partition execution of the graphics code between them in a variety of ways and you standardize that. What, exactly, is the invention supposed to be?
Microsoft may well be aiming to use this to exclude open source from the table--commercial vendors that are part of the consortium cross-license their patent portfolios related to OpenGL and Linux is out in the cold. That is, after all, what Microsoft really wants. They know they can beat down Apple and SGI, it's Linux they are afraid of.
I own two Macs: a PowerBook and a desktop. More importantly, perhaps, my parents have also used all three systems, Windows, OSX, and KDE, so I know what kinds of problems non-computer folks run into. Windows is bad. KDE and OSX have both been OK for them, with different strengths and weaknesses and no clear winner.
Aqua is so far superior to KDE or Gnome, its almost a laughing matter.
I don't see much functional difference. The biggest differences are that Aqua leaves out a lot of options, which makes it easier to use for beginners, and that Aqua has a much nicer graphical design. And Aqua and the Mac UI have their share of rough spots, too (e.g., printing, finder defaults, wireless configuration, software installers).
OS X plain works. Always. Smoothly.
OS X works very well indeed, and I heartily recommend it. But that derives not from some kind of amazingly superior engineering, but simply because Apple has a much simpler problem than Linux: they need to support only a very limited range of hardware, they get to preinstall OSX, and they have full say in what ships. Specific Linux distributions on specific hardware work just as well.
Anyone can use OS X, but your average day user cannot vi XF86Config and fix their settings.
You are comparing apples and oranges (no pun intended). If you buy a PC with Linux-supported hardware and Linux pre-installed, it works just as well and just as easily as OSX.
Linux with Gnome or KDE is roughly the same as MacOSX with the Mac GUI: a UNIX-like kernel and command line environment with a nice GUI on top of it. I don't see why that should work any less well for Linux than for MacOSX. If anything, the Linux kernel and GUIs are faster, smaller, and more efficient than what Apple is shipping.
Isn't is possible that an OSS-type BeOS is a better option? It provides an environment that is ground-up designed for desktop users.
But what concretely does it do better? Yes, people were thinking "desktop" while writing BeOS, but I have not seen any feature in BeOS that I can't get on Linux, Windows, or MacOSX just as well. And from a programming point of view, an operating system through-and-through based on C++ seems a bit old fashioned and constraining.
Also, I like the fact that Linux and MacOSX are POSIX-based and have a complete server environment integrated as well. And that's not just useful for programmers, it also means that artists and grandmothers get good, free software like web servers and FTP servers.
For example, there are lots and lots of LaTeX papers out there in PDF format that were created with dvips and pstopdf, and the results are just awful. Papers with embedded TeX fonts are also very large.
In fact, many people nowadays just use PDFTeX, and it would be good to have fonts that go with that natively.
Now, you could convert TeX fonts to PostScript or TrueType. But typographically, they are not really all that nice.
Another choice might be the Toyota Electric RAV 4, an electric SUV for commuters.
I would not consider a parallel drive hybrid: the mechanical complexity of having both the electric and the gasoline motor drive the car must be high, and you can get pure gasoline cars with equivalent mileage. Unfortunately, most (all?) current choice for gas/electric hybrids are parallel drive.
I suppose in a world where people spend a lot of time writing PDP-10 and game console emulators, another nostaliga-driven software effort won't matter much. But just imagine if all that effort were directed towards doing something new and original: coming up with new kinds of user interaction, figuring out entirely new ways of organizing kernels, rethinking the way kernels are implemented.
If it has to be a clone of a system that has been done before, why not clone and create a better implementation of something that differs more from what we already have than BeOS?
In any case, the reason why systems written in languages like Java are often much more efficient than systems written in C/C++ is not because Java can be compiled well (which it can) but because Java is safe. In something like Gnome or KDE, every single desk accessory is its own process, using some inefficient IPC or DO mechanism for communicating with the rest of the system. In something like Java, all those can run in the same process and just pass data structures. Using C++ for such applications is penny-wise and pound-foolish; the resulting software systems are ridiculously inefficient.
C and C++ have their uses and they are great languages for some problems. But 95% of all C/C++ applications would be faster, smaller, and work better if they were written in something else.
Copy-protected CDs don't hold up their end of the bargain because the work can't go into the public domain (more likely, it will simply become inaccessible after a few years as the DRM technology changes). Therefore, any content published on copy-protected CDs should not be subject to copyright protection: if people break the copy protection, they should be able to redistribute the content freely.
The legal power and protection of copyright should be reserved for content that is actually published and that will eventually be able to fall into the public domain.
Granted, it's still a bit shaky on Macintosh OS X, but it's getting better.
I suggest you read E. O. Wilson's book "The Future of Life". Wilson is one of the top biologists in the world.
As for your points, we are clearly not running out of oil, and Americans are at no risk of starving. What we are running out of is habitats and species. 10 billion people may be able to eke out a living on earth, but it won't be much of a life, and it won't be much of an earth either. And at some point, growth has to stop anyway--why not now?
Perhaps what is confusing you is the way in which those consequences play out. People who can't feed themselves where they live don't just quietly die, they move around, they burn down rain forest, they overgraze their land, they settle in mosquito-infested areas, they fight wars, they become economic refugees, etc.
The consequences for the planet have been devastating. Foremost, the number of species going extinct is unprecedented in earth's history. We are consuming resources far in excess of sustainable levels. And human activities have already had profound influences on weather and the environment, and this will only get worse.
As long as the West has a strong military and know-how, we will be able to continue to live comfortably. Deterioration of our environment happens slowly enough that we don't really notice it day-to-day and don't really miss much. Global warming won't kill you or me, although it may start making life uncomfortable in half a century. We're well separated from the starving and sick masses of the third world. Well, at least it's a fairly comfortable way to go to hell.
There is no place to go. If we can't live sustainably on earth, how could we colonize another planet, a place where the slightest mistake or waste means instant death? We either make it here on earth or we don't make it at all.
No, it isn't. I made a specific claim about execution speed.
While I've done no Java work
So, what do you base your opinions on, then? I use both Java and C++ for my work.
more than edify the reader...
Your edification is your own responsibility; you can hardly expect a free education from Slashdot. What you can get, however, is people challenging your assumptions and sharing their own experience. And my experience is that, properly used, Java can be nearly as fast as C++ for compute-intensive stuff, and it can be a lot more responsive and a lot less resource intensive than a C++ GUI environment. Think for yourself. Think about why Windows and Gnome/KDE are so huge. Try to find some fast Java apps and pick them apart. Etc.
Java gets translated into byte code, and the byte code gets translated into machine code. The machine code is then executed. C++ isn't involved in the execution at all.
Think of it this way: the JIT compiler is like someone who gives you directions. How fast you get to your destination doesn't depend on what kind of car the guy giving you directions has, but it depends on how fast your car is and how good the directions are.
Because "X is written in Y", "X must be slower than Y"? Sorry, it doesn't work that way.
I didn't claim Java was free, merely that Sun's compiler produces good code.
performs equally on memory and speed to a myriad of equal C and C++ programs
On microbenchmarks (which is what you are thinking of), Java is a little slower than C/C++ because of mandatory error checking, but not significantly. Properly written, large systems are orders of magnitude faster and smaller in Java than in C/C++ because they don't need separate processes or IPC.
If this sort of retardation wants to adopt Java, all the power to them.
It is your sort of retardation that keeps people developing open source 300M desktops in C or C++ and live in the blissfully ignorant belief that it is "efficient".
Java requires array bounds checking, some null pointer checking, and a very small number of runtime type checks, roughly the same as most other high level languages. That does not impose a lot of overhead, in particular with dynamic compilation and optimization techniques. And, in practice, Java code written for efficiency runs close to C/C++ performance.
What is true is that writing efficient Java code is cumbersome--the language does not make it easy, and most people don't know how to do it.
Java requires extensive and neverending twiddling aroung with your path.
So does Perl, and so do most other languages that load libraries at runtime. The only reason why you don't see it in Perl is because people usually put all libraries into the system directory.
Java performance is excellent--very close to C and C++. What gives Java a reputation for being slow is that it takes a long time to start up.
Java is also one of the easiest systems to install: all you need to do is untar the archive somewhere, or run the installer (on Windows). Perhaps what you mean is that the Java runtime is big--but it isn't really if you compare it to other runtimes.
However, ultimately Java's success comes down to the lack of choices in the language syntax and a strong networking library
Initially, Java succeeded because it was simple and promised that people could deliver software as applets. Today, Java is widely used because it is well-supported, runs fast, has a huge library, and because it beats the alternatives for server applications.
I wish there was a shell with the simple grace of C, the libraries and idiot proof installing packages of Perl, and the portability of bash.
Seeing how given you are to snap judgements, I doubt you would recognize such a shell if it bit you in the behind.
I used to write a lot of Perl scripts and libraries. But I've been cutting back and using other scripting languages instead. Perl6 looks like it would not be a pleasant transition from Perl5; I don't want to have to learn a new, idiosyncratic language every major release. If some of the features in Perl6 turn out to be useful (like the new regex syntax), they will make it as libraries into other languages.
I think what XFree86 really needs to become mainstream on Windows is a simpler install process and a smaller installation. There really isn't any reason why an X server install should be more than a couple of megabytes. Even better would be a simple drag-and-drop install: you drag over a directory containing the server, and you can double click on the server to start it.
Both the Mac and the Windows version also would benefit from GDI calls. They are usably fast without it (on the Mac, the X11 rendering hack seems actually faster than OSX's Quartz engine), but window redrawing just doesn't look right with the off-screen rendering.
If I rent your property, I have use of that property; that's what I pay you money for. For most purposes, the property is mine, to use as I please, during the duration of the contract. Of course, it is also (by default) my responsibility should it get damaged. Any additional restrictions on use must be clearly spelled out in our contract.
There are also legal restrictions on what you can put into the rental contract and when you can put it in there. It is not in general OK to tell a customer that walks up to a rental counter after a long flight that you are going to impose some unusual or costly provisions.
In short, I get your property (car) for giving you my property (money). We both have property and contractual rights. Neither of us gets to do arbitrary things to the other person because of the exchange. Now, is that so hard to understand?