It's not clear that Troll Tech would permit the creation of an API-compatible implementation (but it's also not clear they have the legal power to prevent it). When people were developing Harmony, an independent implementation of the Qt APIs, Troll Tech apparently claimed it violated their copyright. This was never really worked out because Troll Tech changed their license to GPL, addressing the needs of KDE developers. Non-KDE developers didn't care enough and just went with Gtk+ (which is LGPL), and that's also what Sun and HP have adopted.
In the end, it probably doesn't matter. I wouldn't expect either Gtk+ or Qt to be central to GUI development on Linux a few years from now. While mature, they represent a fairly tedious and traditional way of writing UIs. There are new paradigms already sneaking into real apps.
I have had good luck with Netgear's Phoneline 10x. It basically turns your phone lines into a 10Mbps network without any additional wiring. There is also no need for special drivers or anything else. The boxes are about $200 each. A few other manufacturers make equivalent equipment; I don't know whether that interoperates or not.
I wouldn't bother with the PCI cards (too much work). There is no driver for their USB adapter (PA101).
What are the plans for the compilation of Python code to efficient executables? Python's object system is very dynamic, allowing anybody to add instance variables and methods to any object at any time--how are you planning on dealing with that during compilation? Performance-wise, how do you expect Python will compare to compiled CommonLisp or Smalltalk, which evolved along similar lines 20 years ago? And will there be a language standard, or will Python continue to be defined by what the C implementation does?
AVES breaks subtle assumptions that a lot of software makes about the relationship between names and IP addresses. But, hey, it works in the simplistic cases, so it's largely backwards compatible, right? Sorry, I don't think that's a good approach.
The problem isn't a shortage of IP addresses, it's a shortage of well-known ports. There are only so many port 80s and port 23s to go around. However, there are a lot of other ports, and there are good, reliable, safe ways of forwarding them (firewall forwarders, ssh, SOCKS,...). Rather than fixing subtle assumptions about name/IP correspondences in lots of software, I'd rather be fixing software that hardcodes port numbers; the latter is much easier to find and code.
AVES is a prototypical example of how we create messes and maintenance headaches: it looks like it solves most of the problem and, hey, we can fix the remaining problems, right? But it isn't the right thing to do, and the long term costs of creating such a mess would be high. Fortunately, I don't think it will catch on: ISPs don't want people to run servers anyway.
You know what the future likely hold for Blogger and Trellix: either they'll go out of business or they'll get bought by AOL or Microsoft. That's not the place to put anything you care about.
I think it's better to put personal data on your personal site, with a company you have a paying relationship with, that provides a commodity service. Those companies tend to stay in business, and if they don't, you can always switch to a different one. Yes, you may have to download a PHP script or use a web editor.
Apparently, you can get away with a lot these days. A tax expert described this as: "many business people treat the filing of their tax return as a 'first offer'"; if the IRS doesn't audit them, they pay a small fraction of what is due.
My point is don't bother with any of the high end stuff, very likely anything faster than 600 M processor on a 100 M bus will be fine for the forseeable future.
I don't think that's true. Developers will be moving to the faster machines. They will be using tools that trade performance for faster time to market, and they will be putting in more features. Experimental UIs in research labs right now do a lot more than what Gnome, KDE, or Windows do, and they are using tools that do eat up lots of CPU time. Maybe there is a very temporary lull because Microsoft hasn't released anything new in a few years, but sooner or later, Microsoft will copy someone else's nifty but slow GUI again and that will drive the next generation hardware purchases.
There is already lots of 64bit code in C and Fortran. And gcc knows about 64bit code. So, all AMD needs to do is sponsor gcc backend development. And I think they are doing just that. Commercial vendors, ever eager for better benchmark results, will follow.
The point of writing shit small and fast is so they don't overuse your system resources.
Is that why Konqueror and KIO together take 47Mbytes on my machine to display six simple web pages and feel sluggish on a 300MHz PII? (And that's not even counting the X server.) Is that the kind of "small and fast" you are talking about?
The fact is that large software systems like Gnome and KDE need the features that languages like Java, Smalltalk, Objective-C, or Lisp provide. The only choice their authors have is whether they leave the implementation of those features to compiler writers, who know what they are doing, or whether they try to come up with substandard ad-hoc solutions themselves.
Think of it like cars. A Z3 is a very fast car to move a person around. But trying to use a fleet of Z3's to haul a few tons of dirt is much slower and much more costly than using a truck.
Why would I want to write toolkit code (GTK, Qt, ect) in a language that has to be run in a virtual machine?
You wouldn't. You would want to write it in a dynamic language that can be compiled into efficient native code. A language like Java, Objective-C, Lisp, or Smalltalk. Your code in those languages may run 2-5x slower than C/C++ on small benchmark snippets. But for large software systems, there is a good chance that
it will end up being faster and use less memory than the C/C++ code. And it will definitely be easier to develop and maintain. For really compute-intensive inner loops, you can always drop back to raw C or C++ no matter what language you use.
Project like Gnome/Gtk, KDE/Qt, and Windows/MFC go out of their way to write things in "efficient" languages like C and C++. Many of the people on those projects look down their noses at any suggestion that one might use a high-level, slower, language for writing GUI stuff. And the Linux kernel seems to be a refuge of people who think that anything other than ANSI C is wastefully evil.
Yet, at the same time, many GUI applications under Gnome, KDE, or Windows are huge, complex messes. Trying to modify their behavior is an exercise in patience and persistence, not just because of the mountains of code one has to wade through, but also just because of the lengthy edit/compile/run cycle. And the irony is that, while those systems start out really fast when they are small, taking full advantage of the "fast" languages they are built on, they actually get very slow when they grow, because their authors end up reinventing higher-level language constructs without being able to do a good job at the implementation ("GObject" in Gtk is a recent example).
Even trying to install a sound card for the Linux kernel can take hours in trying to track down the right version and getting bits arranged just right for the superfast but dumb kernel to have its driver nuggets in all the right places.
Let's use the spare cycles and memory to make our systems smarter and easier to deal with. That does not necessarily mean something as complex as "artificial intelligence". It may mean putting a scripting language into the kernel that lets people add simple kernel extensions simply. It may mean using a language like Objective-C to extend an existing C system. It may mean doing GUIs in Python or Smalltalk or even just Java.
There are lots of things wrong with software: it's hard to install, it's hard to manage, and it fails a lot. Yet, both Linux and Windows developers still have an unhealthy obsession with performance (and, often, they don't even achieve it). Simplify your projects and deliver a better product: put those 1GHz+ machines to work by writing in languages that don't force you to optimize every bit. And if you can't get over worrying about performance when you look at that pretty but sluggish scripting language code, close your eyes and think about the good of the US economy.
I don't understand why this is even a WIPO or trademark issue. Whether "WallMartCanadaSucks.com" or "WalMartCanadaSucks.com" or "WalMart-sucks.com", use of the term "WalMart" seems entirely appropriate: it identifies correctly and specifically the product WalMart provides. Furthermore, it doesn't look like Harvey is using the term to engage in his own trade, he is merely relating his experience as a customer.
The purpose of trademarks isn't to let companies control the use of a term in every way possible or restrict speech they find inconvenient, it is to ensure that consumers know which product they are buying when it's identified by a trademark.
I know benchmarks don't tell the whole story, but the SPEC benchmarks would likely show any really serious performance problems. In fact, the 1.5GHz P4 seems to be a little faster than the 1GHz Athlon on integer and significantly faster on floating point.
I don't like the P4 design. It's complex, has a messy instruction set, and consumes too much power for the performance they deliver. But the same is true of the whole Pentium series, and we have learned to live with it.
Overall, I think the Athlon may be a somewhat better deal than the P4, but the P4 isn't a slouch either. Now, I am looking forward to Sledgehammer: the 64bit AMD chip might end up being a much better compromise than Intel's 64bit offerings.
Open source skeptic: Greg Rose of LynuxWorks questions the suitability of Linux in the embedded world.
This comes from a company that ships BlueCat Linux and touts the compatibility of LynuxWorks with the Linux APIs. I guess they don't quite get it, and the market will likely punish them for it in the long run. Lynx may or may not be better for real-time applications right now than real-time Linux, but in the long run, there will be open source real-time operating systems: the long-term economic incentive for companies to create and share that kind of software are simply too overwhelming for any proprietary software vendor like LynuxWorks to compete.
Of course, they can try to hedge their bets by shipping BlueCat Linux, but as long as they also have a proprietary product, there will be conflicts of interest within their company: whenever they enhance their free software, they cut into the market position of the proprietary stuff. This seems worse to me than committing to one or the other business model and focussing all their resources on that.
Note that I'm not saying that there is anything wrong with them trying to sell proprietary systems; I simply think they won't be competitive in the long run.
One's killer app depends on one's needs. I don't really care much about Apache: on a modern Pentium, I can saturate any kind of bandwidth I can afford easily. I do care about supercomputing, however.
In any case, is the Xbox competitive for general purpose applications, be they Apache or supercomputing? I kind of doubt it. Paying $300 for a 733MHz Pentium with 64M of memory, an 8G hard drive, and almost no ports isn't all that great a deal anymore. By the time the Xbox will be widely available, it will likely be a completely uninteresting deal. In addition, the form factor may turn out to be not all that convenient for building server farms (server room space is very costly, in particular when co-locating).
The Xbox is mostly about convenience: having a stable, uniform hardware platform makes writing games easier. It is also about low cost of entry: assuming the Xbox meets a price target of $300, you can't get $300 PCs, but you will be able to get something that's twice as fast for twice the money. For server farms, aggregate performance matters, not cost of entry. Its performance and features, on the other hand, seem greatly overhyped to me.
Conversely, the (perhaps only?) good thing about MS Office is that any computer with Windows is likely to also have Office, so you can edit/display/transmit your files to virtually any Windows user.
Did the Tooth Fairy magically drop Office onto your computer? She didn't on mine. Getting Office would have been several hundred dollars more. I consider it rather rude when people send me content in a format that would force me to buy a product that I don't want to buy. But perhaps you are the kind of person that gives somebody a birthday present of a vacation somewhere and expects them to buy the flight to go with it?
The most compelling example of this that I can think of is PowerPoint; if I need show someone my presentation at short notice and don't have my laptop handy, I can borrow someone else's, as long as they have Office.
I don't have a problem with that: I save my presentations in PDF or HTML format, and I can display them on just about every computer, not just those running overpriced Microsoft software.
Why doesn't a major Linux distribution provider (like RedHat) specifically embrace an application suite, and ship it with their bundle?
Probably because there is no need for it. It's only Windows users that think it's OK to send around documents in proprietary formats. On Linux, people use a wide variety of open, well-documented, non-proprietary formats that are understood by many different kinds of software.
A few Windows vendors like Corel have tried to bring bad Windows habits to the Linux platform, but they seem to have failed, fortunately.
My problem with closed source, proprietary software like TheKompany is not philosophical, it's economic: I don't see how they can stay in business long. Apparently, you yourself have your doubts that TheKompany has a good value proposition, otherwise you wouldn't beg people to buy their stuff. So, what's wrong with TheKompany's business model? Two major things.
First, there are free alternatives out for all their products already; it's only a question of time until the free stuff gets good enough to kill off their market. Only Microsoft has been able to insulate themselves a little bit from free software, through an intricate web of proprietary standards, and even Microsoft has to be scared. The fact is that free software kills off proprietary software because it's the economically rational choice for customers.
Second, their software model is antiquated. Big do-everything C++ applications, the kind that made Bill Gates rich and famous, are not the way to go anymore. They were needed in the 1980's and 1990's because all you could do is distribute software on floppy and CD-ROM, and you better made sure that what you distributed addressed everybody's needs. With the Internet, you can now deliver small, targeted, light-weigh applications.
There is money to be made in software, but in the long run, not in proprietary, closed-source packages. It's nice if you want to support TheKompany. But don't kid yourself: from an economic and free market perspective, enterprises like TheKompany are irrational and an anachronism. Your $30 is more rationally put into a large pot that enhances GNUcash than TheKompany.
You can spend hours chasing big, nasty bugs in/usr/src/linux, building new worlds in gcc/g++, creating art in the Gimp, creating artificial life in Objective-C, etc.
Seriously, I haven't been holding my breath for commercial gaming companies to port to Linux. There are some nice Linux games out there, and I'd much rather see the tradition of open source games continue. The classic UNIX games (rogue, etc.) are great, and they are great because lots of people contributed. I think the gameplay is still better than in most of the commercial games. Let's bring back that tradition.
Well, Microsoft made the right decision on this one. USB2.0 is a poor engineering tradeoff and largely just an attempt to capitalize on Apple's marketing blunders related to FireWire.
FireWire products are widely available now, FireWire has a number of technical advantages over USB2.0, FireWire products work well, and they are faster now than USB2.0 when it will be released.
People have tried to use FPGAs for building supercomputers as long as they have been around. So far, they have never proven cost effective. You gain a lot in processing speed by not having to interpret instructions, but you lose a lot in speed and area because of the hooks needed for reprogrammability. It sounds good and attracts a certain brand of investor, but I wouldn't put my money on it. I think you are going to see massively parallel machines with single-package processor/memory combos succeed before FPGAs.
I think you misunderstood what I was saying, and we seem to basically agree: Xerox didn't come up with all that stuff, but Xerox demonstrated the first working example of an integrated GUI-based desktop for business applications. That is what Apple saw, and that is the idea they based their Mac business on.
I should add that I don't think that Apple is guilty of either patent violations or intellectual dishonesty: they are a company that made a product and they only have to stay within legal bounds, not academic standards.
What I do fault Apple for is that they didn't take a lot of the other stuff that formed the basis of the Xerox systems, foremost Smalltalk. MacOS delivered the look, but it failed to deliver the safety and programmability. I think Apple set us on a course of twenty years of horribly engineered, kludgy, bulky, difficult-to-extend systems. By that I don't mean just MacOS up to and including version 9, but Windows and Gnonme/KDE.
Linux has done just fine even though for most of its history, it was pretty, shall we say, "hands-on".
If the Agenda hardware is reasonable and it boots and runs the Linux kernel and some scripting languages reasonably reliably, people will find some uses for it. It won't be a PalmPilot "killer", but that's not the point.
if you want to program it, for example
on
Agenda VR3 Review
·
· Score: 1
Have you tried writing custom applications for the Pilot? I have. It's a lot of work. PalmOS is primitive and specialized, and the Palm hardware is limited and slow. Palm apps work so well because people invest a lot of time in it.
If you want to write custom/vertical applications, PalmOS isn't the right choice. WinCE may be. Even an Agenda, despite its limitations, may be. An iPaq running Linux probably is.
Slashdot Mirror
That's why the most commonly used form of naming network services these days, URLs, includes port numbers.
In the end, it probably doesn't matter. I wouldn't expect either Gtk+ or Qt to be central to GUI development on Linux a few years from now. While mature, they represent a fairly tedious and traditional way of writing UIs. There are new paradigms already sneaking into real apps.
You can run Apache or FTP or other servers on whatever port you like, and people do. Perhaps you haven't noticed.
I wouldn't bother with the PCI cards (too much work). There is no driver for their USB adapter (PA101).
What are the plans for the compilation of Python code to efficient executables? Python's object system is very dynamic, allowing anybody to add instance variables and methods to any object at any time--how are you planning on dealing with that during compilation? Performance-wise, how do you expect Python will compare to compiled CommonLisp or Smalltalk, which evolved along similar lines 20 years ago? And will there be a language standard, or will Python continue to be defined by what the C implementation does?
The problem isn't a shortage of IP addresses, it's a shortage of well-known ports. There are only so many port 80s and port 23s to go around. However, there are a lot of other ports, and there are good, reliable, safe ways of forwarding them (firewall forwarders, ssh, SOCKS, ...). Rather than fixing subtle assumptions about name/IP correspondences in lots of software, I'd rather be fixing software that hardcodes port numbers; the latter is much easier to find and code.
AVES is a prototypical example of how we create messes and maintenance headaches: it looks like it solves most of the problem and, hey, we can fix the remaining problems, right? But it isn't the right thing to do, and the long term costs of creating such a mess would be high. Fortunately, I don't think it will catch on: ISPs don't want people to run servers anyway.
I think it's better to put personal data on your personal site, with a company you have a paying relationship with, that provides a commodity service. Those companies tend to stay in business, and if they don't, you can always switch to a different one. Yes, you may have to download a PHP script or use a web editor.
Apparently, you can get away with a lot these days. A tax expert described this as: "many business people treat the filing of their tax return as a 'first offer'"; if the IRS doesn't audit them, they pay a small fraction of what is due.
It's 21% faster, to be precise.
Compared to the visual impact of 900Mhz versus 600Mhz.
That's 50% faster.
Stupid, yes,
Doesn't seem stupid to me.
I don't think that's true. Developers will be moving to the faster machines. They will be using tools that trade performance for faster time to market, and they will be putting in more features. Experimental UIs in research labs right now do a lot more than what Gnome, KDE, or Windows do, and they are using tools that do eat up lots of CPU time. Maybe there is a very temporary lull because Microsoft hasn't released anything new in a few years, but sooner or later, Microsoft will copy someone else's nifty but slow GUI again and that will drive the next generation hardware purchases.
There is already lots of 64bit code in C and Fortran. And gcc knows about 64bit code. So, all AMD needs to do is sponsor gcc backend development. And I think they are doing just that. Commercial vendors, ever eager for better benchmark results, will follow.
Is that why Konqueror and KIO together take 47Mbytes on my machine to display six simple web pages and feel sluggish on a 300MHz PII? (And that's not even counting the X server.) Is that the kind of "small and fast" you are talking about?
The fact is that large software systems like Gnome and KDE need the features that languages like Java, Smalltalk, Objective-C, or Lisp provide. The only choice their authors have is whether they leave the implementation of those features to compiler writers, who know what they are doing, or whether they try to come up with substandard ad-hoc solutions themselves.
Think of it like cars. A Z3 is a very fast car to move a person around. But trying to use a fleet of Z3's to haul a few tons of dirt is much slower and much more costly than using a truck.
Why would I want to write toolkit code (GTK, Qt, ect) in a language that has to be run in a virtual machine?
You wouldn't. You would want to write it in a dynamic language that can be compiled into efficient native code. A language like Java, Objective-C, Lisp, or Smalltalk. Your code in those languages may run 2-5x slower than C/C++ on small benchmark snippets. But for large software systems, there is a good chance that it will end up being faster and use less memory than the C/C++ code. And it will definitely be easier to develop and maintain. For really compute-intensive inner loops, you can always drop back to raw C or C++ no matter what language you use.
Yet, at the same time, many GUI applications under Gnome, KDE, or Windows are huge, complex messes. Trying to modify their behavior is an exercise in patience and persistence, not just because of the mountains of code one has to wade through, but also just because of the lengthy edit/compile/run cycle. And the irony is that, while those systems start out really fast when they are small, taking full advantage of the "fast" languages they are built on, they actually get very slow when they grow, because their authors end up reinventing higher-level language constructs without being able to do a good job at the implementation ("GObject" in Gtk is a recent example).
Even trying to install a sound card for the Linux kernel can take hours in trying to track down the right version and getting bits arranged just right for the superfast but dumb kernel to have its driver nuggets in all the right places.
Let's use the spare cycles and memory to make our systems smarter and easier to deal with. That does not necessarily mean something as complex as "artificial intelligence". It may mean putting a scripting language into the kernel that lets people add simple kernel extensions simply. It may mean using a language like Objective-C to extend an existing C system. It may mean doing GUIs in Python or Smalltalk or even just Java.
There are lots of things wrong with software: it's hard to install, it's hard to manage, and it fails a lot. Yet, both Linux and Windows developers still have an unhealthy obsession with performance (and, often, they don't even achieve it). Simplify your projects and deliver a better product: put those 1GHz+ machines to work by writing in languages that don't force you to optimize every bit. And if you can't get over worrying about performance when you look at that pretty but sluggish scripting language code, close your eyes and think about the good of the US economy.
The purpose of trademarks isn't to let companies control the use of a term in every way possible or restrict speech they find inconvenient, it is to ensure that consumers know which product they are buying when it's identified by a trademark.
I don't like the P4 design. It's complex, has a messy instruction set, and consumes too much power for the performance they deliver. But the same is true of the whole Pentium series, and we have learned to live with it.
Overall, I think the Athlon may be a somewhat better deal than the P4, but the P4 isn't a slouch either. Now, I am looking forward to Sledgehammer: the 64bit AMD chip might end up being a much better compromise than Intel's 64bit offerings.
This comes from a company that ships BlueCat Linux and touts the compatibility of LynuxWorks with the Linux APIs. I guess they don't quite get it, and the market will likely punish them for it in the long run. Lynx may or may not be better for real-time applications right now than real-time Linux, but in the long run, there will be open source real-time operating systems: the long-term economic incentive for companies to create and share that kind of software are simply too overwhelming for any proprietary software vendor like LynuxWorks to compete.
Of course, they can try to hedge their bets by shipping BlueCat Linux, but as long as they also have a proprietary product, there will be conflicts of interest within their company: whenever they enhance their free software, they cut into the market position of the proprietary stuff. This seems worse to me than committing to one or the other business model and focussing all their resources on that.
Note that I'm not saying that there is anything wrong with them trying to sell proprietary systems; I simply think they won't be competitive in the long run.
In any case, is the Xbox competitive for general purpose applications, be they Apache or supercomputing? I kind of doubt it. Paying $300 for a 733MHz Pentium with 64M of memory, an 8G hard drive, and almost no ports isn't all that great a deal anymore. By the time the Xbox will be widely available, it will likely be a completely uninteresting deal. In addition, the form factor may turn out to be not all that convenient for building server farms (server room space is very costly, in particular when co-locating).
The Xbox is mostly about convenience: having a stable, uniform hardware platform makes writing games easier. It is also about low cost of entry: assuming the Xbox meets a price target of $300, you can't get $300 PCs, but you will be able to get something that's twice as fast for twice the money. For server farms, aggregate performance matters, not cost of entry. Its performance and features, on the other hand, seem greatly overhyped to me.
Did the Tooth Fairy magically drop Office onto your computer? She didn't on mine. Getting Office would have been several hundred dollars more. I consider it rather rude when people send me content in a format that would force me to buy a product that I don't want to buy. But perhaps you are the kind of person that gives somebody a birthday present of a vacation somewhere and expects them to buy the flight to go with it?
The most compelling example of this that I can think of is PowerPoint; if I need show someone my presentation at short notice and don't have my laptop handy, I can borrow someone else's, as long as they have Office.
I don't have a problem with that: I save my presentations in PDF or HTML format, and I can display them on just about every computer, not just those running overpriced Microsoft software.
Why doesn't a major Linux distribution provider (like RedHat) specifically embrace an application suite, and ship it with their bundle?
Probably because there is no need for it. It's only Windows users that think it's OK to send around documents in proprietary formats. On Linux, people use a wide variety of open, well-documented, non-proprietary formats that are understood by many different kinds of software.
A few Windows vendors like Corel have tried to bring bad Windows habits to the Linux platform, but they seem to have failed, fortunately.
First, there are free alternatives out for all their products already; it's only a question of time until the free stuff gets good enough to kill off their market. Only Microsoft has been able to insulate themselves a little bit from free software, through an intricate web of proprietary standards, and even Microsoft has to be scared. The fact is that free software kills off proprietary software because it's the economically rational choice for customers.
Second, their software model is antiquated. Big do-everything C++ applications, the kind that made Bill Gates rich and famous, are not the way to go anymore. They were needed in the 1980's and 1990's because all you could do is distribute software on floppy and CD-ROM, and you better made sure that what you distributed addressed everybody's needs. With the Internet, you can now deliver small, targeted, light-weigh applications.
There is money to be made in software, but in the long run, not in proprietary, closed-source packages. It's nice if you want to support TheKompany. But don't kid yourself: from an economic and free market perspective, enterprises like TheKompany are irrational and an anachronism. Your $30 is more rationally put into a large pot that enhances GNUcash than TheKompany.
Seriously, I haven't been holding my breath for commercial gaming companies to port to Linux. There are some nice Linux games out there, and I'd much rather see the tradition of open source games continue. The classic UNIX games (rogue, etc.) are great, and they are great because lots of people contributed. I think the gameplay is still better than in most of the commercial games. Let's bring back that tradition.
FireWire products are widely available now, FireWire has a number of technical advantages over USB2.0, FireWire products work well, and they are faster now than USB2.0 when it will be released.
People have tried to use FPGAs for building supercomputers as long as they have been around. So far, they have never proven cost effective. You gain a lot in processing speed by not having to interpret instructions, but you lose a lot in speed and area because of the hooks needed for reprogrammability. It sounds good and attracts a certain brand of investor, but I wouldn't put my money on it. I think you are going to see massively parallel machines with single-package processor/memory combos succeed before FPGAs.
I should add that I don't think that Apple is guilty of either patent violations or intellectual dishonesty: they are a company that made a product and they only have to stay within legal bounds, not academic standards.
What I do fault Apple for is that they didn't take a lot of the other stuff that formed the basis of the Xerox systems, foremost Smalltalk. MacOS delivered the look, but it failed to deliver the safety and programmability. I think Apple set us on a course of twenty years of horribly engineered, kludgy, bulky, difficult-to-extend systems. By that I don't mean just MacOS up to and including version 9, but Windows and Gnonme/KDE.
If the Agenda hardware is reasonable and it boots and runs the Linux kernel and some scripting languages reasonably reliably, people will find some uses for it. It won't be a PalmPilot "killer", but that's not the point.
If you want to write custom/vertical applications, PalmOS isn't the right choice. WinCE may be. Even an Agenda, despite its limitations, may be. An iPaq running Linux probably is.