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

221–230 of 246 posts

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

#221

Post by milesrout »

ZenoArrow wrote: post #38
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…

>"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 invasiven…

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.

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

#222

Post by milesrout »

pjmlp wrote: post #53
stock_toaster wrote: post #50

Earlier quoted context omitted.

Clang, LLVM, WebKit, Chrome/Blink?

Have you bothered to learn my comment? > C++ has become an infrastructure language on the enterprise. None of those examples, except for clang, are a full stack application written 100% in C++.

I can't think of any really big programmes written entirely in a single language. Every single programme out there is dependent on libraries written in C, kernels written in C, libraries written in C++, etc. Emacs is full of Lisp.

Maybe Chrome? Chrome is written entirely in C++.

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

#223

Post by milesrout »

pjmlp wrote: post #30
ndesaulniers wrote: post #27

Earlier quoted context omitted.

"There are literally dozens of us!" FWIW, I think C++ is killing it on mobile and many other platforms and disagree with the post you responded to. Just pointing out that 2 samples isn't statistically significant.

Where are the C++ killer applications on iOS and Android, besides game engines, written 100% in C++? Where is C++ on the iOS and Android documentation versus Objective-C, Swift and Java?

Why '100% in C++'?

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

#224

Post by DaiPlusPlus »

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…

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

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

#225

Post by Animats »

jstimpfle wrote: post #211
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…

It's complicated.

Posix "rename()" is now supposed to be atomic, but it isn't on NFS.[1] Windows has version problems. XP couldn't do an atomic rename. Vista could for NTFS file systems, using the NTFS transactional rename function. That's now deprecated in favor of ReplaceFile, which came in with Windows 7.[2] That's supposed to be atomic even if a copy across file systems is required. Not sure about Windows file shares.

In MacOS X, "rename" was not atomic before 2011. It's now believed to be.[3]

Even with "rename", you have to find the directory in which the old file lives, and create the new file there (as something like a ".part" file) before renaming. This requires resolving symbolic links and such. So it's non-trivial to get this right. My point is that this should Just Work as the default.

[1] http://stackoverflow.com/questions/41362016/rename-atomicity... [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [3] http://www.weirdnet.nl/apple/rename.html

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

#226

Post by pjmlp »

milesrout wrote: post #214
pjmlp wrote: post #12

Earlier quoted context omitted.

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

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

So which one it is?

As gcc, clang, icc, VC++, C++ Builder are all written in C++.

Are you using tcc for production work?

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

Sure, even I do it.

But we only do it, because during almost two decades C and C++ became the only options available for compiling code AOT to native code, with support for value types.

And I would never ever use C willingly, so C++ it is.

But the wind is changing and the choice for programming languages with AOT compilation to native code and support for value types, is widening.

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

No, it reduces the usefulness of the language, the bigger the upper layers are, eventually the underlying layer can be migrated to something else.

For example, Oracle is planning to replace Hotspot (C++) with Graal (Java) in the long term. Likewise Microsoft has plans to replace parts of CLR with C# now that there is .NET Native.

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

#227

Post by AnthonyMouse »

DaiPlusPlus wrote: post #224
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…

> 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? Rea…

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.

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

#228

Post by pjmlp »

milesrout wrote: post #222
pjmlp wrote: post #53

Earlier quoted context omitted.

Have you bothered to learn my comment? > C++ has become an infrastructure language on the enterprise. None of those examples, except for clang, are a full stack application written 100% in C++.

I can't think of any really big programmes written entirely in a single language. Every single programme out there is dependent on libraries written in C, kernels written in C, libraries written in C++, etc. Emacs is full of Lisp. Maybe Chrome? Chrome is written entirely in C++.

> Every single programme out there is dependent on libraries written in C, kernels written in C,

There are no mainframe OS with kernels written in C.

Linking to C is an option of the program author, sometimes there is an option, sometimes the authors doesn't do any better.

When I wrote my compiler project for the university, I made the point the language runtime should have zero lines of C.

> Maybe Chrome? Chrome is written entirely in C++.

The purpose of Chrome is to allow users to run applications written in HTML, CSS, JavaScript.

Those users would be able to see exactly the same web pages regardless of the programming language used to write the browser.

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

#229

Post by skissane »

DaiPlusPlus wrote: post #224
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…

> 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? Rea…

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

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

#230

Post by chetanahuja »

> The original goal of the POSIX standard was application source code portability. However, modern applications are no longer being written to standardized POSIX interfaces.

This is a weird claim to make. The three OS's that they're talking about (desktop Linux, iOS and Android) all have plenty of popular applications written directly at the Posix API level.

Heck, when we were architecting our mobile-network-enabler stack that had client side and server side components (all in user-space), it was a no-brainer for us to just pick the posix API as our base and we designed and wrote a lot of native level code that "just worked" on all three platforms.

Even if there's any sort of framework layer between the application and the system, the Posix semantics are so deeply embedded in the culture of programming today that frameworks can say things like "this API opens a new file for write" without having to explain what all that means. The very language we use to architect a solution has deep, unspoken assumptions built-in, and it's more or less based on what Posix semantics allow.

Post reply on HN