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

211–220 of 246 posts

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

#211

Post by jstimpfle »

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…

> Today, you still have to jump through hoops to do atomic file replace, and the hoops are different for different OSs

Do you? I may be misunderstanding you, but Posix says rename() is atomic.

Regarding your file system issues, note that you can have most of this with O_TMPFILE on linux. I think the slight exception is that file modes can't be restored if you are not a member of the original file's user or group.

But disregarding that, the file system changes you suggest (strict separation of "unit", "log", "managed", "temp" files) are artificial, so I don't think that they belong in the kernel. It's the old mechanism vs policy theme.

A small issue I have with Posix file systems is that the transaction granularity is a single file or sub-tree. You can't have transactions that affect file in distinct sub-trees.

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

#212

Post by skissane »

jstimpfle wrote: post #210
skissane wrote: post #185

Earlier quoted context omitted.

> I think this discussion misses the point what "everything is a file" is about. I don't agree. POSIX systems provide APIs to wait on events on file descriptors – select, poll, etc. I can use those APIs to wait on an event on a pipe, a network socket, a device file, etc. To wait on an event on anything which is represented by an file descriptor. But what if I want to wait for a child process to exit? I can't use sele…

> But what if I want to wait for a child process to exit? I can't use select/poll for that since processes are not represented by file descriptors in standard POSIX – FreeBSD is a notable exception, but FreeBSD's facilities are non-standard. And Linux has signalfd (also not POSIX). I agree with you, signals are a pain, and could probably be replaced by fds at the handling side (of course not: KILL, STOP, CONT...). Th…

> As a matter of fact, you are not. I'm sure you know about EINTR.

The problem with using signals to manage child processes comes when child processes are started by libraries. If the library installs a handler for SIGCHLD, it could conflict with other libraries or with the application which wants to do the same thing. The great thing about FreeBSD style process descriptors is that no signal handlers are needed–a library can start a child process and then wait for it to complete (and wait for other things such as network sockets simultaneously) without relying on signal handlers which don't work well when an application is composed of numerous independently developed libraries (as many modern applications are).

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

#213

Post by jstimpfle »

skissane wrote: post #212
jstimpfle wrote: post #210

Earlier quoted context omitted.

> But what if I want to wait for a child process to exit? I can't use select/poll for that since processes are not represented by file descriptors in standard POSIX – FreeBSD is a notable exception, but FreeBSD's facilities are non-standard. And Linux has signalfd (also not POSIX). I agree with you, signals are a pain, and could probably be replaced by fds at the handling side (of course not: KILL, STOP, CONT...). Th…

> As a matter of fact, you are not. I'm sure you know about EINTR. The problem with using signals to manage child processes comes when child processes are started by libraries. If the library installs a handler for SIGCHLD, it could conflict with other libraries or with the application which wants to do the same thing. The great thing about FreeBSD style process descriptors is that no signal handlers are needed–a lib…

I agree. Signals have process scope, so they are a bad idea in general (they counter composability), no matter what's the delivery mechanism. Signal FDs don't help here vs EINTR.

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

#214

Post by milesrout »

pjmlp wrote: post #12
milesrout wrote: post #9

Earlier quoted context omitted.

No, they haven't. Stop believing everything you read on reddit. Java didn't displace C++, and C++ certainly hasn't displaced C.

> Java didn't displace C++ C++ has become an infrastructure language on the enterprise. We write native libraries in it, like COM components, or plugins that interact with Python, Lua, Java, .NET, Node,... VMs. No one writes full stack applications in C++ any longer, other than maintaining the existing ones. Even game engines have moved into a mix of C++ + higher level language. On the mobile OSes, C++ only has GUI s…

My favourite C compiler most certainly is not written in C++.

Many people write programmes in C++, unfortunately. Any Qt programme is written in C++, all performance-dependent modern libraries are written in C++.

Whether people write every layer of their programme in C++ is irrelevant.

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

#215

Post by milesrout »

notalaser wrote: post #52
gaius wrote: post #41

Earlier quoted context omitted.

who thought Windows would replace Unix Windows now runs all the workloads that Sun, SGI, DEC, HP, IBM yadda yadda workstations once ran. I don't remember the last time I saw a real Unix workstation outside my home office where I keep an Octane for nostalgia's sake, and the wife has her old SPARCstation. But you are right about C and POSIX.

Let me paint this in a more interesting colour: at $work, most of our development work is very POSIX-y software (it only runs on Linux, but historically, at least portions of it used to run on a bunch of BSDs, too, and they probably still do, but no one tried it in years). Almost no one in the office uses Unix on their computer, not even those of us who use Linux at home. Most of us have Windows stations. We can inst…

I'm sure you theoretically could run everything on Windows. But you don't, because doing so would be a bad idea.

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

#216

Post by milesrout »

notalaser wrote: post #208
icebraining wrote: post #188

Earlier quoted context omitted.

It's not that Ubuntu releases aren't production-ready, it's that no major OS releases are production-ready - hence Windows 8.1, and one of the reasons why Enterprise is still on 7. By using LTS, you get to skip that nonsense for years, and jump directly into a release which has had its kinks ironed out (or at least documented). As for Debian security updates, what do you mean?

There is a great deal of effort involved in backporting updates to frequently-updated packages. Debian, for instance, doesn't update WebKit (or at least didn't last time I checked, and had a policy for it). Consequently, things like Evolution (which uses WebKit internally) are a walking CVE museum on Debian stable. The situation is similar for a lot of other packages, on a lot of other distributions with long-term su…

Install Firefox then.

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

#217

Post by milesrout »

moby_click wrote: post #25
milesrout wrote: post #6

Earlier quoted context omitted.

POSIX is neither antiquated nor anemic. There's nothing antiquated about a hierarchical filesystem with a single root. There's nothing antiquated about 'everything is a file'. In fact, that's continually useful to me on a day-to-day basis. There's nothing antiquated about byte streams, which is all they are. They aren't text streams. A great example of how all of this turns out to be good design is that you can see h…

> There's nothing antiquated about a hierarchical filesystem with a single root. Unfortunately the hierarchical structure is lost in the name. It's one flat string and '/' and NUL have special meaning. In a way, containers show that there is a legitimate need for multiple roots.

What?

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

#218

Post by milesrout »

qznc wrote: post #47
gaius wrote: post #43

Earlier quoted context omitted.

Containers are to a large extent a solution to an artificial problem. It your app is a single binary file + a single text configuration file with no dependencies apart from system libraries (i.e. libc POSIX) then you don't need a container, you're just a process. Containers are necessary because applications now consist of hundreds of small files with complex inter- and external dependencies.

You still want the additional security, if your daemon gets compromised. You still want to restrict resources (number of cores, memory, etc). Nevertheless, I agree that containers are often a cut through Gordian Knot. Just put everything in its own box instead of resolving dependencies.

Containers don't provide additional security, nor do they provide additional ways to restrict resources. If you want to restrict resources or sandbox programmes, you can do so without containers.

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

#219

Post by milesrout »

kuschku wrote: post #96
milesrout wrote: post #6

Earlier quoted context omitted.

POSIX is neither antiquated nor anemic. There's nothing antiquated about a hierarchical filesystem with a single root. There's nothing antiquated about 'everything is a file'. In fact, that's continually useful to me on a day-to-day basis. There's nothing antiquated about byte streams, which is all they are. They aren't text streams. A great example of how all of this turns out to be good design is that you can see h…

> There's nothing antiquated about a hierarchical filesystem with a single root. Actually, there’s quite a bit about that. Having actually a filesystem API that takes a UUID for a partition, and then a relative path within the partition, would solve a lot of problems.

Why would you possibly want to do that?

Hell, if you want to do that, you can do it. But there's no reason to want to do that. Partitions are an implementation detail of the filesystem. You shouldn't care whether /home is on the same partition as / or not.

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

#220

Post by milesrout »

hornetblack wrote: post #56
moby_click wrote: post #25

Earlier quoted context omitted.

> There's nothing antiquated about a hierarchical filesystem with a single root. Unfortunately the hierarchical structure is lost in the name. It's one flat string and '/' and NUL have special meaning. In a way, containers show that there is a legitimate need for multiple roots.

It might be worth noting that the original unix designers introduced containers to unix (as "Namespaces") in Plan9.

I wouldn't call the developers of Plan9 the 'original UNIX designers'.

For that matter, I think it's naive to say that containers and namespaces are the same thing.

Post reply on HN