Posix Has Become Outdated (2016) [pdf] • Hacker News Board

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

#201

Post by nickpsecurity » Sat, Feb 11, 2017, 11:13 PM UTC

geezerjay wrote: post #146

nickpsecurity wrote: post #139

Earlier quoted context omitted.

"those platforms were designed with the express purpose" They were designed with the purpose of giving users a way to get things done that was profitable to the company. The first part along with lock-in techniques are why most of the desktop market is Windows with a large chunk of the server market. That means the kind of portability that matters to people wanting to maximize benefit to users or profits to the compa…

> They were designed with the purpose of giving users No, they actually weren't. The "users" don't have any say whether Windows complies with any standard, or even if Microsoft breaks all of them to try to force the world to submit to their "vendor lock-in" business strategy. Trying to pass off the consequences of vendor lock-in policies as technical arguments is somewhere between absurd and disingenuous.

You said the only purpose of what Windows did was locking in people. I said it was to provide software that let people accomplish what they want while making profit sustained by lockin tricks. Are you saying Microsoft never intended people to use Windows API or software to accomplish their personal goals? That there is zero benefit to users of Windows in consumer or business space?

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

#202

Post by nickpsecurity » Sat, Feb 11, 2017, 11:15 PM UTC

AsyncAwait wrote: post #183

nickpsecurity wrote: post #123

Earlier quoted context omitted.

I would not if the goal of a standard is uptake by OS and application developers. Wide usage of a product = popularity. It didn't achieve the popularity it sought. This is independent of what businesses like Microsoft were doing. Microsoft's strategy was to create a permanent dependence on them for long-term profitability. They had too many tactics for that to cover here. Once open standards proliferated, they subver…

> It didn't achieve the popularity it sought By what metric? POSIX was never trying to be the universal interface for all kinds of applications, just some sane common interface for UNIX vendors, all of which do implement POSIX to a large extent these days. You could perhaps make the argument that by the time POSIX saw enough adoption, software development evolved and that nowdays there are lots of interfaces that are…

That's close to my argument. There's kind of two conversations going on in these threads: UNIX portability and general portability. POSIX is fine on former but worse on latter since it wasnt designed for it (among other things).

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

#203

Post by nickpsecurity » Sat, Feb 11, 2017, 11:21 PM UTC

felixgallo wrote: post #134

nickpsecurity wrote: post #112

Earlier quoted context omitted.

"You're confusing popularity with being outdated." POSIX was supposed to be popular to the point of default way that apps were written. It failed. Whereas there's quite a bit of portable apps on (insert framework here). They succeeded with many running on non-UNIX OS's, too. You'll need those or similar things in your code instead of POSIX for truly, portable apps. That's his point.

> POSIX was supposed to be popular to the point of default way that apps were written. It failed. So POSIX was a long series of attempts to codify baseline Unix practice that arose because in the '87 time period there were tens of small, warring, incompatible Unix distributions ( cf. http://www.ugu.com/sui/ugu/show?ugu.flavors ), and systems software vendors could not write software that worked across all of these pl…

As I said go Async, I think there's two conversations going on in these threads: POSIX for UNIX portability; general portability. POSIX succeeded on prior but not latter as it wasnt designed for it. Today, we have portability frameworks that can do more than POSIX on more OS's. They definitely win on general portability with them worth consideration for UNIX portability. That's my position.

Far as early days, you might be able to help me out on a point I have few sources on. One history of Xenix posted here claimed its influence and design choices had strong influence on adoption of features that latter led to POSIX. Source was biased so hard to assess. What's your take on Xenix's influence on adoption of standard or POSIX-like API's?

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

#204

Post by coldtea » Sat, Feb 11, 2017, 11:24 PM UTC

bluejekyll wrote: post #78

coldtea wrote: post #73

Earlier quoted context omitted.

> At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI And it has, except for backend programmers. Most Windows programmers stay all day in Visual Studio and the like, for example. But as far as end users as concerned, that is the 99% of computer users, the CLI might as well not exist.

Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you. The CLI offers an infinitely combinable and customizable development experience, where huge ammounts of innovation have been occuring. You can see this in modern web development toolchains and new buil…

>Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you.

No, I'm speaking from the perspective of someone that has worked in the old days with Sun OS (pre-Solaris) workstations and HP-UX machines, has used (for years) actual VT102 terminals, started using Linux distros around '97 and has been using the CLI in various forms since the mid-eighties or so.

There's nothing limited about the GUI (in theory, and, for most things that matter, in practice too). For example a visual flow language (think Automator in OS X or Quartz Composer, etc) can achieve all the "configurable pipeline" stuff people like in the CLI in a more controlled and formal way.

I also dislike the "dynamic typing" (everything is text/bytes) in the CLI, and would prefer something like PowerShell to have been the norm (with the accompanying toolset). Also note that there's nothing about the GUI that prevents someone from typing some commands too -- and in fact that's part of how lots of GUIs work.

Also, I wouldn't point to "modern web development toolchains" as something to advertise CLIs -- what would that be, Gulp, Grunt, Webpack and the like? All crufty solutions to inadequacies in steering the underlying language properly.

Even in theory, CLIs are not inherently more powerful, it's the other way around (they lack a dimension that GUIs offer (graphics) -- GUIs on the other hand don't lack any dimension -- they can incorporate text commands and text fields and pipelines just fine.

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

#205

Post by coldtea » Sat, Feb 11, 2017, 11:24 PM UTC

AnonymousPlanet wrote: post #115

coldtea wrote: post #73

Earlier quoted context omitted.

> At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI And it has, except for backend programmers. Most Windows programmers stay all day in Visual Studio and the like, for example. But as far as end users as concerned, that is the 99% of computer users, the CLI might as well not exist.

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.

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

#206

Post by coldtea » Sat, Feb 11, 2017, 11:30 PM UTC

JdeBP wrote: post #88

coldtea wrote: post #73

Earlier quoted context omitted.

> At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI And it has, except for backend programmers. Most Windows programmers stay all day in Visual Studio and the like, for example. But as far as end users as concerned, that is the 99% of computer users, the CLI might as well not exist.

I doubt that there is anyone at all in this entire discussion that can state with authority what "most Windows programmers" do. We can point to what we and the people we have met and talked to about this do, but to go from that comapratively scant few handsful of people to a statement the size of "most windows programmers" is an overgeneralization by several orders of magnitude.

I doubt that discussion and insight can happen without generalising. I also doubt that we need to cover 100% or even 99.999% of Windows programmers to be able to speak about what "most Windows programmers do".

Anybody who has experience from 2-5 different Windows shops and been to a few relevant conferences can make a quite accurate assessment of what "most Windows programmers" do.

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

#207

Post by coldtea » Sat, Feb 11, 2017, 11:32 PM UTC

yarou wrote: post #159

mwfunk wrote: post #157

Earlier quoted context omitted.

I don't know what you're referring to with that distinction. AFAICT they weren't testing for POSIX compliance but rather where the POSIX layer was being used in practice, which statistically was by system-level frameworks rather than the applications themselves on the OSes they tested. The notable change between now and 25 years ago is that the POSIX layer tends to be used at the lower levels of system frameworks, wh…

I'm a little confused by the distinction. For example, if I use a framework that abstracts away pthreads from me, but still uses pthreads in its implementation of threading, is the application I write still POSIX-compliant?

>is the application I write still POSIX-compliant?

Obviously not, since you can't go and compile it on another POSIX system -- you are "abstraction compliant" (or rather "abstraction dependent" now.

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

#208

Post by notalaser » Sat, Feb 11, 2017, 11:36 PM UTC

icebraining wrote: post #188

notalaser wrote: post #168

Earlier quoted context omitted.

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.

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

#209

Post by felixgallo » Sun, Feb 12, 2017, 2:33 AM UTC

nickpsecurity wrote: post #203

felixgallo wrote: post #134

Earlier quoted context omitted.

> POSIX was supposed to be popular to the point of default way that apps were written. It failed. So POSIX was a long series of attempts to codify baseline Unix practice that arose because in the '87 time period there were tens of small, warring, incompatible Unix distributions ( cf. http://www.ugu.com/sui/ugu/show?ugu.flavors ), and systems software vendors could not write software that worked across all of these pl…

As I said go Async, I think there's two conversations going on in these threads: POSIX for UNIX portability; general portability. POSIX succeeded on prior but not latter as it wasnt designed for it. Today, we have portability frameworks that can do more than POSIX on more OS's. They definitely win on general portability with them worth consideration for UNIX portability. That's my position. Far as early days, you mig…

I bet your source was right. I don't have inside knowledge, but as one of the first Unixes to try to make a serious business out of it, and as an arguable progenitor of the SysV approach, it wouldn't surprise me.

That said, POSIX was never designed for general portability. Just as a seal of unifying approval and sanity for existing practice; far more descriptive than prescriptive.

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

#210

Post by jstimpfle » Sun, Feb 12, 2017, 3:11 AM UTC

skissane wrote: post #185

jstimpfle wrote: post #149

Earlier quoted context omitted.

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

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