Other Operating Systems

[tg]

It's not about having hardware to support the software, but rather having the software support the hardware.

Exactly! What people don't seem to understand is that every manufacturer of a handheld device has to take the source code for someone's operating system (WinCE, Linux, Symbian, PalmOS, etc.) and change it to work with their hardware. That is difficult, specialized work. I've seen embedded development houses quote six figure prices to develop a WinCE board support package (BSP) for a new hardware platform. And then of course, you can't distribute WinCE without paying Microsoft a fee for every copy that goes out the door.

But there's an even bigger reason that few vendors offer an OS "choice" on their devices ... support costs! Unless you've actually sold PDA hardware or software, you can't even begin to imagine the number of hours that go into customer support. And the more choices you give the customer, the worse it gets.

Let's say you offer a device with WinCE with no "approved" way to modify the OS. Most of your support requests will be generic WinCE questions and you can pass the buck to Microsoft. Now let's say you offer an alternative Linux distro for customers to flash. First off you get a batch of support questions from people who want help deciding which OS they should use. You also get the inevitable percentage of customers who will have problems flashing (usually their fault but don't try to tell them that).

Those who do get Linux going will have questions and problems that you have to field because if you try to pass the buck to Trolltech or Metrowerks (companies your customer has never heard of) you're going to look really incompetent (no one ever looks bad for blaming Microsoft  ). Sure you can offer Linux as an "unsupported" alternative but then most customers won't go anywhere near it (what percentage of iPaqs saw Familiar installed by the original purchaser?). Especially the first time a customer has a problem with the "unsupported" software and starts posting long rants about all their difficulties.

So as a PDA maker that wants to support the Linux community, you can:

1) Make a strictly Linux device (Zaurus approach). This is a tough sell but can work -- at least in some markets. I think it's safe to say the Zaurus is a success in Japan.

2) Open your hardware specs to the community so they can port Linux themselves (Compaq + Familiar approach). The risk here is that you open your hardware specs to your competition and risk competing with less expensive clones (since they don't have to amortize as much development cost).

3) Offer WinCE and Linux (Olympus approach). You dramatically increase your support costs for a very marginal increase in sales. This "might" work for Olympus who appears to be targeting vertical markets, but is highly impractical for the consumer electronics world.

4) Forget Linux and suffer the loud but small wrath of the offended community.

You're the CEO and there are millions of dollars (plus your incentive pay and possibly your job) on the line ... what call do you make?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=65123\"][{POST_SNAPBACK}][/a][/div]

Your point 1) is that Zaurus is a tough sell but works in some markets. The only reason it does not work in all markets is that Sharp decided to not really support and push it. If I'm Sharp CEO with job on the line I release the following machine worldwide and support it:

sl-c960:
Same specs as 3000 with the following addons:
wifi, phone/grps, gps, bluetooth, 256 meg ram (possibly add new 10G hitachi harddrive), better outdoor screen
I also replace most of sharp software/applications with best of breed opensource stuff (browse these forums to find them - ie. use ko/ka/ompi etc for the best PIM available anywhere etc).

This PDA/Phone would be untouchable by anything else in the phone/pda world - you would have the highest end of the phone/pda market exclusively to yourself for a very long time. Contrary to popular beliefs the highest end of phone/pda market is large enought to easily make this very profitable (just look at how small the market share of Apple (desktop) is but even the few percent they have it is good enough to support them for all these years. There are more than enough unix/linux/mac/anti ms geeks out there to make it happen.

[soundwave106]

Apple also had the art and education community for a *long* time to support their high-end boxes.

Open source applications is often the best, but what about support? Support is a surprisingly big deal in the consumer and business world. Many Linux companies make their money solely on support. I don't know if all of the open-source developers (many of them working part time as a hobby) could make the transition to having a full support staff to answer a question when Joe Newbie can't figure out how to use the PIM stuff.

Having said that, I think there is a sufficient geek-factor market in the US for a Linux PDA. Nerds spend money on gizmos after all.  The major bitch-factor on the Slashdot-type forums about the SL-6000L initially was the high price, I don't think too many people would bitch at the $379 closeout price.   I also think the clamshell would've gone over so much better than the brick design.

[Curious Aardvark]

One fairly major reason for running wince on a zaurus would be I could finally have some maps on my zaurus !
The only serious application I can't run on my z is a route planner program (yes I use one, yes I'd like to have one in my pocket). Presumably with wince running this would be possible ?

[iamasmith]

Interesting discussion. Dave (Kopsis) is spot on and I'm sure has more experience of these issues than anyone else on this board so take heed.

As far as I understand it the CE platform builder will do a lot for you basically chainning all the XIP (eXecute In Place) regions together that give the levels of granularity to a CE build (add office apps etc. or not), however, driver support is going to be crucial particularly surrounding things like the GPIO map associated with power control to devices as well as actually setting up data transfers etc.

I think there is potentially more mileage in taking the 'familiar' linux distribution targetting one of the devices and extracting the hardware map that would match a CE image (if indeed the mapping was comprehensive enough to support the CE image) and attempting to produce some kind of 'VMWare' type solution that worked on native execution of ARM instructions and exceptions to handle a virtualisation of the hardware maps.

Three potential problems immediately spring to mind though.

i. I'm well aware of the x86 capability to trap on IO and memory access to routines capable of providing hardware emulation so it's easy to envisage this kind of capability on x86 processors. I don't have that kind of visibility as to what is practical at such a low level on the ARM processor and indeed if necessary kernel endpoints are available that may expose such a capability for an emulator.

ii. The Hardware map needed to run Linux may not include all the pre-requisites that are needed to run the original CE image. There is probably some stuff there to ensure that CE is running on the original target. Stuff that Linux just doesn't care about. This may be a showstopper.

iii. It's likely to be extremely dodgy ground from a licensing perspective since it would mean firstly  owning the specific device that matched the familiar distribution that you were going to use as your base for virtualisation (probably H3600 would be a good target) and even then there may be a licensing issue with running that OS on different hardware (actually almost certainly).

If you proceeded on your current plans to produce a native environment then licensing is also going to be a factor. It's fine as far as I understand it to use a licensed version of platform builder for OEM development and prototyping in house. The next stage in distribution is to approach Microsoft to sort out the per device licensing of the distribution which you may or may not get.

In fact it will be interesting to see if both the Qtopia and CE versions of the Olympus product actually appear on the market. It's M$ usual practice to insist on 'vendor loyalty' and 'commitment to the partnership'. Olympus may, however, be big and ugly enough to pull it off.

- Andy

[dhns]

However, as a geek, I would love to get CE running on my Z.

Just for fun.

A dual boot would be cool too. CE on an SD card anyone?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=62403\"][{POST_SNAPBACK}][/a][/div]

Well, as a geek I would even consider it vice versa.. love running a Z ROM on a CE

A dual boot would not be needed. Just a ".exe" which is a Linux kernel hosted on WinCE + a Zaurus file system. Would run on *any* WinCE device, even those that have not yet been released. What a dream!

If someone is interested: I have created a first experiment version (0.01 or even less) of a "PocketTux.exe" that does handle some Linux system calls. What is missing is real scheduling, loading of files, memory mapping etc. and really running an Linux executable. Therefore the 0.01 version.

Needs the (free) MS Embedded VisualC++ tools for compiling. The concept itself is not new - there is a Linux kernel somewhere (I forgot the name of the project) available that runs on Windows.

-- hns

[iamasmith]

dhns, sounds like you are headed towards to CoLinux (Co-operative Linux) type solution.

Good luck, I have always thought that there was a reasonable amount of merit in this to get the important stuff from Linux. Establishing bandwidth between the Linux environment and the host OS (CE) for games and such like may be difficult.... there again maybe not. Produce a CE based X Server talking to a CoLinux environment running on the CE device....

Your problems would be...

i. Decide on a virtual platform envoronment that offers all the features you need. (exposes the host storage and IO + Graphics + Input etc. etc. etc.)

ii. Develop a HAL (Hardware Abstraction Layer) around that environment that handles properly things like hot ejection of media that you get with CE but not with Linux.

iii. Write the Linux specific stuff to interface with the host HAL and borrow a lot from the original CoLinux project....

Possibly easier to port CyGWin to CE and start there.... depends what you want Linux for at the end of the day..... do you need Linux or do you just want GNU stuff

There again you are still at the mercy of M$, HP or whoever, with your base OS... 6 months later you find there's a newer smaller model and they have discontined sales of your model of CE device and you can't get that feature that you really want on your device because the vendor isn't going to offer a flash upgrade to the next version of CE (disgruntled ex Casio E105, E115, Compaq 3660, Compaq/HP 3970 owner).

[kopsis]

I think there is potentially more mileage in taking the 'familiar' linux distribution targetting one of the devices and extracting the hardware map that would match a CE image (if indeed the mapping was comprehensive enough to support the CE image) and attempting to produce some kind of 'VMWare' type solution that worked on native execution of ARM instructions and exceptions to handle a virtualisation of the hardware maps.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=65540\"][{POST_SNAPBACK}][/a][/div]

There's certainly merit to this approach. Though I doubt you'd need the step of extracting a CE hardware virtualization target from Familiar. CE "out of the box" provides "reference" BSPs that support a fairly generic hardware platform. If you have enough of the CE kernel and driver code (and that's a mighty big "if") it would be possible to stub out the low level operations with calls to virtualization services that implement the operations with Linux system facilities.

The biggest problem with tricks like that is that running two operating systems requires two operating systems worth of resources. Storage and CPU aren't such a big deal but RAM becomes a major issue. I use both coLinux and vmWare extensively and they are truly wonderful if you have enough RAM. An SL-C750 or newer might have enough RAM to pull this off, but I think it would be a tight squeeze.

Going the other way (virtualizing Linux on CE) seems like more of a stretch given that the CE kernel is way less sophisticated and featurefull than the Linux kernel. I could maybe see getting uCLinux (no MMU/virtual memory) running that way, but a full kernel just seems like too much of a stretch. coLinux barely pulls that trick off on a full blown NT kernel (it still can't effectively virtualize the framebuffer, serial ports, USB, etc.). I'm pretty sure that vmWare "cheats" and takes advantage of virtualization features in the X86 architecture.

It makes for an interesting roundtable discussion, but I can't see anyone committing the level of effort needed to take projects like this to completion. For most folks, 95% percent of their application software needs can be met by one platform alone (CE for some folks, Linux for others). In most cases they'd get a better ROI on their time investment by writing (or porting) the 5% of stuff they're missing on their preferred platform  PDA software is really not hard to write (at least not for people with the expertise to create virtualization software). OS hacking is fun (I've been known to do it for a living  ) but app software gives more bang for the buck.

[speculatrix]

The only reason I can think of is that there is no decent windows CE machine with a good keyboard.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=62555\"][{POST_SNAPBACK}][/a][/div]

the new T-Mobile MDA-IV is like an 860 only with a phone built in.

[speculatrix]

3) Offer WinCE and Linux (Olympus approach). You dramatically increase your support costs for a very marginal increase in sales. This "might" work for Olympus who appears to be targeting vertical markets, but is highly impractical for the consumer electronics world.

I have been wondering why Olmpus chose to offer the device with a choice of OS. As you say, I reckon they'd sell 98% as WinCE, 2% as Linux. Now, if you could dual-boot, then there'd be more interest. If the linux one was a lof cheaper, then it'd appeal to some people - turn it into a dual-boot system by acquiring the ROM image of the WinCE version.  

I wonder if it is because they ported linux to the device for testing/development purposes whilst verifying the hardware and realised that they might be able to sell a few more of them that way? Or, they had a specific customer who wanted a PDA linux computer and reckoned they might as sell the product more widely?

Hmm.
Paul

[kopsis]

I have been wondering why Olmpus chose to offer the device with a choice of OS. As you say, I reckon they'd sell 98% as WinCE, 2% as Linux. Now, if you could dual-boot, then there'd be more interest. If the linux one was a lof cheaper, then it'd appeal to some people - turn it into a dual-boot system by acquiring the ROM image of the WinCE version.  
[div align=\"right\"][a href=\"index.php?act=findpost&pid=65967\"][{POST_SNAPBACK}][/a][/div]

Note that neither OS being offered is viable for consumers. WinCE.NET doesn't include things like Pocket Outlook, Pocket Word, Pocket Excel, etc. It's little more than an OS kernel and drivers intended for embedded (single purpose) devices. Qtopia 1.7 is quite a bit more complete but still doesn't include much in the way of apps beyond just the basic PIM stuff. Take all the Sharp developed and third-party apps off your Zaurus and how useful would it be? Remember that past studies have shown that the fraction of consumers who purchase PDAs and don't install a single piece of third party software can be as high as 50%!

Olympus expects businesses to buy the hardware and load it up with a single "enterprise app" that the customer is going to develop themselves. Offering both OS choices in this case makes sense since the end user will likely see nothing more than a single application and won't have a clue (or care) what OS is actually running.