vhaudiquet wrote:
I really like the idea of dropping '..' support [...] and other POSIX features (eg. symlinks) to ensure more stability and security (process isolation here).
I see a lot of broken porcelain and not much to show for it. Those features exist for a reason. And for any OS restriction you can be damn sure people will invent workarounds. In this case, they have no ".." support in the FS server, so why don't we just keep a handle to the root around and keep inheriting that one. Then we can implement path lookup in user space.
vhaudiquet wrote:
I do think that modern operating systems, for an everyday user, will only work in a GUI and in single-user mode (with a capability permission system, kind of like in Android)
So a person who has only ever used a car tells me that nobody uses motorbikes anymore. *sigh* Just because something does not crop up in your world, doesn't meant it isn't still relevant for other people. At latest when you are working at a large company and need to access shared resources, the concept of a user will be very helpful. Which is also why multi-user support in the terminal OS (and FS) is a good idea. Now, yes, for most end-user terminals users are too wide a concept. The solution is not to throw the baby out with the bathwater, but rather, to restrict access scope further, beyond the user, which is what AppArmor and SELinux are doing. Personally I find SELinux impossible to work with, so AppArmor is the way to go for any normal person.
vhaudiquet wrote:
thus most of the POSIX / standard C specifications are useless
I do not see how a claim about the concept of a user somehow connects to this baffling statement. C doesn't even know anything about users, and POSIX really doesn't care about them as much as you claim here.
vhaudiquet wrote:
I think that it is interesting to see them dropping fork(), signals, and exec() as well, it really shows that those are legacy interfaces and that we can do better today.
You have an interesting notion of "better". exec() I don't really have a problem with, but for the most part there is no difference between exec() and spawn()+wait(). I do foresee issues when it comes to PID 1, which is special, but then PID 1 should not run a complex program (which is a lesson the systemd folks really should have learned by now). Dropping fork() in its original semantics is exactly what I am going to do (I wrote about it before). But signals?
I found no rationale given for dropping signals. It is certainly true that they complicate things. Programs handling signals must be written in a signal-safe way, because the signal could arrive at any time. However, we've worked it around a lot, and there is nothing quite like a signal for telling other processes about an event. Other communication channels just get unbearably complex if you require an n:m relationship (multiple senders and multiple receivers). With signals, as long as you know the PID, you can send a signal, even if you are not the parent process or anything.
Plus, once you have signals, you can use them to signal exceptional conditions in a standardized way, and don't have to create another way to do that. There is no way to create a watchdog timer that is quite so expedient as calling alarm(), for instance. Sometimes EINTR isn't a bug but a feature.
vhaudiquet wrote:
i don't really like the idea of userspace programs using 'kernel handles'
What's a file, then? Userspace programs necessarily need to interact with kernel objects, unless they are pure calculations, but even those need to provide their results somehow. And that means they need to interact with the VFS as presented by the kernel. Whether you call it an FD or a "handle" doesn't really matter.
That said, I just read a bit into the documentation and found that they allow creating threads in other processes. So, the worst NT feature to ever grace the planet was added into Zircon as well. What was that you said about process isolation or something? They disallow signals because of isolation problems and then allow this nonsense. That's like buying a Smart for the fuel economy and then deliberately puncturing the fuel line.
vhaudiquet wrote:
What do you guys think about Fuchsia, not as a user but as an OS developer ?
Typical Google. "We are so much better then MS", and then proceed to copy their worst aspects. It would appear that corporate OS development always goes that direction, whether it takes place in Washington or California.
As for Fuchsia itself, I see quite a lot of "change for the sake of change", which is self-indulgent at best, and destructive at worst. A couple good ideas on display, but the maxim "those who fail to learn from Unix are doomed to reinvent it, poorly" does seem to hold.