Just out of curiosity, what makes that better than the Tungsten E2 or the Zire?
The later Zire models and the Tungsten have much more powerful processors, to be sure, but the control layout and the poor screen protection on the Tungsten pretty much rule them out for me.
Any handheld I'm willing to consider must have a thumb controller and a vertically pivoting flipcover. That way it can be used without a bulky protective case and can be used comfortably one-handed while reading e-books. It doesn't matter if the control is a jog-wheel like the Clie, a toggle like the Casio and early Jornadas, or paired buttons like the last Jornada.
The collapsing Tungsten in particular is cute as a bug, but the design makes it impossible to protect the screen properly. The Zire models all, I believe, have a flipcover, but none of them have a thumb control.
The fact that the SJ-22 is probably the last PalmOS handheld shipped without that abomination known as "Graffiti-2" is just the icing on the cake.
I've exchanged email with some of the people who actually may have some of the source to some version of NeWS, they're not sure. It's kind of gotten lost, and they don't really think it's interesting any more. It's a shame, I was really pumped.
Everyone knows that the Sony Clie SJ22 was the closest any handheld manufacturer has ever come to a perfect device, and all others must bow before its near-perfect ergonomics.
OK, I know Godwin's Law, and I know Clarke's Law and the inverse Clarke's Law (AKA Benford's Corrolary), but I forgot whose law it is that every comment complaining about someone's speeling or grammer must contain at least one grammatical error or typo...
Microkernels, and messaging, were an academic fad of 1988-1997 by which time Tanenbaum/CMU/Inria were shown to be wrong, and classic Unix e.g. Solaris; Linux correct
Well, you sure have the Official Linux Policy down pat. It's a good line of patter, pointing at a small bunch of academic systems that came along fairly late and acting as if all the earlier and still in production real-time microkernels didn't exist... or tat they're somehow "not microkernels" because they don't fit the Official Linux Policy definition of a microkernel.
The ones I've had most experience with are RSX-11 and AmigaOS, but pretty much all hard real-time systems have a similar structure. There is a huge history of successful microkernels and, no matter how much Linus was soured on them by his experience with Minix, it's an effective and efficient way to build a system. The problem with Microkernels is you have to make sure that you haven't built in single-threaded bottlenecks that every process has to work through, like the Minix file system. Monolithic kernels largely avoid this issue, at least up to the point where they have to deal with a multi-CPU environment and the simple "single kernel lock" becomes the same kind of bottleneck.
See, concurrency is hard. Both designs force you to work through concurrency problems. Microkernels hit the concurrency wall earlier, but you only have to climb over it once. Monolithic kernels have to keep adding more and more heuristics to work around it, and that itself is a cause of kernel bloat.
what's the advantage to the kernel of moving the interfaces to be more external and require expensive marshalling?
Ah, but they only require marshalling when you cross a protection boundary. Without that, they can be as efficient as the Amiga message primitive which was four instructions long.
The C function interface does not suffice. That's the same problem that RPC mechanisms have. The C function interface is synchronous, messages can be asynchronous, they can be buffered and queued, they make concurrency implicit and invisible rather than forcing every component to be explicitly and painfully aware of it, lest they become a bottleneck.
A lot of kernel functionality could be moved outside the kernel if the intrakernel communication was regularised into some mechanism (messages, for example) that could be efficiently marshalled and moved through a user-kernel boundary.
Obviously you can't do this for everything, but you could simplify the kernel significantly if instead of separate interfaces for every kind of object a single regular interface could be used at least as a starting point. The Amiga did this, and the result was a system of rare simplicity that made quite complex components easy to implement. Matt Dillon, a long-time Amiga hacker, is working on turning the BSD kernel inside out in this way. There's no reason Linux couldn't be cleaned up and pared down the same way.
In my day students got a 300k quota on a timeshared UNIX system that was so slow that during finals week it wasn't unknown for your login to time out while getty was trying to load login to display the login prompt. Running CPU-intensive programs like NROFF was enough to get your account suspended.
An iPod has more computing power and storage than the entire undergraduate computing center did back then.
In my opinion, students should buy their own iPods, if they want them.
My system menu/dock/desktop almost make me wish I had a 17" not a 15" but now I'm rambling.
I've got a 21 and I wish I had a 30.:)
I'm pretty down on Dashboard, but if I thought it would lead people to quit writing apps that use menu extras when they don't need to be on the screen all the time, I'd be all over it.
Despite the fact that you have to sign an agreement, this is certainly more "open" than a blanket rejection to everyone who requests access.
A blanket rejection can be more open, since it legitimizes reverse engineering.
I can think of plenty of companies who won't let you get details about a file format they use under any circumstances.
I have the option of not doing business with such companies. If I had the option of not doing business with Microsoft (as I have the option of not doing business with Bitkeeper) this would not be an issue, now would it?
Microsoft promoted common development of standards by sitting on all of the representative bodies working on them
You gotta laugh, I had this image of a huge lard-ass King Kong with a Bill Gates mask crushing a conference table and the committee members beneath his hairy buns.
SUID/SGID is not flawed by design. When used as designed it's an extremely effective mechanism for privilege separation. The trick is to set*id to a user or group with the minimum necessary privileges to perform a task. Not -ing root.
Setuid scripts are a different ball of barbarian invaders.
The universal search facility in Palm OS is one of its killer capabilities. It's been saving me from wasting neurons on trivia for the past 5 years, and I eagerly await an improved desktop clone of it no matter who it's from.
If they have physical access to your machine you have worse problems than worrying about root escalation.
This isn't Windows. Slowing down root escalation will at least keep the skr1pt k1ddies busy for a little while. Yes, you want to keep them out... but you don't write your PIN on the back of your teller card just because "if someone has physical access to your wallet you have worse problems than worrying about an unauthorised withdrawal".
No, they intended them to be used for storing metadata about the file so it could be indexed for searching purposes (like BeOS/BFS did).
Or like the Macintosh resource fork.
Or like the elements in OS/1100 files, though they ended up being used the way files are in other operating systems, with the files themselves treated like directories.
The thing is, unless you can get all operating systems and applications to handle, preserve, and interconvert these objects, they're more trouble than they're worth. You have to either make them visible as separate files (in which case you might as well use separate files, like NeXT/Mac bundles) or make them look like parts of the same file to what has become the de-facto file-system API (UNIX and STDIO)... in which case you might as well just store them in the file and treat the "smarter" file system as an optimization.
The main thrust of his presentation was to argue that standards (whether open or closed) were more important as long as one could licence the IP on reasonable and non-discriminatory terms.
I would agree with the first part (without the parenthesised inclusion)... open standards can be much more important than source. But the licensing terms for standards... well... the IEEE and ISO have already pushed the limits of what's acceptable there, now and then. If you can't license it on terms that allow completely free redistribution of both conforming and derived works with no royalties or further restrictions, then it's not an open standard. You can't have a "part-way open standard".
Slashdot Mirror
Just out of curiosity, what makes that better than the Tungsten E2 or the Zire?
The later Zire models and the Tungsten have much more powerful processors, to be sure, but the control layout and the poor screen protection on the Tungsten pretty much rule them out for me.
Any handheld I'm willing to consider must have a thumb controller and a vertically pivoting flipcover. That way it can be used without a bulky protective case and can be used comfortably one-handed while reading e-books. It doesn't matter if the control is a jog-wheel like the Clie, a toggle like the Casio and early Jornadas, or paired buttons like the last Jornada.
The collapsing Tungsten in particular is cute as a bug, but the design makes it impossible to protect the screen properly. The Zire models all, I believe, have a flipcover, but none of them have a thumb control.
The fact that the SJ-22 is probably the last PalmOS handheld shipped without that abomination known as "Graffiti-2" is just the icing on the cake.
And The Blabber.
And all Banks' Culture books I can get my hands on.
And Greg Egan's stuff.
I've exchanged email with some of the people who actually may have some of the source to some version of NeWS, they're not sure. It's kind of gotten lost, and they don't really think it's interesting any more. It's a shame, I was really pumped.
Now for the bad news: Arbitration and translation schemes have had unfortunate clenirations with the ridgeway armiphlage.
It maybe be the Linspire is working on changing this for real, but it won't be openly discussed.
What is there to work on? He only needs to undo.
Everyone knows that the Sony Clie SJ22 was the closest any handheld manufacturer has ever come to a perfect device, and all others must bow before its near-perfect ergonomics.
OK, I know Godwin's Law, and I know Clarke's Law and the inverse Clarke's Law (AKA Benford's Corrolary), but I forgot whose law it is that every comment complaining about someone's speeling or grammer must contain at least one grammatical error or typo...
Microkernels, and messaging, were an academic fad of 1988-1997 by which time Tanenbaum/CMU/Inria were shown to be wrong, and classic Unix e.g. Solaris; Linux correct
Well, you sure have the Official Linux Policy down pat. It's a good line of patter, pointing at a small bunch of academic systems that came along fairly late and acting as if all the earlier and still in production real-time microkernels didn't exist... or tat they're somehow "not microkernels" because they don't fit the Official Linux Policy definition of a microkernel.
The ones I've had most experience with are RSX-11 and AmigaOS, but pretty much all hard real-time systems have a similar structure. There is a huge history of successful microkernels and, no matter how much Linus was soured on them by his experience with Minix, it's an effective and efficient way to build a system. The problem with Microkernels is you have to make sure that you haven't built in single-threaded bottlenecks that every process has to work through, like the Minix file system. Monolithic kernels largely avoid this issue, at least up to the point where they have to deal with a multi-CPU environment and the simple "single kernel lock" becomes the same kind of bottleneck.
See, concurrency is hard. Both designs force you to work through concurrency problems. Microkernels hit the concurrency wall earlier, but you only have to climb over it once. Monolithic kernels have to keep adding more and more heuristics to work around it, and that itself is a cause of kernel bloat.
Which is where we came in.
what's the advantage to the kernel of moving the interfaces to be more external and require expensive marshalling?
Ah, but they only require marshalling when you cross a protection boundary. Without that, they can be as efficient as the Amiga message primitive which was four instructions long.
The C function interface does not suffice. That's the same problem that RPC mechanisms have. The C function interface is synchronous, messages can be asynchronous, they can be buffered and queued, they make concurrency implicit and invisible rather than forcing every component to be explicitly and painfully aware of it, lest they become a bottleneck.
A lot of kernel functionality could be moved outside the kernel if the intrakernel communication was regularised into some mechanism (messages, for example) that could be efficiently marshalled and moved through a user-kernel boundary.
Obviously you can't do this for everything, but you could simplify the kernel significantly if instead of separate interfaces for every kind of object a single regular interface could be used at least as a starting point. The Amiga did this, and the result was a system of rare simplicity that made quite complex components easy to implement. Matt Dillon, a long-time Amiga hacker, is working on turning the BSD kernel inside out in this way. There's no reason Linux couldn't be cleaned up and pared down the same way.
In my day students got a 300k quota on a timeshared UNIX system that was so slow that during finals week it wasn't unknown for your login to time out while getty was trying to load login to display the login prompt. Running CPU-intensive programs like NROFF was enough to get your account suspended.
An iPod has more computing power and storage than the entire undergraduate computing center did back then.
In my opinion, students should buy their own iPods, if they want them.
My system menu/dock/desktop almost make me wish I had a 17" not a 15" but now I'm rambling.
:)
I've got a 21 and I wish I had a 30.
I'm pretty down on Dashboard, but if I thought it would lead people to quit writing apps that use menu extras when they don't need to be on the screen all the time, I'd be all over it.
Unfortunately, I'm too cynical for that.
Despite the fact that you have to sign an agreement, this is certainly more "open" than a blanket rejection to everyone who requests access.
A blanket rejection can be more open, since it legitimizes reverse engineering.
I can think of plenty of companies who won't let you get details about a file format they use under any circumstances.
I have the option of not doing business with such companies. If I had the option of not doing business with Microsoft (as I have the option of not doing business with Bitkeeper) this would not be an issue, now would it?
Microsoft promoted common development of standards by sitting on all of the representative bodies working on them
You gotta laugh, I had this image of a huge lard-ass King Kong with a Bill Gates mask crushing a conference table and the committee members beneath his hairy buns.
So that when you pirate it and put it up on the web, they can nail yer wanker butt to the wall.
For a DOCUMENT FORMAT?
SUID/SGID is not flawed by design. When used as designed it's an extremely effective mechanism for privilege separation. The trick is to set*id to a user or group with the minimum necessary privileges to perform a task. Not -ing root.
Setuid scripts are a different ball of barbarian invaders.
So it can be turned on/off depending on need.
Hmmm...
Sounds like Insomnia needs a user interface to go along with the kernel extension. How about this one?
The universal search facility in Palm OS is one of its killer capabilities. It's been saving me from wasting neurons on trivia for the past 5 years, and I eagerly await an improved desktop clone of it no matter who it's from.
If they have physical access to your machine you have worse problems than worrying about root escalation.
This isn't Windows. Slowing down root escalation will at least keep the skr1pt k1ddies busy for a little while. Yes, you want to keep them out... but you don't write your PIN on the back of your teller card just because "if someone has physical access to your wallet you have worse problems than worrying about an unauthorised withdrawal".
The word "stunning" in this context doesn't normally imply praise.
Why don't you put the extension load in /Library/StartupItems so it's done on boot?
No, they intended them to be used for storing metadata about the file so it could be indexed for searching purposes (like BeOS/BFS did).
Or like the Macintosh resource fork.
Or like the elements in OS/1100 files, though they ended up being used the way files are in other operating systems, with the files themselves treated like directories.
The thing is, unless you can get all operating systems and applications to handle, preserve, and interconvert these objects, they're more trouble than they're worth. You have to either make them visible as separate files (in which case you might as well use separate files, like NeXT/Mac bundles) or make them look like parts of the same file to what has become the de-facto file-system API (UNIX and STDIO)... in which case you might as well just store them in the file and treat the "smarter" file system as an optimization.
Do you also replace the bad module when you find it?
The main thrust of his presentation was to argue that standards (whether open or closed) were more important as long as one could licence the IP on reasonable and non-discriminatory terms.
I would agree with the first part (without the parenthesised inclusion)... open standards can be much more important than source. But the licensing terms for standards... well... the IEEE and ISO have already pushed the limits of what's acceptable there, now and then. If you can't license it on terms that allow completely free redistribution of both conforming and derived works with no royalties or further restrictions, then it's not an open standard. You can't have a "part-way open standard".
a REAL laguage to extend it, Java
Java? Please tell me you mean Javascript. Java is tolerable as "C++ with less evil", but as an extension/scripting language? Dear god.