Comment by DaiPlusPlus | Hacker News Reader

Comment by DaiPlusPlus | Hacker News Reader

Parent Full thread

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 shortcomings instead being a consequence of the UNIX design philosophy - a strong personal concern of mine regards UNIX-like's future development course - should we continue to uphold "everything is a file", ioctl(), and piping text-streams as the best way to build an OS?

Curiously, the article chides POSIX for lacking modern abstractions (specifically, graphics) but I disagree - POSIX would be a disaster if it included anything like OpenGL or Cairo (case-in-point: Win32 is tightly coupled with GDI and now we're paying the price by being physically unable to do deep-color graphics in Win32 without serious hacks) - I think that (to paraphrase one of the UNIX philosophies) "small APIs that do one thing and do it well" applies to POSIX (as it does process and system management, and nothing else) and it has worked.

Coming from a modern Windows developer experience - I think there's a great deal to be learned from the failures of the vaporware "object-oriented operating system" concepts of the mid-1990s and how the concept has been resurrected in the form of PowerShell object-piping and WinMD today and should be explored as the next possible step in OS design at a fundamental level - not just as a shim on top as it is with Windows.

That said, UNIX and GNU/Linux have always evolved in small steps - pretty much every great-leap-forward is doomed to failure or endless ideological controversy (see `systemd`) so maybe UNIX-like OSes are not the right place to test new design concepts - but some new OS will - and eventually that OS will supersede Linux in the way many people believe Rust will replace C++.

> should we continue to uphold "everything is a file"

POSIX doesn't do a very good job of upholding that. POSIX is full of entities (e.g. notably processes and threads) which can't be manipulated via file descriptors. Some POSIX implementations do better – e.g. FreeBSD's pdfork – but that isn't standardised. By contrast, Windows NT in which "everything is a handle" actually provides a more unified interface to OS objects than POSIX does.

> POSIX is full of entities (e.g. notably processes and threads) which can't be manipulated via file descriptors.

Well there is /proc

Which isn't a standard part of POSIX. It is an implementation-specific extension, which only some implementations have (OS X most notably lacks it), and even those who have it implement it in incompatible ways (e.g. /proc on Linux is quite different from /proc on Solaris).

Also, Linux /proc doesn't really allow you to treat processes as file descriptors like FreeBSD's pdfork does. Sure, I can open /proc/123, but operations on the resulting file descriptor have no relationship with the process – if I pass the FD into a select() I won't get any notifications about the process lifecycle.

I think this discussion misses the point what "everything is a file" is about.

The standard way to exchange (read, write) information should be through the Unix file interface where possible. Note that "file" here means "FILE *", i.e. an "opened file" or "stream". Not a file on a filesystem which is just one way to make one kind of stream.

In other words that mantra is about simplicity. Simplicity is what enables software to exist.

> 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 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.

If I want to simultaneously wait on both a child process to terminate and a message to arrive on a socket, I am forced to use multiple threads. For example, I could have a thread to execute waitpid() and then have it write to a pipe, and have another thread select/poll on both that pipe and the network socket. If processes were represented by file descriptors, I could have a single thread doing a select/poll on both the network socket and the child process.

> In other words that mantra is about simplicity. Simplicity is what enables software to exist.

Yes, and POSIX fails to be simple here. By failing to sufficiently unify its abstractions, it forces application code to be more complex than it should be.

> 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...). The overhead of polling vs asynchronous signal delivery could be optimized away with the VDSO.

> If I want to simultaneously wait on both a child process to terminate and a message to arrive on a socket, I am forced to use multiple threads.

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

Anyways I was more referring to your original parent ('should we continue to uphold "everything is a file"'), and it seems we both agree that "everything is a file" as a pure ideology is very worthwhile.

> 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).

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.

> and it seems we both agree that "everything is a file" as a pure ideology is very worthwhile.

I don't understand that ideology - I don't believe everything can be abstracted as a file considering that ioctl() breaks that abstraction. For example, what is it to "read from /proc/{pid for Chrome}"? Would you be reading from the process' memory space? Reading from a rendered bitmap of the process' main framebuffer? Reading a human-readable text file of process metadata? If it's labelled metadata then how do you deal with UX localization? Same thing when "reading from a /dev device" which isn't a storage device, what should it mean to "read from a GPU"?

> I don't understand that ideology

The OS kernel needs to provide user space processes with access to kernel-managed resources such as files, devices, network sockets, processes, threads, etc. In order to do so, there needs to be some way of identifying these individual resources to the kernel. And then the question is, should every type of resource have a distinct type of identifier? Or should we have a single type of identifier which could refer to an instance of any one of those types of resources?

The pure "everything is a file descriptor" ideology (or its Windows NT equivalent, "everything is a handle") says we should have a single type of identifier, the file descriptor (or handle), which can represent resources of any type for which the process can invoke kernel services – processes, threads, files, network sockets, etc.

Standardised POSIX does a poor job of living up to this ideology, since APIs for managing processes (kill, waitpid, fork, etc) take and return PIDs, not file descriptors. Since a process is not a file descriptor, I can't select()/poll() on it. Using PIDs is also prone to race conditions, whereas file descriptors are less prone to this problem (although not completely immune from it.)

The process descriptor functions such as pdfork provided by FreeBSD do a much better job of living up to "everything is a file descriptor" ideology than pure standardised POSIX does.

> I don't believe everything can be abstracted as a file considering that ioctl() breaks that abstraction. For example, what is it to "read from /proc/{pid for Chrome}"?

Why must every file support read() and write()? Some device files or other special files might only support ioctl(), and maybe also select() and poll(), and I see nothing in principle is wrong with that.

You're asking the question backwards. It isn't a question of which one the file is -- "/proc/{pid for Chrome}" isn't even a file, it's a directory.

The idea is rather that there should exist a file you can read the process' memory space from, which there is. The path to and specific format of that file is specified by the system documentation.

Ioctl is a deranged joke. The rest has held up surprisingly well, and I regularly find myself dropping down a few layers of abstraction to get away from higher level APIs.

I can generally get more done faster with a binary pipe and some sort of generator for serialization than with higher level communication APIs.

" 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)

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 how easily UNIX-based systems adopted Unicode. Say what you like about byte streams as a universal interface, but it sure was easy to switch from ASCII to UTF-8 when your system APIs weren't all built around the idea that everything would be encoded in a particular way.

I don't think systemd is unpopular or controversial because it's a great leap forward. That's just buying into the propaganda. It's unpopular and controversial because it presents itself as a great leap forward while not being one.

>but some new OS will - and eventually that OS will supersede Linux in the way many people believe Rust will replace C++.

C++ hasn't even replaced C. Why would Rust replace C++? When has a popular, stable, architecturally-important language ever been replaced?

The sort of people that think that Rust will replace C++ are the sort of people who thought Java would replace C++, who thought C++ would replace C, who thought Windows would replace Unix and who think that another system of opaque proprietary object-oriented APIs will replace POSIX. They're wrong, in every way.

> Java would replace C++, who thought C++ would replace C, who thought Windows would replace Unix

All of these have happened, for many use cases.

When I look at large amount of Enterprise software: Yes that happened.... I see Java everywhere. Also think of Android (alone the amount of software). Of course it's seldom exclusively Java in a corporation.

>"I don't think systemd is unpopular or controversial because it's a great leap forward. That's just buying into the propaganda. It's unpopular and controversial because it presents itself as a great leap forward while not being one."

How did you come to that conclusion? The bulk of the controversy I've seen about systemd has nothing to do with hype, the controversy I've seen has largely been focused on its invasiveness.

The controversy about systemd is that while it has some good ideas, it presents itself as being the only modern init system, when that isn't actually true. All the stupid things about it are defended on the basis that it has all these cool modern features, and its defenders continually compare it to sysvinit rather than other modern init systems (over which it has no advantages).

Its designers are also very anti-open-source, disliking any element of choice. They also seem to care only about desktops.

>"The controversy about systemd is that while it has some good ideas, it presents itself as being the only modern init system, when that isn't actually true."

Nope, as I said before the controversy is about its invasiveness. Read almost any article criticising systemd and you'll find people expressing something along the lines of 'what started as an init system has grown massively into something that resembles its own layer of the OS design'.

Bingo. Right now the way to do lid close detection on Linux is via systemd-logind(?!). More and more of what used to be individual projects under the freedesktop umbrella gets lumped into the system blob, and thus one is required to either use systemd wholesale or effectively recreate the Linux "desktop" from scratch.

> 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.

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.

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.

> 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.

If you read about the semantics of mounting a filesystem, particularly with regard to bind mounts, you realise that this is poorly abstracted. Mounting a filesystem and then binding it to a namespace are two separate actions. There is no API for the former.

POSIX added openat and related calls that operate relative to a specified directory descriptor, rather than the root of the mounted directory hierarchy.

It would also be possible to take this a step further and have calls which work with a filesystem descriptor and work on a filesystem independently of the mounted filesystem hierarchy. If it was possible to mount a filesystem without binding it (getting a filesystem descriptor), and then separately bind that filesystem into the mounted filesystem hierarchy using the descriptor. This would enable the direct use of a filesytem without it being bound, and that would allow for example private use of a filesystem by a process without it being globally visible, while might be useful for transient access to storage media without any potential for races (nothing else could open files or have a CWD in the filesystem).

I'll acknowledge that this is not strictly necessary, but it is an area where the underlying design is not well abstracted and is inflexible--sophisticated use of bind mounts is difficult, and the mount(8) dance to use them is terrible, all because it has to work around the lack of separation between mounting and binding.

Well, you could still add mounts – but while we currently can refer to devices by UUID, we can’t access their content by UUID, requiring ugly hacks such as sytemd’s automounting to /run/media/USERNAME/uuid/.

That's a great idea if you want to limit the users' choice of disk layout, similar to antiquated software in Windows that only installs on c: because the paths are hardcoded.

Oh, the paths would be unique for every single partition on this planet.

If your software is hardcoded to a single path, then it will install only on a single drive.

The idea is intended to allow specifying a path that will be globally unique.

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 install anything on them, but most of us didn't bother. They're glorified remote terminals anyway (the code is compiled and edited on a bunch of build servers). The servers do run Linux, but if we were to start from scratch now, we could probably pull off a decent build system under Windows as well. I'm using Emacs and relying on a bunch of Unix tools, either directly (grep) or indirectly (cscope through xcscope), but my colleagues who use Eclipse wouldn't feel much of a difference if the servers ran Windows.

I used to run Linux at my previous $workplace, but I definitely lost more time than my employer would be comfortable knowing disentangling things that regularly broke after updates (mostly Gnome- and systemd-related, really, but thanks to xdg's lovely practices, using a Linux system without something that can perform the black magic associated with sessions, seats, file associations and whatnot is very unpleasant).

My Windows laptop hasn't crashed once, the applications I need haven't broken once, and I haven't had to do the restart your computer to install this driver dance at all, I literally started it and hacked away. Plus, doing systems programming on a Windows system isn't all that bad, thanks to Dave Cutler and his colleagues being brilliant engineers.

I'm torn about using Windows at home, largely because I now have fifteen years' worth of BSD and Linux-managed files and countless convenience scripts to migrate, because I don't really trust Microsoft and because I think fighting my OS so that it will stop giving me ads and sending my stuff to Redmond is about as productive as wrestling with a modern Linux systems' innuvashon. But, much unlike 15 years ago, I probably could.

> my home office where I keep an Octane for nostalgia's sake, and the wife has her old SPARCstation.

I wish I had neighbours like you :-(

I used to run Linux at my previous $workplace, but I definitely lost more time than my employer would be comfortable knowing disentangling things that regularly broke after updates

Sounds like you were upgrading too often (almost sure, if you were already dealing with systemd). Windows releases a new version only every 3-4 years, there's no reason to update your Linux workstations any faster. At my work, we're still using a mix of Ubuntu 12.04 and 14.04, both of which are still supported, and we just add a couple of repositories for specific applications (particularly browsers).

I do use Debian Unstable on my personal laptop, but that's because I don't mind fixing it if I have to (which, mind, I haven't had to do in a long time). But for work? LTS all the way.

Sadly, the choice wasn't quite mine to make, so I had to follow the regular Ubuntu releases. What can I say, I looked at non-LTS releases and looked and looked but didn't see the beta marking and I thought they were actually production-ready...

I used to run Debian stable at home a while ago and did like the stability, but the security update situation is not exactly something I'm happy with.

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 support (Debian actually has a large enough community of skilled enough developers that they're faring well in this regard).

I don't want to minimize or belittle the work that they're doing, I only mention Debian because it's been my go-to distro for a very long time. They're also alleviating the problem in the most common use cases (e.g. they do update Chromium if you need a webkit browser). Codebases like WebKit's are simply too large, too complex and too quickly-shifting for a community-driven project to be able to backport fixes.

Even where the codebase is small enough, backporting is a nasty business. I've seen it done commercially, so with proper funding and proper teams and whatnot, and the success rate is not something that I'd consider encouraging. I've shot myself in the foot while doing it, too.

There are certain types of setups that lend themselves well to long-term support models. Server systems, up to a certain degree of complexity, embedded systems with a restricted set of packages -- maybe. A modern Linux desktop is not one of these systems IMO. A Linux desktop with four year-old packages is very likely to be very buggy in very nasty ways.

Install Firefox then.

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

Reply on news.ycombinator.com