Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Posix Has Become Outdated (2016) [pdf]

cs.columbia.edu

Post reply on HN
Print view View original

191–200 of 246 posts

Re: Posix Has Become Outdated (2016) [pdf]

#191

Post by throwawayish »

TwoBit wrote: post #186
throwawayish wrote: post #180

Earlier quoted context omitted.

I would wish that the whole (disk) I/O mess would be cleaned up. It's just laughable how broken that is across operating systems. And it's supposed to be the back-bone of most operating systems as well. Also, memory management. Only in very recent years proprietary APIs surfaced in Linux and friends that allow to leverage some of a modern MMUs capabilities (which is good). Meanwhile we still have stupid MM semantics…

You're saying that Windows async IO calls aren't async and in fact they will block on reading and writing? I've never heard of that.

Like I said, just the extent (cluster run) operations; if you're overwriting they shouldn't block and I didn't manage to make them, if you're extending they usually don't seem to but some times do block.

Re: Posix Has Become Outdated (2016) [pdf]

#192

Post by mycall »

Animats wrote: post #163

Reasonable enough. The article focuses on client-side programs, especially Android, which have somewhat different requirements than the Posix model envisions. Most of the things you need to do on headless servers can be done through the Posix model. The big weaknesses in Posix they point out are in interprocess communication and parallelism. Both were afterthoughts in UNIX. UNIX/Linux land never had a good IPC mechan…

If you like QNX IPC, you should look at seL4 IPC in Genode.

https://genode.org/documentation/articles/sel4_part_2

Re: Posix Has Become Outdated (2016) [pdf]

#193

Post by jmgao »

pjmlp wrote: post #54
ndesaulniers wrote: post #13

Earlier quoted context omitted.

> then diverged only enough to harm portability How so?

ChromeOS might be built on top of a POSIX like kernel, but the actual application stack is the browser. Android is mostly Java, the NDK only white lists a restricted set of libraries that aren't POSIX related, Android 7 dynamic linker will kill any app that tries to link to device libraries not part of that list, the Linux fork lacks APIs like e.g. UNIX IPC. Android Things is even tighter. Only user space drivers are…

> the NDK only white lists a restricted set of libraries that aren't POSIX related

Uh, libc?

> Android 7 dynamic linker will kill any app that tries to link to device libraries not part of that list

Yes, it prevents you from depending on things that aren't required to be there. Apps depending on the device's OpenSSL libssl.so were horribly broken when Android switched to BoringSSL after Heartbleed. Preventing apps from loading system libraries guarantees that they won't break when those libraries are changed or removed in future releases.

> the Linux fork lacks APIs like e.g. UNIX IPC.

POSIX/SysV IPC are unusable on any system with untrusted applications. They live in a global namespace not tied to a process, and there's no reasonable way of doing any sort of accounting on them. There isn't even a way to use them correctly. If you shm_open, and fail to shm_unlink (for example, if you're OOM killed), the shared memory object will live forever. In the specific case of shm, Android introduced a far superior API, ashmem, which tracks shared memory objects as file descriptors, instead of manually refcounting names in a global namespace (memfd was added in linux 3.17, which solves the same problem in the same way).

Re: Posix Has Become Outdated (2016) [pdf]

#194

Post by Animats »

qznc wrote: post #177
Animats wrote: post #163

Reasonable enough. The article focuses on client-side programs, especially Android, which have somewhat different requirements than the Posix model envisions. Most of the things you need to do on headless servers can be done through the Posix model. The big weaknesses in Posix they point out are in interprocess communication and parallelism. Both were afterthoughts in UNIX. UNIX/Linux land never had a good IPC mechan…

I don't know QNX, but for IPC you should also take a good look at the L4 microkernel IPCs. It might be what you describe here. The point is that they are fast. Nearly function-call-speed. The should probably a more complex IPC layer on top or beside it. Something like DBus with schemas, names, groups, broadcasts, etc because otherwise people will reinvent it poorly.

QNX IPC is deliberately just a delivery mechanism for a byte string. That's the OS level. You can put JSON, Google protocol buffers, or something else on top of it. In the hard real-time world, it's common to just pass known C structs with the necessary data items around. The OS doesn't care.

If you're implementing microservices, it's quite useful. I did a robot vehicle that way. All the Boston Dynamics robots run QNX.

Re: Posix Has Become Outdated (2016) [pdf]

#195

Post by pjmlp »

jmgao wrote: post #193
pjmlp wrote: post #54

Earlier quoted context omitted.

ChromeOS might be built on top of a POSIX like kernel, but the actual application stack is the browser. Android is mostly Java, the NDK only white lists a restricted set of libraries that aren't POSIX related, Android 7 dynamic linker will kill any app that tries to link to device libraries not part of that list, the Linux fork lacks APIs like e.g. UNIX IPC. Android Things is even tighter. Only user space drivers are…

> the NDK only white lists a restricted set of libraries that aren't POSIX related Uh, libc? > Android 7 dynamic linker will kill any app that tries to link to device libraries not part of that list Yes, it prevents you from depending on things that aren't required to be there. Apps depending on the device's OpenSSL libssl.so were horribly broken when Android switched to BoringSSL after Heartbleed. Preventing apps fr…

> Uh, libc?

libc is the C runtime library, a subset of POSIX.

A conforming ANSI C implementation is not required to provide headers like unistd, or any kind of POSIX compatibility beyond what ISO/IEC 9899 requires.

> POSIX/SysV IPC are unusable on any system with untrusted applications.....

Either POSIX compatibility matters, or it doesn't.

Re: Posix Has Become Outdated (2016) [pdf]

#196

Post by pjmlp »

AsyncAwait wrote: post #181
pjmlp wrote: post #162

Earlier quoted context omitted.

So Microsoft, Google and Apple do it, it is bad. Linux does it, it is me that doesn't understand, I see.

Linux is mostly POSIX compliant. It has layers on top that are not POSIX, but that doesn't mean it is not POSIX or that you can't expect your POSIX apps to work on Linux.

Not at all, it means that many mistakenly use Linux syscalls as synonym for POSIX, thus making the same lock-in to GNU/Linux as Google, Apple and Microsoft do to their own systems.

*BSD devs jump of joy having to port GNU/Linux applications that depend on D-BUS, systemd, or any other Linux specific APIs.

Re: Posix Has Become Outdated (2016) [pdf]

#197

Post by jmgao »

yamaneko wrote: post #68
kccqzy wrote: post #32

Earlier quoted context omitted.

That's what majority of computer users (smartphones included) use though. As for developer-oriented CLI tools, I've also seen more and more GNU-isms and macOS-isms creeping in.

Just curious, can you give me some examples of GNU-isms/macOS-isms? I have a suspicion what they might be, but I'm not sure.

One hilarious one is basename(3), which is two functions with different behavior, but the same name. The one you get depends on which headers you include, and what _GNU_SOURCE is set to.

See http://man7.org/linux/man-pages/man3/basename.3.html for the manpage.

Re: Posix Has Become Outdated (2016) [pdf]

#198

Post by DaiPlusPlus »

discreteevent wrote: post #51
DaiPlusPlus wrote: post #4

Earlier quoted context omitted.

POSIX compliance is important if you value portability - especially for business critical systems (e.g. you want your bank's transaction processing data to work on IBM Z/Series's UNIX, whatever Linux distro they use, and say... SunOS). My main takeaway from the article is POSIX is too antiquated and anemic as a "system API" for modern-day use - however I'm surprised the article doesn't seem to touch upon POSIX shortc…

" the vaporware "object-oriented operating system" concepts” COM is Windows and COM is about as purely object oriented as you can get. It's not vaporware.

COM can be said to be overly complicated (at least not as bad a CORBA). I think WinMD is a step in the right direction, but both COM and WinMD are userland constructs and neither particularly pervade the OS (e.g. you can't pipe COM objects)

Re: Posix Has Become Outdated (2016) [pdf]

#199

Post by jmgao »

pjmlp wrote: post #195
jmgao wrote: post #193

Earlier quoted context omitted.

> the NDK only white lists a restricted set of libraries that aren't POSIX related Uh, libc? > Android 7 dynamic linker will kill any app that tries to link to device libraries not part of that list Yes, it prevents you from depending on things that aren't required to be there. Apps depending on the device's OpenSSL libssl.so were horribly broken when Android switched to BoringSSL after Heartbleed. Preventing apps fr…

> Uh, libc? libc is the C runtime library, a subset of POSIX. A conforming ANSI C implementation is not required to provide headers like unistd, or any kind of POSIX compatibility beyond what ISO/IEC 9899 requires. > POSIX/SysV IPC are unusable on any system with untrusted applications..... Either POSIX compatibility matters, or it doesn't.

> libc is the C runtime library, a subset of POSIX.

> A conforming ANSI C implementation is not required to provide headers like unistd, or any kind of POSIX compatibility beyond what ISO/IEC 9899 requires.

Yes, and Android's libc provides almost all of (all of? I don't know for sure) POSIX.1.

> Either POSIX compatibility matters, or it doesn't.

POSIX IPC is a non-mandatory option in POSIX. See http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_... if you want to be a language lawyer.

More to the point, POSIX compatibility matters up to the point where it's useful. Implementing the shared memory functions by returning -1 and setting ENFILE is a perfectly compliant implementation. It's also worse than just not providing an implementation.

Re: Posix Has Become Outdated (2016) [pdf]

#200

Post by AsyncAwait »

pjmlp wrote: post #196
AsyncAwait wrote: post #181

Earlier quoted context omitted.

Linux is mostly POSIX compliant. It has layers on top that are not POSIX, but that doesn't mean it is not POSIX or that you can't expect your POSIX apps to work on Linux.

Not at all, it means that many mistakenly use Linux syscalls as synonym for POSIX, thus making the same lock-in to GNU/Linux as Google, Apple and Microsoft do to their own systems. *BSD devs jump of joy having to port GNU/Linux applications that depend on D-BUS, systemd, or any other Linux specific APIs.

Given that *BSDs also have many of their own extensions, (ie openbsd has many security extensions to the POSIX standard), that isn't the best example of a defense.
Post reply on HN