Two worlds, different audiences and I wonder how you define the term "more useful" when it comes to PDAs- GPEs PIM capabilities are much worse than Opies.
That may well be true, but Opie just isn't competitive with PDA offerings from Palm and Microsoft, which have a better UI and run on cheaper machines and nicer hardware. I use Linux on my desktops because it works better, but I don't use Linux on my main PDA because the best PIM software for my Linux PDA, which is Opie, simply isn't competitive.
And by using a non-X11 window system by default, Opie kills the two other uses I would have for a Linux PDA: quickly prototype PDA applications in an X11 toolkit and environment of my choice, as opposed to being forced to do everything in Qt.
Maybe you would like to contribute with detailed ideas instead of flames ?
I have a very simple, detailed idea: make X11 the default window system for all Opie distibutions. That won't make Opie any more competitive as a PIM and it won't make it any more attractive to mainstream users, but it will make Opie-based PDAs a lot more attractive to people like me, who want to develop special-purpose applications and port Linux applications to handhelds quickly without being forced to port everything to Qt.
However, I don't believe it is possible to create a high-quality PIM application in either Qt or Gtk+. In fact, I think it's impossible to create a high-quality PIM suite in any toolkit that's designed for the desktop or designed to be cross platform. I think the best way of getting a decent PIM suite for Linux would be to start from scratch, develop a PDA-centric GUI toolkit, and clone the Palm UI and the UI of some of the more successful Palm UI add-ons as closely as possible. There is a reason why Palm is such a successful platform even though the underlying operating system kernel is far worse than either WinCE or Linux, and that reason is the UI.
As for "flaming", "flaming" is the use of personal insults and swear words in a technical argument. I didn't do either of those. You may not want to hear what I have to say, and you may disagree with my conclusions, but that doesn't make what I said a flame.
To me, Opie just seems pointless. Being based on Qt/Embedded, the Opie environment only runs Qt applications, so most UNIX GUI apps don't work on it. And being a GPL'ed fork of Qt/Embedded, people may not even be able to ever develop commercial software for it even if they were willing to pay Troll Tech's licensing fees.
Now, if Opie were a great self-contained PIM suite, maybe it could survive on that alone. Unfortunately, it isn't: even the cheapest Palm is a much more effective and convenient PIM than the Opie environment.
As far as I'm concerned, GPE is a more interesting project. It may not be as mature as Opie yet, but in the end, it will be more useful. If Linux has a future on handhelds at all, I think it will be based on Gtk+ and X11, not Qt/Embedded.
I really don't see KDE or any other linux desktop software beating Windows or MacOS in usabilities tests anytime soon.
You say that as if usability tests actually test something concrete and meaningful, like mass or height or temperature. But they don't really. Usability testing isn't physics. Yes, KDE may do slightly worse in usability tests than Windows, but what does that actually mean? At most it means that it takes a little more time to learn a few more quirks that the KDE interface has. Big deal. In return, KDE is also a more featureful interface and comes with a lot more software out of the box. Usability is only one of many things to optimize for in a piece of software, and it is not the most important one in many applications.
In fact, the fact that the users in the study had "prior computer skills" suggests that they had experience with Windows-like interfaces, which means that most likely a significant part of the slight Windows XP advantage was simply due to familiarity.
What this test shows is that KDE is in the ballpark, and that's all that is really needed.
KDE and GNOME keep playing catchup to windows instead of leading the way.
Many open source projects are unashamedly about providing open source versions of closed-source systems, and there is nothing wrong with that.
Sure there are some unique features, but the bulk of linux desktop development is recreating features that windows and macos have had for years.
Yes, and Microsoft and Apple copied many of those features from yet other systems. That's the way business and product development work: you look at what works in the market and you copy as much of it as you legally can. There is nothing wrong with that.
The KDE team does unquestionably good work, but they are going to need to keep stepping it up if they expect anyone to find their software more useable than the already existing mainstream products.
This test shows that KDE is close enough as far as usability goes. Maybe they can edge out Windows XP in such tests by sacrificing some features or some other hacks, but you are naive to think that there are any great hidden usability improvements possible.
In my experience, the performance of gcj-compiled code is roughly comparable to that of Sun's and IBM's JITs.
In principle, a JIT should be able to beat a batch compiler on long-running, compute intensive tasks, but none of the existing Java JITs seem to realize that advantage. Furthermore, for interactive applications like Eclipse, eliminating JIT delays and class loading delays is probably more important than a little bit of difference in performance.
I do a lot of compute intensive stuff in Java and I have found gcj performance to be comparable to Sun's and IBM's JIT. That's also what most of the benchmarks on the page you link to show.
In fact, I only see one benchmark where there is a significant difference, and that is probably due to some JIT-centric code in that benchmark that is easily eliminated. There are some optimizations available to a JIT that gcj can't do (e.g., inlining of some methods), and for code written with a JIT in mind, that may make a noticeable difference. But it's easy to detect those places and make such code run fast on gcj.
Another big performance feature of gcj is that it has a fast native code interface, as opposed to Sun's sluggish and cumbersome JNI interface.
In general, JIT compilers should be able to do better than batch compilers and do a lot more optimizations on high-level code (specialization, partial evaluation, etc.). But none of the Java JITs realize that advantage, and overall, something like gcj seems to be a better overall compiler for most real-world use at this point.
Java was never designed to start up quickly, though they did a lot of work on startup in 1.4.x. Startup time is slow due primarily to what is executed, not the JVM speed.
Java startup is slow for two reasons. First, Java spends a lot of time looking for classes (try "java -verbose something"). Second, it takes a while for the JIT to kick in and compile classes.
Both of those are design problems with the Java system itself. With a better designed library format, the load overhead would largely disappear. And with a JIT that cached results of previous compilations, we wouldn't have to pay the JIT overhead.
Dynamic loading and JIT are good. But Sun's implementation of them just sucks, and in comparison, gcj is better.
...you cheer on a country with such a horrid human rights record simply because its software ideals appear to align with your own.
Yes, when some engineers in China do something good and useful, like create a new, free video standard, one should cheer them on for that and encourage them. That doesn't amount to a wholesale endorsement of the Chinese government or their political system.
The US has plenty of human rights, social, and economic problems itself and plenty of historical baggage. You should worry about that before you are in a position to single-handedly condemn a country of a billion inhabitants.
What's the intellectual property status of the AVS standard? The article mentions "royalty payments" for China. Do those only apply to products used/distributed in China, or do they apply worldwide? Has China taken out foreign patents related to the AVS standard? Or does AVS infringe on patents in the US or Europe and therefore cannot be used in the US or Europe?
It's bad enough that companies are simultaneously claiming copyright protection under the law while trying to make their content uncopyable even for fair use; companies should have to choose between enjoying copyright protection or employing copy protection. Copyright law loses its meaning and purpose if the content being copyrighted never has a prayer of making it into the public domain.
But this ruling goes even further: in addition to copyright protection, the legal system is now also being burdened, at taxpayer expense, with prosecuting people who circumvent copy protection. If Microsoft or Sony can't figure out how to make their boxes unmoddable (it's not that hard technically), why should the taxpayer pick up the tab for their incompetence? And, no, it's not just Australia: of course, this nonsense is even more widespread in the US.
PalmOS will undergo massive changes over the next couple of years, at least if Palm is going to stay in business, so developing for this thing is not going to be fun. The rest of the gaming stuff is proprietary and expensive. And on top of that, the device is itself quite expensive.
In a few months, the T3 will be out with a 320x480 screen and Sony's Clies will have come down to that price. Those cover PDA users who want gaming pretty well. And for gamers who want PDA functionality, the main players are adding more features as it is cost effective.
And Microsoft is pushing PPC quite aggressively, and while the UI on PPC sucks, that doesn't matter for gaming, and the PPC kernel is probably better suited to gaming than PalmOS.
Finally, cell phones are pushing hard into the gaming area, and they seem to be doing quite well. They don't give you stunning graphics, but they have entertaining games, often written in cross-platform J2ME: much easier to program and much bigger target market for vendors.
Traditionally, a company like this might hope to get acquired, but who's going to buy these guys? Maybe Palm will buy back its ex-employees as they did with Handspring, but that's about the best that can happen.
Overall, I think this device has no chance in hell.
"All students will know someone is watching them, tracking them, and is interested in their success," school board member Laurie Bricker said at a press conference today.
Let's not get carried away: mechanical supervision and administrative checks aren't "someone"--they are impersonal procedures. The next step is probably to hook up the system to pager and E-mail systems to warn parents about this sort of thing automatically. Presenting such impersonal supervision as if it were personal attention and interest is somewhat analogous to referring to a police state as "Big Brother" in 1984.
Now, in this case, impersonal supervision is probably justifiable if personal supervision is just not available. But let's not hide the reality of it behind warm-and-fuzzy phrases.
Encrypted file systems are a pain to configure and they suck up CPU time. If this can be done in hardware, that's a good thing.
Think of it this way: we can generate video signals in software as well, but we still prefer to have special hardware for it (video cards) because it simplifies system design and frees the CPU.
Hardware encryption of IDE drives is a good thing. It's not going to keep the government from looking at your files (they'll just make your life miserable until you give them the key) or the RIAA (they'll just watch what you trade with whom or install a virus). But it does mean that should your machine get stolen, the thieves can't do anything with your data. Actually, as you can imagine, this would be significantly more important on laptops. A few laptops have SmartCard-based hardware encryption built right in, which is arguable the right way of doing this (as opposed to a USB memory dongle).
Maybe you are right but I have written several apps in python and java, and the ones in py left java in the dust. Much less memory for the runtime too.
There is no contradiction: the Java libraries and the Java runtime have numerous design flaws that cause people to build bloated and sluggish applications in Java. In fact, the same can be said for many C++ frameworks.
But if you just look at the languages and their implementations, it's easy to compile Java into tight, efficient machine code, while the same is just not possible for Python. Python is a great language with many applications, but it simply is no substitute for statically typed languages like Java, C#, or C++.
[Python] is beginning to look more and more like a viable competitor to Java.
Python is a great scripting language and development in it is much easier than in Java, but it is not a competitor to Java. Java achieves close to C/C++ performance on low-level code (for loops, arrays, etc.); Python doesn't even get close. That really matters in many applications because it means you don't have to "drop down" to C. And Java has static type checking. Static type checking is a nuisance for prototyping, but it is crucially important for building large system.
Java and Python are just very different tools for very different applications. Both are probably misapplied a lot.
I should also mention that I don't actually recommend you use Java: it is a proprietary language and has a number of serious design problems. If you want a Java-like language, ECMA C# (not.NET) as implemented by Mono is a better choice in every respect. But there are many other statically typed language choices out there if you don't like C# or Java.
But sometimes exceptions have to be made in order to support business needs. An IT department that clings too tightly to abstract principles tends to forget that its reason for existing is to enable other employees to get their work done. [...] I don't feel that it is practical (or even desirable) to force every employee of a company to work on the equivalent of a dumb terminal. The pure glass house model may make life easier and more lucrative for IT, but everyone else rebelled against it a long time ago.
Networks of UNIX workstations are anything but "dumb terminals". If you like and if company policy permits it, you can install software locally or do other things. But the point is that you and the cmopany have a choice, and that anything that you decide needs to be centrally managed can be centrally managed.
Most Linux developers are power users, and thus resistant to letting someone else control their workstations.
Well, that may or may not be the case, but it's completely unrelated to my central point: Microsoft's approach to building large networks of machines is broken. Browseable file servers, ACLs, and all that other ad-hoc stuff they have put in leads to messy and insecure infrastructures. UNIX vendors had this worked out long ago and their offerings are still, after all this time, a much better solution than Windows for enterprise networks.
1.) no power conversion is ever 100% efficient, you would lose much of the electricty when converting to hydrogen.
Conversion efficiency by itself is irrelevant--right now, 100% of that solar energy is wasted. Since the conversion process produces no waste either, the only thing that matters is how much money you need to invest in order to get a unit of energy out as hydrogen. In fact, the most cost-effective methods for that are not the most energy efficient ones.
2.) there is still no acceptably safe way to transport hydrogen.
Sure there is: liquefied, in tankers. Shipping hydrogen that way is a lot safer than shipping oil that way, a risk we accept daily. The risk reduction resulting from the replacement of oil tankers with liquefied hydrogen tankers alone would be worth the switch.
While it would rock to have clean energy finally adopted... Carting it across long distances still sucks.
It's not that hard: ship it as as hydrogen. Use the energy at one end to split water, ship the hydrogen in tankers, burn it at the other end. It's clean and quite doable with current technology. It would be costly at first, but those costs would quickly come down as the technology became used on a larger scale.
One of the safest, most efficient, and cost-effective ways of capturing solar energy in desert regions and distributing it to the industrialized nations is via hydrogen. That's the real motivation behind a "hydrogen economy". In fact, since deserts are where much of the oil is anyway, not that much would have to change, although a number of additional regions could become energy producers.
Hydrogen can be produced from solar energy either via electricity, using microorganisms, or directly using heat.
What about the PlayStation2-Linux project? I believe that is with the help of Sony.
Yes, so what? My point is if the world were populated by Sony gadgets rather than PCs, something like Linux could never have been created in the first place. Now that Linux exists, Sony would be foolish not to take advantage of it when they can use it to make it money.
Why wouldn't Sony want to use their own MiniDISC? It is theirs and they want to keep the money within the company. Sounds fair enough to me. They're there to make money.
That's the same argument people make for Microsoft. Whether it is justified or not is debatable. But it is clear that it kills competition and stifles innnovation, and that isn't good for consumers.
If there are, then clearly there is something wrong with the MP3 player or with Clie breaking some Palm OS licence.
Sony is using a proprietary, undocumented sound API on the Clies. There is no problem with the MP3 player software (they can't write to APIs that haven't been published), and Sony isn't breaking any licenses (Palm permits licensees to modify PalmOS). Implementing an undocumented audio API on the Clies is simply Sony's choice.
The Clie is on the Palm OS, so in theory there shouldn't be any problems.
If you don't know what you are talking about, why do you feel so compelled to comment?
Symbian is a great OS; I hope they'll not just keep shipping cell phone combos but also get back into the handheld market: they beat PPC and PalmOS hands down in just about every respect.
A major feature of that device will also have DRM through-and-through. And Sony makes this sort of thing stick: look at how tightly they have controlled the PS2 and MiniDISC. And their versions of the Palm handhelds are full of proprietary, undocumented APIs (e.g., many (all?) third party MP3 players for Palm don't work on Clies).
Sony has shown signs of openness with some of their efforts, but I think they are just so powerful and like to control things so much that if we end up with a world where Sony controls a significant part of the compute infrastructure, we are in real trouble. Microsoft's dabbling in DRM and proprietary architectures will seem like child's play in comparison.
Slashdot Mirror
Two worlds, different audiences and I wonder how you define the term "more useful" when it comes to PDAs- GPEs PIM capabilities are much worse than Opies.
That may well be true, but Opie just isn't competitive with PDA offerings from Palm and Microsoft, which have a better UI and run on cheaper machines and nicer hardware. I use Linux on my desktops because it works better, but I don't use Linux on my main PDA because the best PIM software for my Linux PDA, which is Opie, simply isn't competitive.
And by using a non-X11 window system by default, Opie kills the two other uses I would have for a Linux PDA: quickly prototype PDA applications in an X11 toolkit and environment of my choice, as opposed to being forced to do everything in Qt.
Maybe you would like to contribute with detailed ideas instead of flames ?
I have a very simple, detailed idea: make X11 the default window system for all Opie distibutions. That won't make Opie any more competitive as a PIM and it won't make it any more attractive to mainstream users, but it will make Opie-based PDAs a lot more attractive to people like me, who want to develop special-purpose applications and port Linux applications to handhelds quickly without being forced to port everything to Qt.
However, I don't believe it is possible to create a high-quality PIM application in either Qt or Gtk+. In fact, I think it's impossible to create a high-quality PIM suite in any toolkit that's designed for the desktop or designed to be cross platform. I think the best way of getting a decent PIM suite for Linux would be to start from scratch, develop a PDA-centric GUI toolkit, and clone the Palm UI and the UI of some of the more successful Palm UI add-ons as closely as possible. There is a reason why Palm is such a successful platform even though the underlying operating system kernel is far worse than either WinCE or Linux, and that reason is the UI.
As for "flaming", "flaming" is the use of personal insults and swear words in a technical argument. I didn't do either of those. You may not want to hear what I have to say, and you may disagree with my conclusions, but that doesn't make what I said a flame.
To me, Opie just seems pointless. Being based on Qt/Embedded, the Opie environment only runs Qt applications, so most UNIX GUI apps don't work on it. And being a GPL'ed fork of Qt/Embedded, people may not even be able to ever develop commercial software for it even if they were willing to pay Troll Tech's licensing fees.
Now, if Opie were a great self-contained PIM suite, maybe it could survive on that alone. Unfortunately, it isn't: even the cheapest Palm is a much more effective and convenient PIM than the Opie environment.
As far as I'm concerned, GPE is a more interesting project. It may not be as mature as Opie yet, but in the end, it will be more useful. If Linux has a future on handhelds at all, I think it will be based on Gtk+ and X11, not Qt/Embedded.
Actually, pad're human factors IS physics ... neural physics
Human factors is a different discipline from physics, with a different methodology.
M$ knows inputs we like and how we like to work with them.
Speak for yourself.
I really don't see KDE or any other linux desktop software beating Windows or MacOS in usabilities tests anytime soon.
You say that as if usability tests actually test something concrete and meaningful, like mass or height or temperature. But they don't really. Usability testing isn't physics. Yes, KDE may do slightly worse in usability tests than Windows, but what does that actually mean? At most it means that it takes a little more time to learn a few more quirks that the KDE interface has. Big deal. In return, KDE is also a more featureful interface and comes with a lot more software out of the box. Usability is only one of many things to optimize for in a piece of software, and it is not the most important one in many applications.
In fact, the fact that the users in the study had "prior computer skills" suggests that they had experience with Windows-like interfaces, which means that most likely a significant part of the slight Windows XP advantage was simply due to familiarity.
What this test shows is that KDE is in the ballpark, and that's all that is really needed.
KDE and GNOME keep playing catchup to windows instead of leading the way.
Many open source projects are unashamedly about providing open source versions of closed-source systems, and there is nothing wrong with that.
Sure there are some unique features, but the bulk of linux desktop development is recreating features that windows and macos have had for years.
Yes, and Microsoft and Apple copied many of those features from yet other systems. That's the way business and product development work: you look at what works in the market and you copy as much of it as you legally can. There is nothing wrong with that.
The KDE team does unquestionably good work, but they are going to need to keep stepping it up if they expect anyone to find their software more useable than the already existing mainstream products.
This test shows that KDE is close enough as far as usability goes. Maybe they can edge out Windows XP in such tests by sacrificing some features or some other hacks, but you are naive to think that there are any great hidden usability improvements possible.
In my experience, the performance of gcj-compiled code is roughly comparable to that of Sun's and IBM's JITs.
In principle, a JIT should be able to beat a batch compiler on long-running, compute intensive tasks, but none of the existing Java JITs seem to realize that advantage. Furthermore, for interactive applications like Eclipse, eliminating JIT delays and class loading delays is probably more important than a little bit of difference in performance.
I do a lot of compute intensive stuff in Java and I have found gcj performance to be comparable to Sun's and IBM's JIT. That's also what most of the benchmarks on the page you link to show.
In fact, I only see one benchmark where there is a significant difference, and that is probably due to some JIT-centric code in that benchmark that is easily eliminated. There are some optimizations available to a JIT that gcj can't do (e.g., inlining of some methods), and for code written with a JIT in mind, that may make a noticeable difference. But it's easy to detect those places and make such code run fast on gcj.
Another big performance feature of gcj is that it has a fast native code interface, as opposed to Sun's sluggish and cumbersome JNI interface.
In general, JIT compilers should be able to do better than batch compilers and do a lot more optimizations on high-level code (specialization, partial evaluation, etc.). But none of the Java JITs realize that advantage, and overall, something like gcj seems to be a better overall compiler for most real-world use at this point.
Java was never designed to start up quickly, though they did a lot of work on startup in 1.4.x. Startup time is slow due primarily to what is executed, not the JVM speed.
Java startup is slow for two reasons. First, Java spends a lot of time looking for classes (try "java -verbose something"). Second, it takes a while for the JIT to kick in and compile classes.
Both of those are design problems with the Java system itself. With a better designed library format, the load overhead would largely disappear. And with a JIT that cached results of previous compilations, we wouldn't have to pay the JIT overhead.
Dynamic loading and JIT are good. But Sun's implementation of them just sucks, and in comparison, gcj is better.
It would be interesting to hear what the software is written in and what it runs on. A mix of Ada/C on Windows NT/Embedded maybe? Or something else?
Come on, where are the people who brag about those "billion dollar projects implemented with 'our' tools"? Please step forward--we'd like to know.
RTFA. It is not royalty-free, but certainly less expensive than MPEG.
The article only talks about royalties in China; it may well be royalty-free elsewhere.
...you cheer on a country with such a horrid human rights record simply because its software ideals appear to align with your own.
Yes, when some engineers in China do something good and useful, like create a new, free video standard, one should cheer them on for that and encourage them. That doesn't amount to a wholesale endorsement of the Chinese government or their political system.
The US has plenty of human rights, social, and economic problems itself and plenty of historical baggage. You should worry about that before you are in a position to single-handedly condemn a country of a billion inhabitants.
What's the intellectual property status of the AVS standard? The article mentions "royalty payments" for China. Do those only apply to products used/distributed in China, or do they apply worldwide? Has China taken out foreign patents related to the AVS standard? Or does AVS infringe on patents in the US or Europe and therefore cannot be used in the US or Europe?
It's bad enough that companies are simultaneously claiming copyright protection under the law while trying to make their content uncopyable even for fair use; companies should have to choose between enjoying copyright protection or employing copy protection. Copyright law loses its meaning and purpose if the content being copyrighted never has a prayer of making it into the public domain.
But this ruling goes even further: in addition to copyright protection, the legal system is now also being burdened, at taxpayer expense, with prosecuting people who circumvent copy protection. If Microsoft or Sony can't figure out how to make their boxes unmoddable (it's not that hard technically), why should the taxpayer pick up the tab for their incompetence? And, no, it's not just Australia: of course, this nonsense is even more widespread in the US.
PalmOS will undergo massive changes over the next couple of years, at least if Palm is going to stay in business, so developing for this thing is not going to be fun. The rest of the gaming stuff is proprietary and expensive. And on top of that, the device is itself quite expensive.
In a few months, the T3 will be out with a 320x480 screen and Sony's Clies will have come down to that price. Those cover PDA users who want gaming pretty well. And for gamers who want PDA functionality, the main players are adding more features as it is cost effective.
And Microsoft is pushing PPC quite aggressively, and while the UI on PPC sucks, that doesn't matter for gaming, and the PPC kernel is probably better suited to gaming than PalmOS.
Finally, cell phones are pushing hard into the gaming area, and they seem to be doing quite well. They don't give you stunning graphics, but they have entertaining games, often written in cross-platform J2ME: much easier to program and much bigger target market for vendors.
Traditionally, a company like this might hope to get acquired, but who's going to buy these guys? Maybe Palm will buy back its ex-employees as they did with Handspring, but that's about the best that can happen.
Overall, I think this device has no chance in hell.
"All students will know someone is watching them, tracking them, and is interested in their success," school board member Laurie Bricker said at a press conference today.
Let's not get carried away: mechanical supervision and administrative checks aren't "someone"--they are impersonal procedures. The next step is probably to hook up the system to pager and E-mail systems to warn parents about this sort of thing automatically. Presenting such impersonal supervision as if it were personal attention and interest is somewhat analogous to referring to a police state as "Big Brother" in 1984.
Now, in this case, impersonal supervision is probably justifiable if personal supervision is just not available. But let's not hide the reality of it behind warm-and-fuzzy phrases.
Encrypted file systems are a pain to configure and they suck up CPU time. If this can be done in hardware, that's a good thing.
Think of it this way: we can generate video signals in software as well, but we still prefer to have special hardware for it (video cards) because it simplifies system design and frees the CPU.
Hardware encryption of IDE drives is a good thing. It's not going to keep the government from looking at your files (they'll just make your life miserable until you give them the key) or the RIAA (they'll just watch what you trade with whom or install a virus). But it does mean that should your machine get stolen, the thieves can't do anything with your data. Actually, as you can imagine, this would be significantly more important on laptops. A few laptops have SmartCard-based hardware encryption built right in, which is arguable the right way of doing this (as opposed to a USB memory dongle).
Maybe you are right but I have written several apps in python and java, and the ones in py left java in the dust. Much less memory for the runtime too.
There is no contradiction: the Java libraries and the Java runtime have numerous design flaws that cause people to build bloated and sluggish applications in Java. In fact, the same can be said for many C++ frameworks.
But if you just look at the languages and their implementations, it's easy to compile Java into tight, efficient machine code, while the same is just not possible for Python. Python is a great language with many applications, but it simply is no substitute for statically typed languages like Java, C#, or C++.
[Python] is beginning to look more and more like a viable competitor to Java.
.NET) as implemented by Mono is a better choice in every respect. But there are many other statically typed language choices out there if you don't like C# or Java.
Python is a great scripting language and development in it is much easier than in Java, but it is not a competitor to Java. Java achieves close to C/C++ performance on low-level code (for loops, arrays, etc.); Python doesn't even get close. That really matters in many applications because it means you don't have to "drop down" to C. And Java has static type checking. Static type checking is a nuisance for prototyping, but it is crucially important for building large system.
Java and Python are just very different tools for very different applications. Both are probably misapplied a lot.
I should also mention that I don't actually recommend you use Java: it is a proprietary language and has a number of serious design problems. If you want a Java-like language, ECMA C# (not
But sometimes exceptions have to be made in order to support business needs. An IT department that clings too tightly to abstract principles tends to forget that its reason for existing is to enable other employees to get their work done. [...] I don't feel that it is practical (or even desirable) to force every employee of a company to work on the equivalent of a dumb terminal. The pure glass house model may make life easier and more lucrative for IT, but everyone else rebelled against it a long time ago.
Networks of UNIX workstations are anything but "dumb terminals". If you like and if company policy permits it, you can install software locally or do other things. But the point is that you and the cmopany have a choice, and that anything that you decide needs to be centrally managed can be centrally managed.
Most Linux developers are power users, and thus resistant to letting someone else control their workstations.
Well, that may or may not be the case, but it's completely unrelated to my central point: Microsoft's approach to building large networks of machines is broken. Browseable file servers, ACLs, and all that other ad-hoc stuff they have put in leads to messy and insecure infrastructures. UNIX vendors had this worked out long ago and their offerings are still, after all this time, a much better solution than Windows for enterprise networks.
1.) no power conversion is ever 100% efficient, you would lose much of the electricty when converting to hydrogen.
Conversion efficiency by itself is irrelevant--right now, 100% of that solar energy is wasted. Since the conversion process produces no waste either, the only thing that matters is how much money you need to invest in order to get a unit of energy out as hydrogen. In fact, the most cost-effective methods for that are not the most energy efficient ones.
2.) there is still no acceptably safe way to transport hydrogen.
Sure there is: liquefied, in tankers. Shipping hydrogen that way is a lot safer than shipping oil that way, a risk we accept daily. The risk reduction resulting from the replacement of oil tankers with liquefied hydrogen tankers alone would be worth the switch.
While it would rock to have clean energy finally adopted... Carting it across long distances still sucks.
It's not that hard: ship it as as hydrogen. Use the energy at one end to split water, ship the hydrogen in tankers, burn it at the other end. It's clean and quite doable with current technology. It would be costly at first, but those costs would quickly come down as the technology became used on a larger scale.
One of the safest, most efficient, and cost-effective ways of capturing solar energy in desert regions and distributing it to the industrialized nations is via hydrogen. That's the real motivation behind a "hydrogen economy". In fact, since deserts are where much of the oil is anyway, not that much would have to change, although a number of additional regions could become energy producers.
Hydrogen can be produced from solar energy either via electricity, using microorganisms, or directly using heat.
What about the PlayStation2-Linux project? I believe that is with the help of Sony.
Yes, so what? My point is if the world were populated by Sony gadgets rather than PCs, something like Linux could never have been created in the first place. Now that Linux exists, Sony would be foolish not to take advantage of it when they can use it to make it money.
Why wouldn't Sony want to use their own MiniDISC? It is theirs and they want to keep the money within the company. Sounds fair enough to me. They're there to make money.
That's the same argument people make for Microsoft. Whether it is justified or not is debatable. But it is clear that it kills competition and stifles innnovation, and that isn't good for consumers.
If there are, then clearly there is something wrong with the MP3 player or with Clie breaking some Palm OS licence.
Sony is using a proprietary, undocumented sound API on the Clies. There is no problem with the MP3 player software (they can't write to APIs that haven't been published), and Sony isn't breaking any licenses (Palm permits licensees to modify PalmOS). Implementing an undocumented audio API on the Clies is simply Sony's choice.
The Clie is on the Palm OS, so in theory there shouldn't be any problems.
If you don't know what you are talking about, why do you feel so compelled to comment?
Symbian is a great OS; I hope they'll not just keep shipping cell phone combos but also get back into the handheld market: they beat PPC and PalmOS hands down in just about every respect.
A major feature of that device will also have DRM through-and-through. And Sony makes this sort of thing stick: look at how tightly they have controlled the PS2 and MiniDISC. And their versions of the Palm handhelds are full of proprietary, undocumented APIs (e.g., many (all?) third party MP3 players for Palm don't work on Clies).
Sony has shown signs of openness with some of their efforts, but I think they are just so powerful and like to control things so much that if we end up with a world where Sony controls a significant part of the compute infrastructure, we are in real trouble. Microsoft's dabbling in DRM and proprietary architectures will seem like child's play in comparison.