Putting individuals into concentration camps would be murder and genocide. That's wrong.
Yes, just as the kind of moral calculus you are engaging in is wrong. It is not OK for a society to let people rot just because they have made mistakes or just because they are stupid. You may think it is, but fortunately, most people disagree.
Spend whatever it takes to inform and educate people - at schools, via the media, via outreach programs - do whatever it takes so that we can say with 100% certainity that every American of sexual age knows that unprotected sex can lead to HIV. Let every American know that consuming thousands of empty calories on junk food can lead to obesity and premature death. Give them the information, and let them live with their choices.
Yes, if everybody were just as perfect, well-informed, and logical as you. But in the real world, people don't operate that way: people behave erratically, have personal crises, and make mistakes. They believe that if they rape a virgin, they will get cured of AIDS. They believe that they can't get it from doing it just once. They think that only homosexuals get it. They really love their boy/girlfriend and trust them only to find out s/he has been cheating.
A large chunk of AIDS funding goes to education, but it's hard to inform people, and it's harder to get them to trust and believe the message.
I agree we do not spend enough on research. But no matter what the number there still is a finite point where we must choose. Just because it is far away doesn't mean we shouldn't think about the answer.
You can think about the answer all you want; it is your concrete arguments about current AIDS research spending where I draw the line.
If you exclude the prison population (prison rape is a serious issue which does need to be addressed, but just not in the same way as the general population) there are not 10,000 HIV infections from rape each year.
If you only include reported, documented, white, middle class, suburban rapes by high school football players, you are right, there are not 10000 HIV infections from "rape" each year. If you look at worldwide rape victims, there are many times that.
But do not get distracted by the fact that we are trying to cure a viral disease. Remember that medicine so far has virtually no useful "across the board" treatments for viral infections.
This is exactly why your arguments about AIDS spending are so bogus: AIDS research is basic research, and its results are going to be important for many infectious diseases. AIDS is simply a useful and fashionable label for a lot of research that would happen under another label if something else were fashionable.
Society constantly spending money, dedicating medical resources, and throwing goodwill on a problem that shouldn't be a problem is very wasteful. More than that, it's immoral. It depreives others who are in dire need of those resources.
We have already established that we are very far from having reached the limits of our resources. The tradeoff is not between helping two groups of needy people, the tradeoff is between driving a slightly bigger SUV and helping people in need.
Here is my suggestion to you: why don't you spend some time working for an AIDS hotline? You seem to think that all it takes is to tell people the facts--what better way than to volunteer? I think you will find that your "simple" answers don't quite work out in the real world.
Piles isn't going to make MacOS X (or Windows) any easier to use. While die-hard Macintosh users, who may know all the obscure combinations of Shift, Command, and mouse clicks, may be wowed by such gee-whiz features, regular users are already stymied by concepts like "open" and "closed" folders. Adding yet another kind of "collection of documents" will lead to more confusion and more support calls. (Incidentally, Apple also didn't invent the idea--piles have been in scanning and document management software for Windows for years.)
It sounds cold but we MUST answer the question. Especially when we have finite resources..
That argument doesn't hold water because we have not even come anywhere near reaching the limit of our "finite resources". Our tax rates are among the lowest in the industrialized world, so the tradeoff isn't between spending and additional $1 billion on heart disease or spending an additional $1 billion on AIDS, the tradeoff is between spending an additional $1 billion on AIDS vs. buying (on average) an Espresso for every American. The reason why we aren't spending more on research is because the American voter wants money to buy SUVs, gargantuan homes, and lots of other trinkets.
Furthermore, we spend almost twice as much per capita on health care ($4500) than other modern nations with medical outcomes that are no better; if we can afford to waste $600 billion in medical spending per year without bothering to fix it, arguments that a billion or two are too much to spend on a disease that affects millions of Americans seem silly.
But your whole premise is wrong anyway: diseases aren't compartementalized, and $1 of spending on a disease doesn't get you $1 of cure for that disease. AIDS simply happens to be the "hot disease" for research right now: it has public exposure, it touches many interesting areas of medicine, it is just within the reach of current biology and medicine, and it comes with a ready supply of volunteer patients. I think it's unlikely we will ever find a cure for AIDS, but I also think that AIDS is one of the best areas to finance if we are interested in advancing the state of medicine.
For example, people who climb Mount McKinley in Alaska. How much money should be spent to rescue these people when they inevitably get trapped/in serious trouble? $1Million? $10Million? $100Million? Seriously. How much should society spend to protect a determined individual from killing themselves?
I guarantee you, the money that is being spent on such rescues is already many times more than we spend on AIDS research per infected American. So, why don't you pick that as your first battle, as opposed to picking on AIDS research?
If every HIV+ person was sufficently stigmatized that they decided against unsafe sex HIV/AIDs would die off in a generation, and millions if not billions of lives would be saved.
By your reasoning, why not put HIV-infected individuals into concentration camps and gas them? The disease would be gone instantly. You see, once you start that kind of approach to organizing societies, you are pretty much on a one-way street to totalitarianism and death camps. The US and Europe, rightly, criticized China and Cuba sharply for trying to ostracize HIV-positive individuals.
There is no way to justify spending anything on a disease that is obtained only (except those few tiny rare cases, literally probably under 100 a year) through frivulous behavior.
You are so out of touch with human realities. Rape alone accounts for many orders of magnitude more HIV infections than that.
Tonny Yu, founder and CEO of Mailshell, says that any new and better replacement for SMTP would have to have some sort of certification system to guarantee that senders are who they say they are. The obvious candidates would be certificate services like Verisign,
Yes, just like what Verisign would want: $100/year from anybody who wants to send or receive mail. Thanks, but I'll stick with unauthenticated mail and spam.
If that's the sort of thing you want, you can already run SMTP over SSL--you don't need a new protocol for that. Operating systems terminally incapable of building services out of modular building blocks can hard-code SSL into their mail servers. Reasonable operating systems can use something like stunnel for wrapping SMTP. Either way, you get authentication. There doesn't even need to be any complex interaction between the SSL authentication and the SMTP server because SSL can simply verify the identity of the connecting host, and SMTP can continue to use its regular host-based identification.
The other important requirement, according to Yu, is a system for tracking resource usage per sender. Basically this means that profiles should be established for normal amounts of mail sending from different types of users. If you limited normal users to 100 messages per second and major companies to 10,000 messages a second it would be hard for legitimate users to complain, but spamming would be much harder.
We don't need a new protocol for this. Per-user throttling of outgoing SMTP connections could be implemented by ISPs at the TCP level, and per-user throttling of incoming SMTP connections can be implemented by the SMTP server. The reason why this isn't done is because it's largely ineffective: many spammers are beyond such controls for outgoing connections anyway, and limits on incoming connections can be circumvented simply by posing as hundreds of different users.
Solutions to the spam problem are things like CAPTCHAs, intelligent text analysis, and communications pattern analysis. Restrictions on who can send what to whom at the ISP level, or the imposition of authentication fees by ISPs or companies like Verisign, however, are thinly disguised attempts at squeezing money out of users. In addition to being ineffective and increasing the cost of E-mail, they also just threaten the openness of the Internet that has made it so successful in the first place.
What needs to be stored in battery backed RAM is not "small files", it is "frequently accessed data". And for that, you don't need a new file system, you merely need to add a persistent cache to the existing file system.
You have two ways of doing that: either put the logic for that sort of caching into the disk driver, or put battery backed RAM into the disk drive or controller itself. I think both have been explored in the past.
But, as I write this, $US5,000 will buy you more than five terabytes worth of 120Gb 7200RPM commodity ATA drives. They're a lot slower, of course, but 250 times as much storage as a probably-unrealistically-cheap-SSD makes up for a lot.
No, they are not, because you can use them all in parallel. That means, 50 parallel seeks, 50 parallel transfers, etc. Latency remains as for a single drive, but lots of other things are really fast.
Palm cares. That's why they are doing a big rewrite for PalmOS 6.
What argument? I was countering your claim that PalmOS tied you to a single vendor.
PalmOS comes from a single vendor only.
It has a larger memory footprint than PalmOS. It requires far more CPU cycles. It will reduce battery life. It will kill off the low-end $99 machines. And it does not answer a significant need.
What is it intrinsically about Windows that makes it "no good for this sort of thing"? Windows provides all the system services you need to do these tasks, and all the tools you mention are available natively for Windows.
So, you are saying that you have never actually run large scale computational experiments, and you don't actually have any recommendations for how to run them on Windows, but based on a list of Windows "system services" you think it should be pretty good for that.
Well, I have run large scale computational experiments on Windows, UNIX, and other platforms. Based on my experience, my recommendation was and is: if you can, do them on UNIX because it's so much easier. If you have to use Windows, stick to relational databases, because that's how large amounts of data are handled on Windows.
Now, if you have anything technical to contribute, please do.
The review for the Agenda VR is entirely accurate. However, the the Palms available at the time were slower, less responsive, and crashed more.
That is simply incorrect. I have never tried to start an app on an Palm and had it take around a minute for [my] other application to start up or register [my] input as the review stated.
That's because the Palm Pilots we had at the time weren't even capable of starting up multiple applications at the same time.
Again, the Agenda VR UI was not as mature as the Palm UI at the time--after all, it was little more than a beta release. That meant people could do stupid things with it, like start up too many applications. But its applications ran fine, and about as fast as Palm apps.
I have applications on my current Handspring Visor that I originally used on a Palm Pilot Professional (512K RAM).
Yup, and they will work exactly like they did on that machine, in all their 160x160 pixelated glory, knowing nothing about flash memory or anything else that has happened since then.
We all know that you can take any Linux binary and put it on any Linux system and it will work just fine.
Yes, we do all know that: the Linux kernel API has been exceptionally stable.
But you keep missing the point: it's not about binary backwards compatibility, which any idiot can achieve with enough determination (Microsoft managed to do it even for DOS), it's about designing kernels and software systems that scale up and are future-proof.
Tied to a single vendor?
To a single OS vendor.
I can get PalmOS PDAs from Palm, Handspring, and Sony. I can get cell phones from Samsung and Kyocera that incorporate a PalmOS-based PDA.
Yes, the same argument has been made for DOS, and Windows, IBM, and MacDonald's food. But just because something has managed to take over a market doesn't mean it's technically good. Quite to the contrary: technically inferior designs often win in the market for well-understood reasons.
So, you admit that the original OS was suitable for the market at which it was aimed? If so, we've made some progress.
Of course, the OS was "suitable" for its original market and purpose--I never disputed that. But there are many ways of writing a "suitable" OS for even the 128k Palm, and Palm picked one of the technically worst ways, a way that requires them to do a major rewrite of the OS and applications to port it to ARM.
The problem with PalmOS is not its (lack of) suitability to the hardware it was originally designed from, the problem with PalmOS was that it was written without any sense of future hardware or future needs in mind.
I admit that their latest offerings are not very attractive from a price/features standpoint
Actually, I think that the $80 Zire is a good offering: small, light, and inexpensive, and it runs an OS designed for that kind of hardware. The design mistakes in the OS don't matter because that hardware is close to what the OS was designed for.
but Sony's PalmOS handhelds (I love rubbing that in)
Yes, you like to bask in the glory of your limited understanding; I'm way ahead of you.Of course, Sony is a PalmOS licensee (I have a Sony handheld as well). But they are still eating Palm's lunch. Perhaps you have missed that Palm and PalmSource are different companies. Perhaps you don't quite understand that Sony can do what they do by shipping a different OS from PalmIS (that is, the take the PalmOS source and hack it up), and by adding all sorts of non-PalmOS embedded chips and software around PalmOS.
are looking quite attractive.
You mean "big power-hungry bricks"? Sony stands for everyting Palm proponents claim they didn't want in a handheld. The iPaq series looks a whole lot nicer to me, and they are cheaper to boot.
Yeah, it was real nice. Just look at an excerpt from this review of the Agenda [uni-potsdam.de]: There. Now you see how well Linux works on a PDA.
The review for the Agenda VR is entirely accurate. However, the the Palms available at the time were slower, less responsive, and crashed more.
You see, unlike you, I have actually used the various systems. All of the handhelds are compromises. Functionally, the Linux-based ones are about as bad or good as the alternatives. The difference is that they don't require software rewrites every few years and don't tie you to a single vendors.
At this point in time, over 99% of all American AIDS/HIV cases are contracted from unsafe sex or intravenous drug use. That's the bottom line.
Assuming your statistics are correct, what is your point? That people who make one mistake, or even whose entire life is completely screwed up, "deserve" getting AIDS?
Sure, that is one way of thinking. It's a way of thinking as old as human-kind. Two thousand years ago, the story of Mary Magdalen was about that. It's a view, however, that lacks compassion and humanity.
The kind of utilitarian calculus of responsibility you engage in is chillingly cold and inhumane: "how much is this life worth, how much did this person know, what percentage of responsibility should he/she accept"? That's the kind of thinking that leads to death camps.
And, even in a purely utilitarian sense, before you know it, it may end up being applied to you. I mean, assuming you drive a car to work, why should I pay for your risky choice of mode of transportation? If you eat meat or drink sodas, why should I pay for your risky nutritional preferences?
how far should government go to protect these people from themselves?
Who said anything about "protecting people from themselves"? Several hundred thousand people in the US are sick and dying from HIV/AIDS, and we should help them with compassion and humanity. One way we help the sick in modern societies is through medical research. The annual cost to you and me is about the same as a couple of Espressos at Starbucks. Sure, these people may be fully responsible for what they did, but you don't even have that much compassion for them in you?
Merely having those system calls doesn't consume extra power. Using them may or may not.
In terms of responsiveness, I'm sorry, but the argument that POSIX I/O makes systems unresponsive is just silly: not only could you use threads, you can use timeouts, check for available data, or use asynchronous I/O. That is as opposed to the Palm, where the machine becomes catatonic during long operations.
In any case, look at where Palm is now: an emulated CPU and multithreaded OS, together with a big backwards compatibility hassle on their hands. Do you really want to make an argument that PalmOS5 is better for handhelds in terms of battery life, memory footprint, or responsiveness than a decent embedded kernel? I just don't think so.
Managing and organizing really huge amounts of data is one of the big strengths of UNIX--you just have to learn how to use it well:
Consider using "make" or "mk" for automating complex processing steps. "make" also lets you parallelize complex experiments (by figuring out which jobs can be run safely in parallel), and some versions of "make" are capable of dealing with compute clusters. If you need to try something with multiple parameter values, write make rules and put the parameter values in there as dependencies.
Organize your data into directory hierarchies; pick meaningful and self-explanatory names. Don't let directories become too big. Keep related data files and results together in the same directory, and keep different data files in different directories.
Keep scripts and programs along with the data, not in completely separate source trees.
Write scripts that summarize the data and give them obvious names; you can figure out later from that what needs looking at and what it means.
Use textual data files as much as possible and have your programs add information to those files as comments that document what they did.
If you generated important result, keep a snapshot of the sources that generated it along with it.
Leave copious README files everywhere, containing notes to yourself, so that you can figure out what you did.
If you generate junk during some trial runs, delete it, or at least rename it to something like "results.junk", otherwise you'll trip over it later.
Back things up.
Learn the core UNIX command line tools, tools like "sort", "uniq", "awk", "cut", "paste", "find", "xargs", etc.; they are really powerful. You probably also want to learn Perl, but don't get into the habit of trying to do everything in Perl--the traditional UNIX tools are often simpler.
If you are using Windows, switch to UNIX. Windows may be good for starting up MS Office, but it is no good for this sort of thing. If you absolutely must use Windows for data analysis, stick your data into a relational database or Excel spreadsheets.
Learn to use environment variables.
Learn to use the Bourne/Korn/Bash shell; the C-shell is no good for this sort of thing.
For certain kinds of automation, expect is also very handy.
For visualizing data, write scripts that analyze your data and automatically generate the plots/graphs--you will run them again and again.
Distribution of jobs, running things with multiple parameter values, etc., all can be handed smoothly from the shell. This is really the sort of thing that UNIX was designed for, and the entire UNIX environment is your "experiment management software".
You can make up things or quote things out of context till you're blue in the face.
But two simple points remain:
Palm is engaging in a complete rewrite of PalmOS and developers have to rewrite their applications to take advantage of the new capabilities.
Whatever justifications there may have been for Palm's design decisions on the original Palm are irrelevant. They are going for a high-end market now, and they don't have an OS to match.
The only reason Palm is still hanging on is because of developer inertia.
I'm not trying to troll, but it's just common sense that if you're concerned about the risks that come with an activity, you either don't participate in that activity or you
Well, and whaddayaknow, a large chunk of AIDS funding goes towards education to let people know about that. Because, you see, kids aren't born with that kind of knowledge.
Unfortunately, many of the same people who keep talking about people "accepting responsibility for their actions" want to keep the government from giving that information from teenagers.
If people stopped doing the things that spread AIDS (it's not exactly airborne), it would eventually go away. Consequently, politicians and activist groups would lose a manipulation tool to siphon tax dollars away from issues that are a lot less preventable and affect more people.
You are pitting logic against the raging hormones of hundreds of milions of teenagers? You are a fool. STDs have been with us throughout history. If the Spanish inquisition, the Pope, the Nazis, and the Chinese, haven't managed to get rid of them over the last several thousand years, right wing moralizing by US politicians and their followers sure as hell isn't going to do it either. People like Helms have envy the Spanish inquisition, but they are wimps in comparison.
siphon tax dollars away from issues that are a lot less preventable and affect more people.
Yes, that is compassionate conservatism in a nutshell: "these people made a mistake, so let them rot in hell". That's a lot of how conservative thinking works, where "hell" is varyingly "untreated AIDS", "homelessness", or "prison rape". It's an OK position to take--civilizations have done so throughout history. Let's just drop the "compassionate", "moral", and "Christian" pretenses usually associated with such positions: such views are rooted in greed, selfishness, and social Darwinism.
Yes, though my point was that if they had stuck with POSIX(-like) APIs, moving from something like the original Palms to the T|T wouldn't be such a pain. In fact, they could now choose between Linux, QNX, and other systems.
In fact, even with non-POSIX APIs, if they had looked ahead a little and designed APIs that could have scaled up, Palm wouldn't have the problems they are having.
Note that there are small versions of the Linux kernel (here). They even run on the Dragonball Palms.
Also, if you like, you can still get 2.9BSD and even a PDP-11 emulator to run it on (here).
The UNIX API's are not suitable for PDA purposes because they do not take into consideration the power constraints.
Oh? Elaborate on that pearl of wisdom, please. What is "unsuitable" about "read" or "open"?
Just because the CPU performance and the amount of DRAM of a PalmOS 5/6 handheld is greater than that of high-end workstations of a few years back, doesn't mean the battery amp-hours have also scaled to match.
I guess I must be imagining anybody playing audio or video files on something like the T|T.
And, in any case, even if that were true, what would it have to do with using an embedded POSIX kernel or even a Linux kernel? Embedded POSIX or Linux kernels don't sit their keeping the CPU busy for fun. When there is nothing to do for a Linux kernel and the CPU supports it, it goes into power saving mode, just like any other kernel for battery-operated devices.
So, tell me Mr. Unix, how do you propose running Linux, X11, and storing all of your applications and data in 2MB of RAM?
I don't know why you keep blabbing on about "Linux+X11". I said Palm should be using POSIX APIs; there are plenty of POSIX kernels. Do you understand the difference between an API and a specific implementation? Oh, wait, no, you obviously don't.
The Palm Zire, a current, low-end Palm handheld, has 2MB of RAM.
And why do you think that is? Because it would cost a couple of dollars more to put 16M into that machine? Because 16M would consume a fraction more power? No. It's because that's the way Palm is dividing their market. If they put 16M on the Zire, they wouldn't be able to sell as many high-end machines.
X11 can take 10 to 20 megabytes alone
Yeah, and it can take 100Mbytes, or even 1Gbyte. That's because it, gasp, allocates memory for an application when asked to and when it's available. An X11 server can also do all its magic in a few hundred kbytes of memory. Not that it has anything to do with our argument because I wasn't actually proposing running X11 on something like a Zire.
Linux has countless proponents all over the world. The Palm hardware is well-understood. So, if it's so desirable in a handheld, why has no one ported Linux to a Palm?
It has been ported, but the 68k hardware lacked memory management. Newer Palm hardware is just way overpriced--why port to a T|T if you can port to a h1910 that's cheaper, smaller, lighter, and has a nicer screen?
I have been in this industry since 1980 doing embedded systems work. I'm smart enough know that you can't measure compute speed in mhz.
You apparently know little about UNIX, POSIX, Linux, or X11, and keep confusing them. You think that a 16 bit, unsafe, segmented memory architecture is just fine. And you don't even see that Palm is, in fact, busily at work trying to get rid of their outdated and messy OS because they themselves realize that they can't survive on Zire. If you do embedded systems work, you have given us an object lesson in why so many embedded systems suck so badly: you don't know what you are doing, and you have no long-term perspective.
There have been several attempts to create PDAs that ran Linux. They were invariably expensive, large, heavy, and had short battery life.
The Agenda VR was a smaller and nicer machine than the Palms at the time. Of course, its software never had the benefit of having several years of user feedback and hacking, so it just couldn't catch up with Palm.
And they failed in the marketplace.
Just remember that when Microsoft and Sony eat Palm's lunch because, as we all know, the market is so good at picking nice technology, right?
Face it, PalmOS is like DOS: a poorly engineered, unoriginal system that happened to be in the right place at the right time to make it big in the market. The one thing Palm got right was decent end-user applications (which is why I'm actually still using an old Palm).
That's fine: give it 4M of working RAM for the kernel and all applications and you still have 12M of disk storage. Linux is happy.
However, Palm could, of course, simply include flash memory in the device (8M would be plenty for a Linux system and user data). The reason they don't is more that their OS isn't architected to run from it in the first place.
But back then, weren't "Unix workstations" mostly "Unix dumb terminals"? Even a 386 is fine for a remote X display, as long as you are running the programs on another computer.
No, back then, there was one UNIX machine supporting many users on dumb terminals. Think "your Palm with 32 users" all running different applications at the same time.
UNIX workstations presented a breakthrough in comparison by giving a single user the stunning computational power of a Palm handheld all to themselves. But that workstation had to run the window system, the operating system, and all the applications. And it did, quite well, actually.
Remember, too -- software always lags behind hardware. The hardware dev cycle on PDAs has been a *lot* faster than on desktops, but they've still covered much of the same ground.... from 16mhz up to whatever they're running now. (did you say 175 already? wow.) DOS didn't move real fast for a long time either, as I recall.
That's my point: the PDA software is lagging unnecessarily--by about 20 years--because companies like Palm are reinventing the wheel.
And Linux was ported to the Palm in the early years -- but it never went anywhere, presumably because it simply wasn't CPU/memory efficient enough to DO anything. Linux on a PDA might make sense *now*, but it really didn't back then. If it had, it would have made more of an impact.
No, the reason was that the Palm hardware didn't have memory management, which meant it was too different of a target from the regular 32 bit machines that Linux was meant for. But there were/are plenty of POSIX kernels that run on that kind of hardware. Performance-wise, there was no problem.
But Linux is generally tuned for a more capable class of hardware.
More capable than what? A T|T is more capable than most Linux machines a few years ago.
A full-up Linux system with shared libraries, multitasking, graphics, etc., etc., wouldn't fit comfortably in a system with 2, 8, or even 16 megs combined heap, stack, and long-term storage.
Why not? Tom's rescue disk gives you a recent bootable Linux kernel and a pretty complete command line environment on a single 1.4M floppy (including vi, command line editing, networking utilities, and other stuff). Of course, for a handheld, we are talking Linux kernel together with a different kind of user environment.
but Palm started out with 128k of combined heap, stack, and long-term storage..
I'm not sure what that has to do with whether PalmOS would beat Linux in terms of performance.
But yes, 128k is too small for a regular Linux kernel, but other UNIX-like systems do work in space that small. The question arises still whether Palm's quick-time-to-market and corporate success is worth the years and years of backwards compatibility woes for developers. I don't think so: Palm has to take the blame for what they did.
Palm's API is clean, intelligent, and well-designed for its intended purpose (a PDA).
Palm's intended purpose these days is to compete in the consumer and enterprise markets. Even if you could make an argument that its pathetic excuse for APIs was "well designed" for the handful of PDA functions that Palm originally had, Palm OS 4/5 just is a no-go there because programmers aren't going to go back to what amounts to a 16 bit segmented architecture. Even Palm understands this, which is why they are rewriting things.
A POSIX-compatible kernel is completely inappropriate for a Palm-style handheld. Have you ever tried to write a GUI-based Othello program that's 15K long on Linux? How about a 47K full scientific calculator?
I used to do graphics programming on PDP-11s; those things had a 64k address space and ran somewhere in the single digit MHz range. So, yes, I have written GUI apps that, by necessity, used that little memory. Of course, why one needs to undergo that kind of self-flagellation on a 175MHz RISC processor with 16M of RAM is somewhat beyond me. I mean, are you planning on running 1000 simultaneous copies of Othello (fat chance that PalmOS wouldn't crash first anyway). And with all that "efficiency", why is PalmOS actually so damned slow? I mean, I could grep faster on a PDP-11 than the search function on my Palm.
Incidentally, my first personal UNIX machine had a 20MHz processor, 4M of RAM, and ran X11 plus many command line tools we still get today.
You see, the UNIX APIs were well-designed: they scale from 16 bit machines to 64 bit machines and let you take full advantage of the capabilities. If you give them a Gbyte of memory to play with, users can fill it with applications, images, and other stuff. If it needs to run in a few hundred kbytes of memory, it can do that, too. That is unlike incompetent attempts like DOS, Windows, or PalmOS which need rewriting every time the wind shifts.
It's that I-have-a-hammer-so-every-solution-involves-a-nail kind of thinking that has ruined many embedded systems. If you Linux pushers had your way, PalmOS handhelds would need faster CPUs, far more RAM, and would drain batteries so fast that Rayovac shares would jump up 50%.
If "us UNIX/POSIX pushers" had our way, handhelds would get by with a fraction of the power and resources that they are using, and they wouldn't require major OS and application rewrites every couple of years.
The notion that something like the Tungsten T is a dainty little machine that is too delicate to UNIX/Linux is just ridiculous. I mean, were you born yesterday? The T|T has more CPU power and memory than UNIX workstations from the early 1990s.
It's only people like you and the PalmOS developers who are completely ignorant of history and keep reinventing the wheel--badly.
You've got to be kidding. Linux has been tuned so extensively that it has very little overhead over the raw hardware; Palm is unlikely to come even close in terms of performance.
The real question is why PalmOS is such a pathetic mess on that kind of hardware. PalmOS gives you the programming experience and APIs of a low-end DOS machine on CPUs that are perfectly capable of running a full UNIX workstation environment.
Slashdot Mirror
Yes, just as the kind of moral calculus you are engaging in is wrong. It is not OK for a society to let people rot just because they have made mistakes or just because they are stupid. You may think it is, but fortunately, most people disagree.
Spend whatever it takes to inform and educate people - at schools, via the media, via outreach programs - do whatever it takes so that we can say with 100% certainity that every American of sexual age knows that unprotected sex can lead to HIV. Let every American know that consuming thousands of empty calories on junk food can lead to obesity and premature death. Give them the information, and let them live with their choices.
Yes, if everybody were just as perfect, well-informed, and logical as you. But in the real world, people don't operate that way: people behave erratically, have personal crises, and make mistakes. They believe that if they rape a virgin, they will get cured of AIDS. They believe that they can't get it from doing it just once. They think that only homosexuals get it. They really love their boy/girlfriend and trust them only to find out s/he has been cheating.
A large chunk of AIDS funding goes to education, but it's hard to inform people, and it's harder to get them to trust and believe the message.
I agree we do not spend enough on research. But no matter what the number there still is a finite point where we must choose. Just because it is far away doesn't mean we shouldn't think about the answer.
You can think about the answer all you want; it is your concrete arguments about current AIDS research spending where I draw the line.
If you exclude the prison population (prison rape is a serious issue which does need to be addressed, but just not in the same way as the general population) there are not 10,000 HIV infections from rape each year.
If you only include reported, documented, white, middle class, suburban rapes by high school football players, you are right, there are not 10000 HIV infections from "rape" each year. If you look at worldwide rape victims, there are many times that.
But do not get distracted by the fact that we are trying to cure a viral disease. Remember that medicine so far has virtually no useful "across the board" treatments for viral infections.
This is exactly why your arguments about AIDS spending are so bogus: AIDS research is basic research, and its results are going to be important for many infectious diseases. AIDS is simply a useful and fashionable label for a lot of research that would happen under another label if something else were fashionable.
Society constantly spending money, dedicating medical resources, and throwing goodwill on a problem that shouldn't be a problem is very wasteful. More than that, it's immoral. It depreives others who are in dire need of those resources.
We have already established that we are very far from having reached the limits of our resources. The tradeoff is not between helping two groups of needy people, the tradeoff is between driving a slightly bigger SUV and helping people in need.
Here is my suggestion to you: why don't you spend some time working for an AIDS hotline? You seem to think that all it takes is to tell people the facts--what better way than to volunteer? I think you will find that your "simple" answers don't quite work out in the real world.
Piles isn't going to make MacOS X (or Windows) any easier to use. While die-hard Macintosh users, who may know all the obscure combinations of Shift, Command, and mouse clicks, may be wowed by such gee-whiz features, regular users are already stymied by concepts like "open" and "closed" folders. Adding yet another kind of "collection of documents" will lead to more confusion and more support calls. (Incidentally, Apple also didn't invent the idea--piles have been in scanning and document management software for Windows for years.)
Power problems aren't that bad here in Califo#%*(!.
That argument doesn't hold water because we have not even come anywhere near reaching the limit of our "finite resources". Our tax rates are among the lowest in the industrialized world, so the tradeoff isn't between spending and additional $1 billion on heart disease or spending an additional $1 billion on AIDS, the tradeoff is between spending an additional $1 billion on AIDS vs. buying (on average) an Espresso for every American. The reason why we aren't spending more on research is because the American voter wants money to buy SUVs, gargantuan homes, and lots of other trinkets.
Furthermore, we spend almost twice as much per capita on health care ($4500) than other modern nations with medical outcomes that are no better; if we can afford to waste $600 billion in medical spending per year without bothering to fix it, arguments that a billion or two are too much to spend on a disease that affects millions of Americans seem silly.
But your whole premise is wrong anyway: diseases aren't compartementalized, and $1 of spending on a disease doesn't get you $1 of cure for that disease. AIDS simply happens to be the "hot disease" for research right now: it has public exposure, it touches many interesting areas of medicine, it is just within the reach of current biology and medicine, and it comes with a ready supply of volunteer patients. I think it's unlikely we will ever find a cure for AIDS, but I also think that AIDS is one of the best areas to finance if we are interested in advancing the state of medicine.
For example, people who climb Mount McKinley in Alaska. How much money should be spent to rescue these people when they inevitably get trapped/in serious trouble? $1Million? $10Million? $100Million? Seriously. How much should society spend to protect a determined individual from killing themselves?
I guarantee you, the money that is being spent on such rescues is already many times more than we spend on AIDS research per infected American. So, why don't you pick that as your first battle, as opposed to picking on AIDS research?
If every HIV+ person was sufficently stigmatized that they decided against unsafe sex HIV/AIDs would die off in a generation, and millions if not billions of lives would be saved.
By your reasoning, why not put HIV-infected individuals into concentration camps and gas them? The disease would be gone instantly. You see, once you start that kind of approach to organizing societies, you are pretty much on a one-way street to totalitarianism and death camps. The US and Europe, rightly, criticized China and Cuba sharply for trying to ostracize HIV-positive individuals.
There is no way to justify spending anything on a disease that is obtained only (except those few tiny rare cases, literally probably under 100 a year) through frivulous behavior.
You are so out of touch with human realities. Rape alone accounts for many orders of magnitude more HIV infections than that.
Yes, just like what Verisign would want: $100/year from anybody who wants to send or receive mail. Thanks, but I'll stick with unauthenticated mail and spam.
If that's the sort of thing you want, you can already run SMTP over SSL--you don't need a new protocol for that. Operating systems terminally incapable of building services out of modular building blocks can hard-code SSL into their mail servers. Reasonable operating systems can use something like stunnel for wrapping SMTP. Either way, you get authentication. There doesn't even need to be any complex interaction between the SSL authentication and the SMTP server because SSL can simply verify the identity of the connecting host, and SMTP can continue to use its regular host-based identification.
The other important requirement, according to Yu, is a system for tracking resource usage per sender. Basically this means that profiles should be established for normal amounts of mail sending from different types of users. If you limited normal users to 100 messages per second and major companies to 10,000 messages a second it would be hard for legitimate users to complain, but spamming would be much harder.
We don't need a new protocol for this. Per-user throttling of outgoing SMTP connections could be implemented by ISPs at the TCP level, and per-user throttling of incoming SMTP connections can be implemented by the SMTP server. The reason why this isn't done is because it's largely ineffective: many spammers are beyond such controls for outgoing connections anyway, and limits on incoming connections can be circumvented simply by posing as hundreds of different users.
Solutions to the spam problem are things like CAPTCHAs, intelligent text analysis, and communications pattern analysis. Restrictions on who can send what to whom at the ISP level, or the imposition of authentication fees by ISPs or companies like Verisign, however, are thinly disguised attempts at squeezing money out of users. In addition to being ineffective and increasing the cost of E-mail, they also just threaten the openness of the Internet that has made it so successful in the first place.
You have two ways of doing that: either put the logic for that sort of caching into the disk driver, or put battery backed RAM into the disk drive or controller itself. I think both have been explored in the past.
No, they are not, because you can use them all in parallel. That means, 50 parallel seeks, 50 parallel transfers, etc. Latency remains as for a single drive, but lots of other things are really fast.
Palm cares. That's why they are doing a big rewrite for PalmOS 6.
What argument? I was countering your claim that PalmOS tied you to a single vendor.
PalmOS comes from a single vendor only.
It has a larger memory footprint than PalmOS. It requires far more CPU cycles. It will reduce battery life. It will kill off the low-end $99 machines. And it does not answer a significant need.
As if PalmOS 5/6 is going to run on a Zire.
So, you are saying that you have never actually run large scale computational experiments, and you don't actually have any recommendations for how to run them on Windows, but based on a list of Windows "system services" you think it should be pretty good for that.
Well, I have run large scale computational experiments on Windows, UNIX, and other platforms. Based on my experience, my recommendation was and is: if you can, do them on UNIX because it's so much easier. If you have to use Windows, stick to relational databases, because that's how large amounts of data are handled on Windows.
Now, if you have anything technical to contribute, please do.
That is simply incorrect. I have never tried to start an app on an Palm and had it take around a minute for [my] other application to start up or register [my] input as the review stated.
That's because the Palm Pilots we had at the time weren't even capable of starting up multiple applications at the same time.
Again, the Agenda VR UI was not as mature as the Palm UI at the time--after all, it was little more than a beta release. That meant people could do stupid things with it, like start up too many applications. But its applications ran fine, and about as fast as Palm apps.
I have applications on my current Handspring Visor that I originally used on a Palm Pilot Professional (512K RAM).
Yup, and they will work exactly like they did on that machine, in all their 160x160 pixelated glory, knowing nothing about flash memory or anything else that has happened since then.
We all know that you can take any Linux binary and put it on any Linux system and it will work just fine.
Yes, we do all know that: the Linux kernel API has been exceptionally stable.
But you keep missing the point: it's not about binary backwards compatibility, which any idiot can achieve with enough determination (Microsoft managed to do it even for DOS), it's about designing kernels and software systems that scale up and are future-proof.
Tied to a single vendor?
To a single OS vendor.
I can get PalmOS PDAs from Palm, Handspring, and Sony. I can get cell phones from Samsung and Kyocera that incorporate a PalmOS-based PDA.
Yes, the same argument has been made for DOS, and Windows, IBM, and MacDonald's food. But just because something has managed to take over a market doesn't mean it's technically good. Quite to the contrary: technically inferior designs often win in the market for well-understood reasons.
Of course, the OS was "suitable" for its original market and purpose--I never disputed that. But there are many ways of writing a "suitable" OS for even the 128k Palm, and Palm picked one of the technically worst ways, a way that requires them to do a major rewrite of the OS and applications to port it to ARM.
The problem with PalmOS is not its (lack of) suitability to the hardware it was originally designed from, the problem with PalmOS was that it was written without any sense of future hardware or future needs in mind.
I admit that their latest offerings are not very attractive from a price/features standpoint
Actually, I think that the $80 Zire is a good offering: small, light, and inexpensive, and it runs an OS designed for that kind of hardware. The design mistakes in the OS don't matter because that hardware is close to what the OS was designed for.
but Sony's PalmOS handhelds (I love rubbing that in)
Yes, you like to bask in the glory of your limited understanding; I'm way ahead of you.Of course, Sony is a PalmOS licensee (I have a Sony handheld as well). But they are still eating Palm's lunch. Perhaps you have missed that Palm and PalmSource are different companies. Perhaps you don't quite understand that Sony can do what they do by shipping a different OS from PalmIS (that is, the take the PalmOS source and hack it up), and by adding all sorts of non-PalmOS embedded chips and software around PalmOS.
are looking quite attractive.
You mean "big power-hungry bricks"? Sony stands for everyting Palm proponents claim they didn't want in a handheld. The iPaq series looks a whole lot nicer to me, and they are cheaper to boot.
The review for the Agenda VR is entirely accurate. However, the the Palms available at the time were slower, less responsive, and crashed more.
You see, unlike you, I have actually used the various systems. All of the handhelds are compromises. Functionally, the Linux-based ones are about as bad or good as the alternatives. The difference is that they don't require software rewrites every few years and don't tie you to a single vendors.
Assuming your statistics are correct, what is your point? That people who make one mistake, or even whose entire life is completely screwed up, "deserve" getting AIDS?
Sure, that is one way of thinking. It's a way of thinking as old as human-kind. Two thousand years ago, the story of Mary Magdalen was about that. It's a view, however, that lacks compassion and humanity.
The kind of utilitarian calculus of responsibility you engage in is chillingly cold and inhumane: "how much is this life worth, how much did this person know, what percentage of responsibility should he/she accept"? That's the kind of thinking that leads to death camps.
And, even in a purely utilitarian sense, before you know it, it may end up being applied to you. I mean, assuming you drive a car to work, why should I pay for your risky choice of mode of transportation? If you eat meat or drink sodas, why should I pay for your risky nutritional preferences?
how far should government go to protect these people from themselves?
Who said anything about "protecting people from themselves"? Several hundred thousand people in the US are sick and dying from HIV/AIDS, and we should help them with compassion and humanity. One way we help the sick in modern societies is through medical research. The annual cost to you and me is about the same as a couple of Espressos at Starbucks. Sure, these people may be fully responsible for what they did, but you don't even have that much compassion for them in you?
In terms of responsiveness, I'm sorry, but the argument that POSIX I/O makes systems unresponsive is just silly: not only could you use threads, you can use timeouts, check for available data, or use asynchronous I/O. That is as opposed to the Palm, where the machine becomes catatonic during long operations.
In any case, look at where Palm is now: an emulated CPU and multithreaded OS, together with a big backwards compatibility hassle on their hands. Do you really want to make an argument that PalmOS5 is better for handhelds in terms of battery life, memory footprint, or responsiveness than a decent embedded kernel? I just don't think so.
Distribution of jobs, running things with multiple parameter values, etc., all can be handed smoothly from the shell. This is really the sort of thing that UNIX was designed for, and the entire UNIX environment is your "experiment management software".
The only reason Palm is still hanging on is because of developer inertia.
Well, and whaddayaknow, a large chunk of AIDS funding goes towards education to let people know about that. Because, you see, kids aren't born with that kind of knowledge.
Unfortunately, many of the same people who keep talking about people "accepting responsibility for their actions" want to keep the government from giving that information from teenagers.
If people stopped doing the things that spread AIDS (it's not exactly airborne), it would eventually go away. Consequently, politicians and activist groups would lose a manipulation tool to siphon tax dollars away from issues that are a lot less preventable and affect more people.
You are pitting logic against the raging hormones of hundreds of milions of teenagers? You are a fool. STDs have been with us throughout history. If the Spanish inquisition, the Pope, the Nazis, and the Chinese, haven't managed to get rid of them over the last several thousand years, right wing moralizing by US politicians and their followers sure as hell isn't going to do it either. People like Helms have envy the Spanish inquisition, but they are wimps in comparison.
siphon tax dollars away from issues that are a lot less preventable and affect more people.
Yes, that is compassionate conservatism in a nutshell: "these people made a mistake, so let them rot in hell". That's a lot of how conservative thinking works, where "hell" is varyingly "untreated AIDS", "homelessness", or "prison rape". It's an OK position to take--civilizations have done so throughout history. Let's just drop the "compassionate", "moral", and "Christian" pretenses usually associated with such positions: such views are rooted in greed, selfishness, and social Darwinism.
In fact, even with non-POSIX APIs, if they had looked ahead a little and designed APIs that could have scaled up, Palm wouldn't have the problems they are having.
Note that there are small versions of the Linux kernel (here). They even run on the Dragonball Palms.
Also, if you like, you can still get 2.9BSD and even a PDP-11 emulator to run it on (here).
Oh? Elaborate on that pearl of wisdom, please. What is "unsuitable" about "read" or "open"?
Just because the CPU performance and the amount of DRAM of a PalmOS 5/6 handheld is greater than that of high-end workstations of a few years back, doesn't mean the battery amp-hours have also scaled to match.
I guess I must be imagining anybody playing audio or video files on something like the T|T.
And, in any case, even if that were true, what would it have to do with using an embedded POSIX kernel or even a Linux kernel? Embedded POSIX or Linux kernels don't sit their keeping the CPU busy for fun. When there is nothing to do for a Linux kernel and the CPU supports it, it goes into power saving mode, just like any other kernel for battery-operated devices.
I don't know why you keep blabbing on about "Linux+X11". I said Palm should be using POSIX APIs; there are plenty of POSIX kernels. Do you understand the difference between an API and a specific implementation? Oh, wait, no, you obviously don't.
The Palm Zire, a current, low-end Palm handheld, has 2MB of RAM.
And why do you think that is? Because it would cost a couple of dollars more to put 16M into that machine? Because 16M would consume a fraction more power? No. It's because that's the way Palm is dividing their market. If they put 16M on the Zire, they wouldn't be able to sell as many high-end machines.
X11 can take 10 to 20 megabytes alone
Yeah, and it can take 100Mbytes, or even 1Gbyte. That's because it, gasp, allocates memory for an application when asked to and when it's available. An X11 server can also do all its magic in a few hundred kbytes of memory. Not that it has anything to do with our argument because I wasn't actually proposing running X11 on something like a Zire.
Linux has countless proponents all over the world. The Palm hardware is well-understood. So, if it's so desirable in a handheld, why has no one ported Linux to a Palm?
It has been ported, but the 68k hardware lacked memory management. Newer Palm hardware is just way overpriced--why port to a T|T if you can port to a h1910 that's cheaper, smaller, lighter, and has a nicer screen?
I have been in this industry since 1980 doing embedded systems work. I'm smart enough know that you can't measure compute speed in mhz.
You apparently know little about UNIX, POSIX, Linux, or X11, and keep confusing them. You think that a 16 bit, unsafe, segmented memory architecture is just fine. And you don't even see that Palm is, in fact, busily at work trying to get rid of their outdated and messy OS because they themselves realize that they can't survive on Zire. If you do embedded systems work, you have given us an object lesson in why so many embedded systems suck so badly: you don't know what you are doing, and you have no long-term perspective.
There have been several attempts to create PDAs that ran Linux. They were invariably expensive, large, heavy, and had short battery life.
The Agenda VR was a smaller and nicer machine than the Palms at the time. Of course, its software never had the benefit of having several years of user feedback and hacking, so it just couldn't catch up with Palm.
And they failed in the marketplace.
Just remember that when Microsoft and Sony eat Palm's lunch because, as we all know, the market is so good at picking nice technology, right?
Face it, PalmOS is like DOS: a poorly engineered, unoriginal system that happened to be in the right place at the right time to make it big in the market. The one thing Palm got right was decent end-user applications (which is why I'm actually still using an old Palm).
However, Palm could, of course, simply include flash memory in the device (8M would be plenty for a Linux system and user data). The reason they don't is more that their OS isn't architected to run from it in the first place.
No, back then, there was one UNIX machine supporting many users on dumb terminals. Think "your Palm with 32 users" all running different applications at the same time.
UNIX workstations presented a breakthrough in comparison by giving a single user the stunning computational power of a Palm handheld all to themselves. But that workstation had to run the window system, the operating system, and all the applications. And it did, quite well, actually.
Remember, too -- software always lags behind hardware. The hardware dev cycle on PDAs has been a *lot* faster than on desktops, but they've still covered much of the same ground.... from 16mhz up to whatever they're running now. (did you say 175 already? wow.) DOS didn't move real fast for a long time either, as I recall.
That's my point: the PDA software is lagging unnecessarily--by about 20 years--because companies like Palm are reinventing the wheel.
And Linux was ported to the Palm in the early years -- but it never went anywhere, presumably because it simply wasn't CPU/memory efficient enough to DO anything. Linux on a PDA might make sense *now*, but it really didn't back then. If it had, it would have made more of an impact.
No, the reason was that the Palm hardware didn't have memory management, which meant it was too different of a target from the regular 32 bit machines that Linux was meant for. But there were/are plenty of POSIX kernels that run on that kind of hardware. Performance-wise, there was no problem.
More capable than what? A T|T is more capable than most Linux machines a few years ago.
A full-up Linux system with shared libraries, multitasking, graphics, etc., etc., wouldn't fit comfortably in a system with 2, 8, or even 16 megs combined heap, stack, and long-term storage.
Why not? Tom's rescue disk gives you a recent bootable Linux kernel and a pretty complete command line environment on a single 1.4M floppy (including vi, command line editing, networking utilities, and other stuff). Of course, for a handheld, we are talking Linux kernel together with a different kind of user environment.
but Palm started out with 128k of combined heap, stack, and long-term storage..
I'm not sure what that has to do with whether PalmOS would beat Linux in terms of performance.
But yes, 128k is too small for a regular Linux kernel, but other UNIX-like systems do work in space that small. The question arises still whether Palm's quick-time-to-market and corporate success is worth the years and years of backwards compatibility woes for developers. I don't think so: Palm has to take the blame for what they did.
Palm's intended purpose these days is to compete in the consumer and enterprise markets. Even if you could make an argument that its pathetic excuse for APIs was "well designed" for the handful of PDA functions that Palm originally had, Palm OS 4/5 just is a no-go there because programmers aren't going to go back to what amounts to a 16 bit segmented architecture. Even Palm understands this, which is why they are rewriting things.
A POSIX-compatible kernel is completely inappropriate for a Palm-style handheld. Have you ever tried to write a GUI-based Othello program that's 15K long on Linux? How about a 47K full scientific calculator?
I used to do graphics programming on PDP-11s; those things had a 64k address space and ran somewhere in the single digit MHz range. So, yes, I have written GUI apps that, by necessity, used that little memory. Of course, why one needs to undergo that kind of self-flagellation on a 175MHz RISC processor with 16M of RAM is somewhat beyond me. I mean, are you planning on running 1000 simultaneous copies of Othello (fat chance that PalmOS wouldn't crash first anyway). And with all that "efficiency", why is PalmOS actually so damned slow? I mean, I could grep faster on a PDP-11 than the search function on my Palm.
Incidentally, my first personal UNIX machine had a 20MHz processor, 4M of RAM, and ran X11 plus many command line tools we still get today.
You see, the UNIX APIs were well-designed: they scale from 16 bit machines to 64 bit machines and let you take full advantage of the capabilities. If you give them a Gbyte of memory to play with, users can fill it with applications, images, and other stuff. If it needs to run in a few hundred kbytes of memory, it can do that, too. That is unlike incompetent attempts like DOS, Windows, or PalmOS which need rewriting every time the wind shifts.
It's that I-have-a-hammer-so-every-solution-involves-a-nail kind of thinking that has ruined many embedded systems. If you Linux pushers had your way, PalmOS handhelds would need faster CPUs, far more RAM, and would drain batteries so fast that Rayovac shares would jump up 50%.
If "us UNIX/POSIX pushers" had our way, handhelds would get by with a fraction of the power and resources that they are using, and they wouldn't require major OS and application rewrites every couple of years.
The notion that something like the Tungsten T is a dainty little machine that is too delicate to UNIX/Linux is just ridiculous. I mean, were you born yesterday? The T|T has more CPU power and memory than UNIX workstations from the early 1990s.
It's only people like you and the PalmOS developers who are completely ignorant of history and keep reinventing the wheel--badly.
The real question is why PalmOS is such a pathetic mess on that kind of hardware. PalmOS gives you the programming experience and APIs of a low-end DOS machine on CPUs that are perfectly capable of running a full UNIX workstation environment.