There's a project going on now to port Linux to the MIPS processor, with complete emphasis on the mini, till now CE type devices. The Clio is the big one, in fact. The folks on the project actually have a Linux Kernel running in ROM on a Clio, I believe!
Power sucks- the Clio isn't exactly long life (look ma, I'm on topic:)
The fact that Linux isn't really built for living in in such cramped quarters (except maybe now it is- any word on Mobile Linux from our fearless leader?)
The lack of little, artsy apps in a light framework to run on the thing (except I hear Squeak is going well for you Dynabooky types, and then there's always the Gimp, if it could be pared down... And its only a matter of time till somebody smart builds a Flash editor, now that the format is open...And some professional music sequencing software is coming out here, too, some of it has to be smallish...And then there's film editing stuff..never mind)
umm.. did I mention power?
The Clio's design may be copyrighted (You'll have to ask Vadem about that...)
Where are the Open Source PalmOS nerds? While uCLinux looks really neat, It's not palmOS by any measure. Linux was just conceived to do different stuff. There is also a company called OSK who claim to have a Linux and PalmOS compatable operating system, with the base open source, since they'd be in violation of the Linux license if it wasn't. Besides, it seems like a PalmOS emulator running on top of Linux...
Is there, to anyone's knowledge
An open sourced, teeny lil' OS that will run on Dragonball Processors, is a single task, messaging based, and has a data storage abstraction like PalmOS databases?
Barring that, is there any attempt to clone the PalmOS interface in an efficient, open source implementation? Would this kind of thing be legal?
Barring both of the above, is there at least a community of Open Source development for PalmOS out there anywhere? And how would one get in touch with that community?
From a very, very cursory perusal of the site, I get the following impression of what this thing actually is.
From the look of it, its a way for programs to invoke RPC's from hosts they don't know exist. That is:
Suppose My coffee maker wants to know the time, and its sitting on a network in my Home Of The Future® It can query the local e-speak server server (e-speak core???) for a service with the appropriate properties (must have TimeZone=>GMT, must have Precision=>microsecond, must have Name=>Time, etc), and then follow it up with a call to the *right* server's services. shazam.
This could be really cool, not just for coffee (which is pretty neat to start with) but for the ultra-thin cell phone-futurerama devices everyone is so keen on ushering into reality. And cool or not, it could be very popular with the "Now I don't have to worry about the license at all 'cuz I'm not distributing the software at all just the service' crowd.
There might come a day when open services are the name of the game- when we not only have to see that software has source shipped with distributions, but that Completely Documented Service API's are published (And the only way to do that, really, is expose the source). It would really bite to have to get a Micro$oft coffe maker to get the most out of my Micro$oft Microwave, which I got because it was the only kind that could use the Micro$oft clock-radio correctly... We may be compelled to establish our own network of services on this second chapter of the internet that HP is so cheery about (and hey, I can't say I'm not, it'll be an excuse to buy a pilot...). An open source service negotiation protocol is a great start, but from the look of things, it may be uphill from here.
It seems like the right to fork, far from being a liability of the GPL, is a signifigant strength. Its a way to get a bunch of random people to work very hard to reconcile their visions of what a system should be like- nobody wants a code fork, so people try very hard to work together.
On the other hand, when visions are really irreconciliable, the option to fork can be a good thing- Lots of people like Xemacs, and lots of other people like emacs classic, and this code fork let those people do there thing where it was needed. And both emaxen are open source. Everybody still wins.
With the Artistic license things seem to become much more difficult. A lot more responsibility rests with the community- If MegaCorp markets 'MegaPerl', complete with non-standard name & clear documentation of differences, the perl community has to catch up, and quick. Especially when MegaCorp starts introducing Value Adding Incompatabilities® That nobody else gets to see... If one fork of emacs dies tomorrow nobody loses. If perl dies and MegaPerl continues everyone does.
The way to deal with this is aggressive development and promotion. Perl has this, thanks to an amazing community with great leadership. Ad as long as that keeps up, and new features keep getting added to the system, MegaPerl is doomed to failure. But they live in a much more dangerous place than their GPL'd bretheren.
There really a large existing body of work concerning a philosophy of technology, whether you're in for the "Philosophy as it Should Be" (at the philosophy department of your local U) or "Philosopy as it Is" (the engineering department of your local tech company, the sales rep at your local quik-e-mart). I would actually be very interested in a reading list or beginners bibliography pertaining to either subject.
As it stands, here are a few resources I have found interesting and useful:
Downey, Gary Lee : _The_Machine_In_Me_ This is a damn good book chronicling a slice of the rise and fall of CAD/CAM mania in the 80's- There are a lot of visions that parallel Mr. Katz's vision of Uncle Walt's vision, and some of the realities that conflicted with/resulted from that sort of thinking. This is a reallly in depth study of philosophy type B (quik-e-mart)
Heidegger, Martin : _The_Question_Concerning_Technology_ This is an essay of the other type (phil. department) and it is heavy- It took me weeks of reading and re-reading to get a foggy notion of what was going on, and my notion is still probably pretty foggy ("Engineers don't need that liberal-arts garbage" thunders a someone at a curriculum planning meating in my distant past...) But It has really changed the way I think about the work that I do in a fundamental way.
(Drifting off of the topic, I would really, really, *really* like to see a "philosophy department philosophy of technology for the rest of us" somewhere- maybe even here at/.???)
Slashdot Mirror
There's a project going on now to port Linux to the MIPS processor, with complete emphasis on the mini, till now CE type devices. The Clio is the big one, in fact. The folks on the project actually have a Linux Kernel running in ROM on a Clio, I believe!
(Cooler people than me have the details here)
The depressing hang-ups at this point are really:
The Clio's design may be copyrighted (You'll have to ask Vadem about that...)
Where are the Open Source PalmOS nerds? While uCLinux looks really neat, It's not palmOS by any measure. Linux was just conceived to do different stuff. There is also a company called OSK who claim to have a Linux and PalmOS compatable operating system, with the base open source, since they'd be in violation of the Linux license if it wasn't. Besides, it seems like a PalmOS emulator running on top of Linux...
Is there, to anyone's knowledge
From a very, very cursory perusal of the site, I get the following impression of what this thing actually is.
From the look of it, its a way for programs to invoke RPC's from hosts they don't know exist. That is:
Suppose My coffee maker wants to know the time, and its sitting on a network in my Home Of The Future® It can query the local e-speak server server (e-speak core???) for a service with the appropriate properties (must have TimeZone=>GMT, must have Precision=>microsecond, must have Name=>Time, etc), and then follow it up with a call to the *right* server's services. shazam.
This could be really cool, not just for coffee (which is pretty neat to start with) but for the ultra-thin cell phone-futurerama devices everyone is so keen on ushering into reality. And cool or not, it could be very popular with the "Now I don't have to worry about the license at all 'cuz I'm not distributing the software at all just the service' crowd.
There might come a day when open services are the name of the game- when we not only have to see that software has source shipped with distributions, but that Completely Documented Service API's are published (And the only way to do that, really, is expose the source). It would really bite to have to get a Micro$oft coffe maker to get the most out of my Micro$oft Microwave, which I got because it was the only kind that could use the Micro$oft clock-radio correctly... We may be compelled to establish our own network of services on this second chapter of the internet that HP is so cheery about (and hey, I can't say I'm not, it'll be an excuse to buy a pilot...). An open source service negotiation protocol is a great start, but from the look of things, it may be uphill from here.
It seems like the right to fork, far from being a liability of the GPL, is a signifigant strength. Its a way to get a bunch of random people to work very hard to reconcile their visions of what a system should be like- nobody wants a code fork, so people try very hard to work together.
On the other hand, when visions are really irreconciliable, the option to fork can be a good thing- Lots of people like Xemacs, and lots of other people like emacs classic, and this code fork let those people do there thing where it was needed. And both emaxen are open source. Everybody still wins.
With the Artistic license things seem to become much more difficult. A lot more responsibility rests with the community- If MegaCorp markets 'MegaPerl', complete with non-standard name & clear documentation of differences, the perl community has to catch up, and quick. Especially when MegaCorp starts introducing Value Adding Incompatabilities® That nobody else gets to see... If one fork of emacs dies tomorrow nobody loses. If perl dies and MegaPerl continues everyone does.
The way to deal with this is aggressive development and promotion. Perl has this, thanks to an amazing community with great leadership. Ad as long as that keeps up, and new features keep getting added to the system, MegaPerl is doomed to failure. But they live in a much more dangerous place than their GPL'd bretheren.
There really a large existing body of work concerning a philosophy of technology, whether you're in for the "Philosophy as it Should Be" (at the philosophy department of your local U) or "Philosopy as it Is" (the engineering department of your local tech company, the sales rep at your local quik-e-mart). I would actually be very interested in a reading list or beginners bibliography pertaining to either subject.
As it stands, here are a few resources I have found interesting and useful:
This is a damn good book chronicling a slice of the rise and fall of CAD/CAM mania in the 80's- There are a lot of visions that parallel Mr. Katz's vision of Uncle Walt's vision, and some of the realities that conflicted with/resulted from that sort of thinking. This is a reallly in depth study of philosophy type B (quik-e-mart)
This is an essay of the other type (phil. department) and it is heavy- It took me weeks of reading and re-reading to get a foggy notion of what was going on, and my notion is still probably pretty foggy ("Engineers don't need that liberal-arts garbage" thunders a someone at a curriculum planning meating in my distant past...) But It has really changed the way I think about the work that I do in a fundamental way.
(Drifting off of the topic, I would really, really, *really* like to see a "philosophy department philosophy of technology for the rest of us" somewhere- maybe even here at /.???)