[ge-talk] Possible Future Development Branch?
Ian Nowland
ian.nowland at gmail.com
Fri Feb 29 21:13:57 EST 2008
I see a couple of benefits for Haiku being adapted to the mobile world, with
the benefit of saying our OS is used on X amount of mobile devices actually
somewhat minor. Primarily, the benefit I see is that Haiku has many features
which make it particularly suited to being a mobile device OS, in some
places even more so than its suitability as a desktop OS: being single user,
for instance, is not a detraction, but helps cut down on size. Being so
adept with media makes it a serious competitor in an area where devices have
a primary purpose of delivering such media. In other words, more than in any
other area, Haiku possesses exactly the qualities I most want in a mobile
device OS. One of the issues you bring up, size, is definitely a reason why
Haiku would be drastically better than Linux, Android, or any of the mobile
windows platforms which currently compete in this area.
As for the benefits to end users, there would be several. Since Android
software is simply written in a flavor of Java, if Haiku had an Android
compatibility layer, it would open up Android software to run directly on
Haiku - which would be a great source of new Apps, even for the desktop. If
Haiku similarly was compatible with Android compatible hardware, there would
be a rapidly expanding list of devices it could run on, and if it had both,
you would have a an excellent OS for mobile devices which was capable of
running not only Android software but also the host of applications that can
run on Haiku currently.
--Ian
On Fri, Feb 29, 2008 at 6:24 PM, Ryan Leavengood <leavengood at gmail.com>
wrote:
> 2008/2/29 Ian Nowland <ian.nowland at gmail.com>:
> >
> > What does everyone think of this idea?
>
> Well my main question for this would be what is the benefit for Haiku,
> and what is the benefit for end users?
>
> For Haiku the benefit might be for us to say "our OS is used on x
> amount of mobile devices", but beyond that I'm not sure. With the
> Android compatibility layer it is not like there would be more
> applications for the desktop Haiku. Though if there was a "native"
> Haiku mobile API maybe it would be possible to write one app for both
> desktop and mobile with just different interfaces. That would be kind
> of neat, but which version of the app would take precedence? Would the
> desktop version have a slightly bigger interface but the same limited
> capability? Word Mobile and the full Word are quite different beasts.
>
> For end users there may be even less benefit. In general I doubt they
> would care if their Android-based phone ran Linux or Haiku behind the
> scenes. Maybe if they had both a Haiku mobile device and a Haiku
> desktop their might be some cool convergence features, but I can't say
> how much real benefit that would be. Smooth syncing between the mobile
> device and their desktop would be nice (remote BMessages for "remote
> control" maybe.) But even now all that isn't too hard with properly
> designed shared formats.
>
> In my opinion the better place for Haiku outside the desktop at this
> point is on ultra portables like the EeePC. From what I can see even
> the most bare bone Linux install still can be quite large, whereas the
> base Haiku at this point is a scant 60 MB or so, with full GUI and
> quite a few useful programs. Adding a WebKit-based browser and
> associated libraries might add another 25 MB at the most. Plus it is
> fast and efficient and easy on memory. But I don't want to side-track
> this discussion about mobile devices (though maybe it is too late for
> that ;)
>
> Regards,
> Ryan
> _______________________________________________
> glasselevator-talk mailing list
> glasselevator-talk at bug-br.org.br
> http://www.bug-br.org.br/mailman/listinfo/glasselevator-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.bug-br.org.br/pipermail/glasselevator-talk/attachments/20080229/8d43a0f2/attachment.html
More information about the glasselevator-talk
mailing list