If you are a US military employee or draftee and you are told to work on the software, you do it because you are obligated to. If the US military pays you to do it and you like the money and don't mind working for them, you do it.
If they ask for a feature or bug fix without paying, it's like any other open source project and any other feature request: you have no obligation to do anything for whatever reason. You have a perfect right to decide for yourself if this is something you want to volunteer your time for. There is absolutely nothing wrong with telling the US military, like any other open source user, that if they want a feature, they can hire you to implement it.
But don't worry: Rumsfeld will probably invoke some sort of "emergency draft procedure for skilled individuals", used to force open source developers for free. After all, it's only big companies like Lockheed and Microsoft that should receive the benefit of our tax dollars.
How do they know what patches you need if they can't look at your system and tell their servers what you've already got.
Perhaps the same way Debian does: Debian sends you a list of available packages, and your local apt client decides which to install. And if you install through a web cache, the Debian servers never even get to see what packages you download.
And, in any case, they never need to send information about software they clearly don't have patches for (like Mozilla or Java).
Microsoft receives this information because they want to spy on their users and have the best marketing and user info to beat their competitors, not because they have to. Or maybe they receive this information because their technical imagination is as limited as yours.
a company called "Kodak". In fact, lots of people have been working busily on commercializing this, and there are probably some OLED products on the market. It's not quite competitive with LCDs or CRTs yet.
If you search USENET, you'll find that there are about 1300 uses of the word "google" prior to 1995, a variant spelling of "googol". One google/googol = 10^100. So, not only is it a verb now, it has been a variant spelling of "googol" since before Google even existed.
Even if the distinction mattered, people were using CVS and staging areas for web content management before the Interwoven patent was applied for. (People were using and are using CVS for lots of things besides versioning code; you should try it.)
And dedicated, Interwoven-like content management systems were already around at least in 1996.
Scripting languages like Perl and Python get their enormous power, their flexibility, and their ability to evolve rapidly by having no strong dividing line between the language and its implementation. Furthermore, they usually prefer simple and general purpose mechanisms, to complex mechanisms. Python and Perl objects are essentially hash tables, and you can hack around with them easily.
But, like anything, that's an engineering tradeoff. By exposing so much of the implementation and having no fixed, defined standard, things can shift under the programmer from release to release. High performance implementations are nearly impossible to create. And issues like scoping may end up being more convenient but less reliable (Python scoping is something no serious language designer would choose to put into a language, for example).
So, by all means, use scripting languages. But don't expect that code to survive in the long term: 10-20 years from now, the interpreter that executed that code will be gone, and nobody will be able to determine exactly anymore what it actually meant.
A "real language" is a language with a clear, well-thought-out definition that doesn't change every few years and that does not excessively expose implementation details. And while "real languages" are almost universally less convenient to program in than scripting languages, there are reason why people put up with the hassles.
In addition to problems with code size and price, the fact that code generation for it appears considerably harder than for Pentium and that it effetively doesn't offer useful backwards compatibilitly make it a very undesirable chip.
64bit is very important in my opinion, both on the server and on the desktop, but not at any cost. And the cost with Itanium is simply too high.
You are kidding, right? The segment registers are in the Pentium architecture because that's how the 8086 got extended to 32bit. Yes, in the process, the segment registers ended up allowing you to address more than 32bit of data, but essentially no user programs are using that feature (in fact, they probably can't, under NT or Linux). And only for supporting the occasional moving of data inside a huge kernel address space, having those instructions would be a colossal engineering blunder and waste of chip area. It's nice if these instructions find at least minimal use in a few niches in the kernel (although any such use would be high unportable), so they are not completely wasted, but they simply do not address the needs of application programmers developing software requiring more than 4G of address space.
Um.... no. Segment registers have been in Intel's products from the beginning (at least since the 8088). It wasn't a band-aid to stall adoption of 32-bit processors as you imply with the above comment.
I think you are a bit unfamiliar with the history. Intel's processors didn't start with the 8088. Intel used to have the 8080 and 8085 processors, processors with 16 bit address spaces. The 8088 was an extension of those and an attempt to give the processor an address space larger than 16 bit without changing the programming model too much.
The current 32-bit processors also have segment registers and you can use them with the "flat" address space. Some OSes (like Linux) just set all the registers to the same segment and never change them. But you could have separate segments for the stack, data, code, etc.
Of course, they do. And the degree to which they are used means that they have been an utter failure.
Going from 16 bit to 32 bit address spaces changed the nature of software radically. With 16 bit address spaces, a lot of text processing had to be stream oriented. Text editors were written in a way that they would text in and out from disk. Compilers consisted of many passes and performing global optimization was nearly impossible. Going to 32 bit address spaces changed all that and much more.
Intel didn't want to make the jump to 32 bit, so they introduced "segment registers". They tried to convince people that this was actually a good thing, that it would make software better. Of course, we know better: segment registers were a mess. Software is complex enough than to have to deal with that. That's why we ended up with 32 bit flat address spaces.
64 bit address spaces are as radical a change from 32 bit as 32 bit was from 16 bit. Right now, we can't reliably memory map files anymore because many files are bigger than 2 or 4 Gbytes. Kernel developers are furiously moving around chunks of address space in order to squeeze out another hundred megabytes here or there.
With flat 64 bit address spaces, we can finally address all disk space on a machine uniformly. We can memory map files. We don't have to worry about our stack running into our heap anymore. Yes, many of those 64 bit words will only be filled "up to" 32 bits. But that's a small price to pay for a greatly simplified software architecture; it simply isn't worth it repeating the same mistake Intel made with the x86 series by trying to actually use segment registers. And code that actually works with a lot of data can do what we already do with 16 bit data on 32 bit processors: pack it.
Even if having 4G of memory standard is a few years off yet, we need 64 bit address spaces. If AMD manages to release the Athlon 64 at prices comparable to 32 bit chips, they will sell like hotcakes because they are fast; but even more worrisome for Intel, an entirely new generation of software may be built on the Athlon 64, and Intel will have no chips to run it on. If AMD wins this gamble, the payoff is potentially huge.
good thinking--the shuttle is even worse, then
on
More on Columbia
·
· Score: 4, Interesting
Indeed, the shuttle lifts lots of cargo, plus the weight of the shuttle itself, somewhere between 100 and 200 tons. And on its return trip, most of that mass is deorbited again with the shuttle, except for the cargo. Of course, going up, both Soyuz and the shuttle use roughly the same technology: big rockets. All that mass and complexity on the shuttle is for giving the astronauts a plane-like landing.
If you think about it, that means the shuttle is an even worse deal than usually assumed. Lifting mass into orbit is hugely expensive. First, we spend all that money lifting the huge mass of the shuttle itself into space, and then we bring it all back again? Imagine if every shuttle launch had left a carefully designed, multi-purpose transport vehicle and container of the size of the shuttle in space and returned the astronauts via a Soyuz-like capsule--the ISS could have been completed long ago from those vehicles and transport containers.
The more one thinks about it, the more wasteful and bizarre the shuttle program becomes.
An increase in the price of gasoline would hurt low-income families substantially because they need transportation like everybody else.
Mandating fleet fuel efficiency standards, in contrast, results in car manufacturers charging less for fuel efficient cars and charging more for gas guzzlers. That allows low-income families to both buy inexpensive fuel-efficient cars and save money on gas, while being subsidized by people who voluntarily choose to buy gas guzzlers. It seems like a very elegant free market solution to me. And it seems like a much better solution than raising the price of gasoline.
down comes the ISS, which signifies the unity of the human race dedicated to one cause
Yes, but is it a good cause? I'd much rather have the cause be something useful, like trying to build the first interstellar probe, or building a huge fleet of planetary probes that will examine every nook and cranny of our solar system. An even better cause might be the elimination of nuclear weapons, world hunger, or building a hydrogen economy.
But sending a bunch of people into orbit, what's the point? (Well, maybe to get rid of Lance, but there must be cheaper ways.)
scary kind of engineering
on
More on Columbia
·
· Score: 4, Interesting
Given what is coming out now about the construction of the shuttle, it's amazing that these things fly at all: a tiny hole can lead to a burn through, as can the slightest error in the computer controlled reentry-angle, malfunction of some servo system, or a host of other problems. And there is nothing that the crew can do to fix such problems during reentry.
This just doesn't seem like good engineering. The traditional Apollo/Soyuz reentry vehicles had few if any of those risk factors. Compare what happened to Columbia with what happened to Soyuz 5: the reentry module failed to separate from the service module and entered into the atmosphere backwards. But when the service module had burned off, the reentry module righted itself (just because of its weight distribution--that's what it was designed to do) and Volynov landed and survived. Those reentry vehicles require no electronics and no flight control. The only thing that needs to happen is that the parachutes open some time before the capsule hits the ground. I think I'd have a bit more confidence in something like a Soyuz reentry vehicle than in the shuttle. And they are probably a lot cheaper, too.
I don't agree with creating a law that says any vehicle should get X milege per gallon. I think supply and demand will take care of that for us.
That's not what the cafe standards say; they say that the average MPG should be a certain value. Then, manufacturers adjust the pricing of their different vehicles accordingly: fuel-efficient vehicles become disproportionately cheaper (if they are considered less desirable), while gas guzzlers become disproportionately more expensive. It is market mechanisms at work. Its effect is similar to what Europe is trying to achieve with taxing cars by the size of their motors.
That approach is a lot better than simply imposing a high gasoline tax, which is regressive and hits low income earners hardest. With the cafe standards, low income earners can save twice, by getting fuel-efficient cars more cheaply and saving on gas.
Why don't we (the U.S.A) have a decent rail system like Europe?
That requires long term planning, long term commitments of funds, and concerted action, something the US has become incapable of over the last few decades. Cars and air travel are much easier to subsidize. And even the road infrastructure is falling apart because of lack of upkeep.
You will hear occasionally that this is because the US is so much bigger. That is nonsense. Distances in Europe are comparable to those in the US: Hammerfest to Palermo or Lisbon to Prague are roughly a couple of thousand miles. If the US had maintained an efficient rail system, people would have settled in ways that would have made train travel efficient.
Bush has been talking about hydrogen-based energy as well. Of course, in the case of Bush, it looks more like a strategy to avoid doing anything substantial on the environment in the short term; if Bush really cared about the environment, he'd mandate increases in fuel efficiency and the like.
Yes, I somehow don't understand why "artists" get away with claiming that the music or books they create are not "work for hire", while software development pretty much always is considered that, no matter how innovative it may be. The attitude by many musicians, visual artists, and writers that they are "the creative people", while software professionals are "just engineers" is also kind of annoying. But maybe the solution to that is for software professionals to become more vocal.
Nobody knows for certain. It's not even clear what "market share" even means. Do you mean "new sales" or "current users"? Do you mean "number of units" or "money spent on"? And how would anybody even measure those numbers for Linux?
Overall, my guess is that there are more people who use Linux regularly and interactively than there are people who use OS X. One reason is that you don't need to have Linux on your desktop in order to use it interactively. And I suspect that there are even people who have desktop machines that run Linux at least some time than there are people who have desktop machines that run OS X.
Also, I doubt that there is a groundswell of people "converting" from Linux to OS X. OS X is a nice consumer OS, but it is no replacement for Linux. Many Linux users who got OS X machines (like myself) probably got them as second machines. And, believe me, that's all OS X is going to remain for me--a nice looking second machine that I occasionally use for the kinds of consumer things and proprietary software that I used to use Windows for.
Dont get stuck with an useless and outdated OS, meet the future and get a Zaurus [sharp-usa.com] (or wait for the IBM Linux handhelds [geek.com]).
Huh? GPE runs on top of Linux, just like the Zaurus. The only difference is the window system.
Zire is the only one that make sense
on
Palm PDA Roundup
·
· Score: 5, Insightful
You can get the Palm Zire for about $80-$100 at your local electronics store. It's great for the things that PalmOS is traditionally good at: calendaring, TODO lists, and simple note taking. I think it's the only Palm that makes any sense.
The high-end Palms with high-end features (MP3, multitasking, cameras, high-resolution screens, etc.) are a horrible combination of hardware and software kludges to get PalmOS to do things that PalmOS was never designed to do. For example, many of those nifty features on the Clie have required Sony to hack their own extensions into PalmOS, and every Palm software vendor needs to accomodate those. And because each vendor hacks PalmOS to their liking, Palm can't even ship a single upgrade from PalmOS 5 to PalmOS 6--you will be able to upgrade your Sony only if Sony spends the time and money to create their own upgrade.
Unfortunately, the Linux PDAs aren't doing much better either. The Zaurus (I own one) is a brick. Several other Linux handheld startups went belly-up. And handhelds.org is fighting a constant battle to reverse engineer handhelds in order to run Linux on them--even handhelds that are developed within Compaq/HP, the company hosting handhelds.org. However, Motorola's use of Linux on their cell phones may give Linux on PDAs a new life.
I hate to say it, but if you are using Windows on your desktop and if you are looking for a high-end handheld, a PocketPC machine probably makes more sense. Even something like the iPaq h1910 ($299) runs rings around more expensive Palm models and is lighter to boot. The big problem with PocketPC is that it is completely proprietary: it pretty much only talks to Windows desktops and the primary development platform for it is Microsoft proprietary. But, then, it isn't clear to me why you would want a high-end handheld to begin with.
Overall, I'd just stick with the Palm Zire, and for the other features (MP3 player, GPS, camera, games, etc.) get separate, dedicated devices.
USB belongs to intel. Remember when usb was first forced down our throats?
I do. I was eagerly awaiting an alternative to PS/2 and RS-232c. Apple made USB a modest success in their market niche, and I was glad to see it come to the PC platform. What is wrong with that? And USB has turned out to be great for Linux: USB offers by far the widest selection of devices for Linux that just plug in and work.
Now that it is ubiquitous intel can levy massive royalties. I'm pretty shure intel wants to shove it's usb2 anywhere it can either with convincing or coercive arguments.
So? Apple was trying to charge FireWire royalties. Given that both standards are proprietary, that is not a basis for preferring one over the other.
Maybe it's just me but I would have gone with 1394.
All things being equal, I would have gone with 1394 as well. However, USB 2.0 is here, and it is cheap and extremely widely supported. There is a large number of "class drivers" for it--standards for how computers can talk to specific kinds of devices, like network adapters, disks, monitors, keyboards, printers, MIDI devices, etc. And there are lots of devices on sale that actually conform to those specifications. And there are even more de-facto standards for USB devices.
1394 and 1394b look pretty bleak in comparison. What I see sitting on the shelves that plugs into 1394 is very limited: disk drives, camcorders, and a few web cams (but you need to buy a special driver for those on the Mac).
1394 and 1394b are niche products now, primarily used for disks and video. I don't see that turning around. It would have been nice if their rollout had been handled differently, but it wasn't.
It remains the case that a programmer is something that, if you don't program, you are not.
Yes, that remains the case for now. However, it doesn't have to remain the case forever. The concept of communicating rules and behavior to a computer is not alien to even naive users, it is just that computer scientists haven't come up with a syntax and interaction style that feels comfortable to everybody.
If they ask for a feature or bug fix without paying, it's like any other open source project and any other feature request: you have no obligation to do anything for whatever reason. You have a perfect right to decide for yourself if this is something you want to volunteer your time for. There is absolutely nothing wrong with telling the US military, like any other open source user, that if they want a feature, they can hire you to implement it.
But don't worry: Rumsfeld will probably invoke some sort of "emergency draft procedure for skilled individuals", used to force open source developers for free. After all, it's only big companies like Lockheed and Microsoft that should receive the benefit of our tax dollars.
Perhaps the same way Debian does: Debian sends you a list of available packages, and your local apt client decides which to install. And if you install through a web cache, the Debian servers never even get to see what packages you download.
And, in any case, they never need to send information about software they clearly don't have patches for (like Mozilla or Java).
Microsoft receives this information because they want to spy on their users and have the best marketing and user info to beat their competitors, not because they have to. Or maybe they receive this information because their technical imagination is as limited as yours.
a company called "Kodak". In fact, lots of people have been working busily on commercializing this, and there are probably some OLED products on the market. It's not quite competitive with LCDs or CRTs yet.
You're missing the point.
If these "demands" of mine need Nethack to be some commercial product, so be it.
NetHack would lose something if it got that kind of graphics. But if you like that sort of thing, why not just play Diablo?
If you search USENET, you'll find that there are about 1300 uses of the word "google" prior to 1995, a variant spelling of "googol". One google/googol = 10^100. So, not only is it a verb now, it has been a variant spelling of "googol" since before Google even existed.
And dedicated, Interwoven-like content management systems were already around at least in 1996.
But, like anything, that's an engineering tradeoff. By exposing so much of the implementation and having no fixed, defined standard, things can shift under the programmer from release to release. High performance implementations are nearly impossible to create. And issues like scoping may end up being more convenient but less reliable (Python scoping is something no serious language designer would choose to put into a language, for example).
So, by all means, use scripting languages. But don't expect that code to survive in the long term: 10-20 years from now, the interpreter that executed that code will be gone, and nobody will be able to determine exactly anymore what it actually meant.
A "real language" is a language with a clear, well-thought-out definition that doesn't change every few years and that does not excessively expose implementation details. And while "real languages" are almost universally less convenient to program in than scripting languages, there are reason why people put up with the hassles.
64bit is very important in my opinion, both on the server and on the desktop, but not at any cost. And the cost with Itanium is simply too high.
You are kidding, right? The segment registers are in the Pentium architecture because that's how the 8086 got extended to 32bit. Yes, in the process, the segment registers ended up allowing you to address more than 32bit of data, but essentially no user programs are using that feature (in fact, they probably can't, under NT or Linux). And only for supporting the occasional moving of data inside a huge kernel address space, having those instructions would be a colossal engineering blunder and waste of chip area. It's nice if these instructions find at least minimal use in a few niches in the kernel (although any such use would be high unportable), so they are not completely wasted, but they simply do not address the needs of application programmers developing software requiring more than 4G of address space.
I think you are a bit unfamiliar with the history. Intel's processors didn't start with the 8088. Intel used to have the 8080 and 8085 processors, processors with 16 bit address spaces. The 8088 was an extension of those and an attempt to give the processor an address space larger than 16 bit without changing the programming model too much.
The current 32-bit processors also have segment registers and you can use them with the "flat" address space. Some OSes (like Linux) just set all the registers to the same segment and never change them. But you could have separate segments for the stack, data, code, etc.
Of course, they do. And the degree to which they are used means that they have been an utter failure.
Intel didn't want to make the jump to 32 bit, so they introduced "segment registers". They tried to convince people that this was actually a good thing, that it would make software better. Of course, we know better: segment registers were a mess. Software is complex enough than to have to deal with that. That's why we ended up with 32 bit flat address spaces.
64 bit address spaces are as radical a change from 32 bit as 32 bit was from 16 bit. Right now, we can't reliably memory map files anymore because many files are bigger than 2 or 4 Gbytes. Kernel developers are furiously moving around chunks of address space in order to squeeze out another hundred megabytes here or there.
With flat 64 bit address spaces, we can finally address all disk space on a machine uniformly. We can memory map files. We don't have to worry about our stack running into our heap anymore. Yes, many of those 64 bit words will only be filled "up to" 32 bits. But that's a small price to pay for a greatly simplified software architecture; it simply isn't worth it repeating the same mistake Intel made with the x86 series by trying to actually use segment registers. And code that actually works with a lot of data can do what we already do with 16 bit data on 32 bit processors: pack it.
Even if having 4G of memory standard is a few years off yet, we need 64 bit address spaces. If AMD manages to release the Athlon 64 at prices comparable to 32 bit chips, they will sell like hotcakes because they are fast; but even more worrisome for Intel, an entirely new generation of software may be built on the Athlon 64, and Intel will have no chips to run it on. If AMD wins this gamble, the payoff is potentially huge.
If you think about it, that means the shuttle is an even worse deal than usually assumed. Lifting mass into orbit is hugely expensive. First, we spend all that money lifting the huge mass of the shuttle itself into space, and then we bring it all back again? Imagine if every shuttle launch had left a carefully designed, multi-purpose transport vehicle and container of the size of the shuttle in space and returned the astronauts via a Soyuz-like capsule--the ISS could have been completed long ago from those vehicles and transport containers.
The more one thinks about it, the more wasteful and bizarre the shuttle program becomes.
Mandating fleet fuel efficiency standards, in contrast, results in car manufacturers charging less for fuel efficient cars and charging more for gas guzzlers. That allows low-income families to both buy inexpensive fuel-efficient cars and save money on gas, while being subsidized by people who voluntarily choose to buy gas guzzlers. It seems like a very elegant free market solution to me. And it seems like a much better solution than raising the price of gasoline.
Yes, but is it a good cause? I'd much rather have the cause be something useful, like trying to build the first interstellar probe, or building a huge fleet of planetary probes that will examine every nook and cranny of our solar system. An even better cause might be the elimination of nuclear weapons, world hunger, or building a hydrogen economy.
But sending a bunch of people into orbit, what's the point? (Well, maybe to get rid of Lance, but there must be cheaper ways.)
This just doesn't seem like good engineering. The traditional Apollo/Soyuz reentry vehicles had few if any of those risk factors. Compare what happened to Columbia with what happened to Soyuz 5: the reentry module failed to separate from the service module and entered into the atmosphere backwards. But when the service module had burned off, the reentry module righted itself (just because of its weight distribution--that's what it was designed to do) and Volynov landed and survived. Those reentry vehicles require no electronics and no flight control. The only thing that needs to happen is that the parachutes open some time before the capsule hits the ground. I think I'd have a bit more confidence in something like a Soyuz reentry vehicle than in the shuttle. And they are probably a lot cheaper, too.
That's not what the cafe standards say; they say that the average MPG should be a certain value. Then, manufacturers adjust the pricing of their different vehicles accordingly: fuel-efficient vehicles become disproportionately cheaper (if they are considered less desirable), while gas guzzlers become disproportionately more expensive. It is market mechanisms at work. Its effect is similar to what Europe is trying to achieve with taxing cars by the size of their motors.
That approach is a lot better than simply imposing a high gasoline tax, which is regressive and hits low income earners hardest. With the cafe standards, low income earners can save twice, by getting fuel-efficient cars more cheaply and saving on gas.
Why don't we (the U.S.A) have a decent rail system like Europe?
That requires long term planning, long term commitments of funds, and concerted action, something the US has become incapable of over the last few decades. Cars and air travel are much easier to subsidize. And even the road infrastructure is falling apart because of lack of upkeep.
You will hear occasionally that this is because the US is so much bigger. That is nonsense. Distances in Europe are comparable to those in the US: Hammerfest to Palermo or Lisbon to Prague are roughly a couple of thousand miles. If the US had maintained an efficient rail system, people would have settled in ways that would have made train travel efficient.
Bush has been talking about hydrogen-based energy as well. Of course, in the case of Bush, it looks more like a strategy to avoid doing anything substantial on the environment in the short term; if Bush really cared about the environment, he'd mandate increases in fuel efficiency and the like.
Yes, I somehow don't understand why "artists" get away with claiming that the music or books they create are not "work for hire", while software development pretty much always is considered that, no matter how innovative it may be. The attitude by many musicians, visual artists, and writers that they are "the creative people", while software professionals are "just engineers" is also kind of annoying. But maybe the solution to that is for software professionals to become more vocal.
Overall, my guess is that there are more people who use Linux regularly and interactively than there are people who use OS X. One reason is that you don't need to have Linux on your desktop in order to use it interactively. And I suspect that there are even people who have desktop machines that run Linux at least some time than there are people who have desktop machines that run OS X.
Also, I doubt that there is a groundswell of people "converting" from Linux to OS X. OS X is a nice consumer OS, but it is no replacement for Linux. Many Linux users who got OS X machines (like myself) probably got them as second machines. And, believe me, that's all OS X is going to remain for me--a nice looking second machine that I occasionally use for the kinds of consumer things and proprietary software that I used to use Windows for.
Why not get one of these and run this? You can get a complete system with power supply and nice case for less than just the C-ONE board alone costs.
Huh? GPE runs on top of Linux, just like the Zaurus. The only difference is the window system.
The high-end Palms with high-end features (MP3, multitasking, cameras, high-resolution screens, etc.) are a horrible combination of hardware and software kludges to get PalmOS to do things that PalmOS was never designed to do. For example, many of those nifty features on the Clie have required Sony to hack their own extensions into PalmOS, and every Palm software vendor needs to accomodate those. And because each vendor hacks PalmOS to their liking, Palm can't even ship a single upgrade from PalmOS 5 to PalmOS 6--you will be able to upgrade your Sony only if Sony spends the time and money to create their own upgrade.
Unfortunately, the Linux PDAs aren't doing much better either. The Zaurus (I own one) is a brick. Several other Linux handheld startups went belly-up. And handhelds.org is fighting a constant battle to reverse engineer handhelds in order to run Linux on them--even handhelds that are developed within Compaq/HP, the company hosting handhelds.org. However, Motorola's use of Linux on their cell phones may give Linux on PDAs a new life.
I hate to say it, but if you are using Windows on your desktop and if you are looking for a high-end handheld, a PocketPC machine probably makes more sense. Even something like the iPaq h1910 ($299) runs rings around more expensive Palm models and is lighter to boot. The big problem with PocketPC is that it is completely proprietary: it pretty much only talks to Windows desktops and the primary development platform for it is Microsoft proprietary. But, then, it isn't clear to me why you would want a high-end handheld to begin with.
Overall, I'd just stick with the Palm Zire, and for the other features (MP3 player, GPS, camera, games, etc.) get separate, dedicated devices.
I do. I was eagerly awaiting an alternative to PS/2 and RS-232c. Apple made USB a modest success in their market niche, and I was glad to see it come to the PC platform. What is wrong with that? And USB has turned out to be great for Linux: USB offers by far the widest selection of devices for Linux that just plug in and work.
Now that it is ubiquitous intel can levy massive royalties. I'm pretty shure intel wants to shove it's usb2 anywhere it can either with convincing or coercive arguments.
So? Apple was trying to charge FireWire royalties. Given that both standards are proprietary, that is not a basis for preferring one over the other.
All things being equal, I would have gone with 1394 as well. However, USB 2.0 is here, and it is cheap and extremely widely supported. There is a large number of "class drivers" for it--standards for how computers can talk to specific kinds of devices, like network adapters, disks, monitors, keyboards, printers, MIDI devices, etc. And there are lots of devices on sale that actually conform to those specifications. And there are even more de-facto standards for USB devices.
1394 and 1394b look pretty bleak in comparison. What I see sitting on the shelves that plugs into 1394 is very limited: disk drives, camcorders, and a few web cams (but you need to buy a special driver for those on the Mac).
1394 and 1394b are niche products now, primarily used for disks and video. I don't see that turning around. It would have been nice if their rollout had been handled differently, but it wasn't.
Yes, that remains the case for now. However, it doesn't have to remain the case forever. The concept of communicating rules and behavior to a computer is not alien to even naive users, it is just that computer scientists haven't come up with a syntax and interaction style that feels comfortable to everybody.