What kinds of tools are out there for taking binary Linux or Windows drivers and turning them into source code?
Of course, a simple assembler/disassembler combo will do and allow simple modifications, but it won't result in anything very readable and would make it hard to adapt a Windows driver to Linux kernel APIs.
Something that goes from binary to structured C code and that has support for program flow analysis and renaming identifiers globally would seem like it would be useful for this sort of thing. Any recommendations?
The situation where one company holds another hostage by claiming infringement without every putting up any evidence is not new. To address it, we have declarative judgements. The Linux community could and should ask for a declarative judgement on SCO's alleged copyright violations. Then, SCO either has to put up the evidence, or the judge will rule against them.
If, on the other hand they say, "your existing license is invalid, here have another." Then they are in the right.
But even if SCO owned bits and pieces of the current Linux kernel, the result would simply be that nobody could redistribute Linux anymore until SCO's pieces are removed. Furthermore, if they ever went to court over license violations, they'd actually have to disclose what parts of the Linux kernel violate their intellectual property, which means that they can be removed. So, that still means SCO can't make a business out of selling licenses to Linux.
You cannot redistribute GPL'ed software if it infringes on anybody's intellectual property. That clause was put there with the intention of preventing SCO-style blackmail. It could be argued that that means that companies that obtain software with the intention of paying a licensing fees already are not covered by the GPL because they believe it infringes on someone's intellectual property.
The clause may not be strong enough to achieve its intended effect, so perhaps it should be revised for the next version of the GPL to something that explicitly states "if you pay anyone a license fee for using this piece of software, you lose your rights to use or redistribute it under the GPL".
Yeah, I guess the OS X zealots really have a thing or two to learn from the open-minded, calm, rational Linux userbase out there. And what better web site than Slashdot to be preaching the virtues of idea-tolerance in the IT industry from? Congratulations on your insightful post.
Just because there are also zealous Linux users doesn't excuse bad moderation by Macintosh zealots. I, for one, have never modded down anybody for having an opinion that disagrees with my own, even those of people who I consider irrationally exhuberant about Windows XP or Macintosh. But every time I post something about my experiences with OS X, and they are my hands-on experiences, it gets modded down.
Also, Apple is a multi-billion dollar company that carefully crafts this illusion of technical superiority and whose PR department has become really good at creating Mac evangelists/zealots. Linux, on the other hand, is a true grass-roots effort.
the heat sinks are so large becasue it allows for a quieter system by dipersing more heat.
That seems like a pretty silly reason, given that Apple's recent G4 towers are quite noisy, while you can get P4 and AMD desktops that are essentially inaudible. And the P4 and AMD machines do not require huge heat sinks to achieve low noise. (I have a G4 tower and an ultra-quiet PC desktop, so this is based on first-hand experience.)
if your assertions about the PPC are based just on the Heat sink, I think you need to reevaluate them with hard data.
I didn't make an assertion, I just said that architecturally, I don't see why the PPC should consume much less power.
But now that I have checked up on it, it seems like the 1.8GHz PPC 970 actually generates 42W of heat, while the 1.8GHz Opteron seems to generate around 40W. And that confirms my suspicion that the PPC is not significantly more efficient than other recent x86 processors.
The PPC instruction set used to result in more energy-efficient architectures than the x86 instruction set for comparable performance many years ago. But today, the instruction set just doesn't seem to make much of a difference anymore.
Good: while that table compares apples and oranges, it contains the data we need. What it tells us is that:
The 1GHz G4e consumes 30W, which is, in fact, more than a comparable 1GHz P3, which comes in at around 20W
The 1.8GHz PPC 970 consumes 42W against the 70W of the P4 2.8GHz, but that difference seems largely accounted for by the fact that the PPC 970 is made with a newer process and runs at a lower voltage.
The 1.8GHz PPC 970 probably consumes more power than a 1.8GHz Opteron, which rates at around 40W.
So, we have to conclude that the idea that PPCs are particularly power efficient is a myth.
Let's look at the Munich news. Yes, Munich is going to be running Windows XP under VMware. What does that tell us? Two things. First, Windows XP is such a costly nightmare to administer as a desktop operating system that Munich prefers running it under Linux and incurring the extra cost of VMware to installing it directly. Second, Microsoft's monopoly, enforced through Office file formats, is alive and well, and there still is a problem to be addressed by antitrust regulators.
Overall, the Munich decision is a stinging indictment of Microsoft Windows on both fronts: cost-of-ownership and monopolistic practices.
As for Paul Thurott, the author of all that bogosity about linux, he is in the business of making money from Microsoft, so you can't expect him to do anything other than badmouth Linux and talk up Windows, no matter what the facts are. Basically, the more Windows sucks, the more books he sells. He is a member of that huge cottage industry that benefits from Microsoft's poor software. The last thing those people want is high-quality, reliable software, free or otherwise, because they'd be out of business.
Have you looked at the heat sinks on G4's recently? They are bigger than on Pentium or AMD. I think it's a myth that the PPC architecture requires less power for comparable performance (but feel free to dig up the numbers).
And what would the reason be for PPC to consume less power? All these chips are RISC machines; the differences in the instruction encoding don't translate into big performance or power differences anymore.
Mac zealots are so predictable: any posting that says OS X is less than spectacular gets modded down. Which brings me to another disadvantage of OS X: the zealots in the user community. Zealotry is one of those things that keeps OS X from improving: after all, if it's already perfect, how could it possibly be improved? The Mac user community is another reason why OS X has little place in an enterprise or in a scientific or engineering environment.
Will the Sony Sound Developer Kit [cliedeveloper.com] suffice for your needs?
No. That's been out for a while, and it is apparently not sufficient to do high quality audio playback, according to the developers of AeroPlayer and Pocket-Tunes. Those APIs apparently are good enough only for simple game sounds.
Given your desire to use AeroPlayer and Pocket-Tunes , you appear to use Palm apps for entertainment. Would that be considered pathetic by your standards?
I'm sorry, but I don't understand the question. Are you asking me whether I consider any kind of portable MP3 player "pathetic"? No, I don't--I see nothing wrong with portable music players.
I do find it rather annoying, however, that I have a nicely designed piece of hardware, a 200MHz ARM machine, that is hamstrung by an operating system that is slow, crashes regularly, can't deal well with different screen sizes, and has lots of undocumented APIs. PalmOS is like DOS used to be: really awful technically, but there are good applications for it, in spite of the OS, not because of it.
The 64bit offerings from AMD look more compelling to me: they give you comparable performance, cost less, and are fully backwards compatible with existing x86 software. You can already buy high-end dual-processor systems, and the desktop versions are going to be out later this year. If you are going to run Linux, they seem like a better choice.
I do wish that non-x86 platforms, like PPC, would become more widely used so that the Penguin's eggs aren't all in one basket, but realistically, I don't see it happening. Linux runs quite well on PPC, but some things just don't work: some compilers and JITs don't have a PPC backend, the AltiVec macros screw up some compilation, etc. But it's nice that IBM is trying; maybe if the get really aggressive on the pricing, they will make some inroads. $3500 for a 4x machine might do it, although AMD will do 4x as well at a reasonable price.
MacOSX already offers a great kernel with an even better GUI, and right now I wouldn't put money on Linux against that for a work desktop.
I bought some Macs and really gave OS X a good try, but finally, I just erased the disks and installed Linux. Why? Graphics on OS X looks slick but it is actually quite slow and its APIs are completely non-standard, package management and software updating is a headache, there was no journaling file system (that's being fixed at least), and the kernel and file system weren't all that fast either. OS X also has worse driver support than Linux, and many facilities (like audio) are only available through cumbersome Carbon APIs rather than UNIX devices. And, frankly, there is a lot more software that I want to run for Linux than for OS X.
OS X is a good consumer operating system, but it still falls short as a workstation operating system and a server operating system. If Apple wants to move OS X in that direction and make it more of an alternative to UNIX workstations, they still have a lot of work ahead of them before they can compete with AIX or Linux. But it's not clear to me that Apple should try to compete there: trying to be everything to everybody is what makes Windows such a mess. Maybe Apple should be satisfied with their market and leave the server and workstation market to AIX, Solaris, and Linux.
If you don't publish your invention in some form, it doesn't count as prior art for the purposes of the patent system; if it did, it would undermine the whole purpose of the patent system, which is to get people to document and publish their inventions.
but I have to defend Sony on a few points here. Sony wrote a lot of extensions to the Palm OS in their API because quite frankly, Palm was dragging its ass.
So? I didn't make any statements that this was Sony's fault. In fact, I find it pretty amazing what Sony has been able to do with what has got to be one of the most poorly designed operating systems around.
So yes, something written using the Palm OS5's (more recent) sound API won't work on an older OS4 Clie. [...] Sony's newer Clies actually do run OS5 and do obey the new Palm APIs
You don't know what you are talking about: the Palm OS 5 Clies do not support the standard Palm sound APIs.
Finally, the Sony APIs are documented. They're available with their freely downloadable SDK, along with PDF docs, Clie simulators, emulators, etc.
Again, you don't know what you are talking about. Check AeroPlayer or Pocket-Tunes; they don't work on OS5 Clies and their developers can't get them to work because Sony isn't publishing the API.
But, hey, if you can prove me wrong by posting a pointer to Sony's audio API documentation for OS5 (note that they have some documentation for some audio API on their site, but that's not what goes with their OS5 Clies; I think that's for their OS4 stuff, which is yet different), then I, as well as the developers of AeroPlayer and Pocket-Tunes would be really happy.
Their different ratio screens haven't been a backwards compatibility problem for most things, as the extra space was usually used as a software silkscreen input area.
That is precisely the problem: a decent window system would let applications take advantage of more screen space. A regular PalmOS app running on a 320x480 device will get rescaled from 160x160 to 320x320, looking very blocky, and not use 160x320 pixels. Short of displaying nothing at all, it's hard to imagine how any window system could support larger screens any worse than PalmOS does.
According to the normal timetable, Flash 7 should be released before the year is out and that seems to be your primary competitor. Unfortunately it also offers video, sound, raster graphics, and a good lead on a decent OO scripting langage. Oh wait, that's Flash 6.
Well, there you have one problem with Flash: a new version every year. And that's not a coincidence: it's the way the format can appear to be open yet ends up being proprietary for practical purposes.
Is there something new you're offering (other than a different set of lawyers) that we should be noticing?
I don't know whether dSVG is the answer, but I do know that Flash isn't: the fact that it's a binary format alone makes it uninteresting.
Proprietary processor though... Hmmm... that might be a red flag.
Well, the weird part isn't the ARM core, it's the undocumented and proprietary audio I/O, DSP, memory architecture and other devices that Sony puts into these devices. You can't even access those through the proprietary OS that runs on these machines.
However, this thing has a bigger screen, and it sounds like the sony may have much better battery life.
The Sharp actually seems like a nicer handheld and the Sharp screen has double the number of pixels. However, the better battery life and built-in BT and WiFi make the Sony a winner.
Also, the PDA software on the Sharp just isn't competitive: the Palm PDA apps are far better than the Sharp, and Bluetooth configuration on the Sharp is a nightmare. Furthermore, in a twist of irony, you can develop commercial apps for the Sony for free, using all free tools, while you need to pay a lot of money to develop commercial Qt/Embedded apps.
This thing fits in your pocket and has excellent battery life; neither of those is true for even the smallest laptops (which Sony also makes). And small laptops are actually quite expensive, usually upwards of $2000.
The process may be broken, but not as badly as you'd think from all the postings you see around here.
The process is, however, very badly broken from the perspective of the people actually having to spend enormous amounts of money on filing the patents in order to make their patent portfolio sufficiently thick for trading, or getting sued over bogus patents on decades old technology. And plenty of people on Slashdot have been in either or both situations (myself included). For that, it doesn't take "armchair lawyering", or any kind of legal opinion at all, the drain on one's bank account is obvious enough.
The whole thing is a complete racket that has nothing to do with innovation anymore and everything with big companies keeping little companies out of the market, while patent laywers are making a pretty penny.
Well, then, if his work in the 1980s counts as published prior art for the Pinpoint patent, then they also invalidate his own patents from 1998 and 1999.
In any case, collaborative filtering goes back a long way; I doubt any of these patents are valid, and it doesn't take Robinson's work to invalidate them.
The Clies are nifty hardware, but their software is getting weirder and weirder. Nominally, they run PalmOS, but the user interface is quite different and the Clies ship with a lot of applications that won't run on any other Palm.
Furthermore, some important Palm functions, like anything using audio, won't work on the Clies because Sony has created their own undocumented and proprietary APIs. Memory on these devices is also getting really strange, with 16M of RAM, 16M of more RAM that is somehow not quite as accessible, and 29M of built-in flash memory, plus some other RAM somewhere else for some other purpose.
Furthermore, Palm applications in general often don't scale well to high resolution or non-square screens, meaning that primarily applications designed for 320x480 landscape mode on these Clies will work well on them, while regular Palm applications will often just be scaled-up 160x160 windows.
I guess the best way to look at Clies is as consumer gadgets, not hardware running an operating system: you get the software that comes with them. Some additional Palm software may work on them, but perhaps not all that well.
I wish Sony would just put Palm out of their misery and buy them. They could then do something sensible like put PalmOS on top of a decent kernel, like Linux, QNX, or Symbian, while keeping the existing applications; those kernels could do as good a job at running existing Palm applications as PalmOS 5 does, and they don't suffer from the same memory management or driver stupidity as PalmOS. They would also make PalmOS a much more credible platform for enterprise apps. And, unlike PalmOS 6, they are here right now, they are debugged, they are mature, and they are efficient.
$30 Million for a recall election, vs. keeping a governor that gave us a $30 billion+ defecit and show no promise of doing any better. $30 million sounds like a deal to me.
It is idiotic to hold Davis responsible for California's current economic troubles; do you seriously believe that the $30b deficit is Davis's fault and that someone else could have avoided it? A Republican governor at that, when Republicans traditionally love to increase spending and lower taxes at the same time? And even if Davis were responsible, what could another governor change in the little time gained between the recall election and the regular election?
Of course, what is really responsible for California's ills is in part its pseudo-democracy, the same nonsense that has led to this recall. One of the biggest examples of that is Prop. 13. Also responsible is political gridlock, which leaves California (and many other states) with a completely antiquated and irrational system of taxation and financing of public services. And a new governor won't be able to do anything more about it than the old one.
Californians have been greedy and they have believed in the tooth fairy: they want public services without being willing to pay for them. After a few decades of this, it's finally catching up with the state in a bad way. And no governor will be able to fix it. It will probably get a lot worse before voters figure it out and vote for real change. Let's start by getting rid of the proposition and recall procedures.
In some cases, a proprietary tool is the best for the job.
Yes, but only temporarily. Eventually, every piece of proprietary software will get cloned and replaced by an open source equivalent--it's just basic economics.
The most popular free software source management tool (CVS) is a complete p-o-s in many respects and unsuitable for large projects and for those with automated builds.
That's just not true. Maybe the Linux kernel has special requirements (huge numbers of merges, E-mail management, etc.), but CVS has proven itself time and again suitable for huge projects. And lots of projects use automated builds with CVS--it's standard practice.
Add to that the fact that our network is designed and optimized for ground level users, and you're looking at a crappy call, assuming you can even orginate one.
If most of the time, people either get lousy quality or can't call at all, then there would be no reason to have regulations prohibiting the use of cell phones for the benefit of the cellular companies: people would quickly stop trying all by themselves.
That means that either cell phones work from airplanes and the cellular carries just don't like it, or that they really do interfere with flight equipment.
Slashdot Mirror
What kinds of tools are out there for taking binary Linux or Windows drivers and turning them into source code?
Of course, a simple assembler/disassembler combo will do and allow simple modifications, but it won't result in anything very readable and would make it hard to adapt a Windows driver to Linux kernel APIs.
Something that goes from binary to structured C code and that has support for program flow analysis and renaming identifiers globally would seem like it would be useful for this sort of thing. Any recommendations?
The situation where one company holds another hostage by claiming infringement without every putting up any evidence is not new. To address it, we have declarative judgements. The Linux community could and should ask for a declarative judgement on SCO's alleged copyright violations. Then, SCO either has to put up the evidence, or the judge will rule against them.
If, on the other hand they say, "your existing license is invalid, here have another." Then they are in the right.
But even if SCO owned bits and pieces of the current Linux kernel, the result would simply be that nobody could redistribute Linux anymore until SCO's pieces are removed. Furthermore, if they ever went to court over license violations, they'd actually have to disclose what parts of the Linux kernel violate their intellectual property, which means that they can be removed. So, that still means SCO can't make a business out of selling licenses to Linux.
You cannot redistribute GPL'ed software if it infringes on anybody's intellectual property. That clause was put there with the intention of preventing SCO-style blackmail. It could be argued that that means that companies that obtain software with the intention of paying a licensing fees already are not covered by the GPL because they believe it infringes on someone's intellectual property.
The clause may not be strong enough to achieve its intended effect, so perhaps it should be revised for the next version of the GPL to something that explicitly states "if you pay anyone a license fee for using this piece of software, you lose your rights to use or redistribute it under the GPL".
Yeah, I guess the OS X zealots really have a thing or two to learn from the open-minded, calm, rational Linux userbase out there. And what better web site than Slashdot to be preaching the virtues of idea-tolerance in the IT industry from? Congratulations on your insightful post.
Just because there are also zealous Linux users doesn't excuse bad moderation by Macintosh zealots. I, for one, have never modded down anybody for having an opinion that disagrees with my own, even those of people who I consider irrationally exhuberant about Windows XP or Macintosh. But every time I post something about my experiences with OS X, and they are my hands-on experiences, it gets modded down.
Also, Apple is a multi-billion dollar company that carefully crafts this illusion of technical superiority and whose PR department has become really good at creating Mac evangelists/zealots. Linux, on the other hand, is a true grass-roots effort.
the heat sinks are so large becasue it allows for a quieter system by dipersing more heat.
That seems like a pretty silly reason, given that Apple's recent G4 towers are quite noisy, while you can get P4 and AMD desktops that are essentially inaudible. And the P4 and AMD machines do not require huge heat sinks to achieve low noise. (I have a G4 tower and an ultra-quiet PC desktop, so this is based on first-hand experience.)
if your assertions about the PPC are based just on the Heat sink, I think you need to reevaluate them with hard data.
I didn't make an assertion, I just said that architecturally, I don't see why the PPC should consume much less power.
But now that I have checked up on it, it seems like the 1.8GHz PPC 970 actually generates 42W of heat, while the 1.8GHz Opteron seems to generate around 40W. And that confirms my suspicion that the PPC is not significantly more efficient than other recent x86 processors.
The PPC instruction set used to result in more energy-efficient architectures than the x86 instruction set for comparable performance many years ago. But today, the instruction set just doesn't seem to make much of a difference anymore.
Good: while that table compares apples and oranges, it contains the data we need. What it tells us is that:
So, we have to conclude that the idea that PPCs are particularly power efficient is a myth.
Let's look at the Munich news. Yes, Munich is going to be running Windows XP under VMware. What does that tell us? Two things. First, Windows XP is such a costly nightmare to administer as a desktop operating system that Munich prefers running it under Linux and incurring the extra cost of VMware to installing it directly. Second, Microsoft's monopoly, enforced through Office file formats, is alive and well, and there still is a problem to be addressed by antitrust regulators.
Overall, the Munich decision is a stinging indictment of Microsoft Windows on both fronts: cost-of-ownership and monopolistic practices.
As for Paul Thurott, the author of all that bogosity about linux, he is in the business of making money from Microsoft, so you can't expect him to do anything other than badmouth Linux and talk up Windows, no matter what the facts are. Basically, the more Windows sucks, the more books he sells. He is a member of that huge cottage industry that benefits from Microsoft's poor software. The last thing those people want is high-quality, reliable software, free or otherwise, because they'd be out of business.
Have you looked at the heat sinks on G4's recently? They are bigger than on Pentium or AMD. I think it's a myth that the PPC architecture requires less power for comparable performance (but feel free to dig up the numbers).
And what would the reason be for PPC to consume less power? All these chips are RISC machines; the differences in the instruction encoding don't translate into big performance or power differences anymore.
Mac zealots are so predictable: any posting that says OS X is less than spectacular gets modded down. Which brings me to another disadvantage of OS X: the zealots in the user community. Zealotry is one of those things that keeps OS X from improving: after all, if it's already perfect, how could it possibly be improved? The Mac user community is another reason why OS X has little place in an enterprise or in a scientific or engineering environment.
Will the Sony Sound Developer Kit [cliedeveloper.com] suffice for your needs?
No. That's been out for a while, and it is apparently not sufficient to do high quality audio playback, according to the developers of AeroPlayer and Pocket-Tunes. Those APIs apparently are good enough only for simple game sounds.
Given your desire to use AeroPlayer and Pocket-Tunes , you appear to use Palm apps for entertainment. Would that be considered pathetic by your standards?
I'm sorry, but I don't understand the question. Are you asking me whether I consider any kind of portable MP3 player "pathetic"? No, I don't--I see nothing wrong with portable music players.
I do find it rather annoying, however, that I have a nicely designed piece of hardware, a 200MHz ARM machine, that is hamstrung by an operating system that is slow, crashes regularly, can't deal well with different screen sizes, and has lots of undocumented APIs. PalmOS is like DOS used to be: really awful technically, but there are good applications for it, in spite of the OS, not because of it.
The 64bit offerings from AMD look more compelling to me: they give you comparable performance, cost less, and are fully backwards compatible with existing x86 software. You can already buy high-end dual-processor systems, and the desktop versions are going to be out later this year. If you are going to run Linux, they seem like a better choice.
I do wish that non-x86 platforms, like PPC, would become more widely used so that the Penguin's eggs aren't all in one basket, but realistically, I don't see it happening. Linux runs quite well on PPC, but some things just don't work: some compilers and JITs don't have a PPC backend, the AltiVec macros screw up some compilation, etc. But it's nice that IBM is trying; maybe if the get really aggressive on the pricing, they will make some inroads. $3500 for a 4x machine might do it, although AMD will do 4x as well at a reasonable price.
MacOSX already offers a great kernel with an even better GUI, and right now I wouldn't put money on Linux against that for a work desktop.
I bought some Macs and really gave OS X a good try, but finally, I just erased the disks and installed Linux. Why? Graphics on OS X looks slick but it is actually quite slow and its APIs are completely non-standard, package management and software updating is a headache, there was no journaling file system (that's being fixed at least), and the kernel and file system weren't all that fast either. OS X also has worse driver support than Linux, and many facilities (like audio) are only available through cumbersome Carbon APIs rather than UNIX devices. And, frankly, there is a lot more software that I want to run for Linux than for OS X.
OS X is a good consumer operating system, but it still falls short as a workstation operating system and a server operating system. If Apple wants to move OS X in that direction and make it more of an alternative to UNIX workstations, they still have a lot of work ahead of them before they can compete with AIX or Linux. But it's not clear to me that Apple should try to compete there: trying to be everything to everybody is what makes Windows such a mess. Maybe Apple should be satisfied with their market and leave the server and workstation market to AIX, Solaris, and Linux.
If you don't publish your invention in some form, it doesn't count as prior art for the purposes of the patent system; if it did, it would undermine the whole purpose of the patent system, which is to get people to document and publish their inventions.
but I have to defend Sony on a few points here. Sony wrote a lot of extensions to the Palm OS in their API because quite frankly, Palm was dragging its ass.
So? I didn't make any statements that this was Sony's fault. In fact, I find it pretty amazing what Sony has been able to do with what has got to be one of the most poorly designed operating systems around.
So yes, something written using the Palm OS5's (more recent) sound API won't work on an older OS4 Clie. [...] Sony's newer Clies actually do run OS5 and do obey the new Palm APIs
You don't know what you are talking about: the Palm OS 5 Clies do not support the standard Palm sound APIs.
Finally, the Sony APIs are documented. They're available with their freely downloadable SDK, along with PDF docs, Clie simulators, emulators, etc.
Again, you don't know what you are talking about. Check AeroPlayer or Pocket-Tunes; they don't work on OS5 Clies and their developers can't get them to work because Sony isn't publishing the API.
But, hey, if you can prove me wrong by posting a pointer to Sony's audio API documentation for OS5 (note that they have some documentation for some audio API on their site, but that's not what goes with their OS5 Clies; I think that's for their OS4 stuff, which is yet different), then I, as well as the developers of AeroPlayer and Pocket-Tunes would be really happy.
Their different ratio screens haven't been a backwards compatibility problem for most things, as the extra space was usually used as a software silkscreen input area.
That is precisely the problem: a decent window system would let applications take advantage of more screen space. A regular PalmOS app running on a 320x480 device will get rescaled from 160x160 to 320x320, looking very blocky, and not use 160x320 pixels. Short of displaying nothing at all, it's hard to imagine how any window system could support larger screens any worse than PalmOS does.
I develop Palm apps for a living.
What a depressing thought.
According to the normal timetable, Flash 7 should be released before the year is out and that seems to be your primary competitor. Unfortunately it also offers video, sound, raster graphics, and a good lead on a decent OO scripting langage. Oh wait, that's Flash 6.
Well, there you have one problem with Flash: a new version every year. And that's not a coincidence: it's the way the format can appear to be open yet ends up being proprietary for practical purposes.
Is there something new you're offering (other than a different set of lawyers) that we should be noticing?
I don't know whether dSVG is the answer, but I do know that Flash isn't: the fact that it's a binary format alone makes it uninteresting.
Proprietary processor though... Hmmm... that might be a red flag.
Well, the weird part isn't the ARM core, it's the undocumented and proprietary audio I/O, DSP, memory architecture and other devices that Sony puts into these devices. You can't even access those through the proprietary OS that runs on these machines.
However, this thing has a bigger screen, and it sounds like the sony may have much better battery life.
The Sharp actually seems like a nicer handheld and the Sharp screen has double the number of pixels. However, the better battery life and built-in BT and WiFi make the Sony a winner.
Also, the PDA software on the Sharp just isn't competitive: the Palm PDA apps are far better than the Sharp, and Bluetooth configuration on the Sharp is a nightmare. Furthermore, in a twist of irony, you can develop commercial apps for the Sony for free, using all free tools, while you need to pay a lot of money to develop commercial Qt/Embedded apps.
This thing fits in your pocket and has excellent battery life; neither of those is true for even the smallest laptops (which Sony also makes). And small laptops are actually quite expensive, usually upwards of $2000.
The process may be broken, but not as badly as you'd think from all the postings you see around here.
The process is, however, very badly broken from the perspective of the people actually having to spend enormous amounts of money on filing the patents in order to make their patent portfolio sufficiently thick for trading, or getting sued over bogus patents on decades old technology. And plenty of people on Slashdot have been in either or both situations (myself included). For that, it doesn't take "armchair lawyering", or any kind of legal opinion at all, the drain on one's bank account is obvious enough.
The whole thing is a complete racket that has nothing to do with innovation anymore and everything with big companies keeping little companies out of the market, while patent laywers are making a pretty penny.
Well, then, if his work in the 1980s counts as published prior art for the Pinpoint patent, then they also invalidate his own patents from 1998 and 1999.
In any case, collaborative filtering goes back a long way; I doubt any of these patents are valid, and it doesn't take Robinson's work to invalidate them.
The Clies are nifty hardware, but their software is getting weirder and weirder. Nominally, they run PalmOS, but the user interface is quite different and the Clies ship with a lot of applications that won't run on any other Palm.
Furthermore, some important Palm functions, like anything using audio, won't work on the Clies because Sony has created their own undocumented and proprietary APIs. Memory on these devices is also getting really strange, with 16M of RAM, 16M of more RAM that is somehow not quite as accessible, and 29M of built-in flash memory, plus some other RAM somewhere else for some other purpose.
Furthermore, Palm applications in general often don't scale well to high resolution or non-square screens, meaning that primarily applications designed for 320x480 landscape mode on these Clies will work well on them, while regular Palm applications will often just be scaled-up 160x160 windows.
I guess the best way to look at Clies is as consumer gadgets, not hardware running an operating system: you get the software that comes with them. Some additional Palm software may work on them, but perhaps not all that well.
I wish Sony would just put Palm out of their misery and buy them. They could then do something sensible like put PalmOS on top of a decent kernel, like Linux, QNX, or Symbian, while keeping the existing applications; those kernels could do as good a job at running existing Palm applications as PalmOS 5 does, and they don't suffer from the same memory management or driver stupidity as PalmOS. They would also make PalmOS a much more credible platform for enterprise apps. And, unlike PalmOS 6, they are here right now, they are debugged, they are mature, and they are efficient.
$30 Million for a recall election, vs. keeping a governor that gave us a $30 billion+ defecit and show no promise of doing any better. $30 million sounds like a deal to me.
It is idiotic to hold Davis responsible for California's current economic troubles; do you seriously believe that the $30b deficit is Davis's fault and that someone else could have avoided it? A Republican governor at that, when Republicans traditionally love to increase spending and lower taxes at the same time? And even if Davis were responsible, what could another governor change in the little time gained between the recall election and the regular election?
Of course, what is really responsible for California's ills is in part its pseudo-democracy, the same nonsense that has led to this recall. One of the biggest examples of that is Prop. 13. Also responsible is political gridlock, which leaves California (and many other states) with a completely antiquated and irrational system of taxation and financing of public services. And a new governor won't be able to do anything more about it than the old one.
Californians have been greedy and they have believed in the tooth fairy: they want public services without being willing to pay for them. After a few decades of this, it's finally catching up with the state in a bad way. And no governor will be able to fix it. It will probably get a lot worse before voters figure it out and vote for real change. Let's start by getting rid of the proposition and recall procedures.
Sorry, man, but CVS doesn't have atomic checkins a la changelists in Perforce
So what? That may matter in some projects (Linux kernel?), and it doesn't matter in many others.
Perhaps Subversion solves this
It does. It could also be added to CVS, but so far, nobody has felt strongly enough about it to do the work.
In some cases, a proprietary tool is the best for the job.
Yes, but only temporarily. Eventually, every piece of proprietary software will get cloned and replaced by an open source equivalent--it's just basic economics.
The most popular free software source management tool (CVS) is a complete p-o-s in many respects and unsuitable for large projects and for those with automated builds.
That's just not true. Maybe the Linux kernel has special requirements (huge numbers of merges, E-mail management, etc.), but CVS has proven itself time and again suitable for huge projects. And lots of projects use automated builds with CVS--it's standard practice.
Add to that the fact that our network is designed and optimized for ground level users, and you're looking at a crappy call, assuming you can even orginate one.
If most of the time, people either get lousy quality or can't call at all, then there would be no reason to have regulations prohibiting the use of cell phones for the benefit of the cellular companies: people would quickly stop trying all by themselves.
That means that either cell phones work from airplanes and the cellular carries just don't like it, or that they really do interfere with flight equipment.