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

231–240 of 246 posts

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

#231

Post by lrem »

pjmlp wrote: post #48
lrem wrote: post #39

Earlier quoted context omitted.

In my case a bunch of microservices. This included a rewrite of a legacy monolithic service written in Python. The C++ rewrite was not only more efficient and maintainable, but also ended up with a quite a few more features fitting in a smaller codebase. People do underestimate the value of rewrite from scratch, which when paired with a redesign trumps any language advantage. My wife's work was (she's full time paren…

Thanks for replying. I would say that you could probably have gotten the same benefits from rewriting the Python system into any AOT compiled language, like Go for example. We have been doing such rewrites to Java and .NET stacks, with some C++ only on "as little as possible" basis. Frontend apps are only done in C++, actually QML, if they need to be native cross platform. Otherwise they are either native to the OS (…

We have piloted go and decided to stay as far away as we can.

I personally believe that rewrite to Python, preferably with static typing, would be just as beneficial.

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

#232

Post by ZenoArrow »

milesrout wrote: post #221
ZenoArrow wrote: post #38

Earlier quoted context omitted.

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

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

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

#233

Post by AnonymousPlanet »

coldtea wrote: post #205
AnonymousPlanet wrote: post #115

Earlier quoted context omitted.

Most Windows programmers I know have never really used an environment that doesn't punish you for using the command line. So what's your point? That most people you know never realised that many of their daily tasks can be easily automated if they wouldn't think that endless, tedious clickfests are the norm, and that this somehow proves that the CLI is obsolete?

> Most Windows programmers I know have never really used an environment that doesn't punish you for using the command line. So what's your point? That they don't miss it either, and that the "endless, tedious clickfests" are a myth of people who don't know the other side.

It's not a myth if you watch it happening nearly every day.

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

#234

Post by rleigh »

milesrout wrote: post #219
kuschku wrote: post #96

Earlier quoted context omitted.

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

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

#235

Post by rleigh »

jstimpfle wrote: post #170
JoBrad wrote: post #161

Earlier quoted context omitted.

Our business uses them to restrict portions of our shared drive to certain groups. They're also used to restrict programmatic access to system folders, by Windows.

And it's not possible to use conventional Unix groups for that?

It's too coarse grained and has annoying and inflexible semantics regarding umask and the setgid bit. And you can only have a single group granted read or write access. What about granting an additional group read-only access? For situations where one group has responsibility for maintaining a dataset, but others need access to the data but are not permitted to modify it. You could use the other permissions, but not if you still need it private for everyone else.

umask: A user with a umask of 0220 can write to the shared directory but no other group members will be able to read setgid: A user creating a directory with the setgid bit dropped will end up losing the shared group ownership and use their default group instead, again making it impossible for other group members to read and write data

ACLs such as NFSv4 ACLs include inherited ACEs for files and directories, so that the permissions set on newly created files and directories are controlled. Since these extended permissions are outside the scope of the standard group, setgid and umask settings, you have a system which is transparent to all users--once they are set up, no end user needs to care about them.

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

#236

Post by kazinator »

Though the article begins by noting that POSIX was first developed over 25 years ago, that opener is actually misleading and sets the wrong tone for the article's content.

POSIX has been continuously developed since the first version was ratified.

The POSIX of 25 years ago didn't have threads or async I/O, for instance.

Then what the article criticizes is precisely the lack of use of mostly the newer stuff from POSIX, not of what was developed over 25 years ago.

Nowhere do I see the claim that functions like open, unlink or chdir are being replaced by something home-spun in Java or what have you.

So the argument boils down to this TL;DR: "new activity in POSIX over the past quarter century has been increasingly bloating the specification with committee-designed cruft that few applications use."

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

#237

Post by ethbro »

wolfgke wrote: post #184
qznc wrote: post #177

Earlier quoted context omitted.

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.

> 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. People also tend to reinvent stuff poorly that they consider as "bloated" or "unnecessarily complex for their use case". I just say C++ vs. Java (Java was indeed also marketed at the beginning that C++ is unnecessarily complex; besides t…

I'd sum it up in terms of "standards bodies / enterprise would be perfectly happy if everything were ossified in a form that encompassed all possible use cases, regardless of complexity."

Whereas reimplementation in a lighter weight protocol is usually the result of "devs don't want to deal with the above when it isn't needed for 80% of common use cases."

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

#238

Post by kuschku »

milesrout wrote: post #219
kuschku wrote: post #96

Earlier quoted context omitted.

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

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

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

#239

Post by digi_owl »

ZenoArrow wrote: post #232
milesrout wrote: post #221

Earlier quoted context omitted.

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…

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

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.

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

#240

Post by jstimpfle »

rleigh wrote: post #235
jstimpfle wrote: post #170

Earlier quoted context omitted.

And it's not possible to use conventional Unix groups for that?

It's too coarse grained and has annoying and inflexible semantics regarding umask and the setgid bit. And you can only have a single group granted read or write access. What about granting an additional group read-only access? For situations where one group has responsibility for maintaining a dataset, but others need access to the data but are not permitted to modify it. You could use the other permissions, but not…

Multiple editors are needed rarely at my workplace, and I haven't had one case which required multiple editors and multiple readers but no global read only access (in > 8 years).

If I had such a case, the ACL solution could easily be emulated by putting such a directory below another directory which is accessible only to readers and writers. (Yes, files would need mode 664 and the right group. Not saying it's not a kludge, but you can tell people to fix the modes, or write a script which does that. It's a minor pain given that this case seems to be really rare).

Contrast that to ACLs on Windows. What I do know is it has Apache-insane chains of "access" and "deny". I've messed up permissions more than once, as only user of a system. Allegedly confirming to view another user's files in the explorer silently causes destructive changes to all the files in there (that must be why it takes ages). The mechanism is more complicated, so harder to debug, and it's harder to understand where's the problem when things don't work as expected.

Anyways, when things get complicated as you described, doesn't that indicate that a proper VCS should be put in place? Multiple editors is crying for problems. It's easy enough to just put these files in a git repo and be done. The traditional hierarchical file system is convenient for simple (i.e. most) uses, but in the end it's just an object graph with a restriction to avoid loops to achieve some amount of "hierarchical". That object graph model isn't really made for treating subtrees of files uniformly. It doesn't have transactions. It's not good for anything much except helping to organizing a bunch of objects in a DAG.

How do inherited ACLs play with files that are linked from multiple directories?

Post reply on HN