Oh, cool! Is this true of just the new iBooks, or the older ones as well?
The Cube: A failure of market differentiation
on
Apple Dumps the Cube
·
· Score: 3
If you're price-sensitive on hardware purchases, Apple will exasperate you. I'm an admitted cheapskate; I have a quite a few single-purpose boxes, and if I spent a lot of money on each one, I'd exhaust my new-toy budget for the year pretty quickly. I wanted to play with OS X; since Apple hardware is a Really Big Dongle for their system software, I had to buy a Mac.
So the first thing I do, like any good mail order weenie, is go looking around on Pricewatch, various Mac-specific web sites etc looking for what the prices are for various kinds of hardware. Well, it turns out that just about every new Mac is priced within about $5 of the online Apple Store. That seems strange, especially considering that most of the big online retailers have their own "we'll throw in 256M/a printer/a scanner/a bunch of media" incentives. The simplest explanation for this seems to be that Apple prohibits its authorized dealers from advertising or competing on lower price, but still allows bundles for differentiation. Well, at least this makes price comparison shopping for new hardware very easy....
Now it's time to go looking for used machines and hit the auction sites. Well, in order to do that, I gotta understand what the specs of the various boxes are. So after a few evenings of trying to understand how the prices and specs work out, here's what I conclude:
There's a very steep price gradient between "pro" hardware and "consumer" hardware; much steeper than anything in the PC world. Obviously, a cheapskate like me should be looking at consumer hardware.
All the consumer hardware is crippled in some way, probably to annoy the feature-sensitive into buying the "pro" hardware. The old-style iBooks have 800x600 displays. The new ones have 1024x768. If you're not careful, the iMac you get won't have VGA out; if it does, like the iBook, it's limited to "mirroring", so your nice big 21" monitor is stuck at 1024x768. The cheap and awful monitor in the iMac might count too.
Sometimes the crippling can be worked around. Rumor has it that the iMac's ATI video hardware can do much higher resolutions; you just need to open up the machine and yank the connection to the internal monitor. The possibility of uncrippling is, I think, the reason the undocumented expansion connector in the original iMac was yanked in later revisions. Third parties had made SCSI and 3d cards for it, and that interfered with Apple's controlled plans for the hardware. (For a few revs, the board still supported the cards if you soldered your own connector onto the PCB!)
So where does this put the Cube? Well, that's the problem. What I really wanted was a headless iMac. The Cube seemed pretty close because of its small size, no fan, and limited expandability. But it has a G4 and allows decent video resolutions, so Apple priced it like a "pro" system.
I think there would be a huge market for a headless iMac. But an important part of the iMac is low cost. And people who want a non-tiny monitor are just the people that Apple wants to squeeze for as many dollars per unit as they can get. As long as Apple has control over all the hardware that can run OS 9/OS X software, they'll probably continue to segment their market, sometimes with artificial limitations, to maximize profit from customers who are less price sensitive.
In general, PC hardware manufacturers can't do this. I can plop a GeForce 2 MX in Ye Olde Celeron 450 if I want video resolution. I can put a Maxtor 1394 card in any old PC. And if nVidia or Maxtor decides to artificially cripple their low-end cards to try to make more high-end sales, their competitors will eat their lunch. In fact, the only big player who has much luck with this kind of market segmentation is Intel (Celeron/P3/P4/Xeon), and AMD is...eating their lunch.
All this could change at MWNY, but I bet there will still be significant limitations designed into whatever new iMac is announced.
University patents created as a result of federal funding are covered by the Bayh-Dole Act. The Council on Governmental Relations has a quick guide which has background, motivation, and summary of what the Act means. Quoting:
The principles of the Bayh-Dole Act were the result of years of intense and emotional debate, dealing with fundamental concerns. The record shows that the debate included such issues as whether exclusive licenses would lead to monopolies and higher prices; whether taxpayers would get their fair share; whether foreign industry would benefit unduly; and whether ownership of inventions by a contractor is anti-competitive. Safeguards were hammered out in numerous legislative drafts. It is certain that the Act became much stronger because of the thorough debate that took place prior to its passage.
I haven't decided what I think of the Act. A simple analogy between patents and copyright seems improper, but this is a case where there was a vigorous debate on issues related to the above posts.
The Act does not automatically result in licensing directly to large companies. Quoting again:
In their marketing of an invention, universities must give preference to small business firms (fewer than 500 employees), provided such firms have the resources and capability for bringing the invention to practical application.
I dunno if it's OK to just buy the startups outright after important patents have been licensed.
Hence rhetoric from RMS to the effect that asking people to pay for software is unethical.
Head on over to the FSF order page, where they offer to sell you a $5000 distro.
I think RMS's position is that it's unethical to restrict redistribution or use of the software after the sale. If you squint at it funny, it almost looks like first sale doctrine.
Disclaimer: I'm not RMS. RMS never even posts to newsgroups, so he wouldn't be posting here. I don't agree with many of his positions. Phenylketonurics: contains phenylalanine.
Whether you call it "Free Software" or "Open Source", it's got one important feature:
No control
I don't have to ask anybody's permission to give it out, modify it---or use it. No EULAs. No "you can only show this to some people we like". No "we'll only let you do this if it fits our strategic goals for the platform." No "we've implemented media access controls because we know what's best for you."
No control
Sun's various "community source" attempts and Microsoft's "shared source" don't give up control. Shared is too strong a term. Maybe "loaned source". "Leased source". There's no mistaking who has a lien on the software and everything you and your organization choose to do with it.
"No control" may not be a deciding factor in what technology you want. But it's a factor.
If you have good ideas on how to solve the cluster of issues related to shared libraries, cmon over to the Linux VR project, where everything is up for redecision. Trying to fit as much useful stuff as possible on an Agenda VR3 means everyone's open to new ideas---if they work!
For instance, Shane Nay and I implemented old-style Linux a.out shared libraries because of significant overhead in MIPS PIC code. There's no dynamic linking, but boy does it run faster. Some people are playing with dynamic-linking applications into a common base executable. And so on. Maybe these things seem silly on a desktop box, but this kind of embedded environment is clearly not a desktop box....
Certainly there is some selection bias here; people who are fanatic about an editor are likely to be the people who spend a lot of time typing at editors. Somebody who spends two hours a week typing probably won't care too much if you give them anything nicer than notepad.exe.
But yeah, emacs people seem to get hit a lot. What's more, in a group of emacs people I know, the RSI diagnosis of choice turned out to be ulnar nerve compression---and we all got the diagnosis before we found out the details of the other people. "Ulnar nerve compression---that's funny, that's what my doctor was thinking...."
Firstly, the action of compiling on different architectures is very different, even without considering optimisation strategies. To compile code into the CISC code of the x86 architecture is very different from that of a RISC chip such as the PowerPC. For a start, instruction ordering etc. for a RISC chip, even for not really optimised code can take far more processing time. Then, if you add optimisation, which in a RISC architecture is a FAR more complex task.
All this means is that compiling on a RISC architecture is bound to be a great deal slower.
I'm aware of that, and I talk about it on that page. See the "Choice of workloads" section.
The install-egcs test does measure native compilation performance. This is relevant for people who use the box for development.
The install-glibc and cross-gcc tests are both compiling to a single RISC architecture, little-endian MIPS. The amount of effort required to optimize for PPC or x86 doesn't factor into this.
If you don't care about development compile times, just look at the cross-only numbers.
By the way, the "per bogohertz" comparison was outright dishonest. It doubles the actual cost of the G4, even by these tests, since the G4 is a dual processor.
No, the Apple Store price I quoted in that table is for a single-processor G4/533. Go price it yourself.
(I'd give a URL but the Apple Store is too sessional.)
I don't think metrics of support time and training directly translate to this kind of cluster. These machines are being used in an unconventional way; you don't really have to worry about somebody screwing up the extensions/dlls/shared libraries on just one of the boxes, for instance.
What's more important to them is the cost of development of software for the cluster. And if they've got enough Mac weenies around to argue for the Apple hardware solution, they probably have the talent and dedication to make it work---so it's probably a pretty cheap solution. This is also why x86 Linux Beowulf clusters work well in some environments...people are excited and knowledgable about a technology that they're recommending.
As far as the TCO numbers go, I'd like to see a recent citation. Yes, it's my intuition that MacOS is cheaper to support than Windows, but most of the numbers people usually quote are traceable back to a study done in 1996, comparing, what, MacOS 7.5 to Windows 95.
BTW, my sources in IT departments say that upgrading boxes from W9x to W2K has cut trouble ticket counts dramatically.
(I'm nominally a Linux weenie, but I gave in and ordered a used iMac because I miss the NeXT. Anybody else in the same boat?)
(Fair warning: I don't work for Agenda. I flame people afraid the PalmOS box they bought isn't the last word in PDAs.)
I think Agenda is concentrating on getting feature-complete and bug-free before tuning for performance. Isn't that what y'all would be screaming for anyway?
The easiest way to fix the "lots of apps running eats all memory and the machine dies thrashing" problem is to do what WinCE did to deal with the same issue: automatically ask background apps to close. This would certainly solve the problem for two important classes of users: the casual "hey what's this do" newbie, and...reviewers.
This shouldn't be too hard to implement. Until then, just close apps you aren't using---that's the usage model everybody here wanted on WinCE: explicit app shutdown.
I'll paste in Shane's comment from the Brighthand discussion:
Well..., this is "Nay", of whom you speak. Shane Nay to be correct. The problems that you reference with regard to speed were solved, but Agenda has decided against implementing them.
I'm not really privy to the reasons why, I don't happen to work there anymore as you mention. But I think that they will eventually implement what Jay Carlson and myself developed, or some version of it. It is harder to work with in a development enviroment, and that is probably why they opted not to suck it into the present distrobutions. I gave them enough information to carry the torch with it.
You can access my final posted demo for speed resolution at:
ftp://ftp.agendacomputing.com/pub/dev/tests/spee d/
If you try that romdisk out I think you will see that the speed problem is just something temporary. Probably Agenda will defend themselves, but it seems right for me to do so since you reference me by name. So..., hey don't blame me;-).
The romdisk there is quite speedy. So again, my speculation is that Agenda wanted to concentrate on getting feature-complete and bug-free for launch before the ABI switch. Isn't that what you'd do?:-)
Microsoft Corp, IBM and Intel Corp, et al, are developing technologies that could be built into PCs that would prevent the copying of files without copyright owner permission.
This isn't about copy protection, it's about access control, or if you'd prefer, control of use.
The organizations that favor this want to force you to use technology that enforces whatever they say are the terms of use for some pile of octets. Sure, the most important thing to them is limiting retransmission, but they can't limit retransmission without making sure that no unexpected use is ever made of those octets.
Once the debate is framed in terms of "copyright protection", the argument is half over. Don't fall for it.
You can go to www.imunified.org for some early information on it. The members include AT&T, Excite@home, MSN, Odigo, Phone.com, Prodigy, and Yahoo! AOL's been battling this all the way.
IMUnified's first priority appears to be interoperability between AOL's service and the services provided by AT&T, Excite@home, MSN, Odigo, etc. That's different from interoperability with an Internet-scale fully distributed protocol. I think IMUnified may still want that, but it's not as time-critical. Quoting their press releases, emphasis mine:
WASHINGTON - Aug. 31, 2000 - IMUnified, a coalition of leading technology and instant messaging (IM) companies, today announced the completion of technical specifications that will enable functional interoperability
among its members' instant messaging services in a seamless, convenient, private and secure manner.
Think of it as the difference between "let us in" and "let everyone in".
I don't think IMUnified's emphasis on service federation is necessarily a bad thing; after all, there are going to be lots of interesting scale and operational issues when any large IM service starts peering with another. It's just that IMUnified may not be an exact representation of the average slashdot reader's interest.
Amid the kernel tweeking (thanks to the fine folks at www.handhelds.org, and basic graphics apps (load monitor, clock, keyboard, scribble, etc...), we have also tried to create some PIM apps (e-mail, etc...), and I have developed a few observations. [...]
2) - Thus, it falls more to companies that are able to pay engineers to work on PIM applications. However, these days engineers are expensive, and the companies are unwilling to pay an engineer 40 bucks an hour, and then turn around and give the suites away. Thats has nothing to do with open source or code sharing, thats just business.
It may be the case that nobody is working on or giving away PIM suites for your chosen platform, but that doesn't mean nobody is doing it. Agenda Computing's Agenda PIM suite is available (later versions in CVS) and it's been ported to the iPaq as part of the Familiar distro. Heck, you folks support fltk on Nano-X, right? So do the port yourself!
PocketLinux is giving away their PIM functionality too.
It would be even better if the Pippy folks made sure it runs on embedded Linux and the BSDs as well.
I dunno if Pippy is much help for the current crop of Linux PDAs, which are pretty studly compared to PalmOS devices. I "ported" Python to Linux VR and it was just a matter of the usual crosscompile business, and removing modules that looked big. I left in the parser stuff. I forget whether I was targeting the Helio or the Agenda VR3 at the time, but it Just Worked (TM).
I'm sure I'll be modded down for saying this, but I've noticed it's good for an average of +1 moderation to say "I'm sure I'll be modded down for this".
Want to play Slashdot competitively? Learn from the masters. I just wish gamefaqs.com would post a slashdot strategy guide, if not a walkthrough....
I can't tell exactly from the changelogs, but WorkMan appears to have had a cd database before xmcd. First entry in the changelog of WorkMan was 12/24/1992; first entry in xmcd changelog was 11/08/1993. Interestingly, in the xmcd changelog for Version 1.1, 02/25/1994:
- A wm2xmcd utility is now included in the xmcd distribution that converts WorkMan CD database files to xmcd format.
I don't understand the relevance of the palmos.com cites to the parts of my text you've quoted. PalmOS 3.0 does not change the way handles and chunks work; it just does a better job of managing them. If it weren't for handles, any freestanding PalmOS device could eventually clog up and die of fragmentation, the same way my Amiga did sometimes.
So, what should Linux people be doing? Sitting back and waiting for Palm to be the source of All Good Things?
So what should Palm developers be doing, wasting their time porting bloated Unix tools to a decidedly (and purposefully) limited platform, for the sheer intellectual rigor of the excercise, or devloping for a fully functional OS that's well suited for the tasks it's asked to perform?
Hey, I didn't say I wanted perl on PalmOS. I make no claims for other slashdot readers, however.:-)
I really don't know what Palm developers should be doing. There are still many undiscovered killer apps nicely implementable on PalmOS. Go forth and hack!
One of the big mysteries on the horizon is the Big ARM Switch coming up---how many more apps will the new architecture will allow, or in what areas we should be working? What new kinds of capability will come with the new OS?
And I think that leads to something I was trying to say with the phrase "Linux people".
The Linux community doesn't have to wait around to see what some company is going to ship, nor is it stuck with one particular goal or vision imposed from outside.
Some of these are probably bad ideas. I think a perl-centric PDA environment is a really bad idea.:-) But I don't make that decision, and neither does any other single person or organization. What will eventually decide it is whether a) someone thinks it should be done and does it, and b) enough people like it to keep it alive---even if it doesn't dominate the market.
Heck, eCos and Squeak don't need Linux, and that's a sign that Linux itself may be a bad idea in some cases. So me saying "Linux people" was a mistatement. I hope you get what I meant.
If the Linux developers are having a tough time figuring out what to do , a much more useful pursuit would be developing a better way of syncing a Palm device to Linux.
Personally, I'd be a lot more interested in working on this if the Palm devices spoke some standard, open protocol for synchronization. Other people are more motivated than me, though.
ELF position-independent code uses offsets from the GOT table for symbol resolution. void* remains word-sized. Besides, there's no general way to relocate a DSO once it's been relocated and running (think of an automatic variable pointing to an errno allocated in libc) so this doesn't help with the fragmentation problem.
If you wanted to do cross-chunk addressing in a handle-based scheme, void* would have to be something like struct void_star {handle_t base; int offset;}.
As far as hardware limitations, DragonBall is a 32-bit processor, so it has an addressable memory space of 4G.
But it's not virtual. So even if you maxed out the Dragonball VZ's DRAM controller with 64M, you'd still need some way of controlling fragmentation etc, because you don't have a hardware MMU to shuffle pages around.
Why is controlling fragmentation important? Old Amiga hackers remember the pain of programs refusing to load, not because you didn't have enough memory left, but because you didn't have enough contiguous memory left. (If an app is expecting to be able to malloc a meg, the OS can't really reply "would you take two 512k chunks instead?".) That kind of behavior sucked back then, and it would suck even more on a PDA that stays up for weeks at a time.
The most reasonable way to solve fragmentation on a 68000 is to address all memory through handles. Load up a raw 32-bit pointer to the start (or middle) of a chunk of memory, then do all addressing based on offsets from that pointer. Whenever nobody is using a chunk, the OS is allowed to move the data and the pointer---after the move, the data, relative to the pointer, will be in the same place.
This is not a very Unix-y memory model. This is why nobody has ported perl to PalmOS. You'd have to change everything that assumed that a single 32-bit pointer was enough to access memory. Even if you could convince PalmOS to give you, say, a contiguous 2M chunk to use for malloc, and lock that region down forever (don't want pointers in there moving out from under us), you'd be back to the original problem of fragmentation.
A 2M chunk would be unnatural for another reason. Until the 020, 68000 addressing modes can only reach +/-32k from a register. Plop your chunk pointer in the middle of a region and out pops...that 64k limit you're always seeing in PalmOS hacking. If you're willing to take the performance hit, you could *manually* add 32-bit offsets to an address register (and give up the offset addressing mode). But pretty soon this starts looking just like the near/far pointer tar pit from the bad old 8086 days.
The newer versions of PalmOS are also moving closer to processor agnosticism with a HAL, which will sever its dependence on the DragonBall Series (MIPS, anyone? How about an IPaq, then? Mayhaps even Crusoe...).
I still can't figure out what they're going to do to move beyond 160x160 or 160x240 screens. Those hundreds of third-party apps are almost all using absolute pixel positioning for form layout. Wait...I have an idea---what if we redefine old pixel positions as really being dimensioned in "dialog units", and...wait, nobody would actually do that...
Unlike Microsoft, Palm is changing and eliminating its OSes primary weaknesses rather than saddling its developers/users/customers with archaic requirements, just like a company in a competitive market should.
So, what should Linux people be doing? Sitting back and waiting for Palm to be the source of All Good Things?
A VHS widescreen movie, on average, uses 180 lines of resolution. An anamorphically encoded DVD uses the full 480 lines of resolution allowed by NTSC. Yeah, that's hardly better quality right there.
Yeah, but I've never seen MPEG artifacts on VHS, and hoo boy do I see 'em on DVD.
As a platform, we have LinuxPPC, which totally blows away the x86 platform in terms of performance.
Cite? I keep hearing this, but I haven't seen any real numbers. Sure, there are rc5 blocks/sec and SETI rates, but that's not why I buy computers. So who has task-specific numbers comparing LinuxPPC and x86? Like kernel rebuilds, X benchmarks, TPC, etc.
What I'd really like is a price/performance chart for both platforms, but I'll settle for even a few data points.
Slashdot Mirror
Oh, cool! Is this true of just the new iBooks, or the older ones as well?
So the first thing I do, like any good mail order weenie, is go looking around on Pricewatch, various Mac-specific web sites etc looking for what the prices are for various kinds of hardware. Well, it turns out that just about every new Mac is priced within about $5 of the online Apple Store. That seems strange, especially considering that most of the big online retailers have their own "we'll throw in 256M/a printer/a scanner/a bunch of media" incentives. The simplest explanation for this seems to be that Apple prohibits its authorized dealers from advertising or competing on lower price, but still allows bundles for differentiation. Well, at least this makes price comparison shopping for new hardware very easy....
Now it's time to go looking for used machines and hit the auction sites. Well, in order to do that, I gotta understand what the specs of the various boxes are. So after a few evenings of trying to understand how the prices and specs work out, here's what I conclude:
So where does this put the Cube? Well, that's the problem. What I really wanted was a headless iMac. The Cube seemed pretty close because of its small size, no fan, and limited expandability. But it has a G4 and allows decent video resolutions, so Apple priced it like a "pro" system.
I think there would be a huge market for a headless iMac. But an important part of the iMac is low cost. And people who want a non-tiny monitor are just the people that Apple wants to squeeze for as many dollars per unit as they can get. As long as Apple has control over all the hardware that can run OS 9/OS X software, they'll probably continue to segment their market, sometimes with artificial limitations, to maximize profit from customers who are less price sensitive.
In general, PC hardware manufacturers can't do this. I can plop a GeForce 2 MX in Ye Olde Celeron 450 if I want video resolution. I can put a Maxtor 1394 card in any old PC. And if nVidia or Maxtor decides to artificially cripple their low-end cards to try to make more high-end sales, their competitors will eat their lunch. In fact, the only big player who has much luck with this kind of market segmentation is Intel (Celeron/P3/P4/Xeon), and AMD is...eating their lunch.
All this could change at MWNY, but I bet there will still be significant limitations designed into whatever new iMac is announced.
I haven't decided what I think of the Act. A simple analogy between patents and copyright seems improper, but this is a case where there was a vigorous debate on issues related to the above posts.
The Act does not automatically result in licensing directly to large companies. Quoting again:
I dunno if it's OK to just buy the startups outright after important patents have been licensed.
Head on over to the FSF order page, where they offer to sell you a $5000 distro.
I think RMS's position is that it's unethical to restrict redistribution or use of the software after the sale. If you squint at it funny, it almost looks like first sale doctrine.
Disclaimer: I'm not RMS. RMS never even posts to newsgroups, so he wouldn't be posting here. I don't agree with many of his positions. Phenylketonurics: contains phenylalanine.
I don't have to ask anybody's permission to give it out, modify it---or use it. No EULAs. No "you can only show this to some people we like". No "we'll only let you do this if it fits our strategic goals for the platform." No "we've implemented media access controls because we know what's best for you."
Sun's various "community source" attempts and Microsoft's "shared source" don't give up control. Shared is too strong a term. Maybe "loaned source". "Leased source". There's no mistaking who has a lien on the software and everything you and your organization choose to do with it.
"No control" may not be a deciding factor in what technology you want. But it's a factor.
For instance, Shane Nay and I implemented old-style Linux a.out shared libraries because of significant overhead in MIPS PIC code. There's no dynamic linking, but boy does it run faster. Some people are playing with dynamic-linking applications into a common base executable. And so on. Maybe these things seem silly on a desktop box, but this kind of embedded environment is clearly not a desktop box....
Doug Lea wrote the core of the malloc() implementation you're using if you're on a Linux box. See http://g.oswego.edu/dl/html/malloc.html .
This work is mainly derived from malloc-2.6.4 by Doug Lea
<dl@cs.oswego.edu>, which is available from:
ftp://g.oswego.edu/pub/misc/malloc.c
But yeah, emacs people seem to get hit a lot. What's more, in a group of emacs people I know, the RSI diagnosis of choice turned out to be ulnar nerve compression---and we all got the diagnosis before we found out the details of the other people. "Ulnar nerve compression---that's funny, that's what my doctor was thinking...."
All this means is that compiling on a RISC architecture is bound to be a great deal slower.
I'm aware of that, and I talk about it on that page. See the "Choice of workloads" section.
The install-egcs test does measure native compilation performance. This is relevant for people who use the box for development.
The install-glibc and cross-gcc tests are both compiling to a single RISC architecture, little-endian MIPS. The amount of effort required to optimize for PPC or x86 doesn't factor into this.
If you don't care about development compile times, just look at the cross-only numbers.
No, the Apple Store price I quoted in that table is for a single-processor G4/533. Go price it yourself.
(I'd give a URL but the Apple Store is too sessional.)
I don't think metrics of support time and training directly translate to this kind of cluster. These machines are being used in an unconventional way; you don't really have to worry about somebody screwing up the extensions/dlls/shared libraries on just one of the boxes, for instance.
What's more important to them is the cost of development of software for the cluster. And if they've got enough Mac weenies around to argue for the Apple hardware solution, they probably have the talent and dedication to make it work---so it's probably a pretty cheap solution. This is also why x86 Linux Beowulf clusters work well in some environments...people are excited and knowledgable about a technology that they're recommending.
As far as the TCO numbers go, I'd like to see a recent citation. Yes, it's my intuition that MacOS is cheaper to support than Windows, but most of the numbers people usually quote are traceable back to a study done in 1996, comparing, what, MacOS 7.5 to Windows 95.
BTW, my sources in IT departments say that upgrading boxes from W9x to W2K has cut trouble ticket counts dramatically.
(I'm nominally a Linux weenie, but I gave in and ordered a used iMac because I miss the NeXT. Anybody else in the same boat?)
If you're looking for little ASCII diagrams of the relationships between PRINCIPALs, SENDER UAs, INSTANT INBOXes etc, it's the place to be!
I think Agenda is concentrating on getting feature-complete and bug-free before tuning for performance. Isn't that what y'all would be screaming for anyway?
The easiest way to fix the "lots of apps running eats all memory and the machine dies thrashing" problem is to do what WinCE did to deal with the same issue: automatically ask background apps to close. This would certainly solve the problem for two important classes of users: the casual "hey what's this do" newbie, and...reviewers.
This shouldn't be too hard to implement. Until then, just close apps you aren't using---that's the usage model everybody here wanted on WinCE: explicit app shutdown.
I'll paste in Shane's comment from the Brighthand discussion:
The romdisk there is quite speedy. So again, my speculation is that Agenda wanted to concentrate on getting feature-complete and bug-free for launch before the ABI switch. Isn't that what you'd do?
This isn't about copy protection, it's about access control, or if you'd prefer, control of use.
The organizations that favor this want to force you to use technology that enforces whatever they say are the terms of use for some pile of octets. Sure, the most important thing to them is limiting retransmission, but they can't limit retransmission without making sure that no unexpected use is ever made of those octets.
Once the debate is framed in terms of "copyright protection", the argument is half over. Don't fall for it.
IMUnified's first priority appears to be interoperability between AOL's service and the services provided by AT&T, Excite@home, MSN, Odigo, etc. That's different from interoperability with an Internet-scale fully distributed protocol. I think IMUnified may still want that, but it's not as time-critical. Quoting their press releases, emphasis mine:
Think of it as the difference between "let us in" and "let everyone in".
I don't think IMUnified's emphasis on service federation is necessarily a bad thing; after all, there are going to be lots of interesting scale and operational issues when any large IM service starts peering with another. It's just that IMUnified may not be an exact representation of the average slashdot reader's interest.
2) - Thus, it falls more to companies that are able to pay engineers to work on PIM applications. However, these days engineers are expensive, and the companies are unwilling to pay an engineer 40 bucks an hour, and then turn around and give the suites away. Thats has nothing to do with open source or code sharing, thats just business.
It may be the case that nobody is working on or giving away PIM suites for your chosen platform, but that doesn't mean nobody is doing it. Agenda Computing's Agenda PIM suite is available (later versions in CVS) and it's been ported to the iPaq as part of the Familiar distro. Heck, you folks support fltk on Nano-X, right? So do the port yourself!
PocketLinux is giving away their PIM functionality too.
I dunno if Pippy is much help for the current crop of Linux PDAs, which are pretty studly compared to PalmOS devices. I "ported" Python to Linux VR and it was just a matter of the usual crosscompile business, and removing modules that looked big. I left in the parser stuff. I forget whether I was targeting the Helio or the Agenda VR3 at the time, but it Just Worked (TM).
Want to play Slashdot competitively? Learn from the masters. I just wish gamefaqs.com would post a slashdot strategy guide, if not a walkthrough....
- A wm2xmcd utility is now included in the xmcd distribution that converts WorkMan CD database files to xmcd format.
Hey, I didn't say I wanted perl on PalmOS. I make no claims for other slashdot readers, however. :-)
I really don't know what Palm developers should be doing. There are still many undiscovered killer apps nicely implementable on PalmOS. Go forth and hack!
One of the big mysteries on the horizon is the Big ARM Switch coming up---how many more apps will the new architecture will allow, or in what areas we should be working? What new kinds of capability will come with the new OS?
And I think that leads to something I was trying to say with the phrase "Linux people".
The Linux community doesn't have to wait around to see what some company is going to ship, nor is it stuck with one particular goal or vision imposed from outside.
Sure, some perl weenies are going to drool over PocketPerl. But I'm not gonna stop them from implementing it. Rebuild a minimalist OS on eCos? Sure, why not. Java PDA? On its way. X on a machine running on AAAs? And how about Smalltalk, for that Dynabook spirit?
Some of these are probably bad ideas. I think a perl-centric PDA environment is a really bad idea. :-) But I don't make that decision, and neither does any other single person or organization. What will eventually decide it is whether a) someone thinks it should be done and does it, and b) enough people like it to keep it alive---even if it doesn't dominate the market.
Heck, eCos and Squeak don't need Linux, and that's a sign that Linux itself may be a bad idea in some cases. So me saying "Linux people" was a mistatement. I hope you get what I meant.
If the Linux developers are having a tough time figuring out what to do , a much more useful pursuit would be developing a better way of syncing a Palm device to Linux.
Personally, I'd be a lot more interested in working on this if the Palm devices spoke some standard, open protocol for synchronization. Other people are more motivated than me, though.
If you wanted to do cross-chunk addressing in a handle-based scheme, void* would have to be something like struct void_star {handle_t base; int offset;}.
But it's not virtual. So even if you maxed out the Dragonball VZ's DRAM controller with 64M, you'd still need some way of controlling fragmentation etc, because you don't have a hardware MMU to shuffle pages around.
Why is controlling fragmentation important? Old Amiga hackers remember the pain of programs refusing to load, not because you didn't have enough memory left, but because you didn't have enough contiguous memory left. (If an app is expecting to be able to malloc a meg, the OS can't really reply "would you take two 512k chunks instead?".) That kind of behavior sucked back then, and it would suck even more on a PDA that stays up for weeks at a time.
The most reasonable way to solve fragmentation on a 68000 is to address all memory through handles. Load up a raw 32-bit pointer to the start (or middle) of a chunk of memory, then do all addressing based on offsets from that pointer. Whenever nobody is using a chunk, the OS is allowed to move the data and the pointer---after the move, the data, relative to the pointer, will be in the same place.
This is not a very Unix-y memory model. This is why nobody has ported perl to PalmOS. You'd have to change everything that assumed that a single 32-bit pointer was enough to access memory. Even if you could convince PalmOS to give you, say, a contiguous 2M chunk to use for malloc, and lock that region down forever (don't want pointers in there moving out from under us), you'd be back to the original problem of fragmentation.
A 2M chunk would be unnatural for another reason. Until the 020, 68000 addressing modes can only reach +/-32k from a register. Plop your chunk pointer in the middle of a region and out pops...that 64k limit you're always seeing in PalmOS hacking. If you're willing to take the performance hit, you could *manually* add 32-bit offsets to an address register (and give up the offset addressing mode). But pretty soon this starts looking just like the near/far pointer tar pit from the bad old 8086 days.
The newer versions of PalmOS are also moving closer to processor agnosticism with a HAL, which will sever its dependence on the DragonBall Series (MIPS, anyone? How about an IPaq, then? Mayhaps even Crusoe...).
I still can't figure out what they're going to do to move beyond 160x160 or 160x240 screens. Those hundreds of third-party apps are almost all using absolute pixel positioning for form layout. Wait...I have an idea---what if we redefine old pixel positions as really being dimensioned in "dialog units", and...wait, nobody would actually do that...
Unlike Microsoft, Palm is changing and eliminating its OSes primary weaknesses rather than saddling its developers/users/customers with archaic requirements, just like a company in a competitive market should.
So, what should Linux people be doing? Sitting back and waiting for Palm to be the source of All Good Things?
Yeah, but I've never seen MPEG artifacts on VHS, and hoo boy do I see 'em on DVD.
You missed Usenet: The Flaming.
Cite? I keep hearing this, but I haven't seen any real numbers. Sure, there are rc5 blocks/sec and SETI rates, but that's not why I buy computers. So who has task-specific numbers comparing LinuxPPC and x86? Like kernel rebuilds, X benchmarks, TPC, etc.
What I'd really like is a price/performance chart for both platforms, but I'll settle for even a few data points.