181–190 of 246 posts
Earlier quoted context omitted.
You're confusing things. You don't break a standard when you write a function or even a whole library.
So Microsoft, Google and Apple do it, it is bad. Linux does it, it is me that doesn't understand, I see.
What I see as biger problem is that current Single UNIX Specification is that it essentially has nothing to do with UNIX. On the list of certified conforming systems, there is Solaris (which does not implement all the optional modules one would expect from something that _IS_ derived from SysV), z/OS and bunch of embedded RTOSes noone ever heard about. And if you look on what is required and how underspecified some things are, you can make "Certified UNIX" out of MS-DOS by rewriting the userspace tools and writing libc with "POSIX-ly correct" syscall names.
Earlier quoted context omitted.
> POSIX was supposed to be popular to the point If you read up on why companies such as Microsoft make it their point to break and avoid standards, you would understand why your comments regarding "popularity" are moot. Business strategies don't make or break technical merits.
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…
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 not part of POSIX/not portable, but that's a slightly different issue.
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…
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.
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 the famous "write once, runs everywhere"), XML vs. JSON, CORBA vs. SOAP (no, please don't start a flame war which of these is the better one ;-) ).
Earlier quoted context omitted.
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 oper…
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 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.
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…
I would wish that the whole (disk) I/O mess would be cleaned up. It's just laughable how broken that is across operating systems. And it's supposed to be the back-bone of most operating systems as well. Also, memory management. Only in very recent years proprietary APIs surfaced in Linux and friends that allow to leverage some of a modern MMUs capabilities (which is good). Meanwhile we still have stupid MM semantics…
Earlier quoted context omitted.
What? Those are not even POSIX environments (well, their primary and intended interface interface is not POSIX, but they maybe eventually inherit some of it because of their underlying environment or Unix influences, but that's irrelevant). Also, I never used OS X but AFAIK many Unix software runs on it easily, so it must be mostly compliant if not completely (IIRC it's a certified Unix).
That's exactly the point of the report: Hardly anybody uses POSIX. Many people use frameworks on top of it though. If POSIX would go away many won't notice.
User's probably won't notice, but they tend not to care about standards anyway.
Earlier quoted context omitted.
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…
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.
As for Debian security updates, what do you mean?
Earlier quoted context omitted.
Isn't a nice common interface that those frameworks and higher-level language libraries and interpreters can be written for a nice thing? It's like a nice road network, you sure want to be in your car not on the road, but it's better if most of it is good for the common tire, you don't want to change your tires at every turn.
Yes, but the need for those shows that POSIX failed.
Earlier quoted context omitted.
Just like CPU opcodes have failed... POSIX is a low level interface, that of the OS and the C library. It's another level of abstraction, necessary for the ones that are building other levels on top of it.
CPU opcodes have a different purpose. POSIX aims to be an API for general purpose application development.
I'd say if you can run bash and gcc on Linux, OSX and BSD, it mostly succeeded.