Fuchsia is not Linux

Re:Fuchsia is not Linux by ansible on Wednesday April 11, 2018 @04:06PM (#16814987)

> ... POSIX is not so great as well ...

Ugh, tell me about it. Just dealing with a relatively simple situation where you've got signals coming in while reading a pipe is a hassle to get completely correct.

I am so there for an operating system API that is relatively simple and sane. Where writing correct programs is, if not the easy path, at least not the hard and obscure path.

[ Parent | on HN ]

Re:Fuchsia is not Linux by derefr on Wednesday April 11, 2018 @05:01PM (#16815585)

I'd be down for an Erlang-like OS ABI (or, to put that another way, a Windows-GUI OS ABI, but for even non-GUI processes): just message-passing IPC all the way down. OS signals, disk IO, network packets, [capabilities on] allocated memory, [ACL'ed] file handles, etc: all just (possibly zero-copy) messages sitting in your process's inbox.

Of course, it's pretty hard to deal with a setup like that from plain C + libc + libpthread code, so OSes shy away from it. But if your OS also has OS-global sandboxed task-thread pools (like macOS's libdispatch)—and people are willing to use languages slightly higher-level than C where tasks built on those thread-pools are exposed as primitives—then it's not out of the question to write rather low-level code (i.e. code without any intermediating virtual-machine abstraction) that interacts with such a system.

[ Parent | on HN ]

Re:Fuchsia is not Linux by pavlov on Wednesday April 11, 2018 @05:22PM (#16815816)

> ... message-passing IPC all the way down

Wasn't QNX like that?

[ Parent | on HN ]

Re:Fuchsia is not Linux by dfox on Wednesday April 11, 2018 @05:36PM (#16815961)

QNX IPC mechanism is essentially cross-process function call, ie. message sender is always blocked while waiting for message reply and the server process cannot meaningfully combine waiting for message and some other event.

Edit: in essence QNX messages work like syscalls, with the difference that there are multiple "systems" that accept "syscalls". For what it's worth Solaris has quite similar IPC mechanism that is mostly unused.

[ Parent | on HN ]

Re:Fuchsia is not Linux by my123 on Wednesday April 11, 2018 @05:59PM (#16816136)

The NT Native API is relatively elegant, especially Alpc (a shame that it's mostly hidden by Win32 tho)

[ Parent | on HN ]

Re:Fuchsia is not Linux by vardump on Wednesday April 11, 2018 @08:48PM (#16817139)

The biggest blunder is that ALPC is not accessible through Win32 at all. ALPC is much more sane than any other IPC Windows got.

Sure, you can use ALPC, but only by using undocumented unstable NT API...

Sigh.

[ Parent | on HN ]

Re:Fuchsia is not Linux by henesy on Thursday April 12, 2018 @05:53PM (#16825231)

Plan 9?

[ Parent | on HN ]

Re:Fuchsia is not Linux by Viper007Bond on Wednesday April 11, 2018 @04:15PM (#16815089)

Interestingly PowerShell is petty awesome in that regard. You pass around objects instead of trying to parse strings and things.

[ Parent | on HN ]

Re:Fuchsia is not Linux by sleepydog on Wednesday April 11, 2018 @05:46PM (#16816052)

I don't think that's what the parent was complaining about, it was more about handling signals correctly. It's incredibly easy to write buggy signal handlers on a Linux system. The "self-pipe" trick[1], and later, signalfd(2) have made signal handling much easier, but a lot of programs still do it the old way.

[1]: http://cr.yp.to/docs/selfpipe.html [2]: http://man7.org/linux/man-pages/man2/signalfd.2.html

[ Parent | on HN ]

Re:Fuchsia is not Linux by vardump on Wednesday April 11, 2018 @04:29PM (#16815246)

PowerShell is not Windows API, win32 is. So your comment makes little sense.

[ Parent | on HN ]

Re:Fuchsia is not Linux by reificator on Wednesday April 11, 2018 @04:38PM (#16815336)

Powershell is just that, a shell. I agree that Powershell itself is pleasant enough to use but that's not what's being discussed.

[ Parent | on HN ]

Re:Fuchsia is not Linux by msla on Wednesday April 11, 2018 @05:01PM (#16815587)

> You pass around objects instead of trying to parse strings and things.

That can't be very good for debuggability.

[ Parent | on HN ]

Re:Fuchsia is not Linux by pzone on Wednesday April 11, 2018 @07:12PM (#16816637)

Type checking and calling help methods can be useful for debuggability! If you want to figure out what you're looking at in string format, call its .ToString method.

[ Parent | on HN ]

Re:Fuchsia is not Linux by msla on Thursday April 12, 2018 @11:31AM (#16821970)

Adding extra complexity just means more to go wrong. Plain text can't really go wrong because anything can use it, anything can edit it, anything can show it. With "objects" I'm betting that Powershell itself never fails.

[ Parent | on HN ]