Relationship to Fuchsia

Development OS
1

OSNews writes at
http://www.osnews.com/story/29802/Google_s_Fuchsia_gets_a_rudimentary_graphical_user_interface
that there are new Screenshots of the Fuchsia OS.
Fuchsia is Googles new Operating Systems for mobile devices. It will be the successor of Android.

The kernel of Fuchsia is called "Magenta"
https://github.com/fuchsia-mirror/magenta
and was initially written by Travis Geiselbrecht.

Travis Geiselbrecht was one of the developers of the BeOS-kernel and later develoiped its own operating system called “NewOS”, which Haiku later forked and used that code base for its own kernel.

So have anybody of the Haiku kernel developers looked at Fuchsia? Is there something better implemented, then in NewOS/Haiku ?
Or differs Fuchsia too much to NewOS, that it makes no sense to look at it?

It is nice, that on mobile deveces, Linux will be replaced with an other OpenSource operating system, with some ideas of BeOS I hope (because the author of the kernel).
Next step is then, replacing Windows with Haiku, Fuchsia or something else. Linux have never found its way on the desktop for the majority of the desktop users.
Linux can still be on Server and Supercomputer.

It is nice, that more Open Source operating systems comming up, which are not all-rounder, however specialized for one special area.

2 Likes
3

Well, we don’t have much direct relationship, and we don’t plan to switch to that new kernel just now. The most important reason is Fuchsia is a 64-bit only system and we still plan to support 32-bit software for some time. The second reason is we are trying to get a release out and it is a bad idea to change the kernel now.

While Travis may be the most “visible” connection to Haiku, according to him there are also several other developers who worked at Be in the Fuchsia team. So it seems the OS could be some kind of technological successor to BeOS.

Is it better than what we have? I hope so, because people don’t start a new project without good reasons. geist stopped working on newOS and switched to lk, which is now the core of Fuchsia kernel. I think he did newOS to make something similar to the Be kernel, and now, he has identified many problems with it, and he can write something better. I don’t know the rest of the team but I suspect they are on the same line.

There can still be some collaboration between the projects. Fuchsia is welcome to borrow some of our (MIT-Licensed) code or ideas. And we have already started looking at their code, for example in an attempt to get XHCI (USB3) working, as their implementation is similar to ours and their code is cleaner and easier to read than Linux or FreeBSD one in this case.

We’ll see where opportunities pop up to share efforts on some things in the future.

3 Likes
4

I wonder if it’s still possible for Haiku to move to a “capability based” security model. My own experience of file permissions (known as Access Control List - ACL) suggests - as a comparatively unskilled computer enthusiast - something intuitively not quite right. Why don’t I have permission to move or edit this file in my computer? What gives with these permission tick boxes in the file info? Because ACL is fundamental to Windows and all unix-style OS I don’t think it is something many of us even think to question. If Fuchsia have a better way, let’s grab it with both hands while Haiku is still relatively fluid.

1 Like
5

ACL was always an ugly hack just like “users” and “groups”, because nobody tought nix will stay with us so long.

2 Likes
6

I’m not sure why that Wikipedia article refers to “ACLs” as a comparison point to capabilities – aren’t ACLs related to file system ‘objects’ only ?

Capabilities refer to absolutely everything an Operating System uses, from IRQs to memory, to threads to graphics card access, networking, audio, file systems, the lot.

They’re one of the tools that you see being used for writing modern operating systems these days (not just Fuschia+Zircon) indeed, together with micro-kernel, components-based composition and so on.

7

In nix world somebody came up with the idea that everything is a file. Or better to say everything can be a file. But not that kind of file, but something different kind of file. Because simulacrum, i guess.
So yeah, ACL can affect those too.

2 Likes
8

First of all there is a confusion since ACL isn’t actually the traditional way to handle rights in UNIX. The original way is much simpler: files have a single owner, and a single “group”. And you can set 3 rights for the owner, the group, and people who are neither the owner nor a member of the group: read, write, execute.

This is simple and allows to fit all the permissions in just 9 bits in the filesystem. However, it quickly shows its limitations, for example if you want one group to have write permissions, another to have read permissions, and everyone else to have no access at all, this is not possible with UNIX rights.

ACLs are a more complicated system designed to allow these more complex cases. The way it works is described in the name: Access Control List. Instead of just 9 bits, there is now a list of who can access the file, and what they can do with it. The list can be as long as you need. There are also more fine grained permissions.

In Haiku, we implement the old UNIX system but make barely any use of it. There is a single user by default and they have read and write access to everything, and execute access to everything that’s executable. We do not have ACLs and as far as I know, we don’t plan to.

We may later have a capability based system, that would not be based on users, but on applications (similar to how it works in Android): before an application can access your webcam, or files on disk, or your contact list, it will have to ask you first. This is not so easy to do and requires a lot of changes to all layers of the system, and as far as I know, it is not on the roadmap for Haiku at the moment, we have more important things to do, and this would require API/ABI changes anyways so we will see about it after the R1 version is done.

17 Likes
9

I’m very happy that haiku is single user, just enable disk encryption and split hdd into multiple installs, you can always have a shared disk space between intalls as well.

Put login in bootman

So long as each instance of the os is password locked and encrypted, i fail to see where any multiuser system is superior.

None of this would effect abi or ap8 compatibly and be nearly over head free

1 Like
10

For a “modern” os the threat is no longer people logged into the same timeshareing system as you, but rather applications destroying other applications data, system config etc.
To solve this one needs a capbility based system for example.
On linux and bsds this is usually solved with unix users, though linux nowadays leans very heavy in a more heavy seperation of ressources for specific contextes that goes way above file permissions, for example namespaces.

Now, it certainly makes sense to implement something like this in Haiku to protect against faulty or malicious applications, and if you have that already adding a second “bigger” context for a second login session should not be enough work to warrant not doing it.

With disk encryption the only thing you are protecting against is your siblings or someone stealing your drive from you on the go. It does nothing against evil maid attacks, or just the way more reliable version of attacking a computer that is turned on.
(This is also why windows just doesn’t care to make it impossible to change windows passwords from another OS on the same device: if the attacker has this level of access you are screwed anyway)

Just my two cents ; )

5 Likes
11

Usually system attacks are about data harvesting, so encryption between installs is a how you protect user A from mis deeds of user B.

You are correct on your other points.

1 Like
12

You are quite right, and in trying to make sure I got the terminology correct, I dragged out something entirely different, even if ACL is the more direct competitor to “capability based” as used by Fuchsia amongst others to secure programmes and data. Here is the obligatory wiki link.

It is perhaps an opportunity for Fuchsia to leapfrog Windows and Mac which also went from a single user to multi-user system with proper security albeit those used inferior ACL technology. This was however accompanied with them fundamentally changing the underpinnings of their systems. Fuchsia also seems to be essentially about changing the underpinnings of Android with its only application to date (a so-called home hub) not exactly being conspicuous to the consumer.

The only problem is that Google are such a massive business that are able to impose their will on ostensibly open-source software, if Android is anything to go by. This is why, as far as a “Relationship to Fuchsia” is concerned, it’s probably best avoided. I now think perhaps the better “relationship” with a cutting edge (microkernel, “capability based security” etc) system might be with Genode.

2 Likes
13

I have no idea why people are so obsessed with security, encryption is the only way to keep data safe.

2 Likes
14

Perhaps slightly off-topic but since Genode came up, I was wondering. Any thoughts on Horizon/Mesosphere? Its design seems very interesting:

https://teddit.net/r/emulation/comments/hygtnx/mesosphere_opensource_nintendo_switch_kernel_now/

15

The situation is actually a lot more complicated. The Android project started outside Google and was originally completely closed source. Without Google buying it, it would probably have remained so. However, despite the efforts of the Google Open Source team, they didn’t quite get the Android team to adopt a true opensource model with openness to 3rd party contributors. The way it works is more that Android is developed by the Android team at Google and they release the sources when they are done.

Another aspect is that the Android OS itself is used by Google just a building brick, on which they add their own closed source layer, just as they do with many other projects, including Linux. And what makes them money is not the plain Android, but the one where they add all their apps. So, of course, that’s the one they are going to put more efforts on. Just like everyone else puts efforts on their UI and frontend, and in the end no one takes care of the lower layers: no one spends time upstreaming their work to Linux, OpenSSL is still maintained by a very small and underfunded company, and Android is getting the same fate. Yet another projects that everyone wants to use, but no one wants to pay for.

We will see for Fuchsia, at least they seem to have a more opensource culture from the start. And they have a lot of former Be employees in the team too, which should be a good sign on the technical side.

Anyway, at the moment Haiku does not plan to replace its kernel or other parts of the OS with 3rd party components we have no control on. And our current architecture is closer to the *BSD, so usually that’s where we go cherry-picking when we need to borrow some sourcecode from someone.

To me, there is a good balance in this: we are not exactly innovative with our kernel, we follow a well-known path, and it allows us to focus on more important things such as the user experience and a nice set of public APIs that make it enjoyable to write applications for Haiku. When we have that part done, we can think about doing crazy new things on the kernel side. That is, however, only my personal opinion, and if other people want to experiment with a new kernel, they can do so, and if it works better than the current one, we can consider integrating it.

9 Likes
16

The haiku kernel, could just be slowly optimized, and that process is probably just getting started

1 Like
17

It’s not really a matter of optimization. Fuchsia is a microkernel, while Haiku is generally a traditional style big monolithic kernel.

If we were to redo things today we would probably go with the microkernel approach. But we have an already working kernel and it’s not the right time to start replacing it, and spend a few months or years on that while we’re still in beta phase and trying to get a stable release out someday.

9 Likes
18

Haiku was always in-between micro/monolithic kernel.

Microkernel isn’t really that big of a benefit imho

1 Like
19

Microkernel is a good advantage for reliability, minix 3 for example has crazy resiliant drivers because of this. Most OS are somewhere between microkernel and monolithic kernel though.

2 Likes
20

BeOS arguably was an attempt at going a tiny bit closer to a microkernel, by moving video drivers and network stack to userspace.

Late BeOS and Haiku moved the network stack back into the kernel. So now only the videodrivers remain in userspace. If that’s enough to call Haiku “in between monolithic and microkernel”, then both Linux (before KMS), all BSD (still using X.Org video drivers) and Windows (since NT) also are in the same situation.

So, yes, there is some compromise in moving things around between the kernel and userspace. But we are not a microkernel at all. The fact that some drivers or filesystems or other things can be done in userspace does not make us a microkernel. The idea of a microkernel is that these things can’t be done kernel-side at all.

2 Likes
21

I understand the semantics of the micro macro monolithic kernels, i really have never seen the security claims rely work out though that rabid microkernelights claim