If that's the only restriction, I don't see a problem and would still consider it a very useful open source release. The company and end users both have an interest in keeping the format standardized. You still have great latitude in improving the code, like speeding it up or porting it.
I think the rest of the license needs to be reviewed carefully to see whether this is truly an open source release or whether you need to pay money if you actually want to use the code for encoding/decoding video.
Even then, however, I would still consider it preferable to Sorenson and other proprietary CODECs: if you can get the source code, at least your content will never become inaccessible even if the company goes out of business.
I'd put my money on...
on
Electronic Paper
·
· Score: 5, Insightful
organic LEDs in the short term. They seem more likely to result in small, flexible, high-quality displays in the short term. Flexible active-matrix LCDs of acceptable quality seem further off at this point.
But neither of those, in my opinion, qualifies as "electronic paper". What distinguishes "electronic paper" from other kinds of displays is that it retains its contents even in the complete absence of power; with real "electronic paper" you only need power to change the display.
Which Um... just happens to be the particular kind of desktop users called: "the professional market"
There are lots of people who work with video for a living and make technical decisions about what to deploy. If you like to reserve the term "professional" in this case to people who fiddle with video in interactive applications on their desktop machines for a living, fine. However, whatever you call them, those people are not the ones who have the technical qualifications to make decisions about what makes a good archival or streaming format.
You argue convincingly that users should archive their Quicktime movies using open standard codecs but that doesn't really have anything to do with using quicktime or MPEG-4 as a container.
Sure it does. The Quicktime approach enables a profusion of variants that is undesirable in an archival format, and it adds a completely unnecessary degree of complexity for the purposes of exchanging and archiving video (even if it is conceivably useful to some of your "professionals" in their desktop applications).
I didn't make any claims about whether Moore's law holds. I simply pointed out that if it holds, it doesn't take until the "end of the universe" to catch up with larger key lengths because Moore's law is exponential, just like the thing it's trying to catch up with.
As for whether Moore's law will actually fail in 12 years or not, that remains to be seen. Looking at current processor designs tells you nothing about that: current processor and systems designs should have been abandoned decades ago. The only reason we still stick with them is because it has been easier to push processes than design. I very much hope we'll hit the limit on processes soon so that we can then focus on getting better performance through better overall systems design.
The other layer of ignorance is that MPEG-4 is also a container method for compressed audio and video streams. In fact its very similar to Quicktime (the packaging standard) indeed because it is actually _based on_ Quicktime!
[...] If I was more naive I'd say I can't believe CNET were presenting the "move" to MPEG4 as a retreat for Quicktime. MPEG 4 is the standardization of Quicktime and a vindication of its owenership of the professional market! Are they stupid or deliberately spinning it - you decide!
For this and many other reasons, MPEG-4 may simply fail to address the needs that an audio/video standard should address, primarily something that is fully and completely documented and hence can be used for archiving video in a way that is guaranteed to be accessible independent of any particular platform or proprietary and undocumented "plug-ins". This is a basic problem with Quicktime in many applications, and it is perpetuated in similar form in MPEG-4. And it may turn out to be a Pyrrhic victory for Apple, as people end up using other video formats that satisfy their needs better, or as some subset of MPEG-4 becomes the de-facto standard. More features really isn't always better when it comes to standards or software.
As for "owning" the "professional market", Quicktime "owns" a particular market segment of a particular kind of desktop users. It is far from the dominant digital video coding format in the world--that honor probably goes to MPEG and MPEG-2. And while Quicktime may be useful for editing and other manipulations on a Macintosh or Windows machine, people working with it would do well to reflect on archival and cross-platform issues when storing video more permanently and distributing it.
Um. If you double compute speed every 18 months, compute power is growing exponentially as well, and you lose one bit of key security every 18 months. It takes years, not eons, to catch up.
In addition, AES may have problems we don't even know yet. DES turned out not to require brute forcing.
Joel's approach (you know, never rewrite from scratch, VB is the best thing since sliced bread, etc.) works in a sense: it's what has made Microsoft such a successful company and lets him churn out Windows applications. Yes, rewriting is bad for business.
But, frankly, I don't care. I loathe the kind of incrementalism that the software industry practices and that results in the kind of commercial software we are getting. If it takes 9 failures to produce something great on the 10th try, great, so be it. The alternative, decades of slowly evolving, uninspired, tedious, bloated, market dominant software is much worse for anybody other than the software publisher. Software needs competition and failure, just like biology and economics.
Of course, failures are painful. Investors and managers don't like them and will anything to avoid them. But, hey, that's probably one of the reasons I prefer open source software. On a project that has no commercial aspirations, you can afford to fail and start over.
I think their position is that people are creating and distributing a German translation of English content that is copyrighted by them. That seems like a valid point to me, and it is probably enforceable under copyright law.
You may still be able to make other modifications to their software and distribute the patches, whether they like it or not.
Of course, instead of contributing to a commercial game without getting compensated for your work, why not just contribute to FreeCiv or similar games? Civilization itself seems mostly like a clone of older games anyway.
To me, it makes a lot of sense to have a plugin architecture for video.
Yes, it makes a lot of sense to have a plug-in architecture at the level of your libraries so that application writers don't have to worry about handling different formats.
But Quicktime goes further: it makes it appear as if files encoded with different CODECs are all the same type and just magically work. Furthermore, Quicktime is commonly used with proprietary CODECs, whether or not that is theoretically necessary. The generality of Quicktime that you correctly point out causes additional problems.
The net effect is that almost all Quicktime is not archival and cannot (easily) be viewed on anything other than Macintosh or Windows machines. People like you who create the content often don't even think anything is wrong (until 10 years from now, you try to get at your old video files and can't). And people like me who write software for processing video end up with lots of headaches because what works fine on your desktop is a big pain trying to get to work on a server, if one can get it to work at all.
So, my point is still: Quicktime is a business strategy for Apple, and it's a good one. I don't expect it to go away, but I hope people like you will think more about archival issues and accessibility of their content.
You're on the right track. Yes, indeed, Quicktime allows many CODECs to be used. In particular, it allows proprietary, undocumented CODECs to be used. And that is why Quicktime content often ends up in proprietary, undocumented formats. By supplying both the container and a number of proprietary CODECs, Apple gets a great deal of control and a lucrative business.
MPEG-2, on the other hand, is a complete format for audio and video. It does not allow you to "plug in" arbitrary CODECs, which is why content in it ends up being conformant with a published specification and will remain accessible in the future. MPEG-2 is not state-of-the-art anymore, but it is good enough for a lot of content. And rather than replacing it with something like Quicktime, we should be replacing it with another documented video compression standard that does not allow proprietary plug-ins. (I'm not sure MPEG-4 fits the bill, but we'll see.)
(Incidentally, you do not need Quicktime to combine MPEG audio and video streams; MPEG formats contain both.)
Hold Apple responsible? Yeah, nice idea. How about we hold Microsoft responsible for the forking of the GUI world? Or Linus for the forking of the Unix world?
You are confusing APIs and streaming/archival formats. I don't care what kind of formats you or Apple use for authoring or in the privacy of your own home.
What I care about is the fact that huge amounts of video data of public interest are being stored in a proprietary format that only Apple has the keys to.
Unless you have pointers to a project working on a cross-platform multimedia architecture then methinks you haven't the foggiest.
See, unlike you, I actually have developed video software. I don't want Apple's "architecture". In fact, dealing with Quicktime has been one of the most problematic issues when developing cross-platform solutions. I want a reasonably high quality, publically documented interchange and streaming format that I can use together with libraries and viewers of my choosing. And I don't want a couple of companies to hold the keys to media content.
Controlling video content is a lucrative business and Apple's business strategy has been deliberate. But there is no reason that the rest of the world should go for that. Video content is too important to leave it at the whims of a couple of big software companies with uncertain futures.
As a "digital media specialist", I think you should think a little further than just the next web site.
Apple envisioned a media format which was extensible and flexible.
Apple envisioned a media format which was maximally under their control, and at that they have succeeded. Quicktime's plug-in architecture was a further attempt by Apple to tie users to its software. Quicktime is a marketing and business construct, not a technical one.
Technically, there is little reason to put animation, MPEG video, audio, and other features all into the same viewer: the amount of content that usefully mixes multiple formats is negligible. And technically, there is every reason not to have "plug-ins": you want well-defined, standardized codecs, not a profusion of proprietary codecs.
I'm kind of glad to see Quicktime losing market share to alternatives. While the alternative are just as proprietary, they may show that Apple's gamble is not working in the long term. Maybe if Apple sees itself excluded from its own home turf by Microsoft, Apple will adopt open standards next time around.
No, Apple did not invent desktop multimedia. The MPEG working group was established in 1988, and other codecs for digital audio and video were around long before that.
I would view Quicktime as more of what big software companies keep doing: using their market position to push through a proprietary document standard. Video ought to be encoded in open, non-proprietary formats, but thanks to Apple, Microsoft, and RealNetworks, almost all our on-line video content requires you to use proprietary software, and almost all our on-line video content will become inaccessible in a few years.
We shouldn't be grateful to Apple for this; to the contrary: we should hold Apple responsible and make sure this doesn't happen again in the future.
If we were talking about some mid-level manager or expert on computer security, I would agree with your statement: there are competent people at Microsoft and you can't blame them for problems throughout Microsoft's product line.
But Schmidt is just "some guy at Microsoft", he is "Microsoft's Chief Security Advisor". As the Chief Security Advisor, he can't say "I'm really quite good, but I just can't get security at this company under control". Getting the company under control is part of the job. In large, hierarchical organization, the buck stops there, and it is justifiable to equate a top-level position with top-level responsibility. If people feel they can't be judged by the record of their part of the organization, they can always step aside.
As for expertise, Microsoft doesn't strike me as a company that has a lot of expertise with "huge, varied networks". In fact, their likely lack of extensive in-house expertise with the kinds of computing systems found in the US government is another factor that raises doubts about this choice.
Re:Why can't anyone see the implications of this?
on
This is IT?
·
· Score: 2
NY could do solve some huge problems with widespread adoption of this.
Someone who thinks that it would be feasible for lots of people to ride around on one of these on busy NYC sidewalks can't be from NYC.
why do you think it's safer?
on
This is IT?
·
· Score: 2
I don't see why IT should be any safer than a bicycle in similar traffic conditions. The only thing that might make it safer is if you permit it on sidewalks, but then, why not permit slow-moving bicycles on sidewalks as well?
Was he responsible for all the holes in Microsoft code over the years?
As security advisor at Microsoft, his job presumably was to define policies that keep those holes from getting into the software and/or to keep Microsoft's sites secure. Microsoft's products are full of holes and their services have suffered major security compromises, so he can't have been very effective.
Since his new role will be similar in nature, it seems reasonable to suspect that he will be equally ineffective at defining national policies to protect our national security infrastructure.
Well, maybe he quit Microsoft in disgust and is trying to do the right thing: push for open source, peer-reviewed, secure systems. But, more likely, he has been imbued with Microsoft corporate policy, still has a financial and personal interest in the company, and has never known another way of doing things besides the Microsoft way.
If the latter is the case, there is a good chance that this guy will follow the easy and obvious (to laymen) path and push Windows. After all, NT was created by someone with decades of experience and it is 'C4' certified (or whatever). It has zillions of security features, even more so than VMS, so how could it not be secure? And it is used by some of the most security conscious companies in the world. And what's good for Microsoft is good for America anyway. At least those will be the arguments that will likely be heard around the White House when issues about what software infrastructure the armed services and US government should use.
This will be followed by calls for keeping source code for criticial infrastructure under wraps, "like Microsoft is already doing", because "we don't want to give the terrorists the blueprints to our advanced technology". He'll probably preach the Microsoft mantra that open source is dangerous, unsafe, and un-American. And he'll likely conflate "security" RIAA style (fair use hijacking) with national security and point to how badly the RIAA and MPAA has been "hurt" by "security problems" resulting from "open source hackers" and how Microsoft, in contrast, keeps content "secure" and protects copyright holder's rights.
Altogether, this appointment is likely going to hurt open source efforts, as well as national information security.
People were born with certain characteristics for a reason, be they "normalities" or "defects".
Yeah, and the reason is that a stray cosmic ray, or, more likely, some noxious industrial chemical, altered their DNA. Or it may be an accident or disease. Ultimately, people afflicted by these limitations will have to decide for themselves. I suspect most quadriplegics or people with terminal liver disease will choose to be "normal".
I think "humanity" would be an awfully cold concept if everyone had everything "fixed" and no one had any differences or "defects".
Don't worry: even among the many available choices to humans, there are still many tradeoffs to be made: do you want to live a long life, be a great runner, be a great weight lifter, look incredibly good, or be incredibly smart? You will probably have to choose one of them because many of the traits are mutually exclusive.
more obesity
on
This is IT?
·
· Score: 3, Insightful
Walking is probably the single most important defence against obesity. Zipping around on a little motorized scooter deprives you of even that minimal exercise. If you need to travel moderate distances and walking is too slow, use a bicycle. There are some nifty compact folding bicycles that are cheap, easy to store, and don't require a battery.
It's also not clear where you are supposed to use these things. Using them in traffic seems more unsafe than a bicycle (since you are even less visible and have even less protection in front of you), but riding anything motorized at 15mph on the sidewalk seems both rude and dangerous. And these things are too slow for bicycle lanes.
A cynic might say that this is simply an attempt to boost sales of one of Kamen's other technologies: automatic insulin pumps, since obesity is the leading cause of diabetes.
The white paper doesn't say that it is "primarily designed for Internets". To the contrary. Go read the article yourself.
It makes even less sense on an intranet than it does on an extranet. On intranets, files usually live on file servers, and that's where most intranets already provide web access. Most machines on intranets are also rarely turned off.
Finally, bundling rsync in a user-friendly package is a lot easier than inventing a completely new service.
You *CAN* run X11 apps under QPE. You can either use the QPE VNC viewer or run QPE and X11 from FBVNC (Frame Buffer VNC).
A VNC viewer doesn't give you the ability to run X11 applications. Even if you add an VNC server to the mix, you end up with a system where the Qt/Embedded applications are integrated (drag-and-drop, cut-and-paste, window management), while the X11 applications are second class and suffer the overhead of going through VNC. Sorry, that is not an attractive proposition.
Also, work is being done to run QPE itself under X11. These methods all cause a minor performance hit, but with a 206mhz CPU, it's hardly noticeable.
Running QPE under X11 shouldn't be a problem, but someone still needs to port an X11 server to the Sharp and Sharp needs to update their distribution. When that happens, the Sharp will become my first choice of Linux PDA, since it is otherwise a nifty device. Until that happens, the Sharp is fatally flawed, IMO.
That's pretty easy: redirect the hot air into an exhaust system that heats a heat store. At night, recover the heat to heat your house. If you have A/C (heat pumps), that's even easier.
Slashdot Mirror
I think the rest of the license needs to be reviewed carefully to see whether this is truly an open source release or whether you need to pay money if you actually want to use the code for encoding/decoding video.
Even then, however, I would still consider it preferable to Sorenson and other proprietary CODECs: if you can get the source code, at least your content will never become inaccessible even if the company goes out of business.
But neither of those, in my opinion, qualifies as "electronic paper". What distinguishes "electronic paper" from other kinds of displays is that it retains its contents even in the complete absence of power; with real "electronic paper" you only need power to change the display.
There are lots of people who work with video for a living and make technical decisions about what to deploy. If you like to reserve the term "professional" in this case to people who fiddle with video in interactive applications on their desktop machines for a living, fine. However, whatever you call them, those people are not the ones who have the technical qualifications to make decisions about what makes a good archival or streaming format.
You argue convincingly that users should archive their Quicktime movies using open standard codecs but that doesn't really have anything to do with using quicktime or MPEG-4 as a container.
Sure it does. The Quicktime approach enables a profusion of variants that is undesirable in an archival format, and it adds a completely unnecessary degree of complexity for the purposes of exchanging and archiving video (even if it is conceivably useful to some of your "professionals" in their desktop applications).
As for whether Moore's law will actually fail in 12 years or not, that remains to be seen. Looking at current processor designs tells you nothing about that: current processor and systems designs should have been abandoned decades ago. The only reason we still stick with them is because it has been easier to push processes than design. I very much hope we'll hit the limit on processes soon so that we can then focus on getting better performance through better overall systems design.
Brute forcing keys is fully parallelizable, so for this case, Moore's law does translate into speed.
For this and many other reasons, MPEG-4 may simply fail to address the needs that an audio/video standard should address, primarily something that is fully and completely documented and hence can be used for archiving video in a way that is guaranteed to be accessible independent of any particular platform or proprietary and undocumented "plug-ins". This is a basic problem with Quicktime in many applications, and it is perpetuated in similar form in MPEG-4. And it may turn out to be a Pyrrhic victory for Apple, as people end up using other video formats that satisfy their needs better, or as some subset of MPEG-4 becomes the de-facto standard. More features really isn't always better when it comes to standards or software.
As for "owning" the "professional market", Quicktime "owns" a particular market segment of a particular kind of desktop users. It is far from the dominant digital video coding format in the world--that honor probably goes to MPEG and MPEG-2. And while Quicktime may be useful for editing and other manipulations on a Macintosh or Windows machine, people working with it would do well to reflect on archival and cross-platform issues when storing video more permanently and distributing it.
In addition, AES may have problems we don't even know yet. DES turned out not to require brute forcing.
But, frankly, I don't care. I loathe the kind of incrementalism that the software industry practices and that results in the kind of commercial software we are getting. If it takes 9 failures to produce something great on the 10th try, great, so be it. The alternative, decades of slowly evolving, uninspired, tedious, bloated, market dominant software is much worse for anybody other than the software publisher. Software needs competition and failure, just like biology and economics.
Of course, failures are painful. Investors and managers don't like them and will anything to avoid them. But, hey, that's probably one of the reasons I prefer open source software. On a project that has no commercial aspirations, you can afford to fail and start over.
You may still be able to make other modifications to their software and distribute the patches, whether they like it or not.
Of course, instead of contributing to a commercial game without getting compensated for your work, why not just contribute to FreeCiv or similar games? Civilization itself seems mostly like a clone of older games anyway.
Yes, it makes a lot of sense to have a plug-in architecture at the level of your libraries so that application writers don't have to worry about handling different formats.
But Quicktime goes further: it makes it appear as if files encoded with different CODECs are all the same type and just magically work. Furthermore, Quicktime is commonly used with proprietary CODECs, whether or not that is theoretically necessary. The generality of Quicktime that you correctly point out causes additional problems.
The net effect is that almost all Quicktime is not archival and cannot (easily) be viewed on anything other than Macintosh or Windows machines. People like you who create the content often don't even think anything is wrong (until 10 years from now, you try to get at your old video files and can't). And people like me who write software for processing video end up with lots of headaches because what works fine on your desktop is a big pain trying to get to work on a server, if one can get it to work at all.
So, my point is still: Quicktime is a business strategy for Apple, and it's a good one. I don't expect it to go away, but I hope people like you will think more about archival issues and accessibility of their content.
MPEG-2, on the other hand, is a complete format for audio and video. It does not allow you to "plug in" arbitrary CODECs, which is why content in it ends up being conformant with a published specification and will remain accessible in the future. MPEG-2 is not state-of-the-art anymore, but it is good enough for a lot of content. And rather than replacing it with something like Quicktime, we should be replacing it with another documented video compression standard that does not allow proprietary plug-ins. (I'm not sure MPEG-4 fits the bill, but we'll see.)
(Incidentally, you do not need Quicktime to combine MPEG audio and video streams; MPEG formats contain both.)
You are confusing APIs and streaming/archival formats. I don't care what kind of formats you or Apple use for authoring or in the privacy of your own home.
What I care about is the fact that huge amounts of video data of public interest are being stored in a proprietary format that only Apple has the keys to.
Unless you have pointers to a project working on a cross-platform multimedia architecture then methinks you haven't the foggiest.
See, unlike you, I actually have developed video software. I don't want Apple's "architecture". In fact, dealing with Quicktime has been one of the most problematic issues when developing cross-platform solutions. I want a reasonably high quality, publically documented interchange and streaming format that I can use together with libraries and viewers of my choosing. And I don't want a couple of companies to hold the keys to media content.
Controlling video content is a lucrative business and Apple's business strategy has been deliberate. But there is no reason that the rest of the world should go for that. Video content is too important to leave it at the whims of a couple of big software companies with uncertain futures.
As a "digital media specialist", I think you should think a little further than just the next web site.
Apple envisioned a media format which was maximally under their control, and at that they have succeeded. Quicktime's plug-in architecture was a further attempt by Apple to tie users to its software. Quicktime is a marketing and business construct, not a technical one.
Technically, there is little reason to put animation, MPEG video, audio, and other features all into the same viewer: the amount of content that usefully mixes multiple formats is negligible. And technically, there is every reason not to have "plug-ins": you want well-defined, standardized codecs, not a profusion of proprietary codecs.
I'm kind of glad to see Quicktime losing market share to alternatives. While the alternative are just as proprietary, they may show that Apple's gamble is not working in the long term. Maybe if Apple sees itself excluded from its own home turf by Microsoft, Apple will adopt open standards next time around.
I would view Quicktime as more of what big software companies keep doing: using their market position to push through a proprietary document standard. Video ought to be encoded in open, non-proprietary formats, but thanks to Apple, Microsoft, and RealNetworks, almost all our on-line video content requires you to use proprietary software, and almost all our on-line video content will become inaccessible in a few years.
We shouldn't be grateful to Apple for this; to the contrary: we should hold Apple responsible and make sure this doesn't happen again in the future.
But Schmidt is just "some guy at Microsoft", he is "Microsoft's Chief Security Advisor". As the Chief Security Advisor, he can't say "I'm really quite good, but I just can't get security at this company under control". Getting the company under control is part of the job. In large, hierarchical organization, the buck stops there, and it is justifiable to equate a top-level position with top-level responsibility. If people feel they can't be judged by the record of their part of the organization, they can always step aside.
As for expertise, Microsoft doesn't strike me as a company that has a lot of expertise with "huge, varied networks". In fact, their likely lack of extensive in-house expertise with the kinds of computing systems found in the US government is another factor that raises doubts about this choice.
Someone who thinks that it would be feasible for lots of people to ride around on one of these on busy NYC sidewalks can't be from NYC.
I don't see why IT should be any safer than a bicycle in similar traffic conditions. The only thing that might make it safer is if you permit it on sidewalks, but then, why not permit slow-moving bicycles on sidewalks as well?
As security advisor at Microsoft, his job presumably was to define policies that keep those holes from getting into the software and/or to keep Microsoft's sites secure. Microsoft's products are full of holes and their services have suffered major security compromises, so he can't have been very effective.
Since his new role will be similar in nature, it seems reasonable to suspect that he will be equally ineffective at defining national policies to protect our national security infrastructure.
If the latter is the case, there is a good chance that this guy will follow the easy and obvious (to laymen) path and push Windows. After all, NT was created by someone with decades of experience and it is 'C4' certified (or whatever). It has zillions of security features, even more so than VMS, so how could it not be secure? And it is used by some of the most security conscious companies in the world. And what's good for Microsoft is good for America anyway. At least those will be the arguments that will likely be heard around the White House when issues about what software infrastructure the armed services and US government should use.
This will be followed by calls for keeping source code for criticial infrastructure under wraps, "like Microsoft is already doing", because "we don't want to give the terrorists the blueprints to our advanced technology". He'll probably preach the Microsoft mantra that open source is dangerous, unsafe, and un-American. And he'll likely conflate "security" RIAA style (fair use hijacking) with national security and point to how badly the RIAA and MPAA has been "hurt" by "security problems" resulting from "open source hackers" and how Microsoft, in contrast, keeps content "secure" and protects copyright holder's rights.
Altogether, this appointment is likely going to hurt open source efforts, as well as national information security.
Yeah, and the reason is that a stray cosmic ray, or, more likely, some noxious industrial chemical, altered their DNA. Or it may be an accident or disease. Ultimately, people afflicted by these limitations will have to decide for themselves. I suspect most quadriplegics or people with terminal liver disease will choose to be "normal".
I think "humanity" would be an awfully cold concept if everyone had everything "fixed" and no one had any differences or "defects".
Don't worry: even among the many available choices to humans, there are still many tradeoffs to be made: do you want to live a long life, be a great runner, be a great weight lifter, look incredibly good, or be incredibly smart? You will probably have to choose one of them because many of the traits are mutually exclusive.
It's also not clear where you are supposed to use these things. Using them in traffic seems more unsafe than a bicycle (since you are even less visible and have even less protection in front of you), but riding anything motorized at 15mph on the sidewalk seems both rude and dangerous. And these things are too slow for bicycle lanes.
A cynic might say that this is simply an attempt to boost sales of one of Kamen's other technologies: automatic insulin pumps, since obesity is the leading cause of diabetes.
It makes even less sense on an intranet than it does on an extranet. On intranets, files usually live on file servers, and that's where most intranets already provide web access. Most machines on intranets are also rarely turned off.
Finally, bundling rsync in a user-friendly package is a lot easier than inventing a completely new service.
A VNC viewer doesn't give you the ability to run X11 applications. Even if you add an VNC server to the mix, you end up with a system where the Qt/Embedded applications are integrated (drag-and-drop, cut-and-paste, window management), while the X11 applications are second class and suffer the overhead of going through VNC. Sorry, that is not an attractive proposition.
Also, work is being done to run QPE itself under X11. These methods all cause a minor performance hit, but with a 206mhz CPU, it's hardly noticeable.
Running QPE under X11 shouldn't be a problem, but someone still needs to port an X11 server to the Sharp and Sharp needs to update their distribution. When that happens, the Sharp will become my first choice of Linux PDA, since it is otherwise a nifty device. Until that happens, the Sharp is fatally flawed, IMO.
That's pretty easy: redirect the hot air into an exhaust system that heats a heat store. At night, recover the heat to heat your house. If you have A/C (heat pumps), that's even easier.