Haiku on Phones

Looks all nice, but who wants a grey background on a phone? I think black is here the better grey :wink:

1 Like

That’s just the placeholder for app content.

Article detailing the process to port and boot a non-Linux OS on the PinePhone:

By any chance, could the info regarding the general Allwinner A64 boot process be potentially useful for the ongoing Haiku ARM ports as well?

1 Like

I believe the ARM ports are at an early stage still so we have more generic issues to be tackled first.

Having said that, if anyone wants to do some bring-up on the A64… contributions are welcome! :wink:

3 Likes

If you’re proposing (in another thread) @SamuraiCrow that Haiku on phones should use another base, then perhaps using Apache NuttX may be more ideal. It is fairly small, well-documented, real-time, a microkernel, and the PinePhone port is being worked on by someone well-acquainted with the hardware including some future drivers planned for it.

Personally though, I’d prefer sticking as close as possible to Haiku.

1 Like

Perhaps Haiku isn’t the best OS for phones but I do like small OSs. My reasoning for wanting to use Genode was outlined in the other thread as well. I do have high hopes for the PinePhone being privacy oriented because it does have a kill-switch in the back cover for each separate subsystem. Using a microkernel would just be the icing on the cake as far as driver isolation goes.

Just to reiterate the core premise:

Haiku is built for desktop, especially the interface. The main appeal (as mentioned by @nephele before):

Good basic phone and a pocketable Haiku installation, the latter being activated when the necessary peripherals are connected.

If all of Haiku is going to be used for a desktop mode, then might as well use parts of it for a distinct mobile mode too.

Parts I’d like to reuse because i sinply like them are stuff like the ALM layouting engine we have, the controllooks(concept), some system designs. But for most parts it may turn out that Maple would use the Haiku variant, and maybe replace them later with more aproriate stuff. Potentially some gets back to Haiku too.

Suppose that makes sense, although maybe it shouldn’t divert too much so that desktop mode remains essentially like regular Haiku.

the desktop mode will need changes, atleast some. but largely unchangef yes. But the mobile mode will likely diverge more

Before we start daydreaming UI, where are the basic fundamentals for a mobile operating system (modem drivers, the ability to make a LTE/5G call, SMS, roaming)? Haiku doesn’t have them, the developers aren’t interested, and forking it to create a mobile OS… is possible? But you’ll most likely give up because forking a large project like Haiku requires not only tons of maintenance but also funding.

One possibility is for example, make a build of Haiku for the PinePhone or Librem or whatever, make the mobile UI and software suite a collection of packages you can install from a repo, and I’m not sure if Haiku has Linux-like kernel modules but somehow add support for modems and stuff along the way, what about that?

2 Likes

Sorry, but why should drivers matter before you even figured out what you want to run on the device? It’s better to start planning out what you want to do before blindly writing drivers. Drivers only do what the userspace wants to have done. If you would never use the accelerometer gor instance you could simply not write a driver.

No, forking does not require funding. It only requires people to have ideas about what to do and then do them, for instance by making a git repo and adding stuff there. forking is not that black and white. does Haiku want maple specific components or code in the sourcetree? probably not. But it is fairly trivial to put it into another sourcetree instead.

Also, a side note: SMS is basically dead, only apple still uses this as the “lowest” standard, everyone else moved on to rcs

1 Like

For Me Haiku is perfect desktop operating system and would be more better when it have more device drivers, i think haiku dont need phone edition, but i agree there are devices like microsoft surface go, 2 in 1 devices tablet with keyboards, touchscreens and more and more, hey i like 2 in 1 i have two old windows 8.1 tablets and i am in love with it, but this devices needs not only touch UI like bigger widgets, but needs work at kernel side like more responsible kernel, in linux you can compile kernel with more responsible sheduler and so (sorry for my bad english), i try not only one but more times to install linux to my tablets but allways i back to windows.

i think better than phones support are 2 in 1 and support for normal notebooks with big touchpads

We’re already sharing drivers with BSD. Who will we share drivers with on the PinePhone or whatever else? It seems BSD doesn’t support any phones. Android drivers are closed-source binary blobs and most Android phones are locked to one carrier in the U.S.

The only reason I would add a custom OS to my PinePhone is if it’s more secure than the locked Android 10 smartphone I currently use. A media-oriented OS like Haiku might work on the desktop but I’m not so sure that that programming paradigm lends itself to mobile use. Mobile phones are primarily internet appliances first and computing devices only as a distant second.

Just for the records: I get sometimes important SMS. For example from my provider.

And I don’t understand why the highlevel stuff has to developed before the drivers. I still think the other way round which means drivers first. But I admit I might be wrong on that.

Greetings
Peter

1 Like

Not in the US, SMS is still widely popular here

2 Likes

Not true, as SMS is still widely used in many nations (including mine). Oftentimes, it is the only reliable communication method in areas with very minimal coverage. RCS has yet to be introduced in most parts of the world.

2 Likes

This is prolly not exactly how development would go, but most likely yes in a general development sense. Get Haiku running on a phone first, then build the mobile mode on top of it. Although it could also go with develop the mobile mode UI on regular Haiku first, then port to a phone.

Regardless, there should prolly be at least a solid concept for how it will look like in the first place beforehand to guide future development.

1 Like

Not a good idea for phone-sized portrait screens, especially if the aspect ratio is something like 9:21 or 6:13 wherein the width is very narrow relative to the height. It might be somewhat ok on 9:16 and 1:2 (aka Univisium ratio) screens, the latter of which is used by the PinePhone.

However, it would prolly be a good idea to design around the assumption that the UI could be used on any screen that doesn’t have a 1:1 ratio. Unless of course, maybe we should even account for square screens too? heh

Alright, how about doing that by unifying the app drawer with quick settings? User opens up quick settings first, then swiping to the app drawer.

Still looking for feedback on whether to stick with the current UI direction or shift to a sidebar layout as proposed earlier:

I’m not sure honestly, maybe it could be nice? I am not sure what you have in mind exactly, atleast severall parts of my design “in my mind” wouldn’t work easily with that, say how windows “stack” and such, that a window has severall views that are sparially right bext to each other, and a list of views to jump to them directly.

edit: as for quick settings, the app drawer to me is more important so… eh, I’d be interested in a shared design but not to have quick settings be the default then.