12 ms·
Is POSIX really outdated?
- jchw 3y agoWindows is not POSIX compliant anymore. Claiming that it is and linking to an article about WSL is just confusing, as most Linux distributions are not POSIX compliant either. I assume this is based on Windows NT's historical status with SfU and UNIX compliance. But Windows doesn't need POSIX compliance today. I'm pretty sure that only ever happened because the U.S. government was pushing for POSIX in an era where UNIX operating systems were far more relevant.
- AlotOfReading 3y agoWSL v1 was just a POSIX wrapper that translated system calls into their NT equivalents. It ended up being scrapped for a Hyper-V based VM approach for WSL2, but it's a pretty good argument as far as practical POSIX compatibility.
- jchw 3y agoFrom my understanding: WSL1 emulated Linux syscalls and ran Linux-compatible ELF binaries on picoprocesses. This isn't really sufficient to call it a POSIX layer. I am not aware (and can not find evidence) of Microsoft attempting to get it certified as compliant, and in order to do so it would need a compliant root image (e.g. not Ubuntu.) Services for UNIX was a different story, but that's not what either version of WSL is.
- alexvitkov 3y agoPOSIX also specifies the coreutils, so implementing a few syscalls definitely doesn't cut it.
- nullindividual 3y ago> Microsoft attempting to get it certified as compliant Who would bother getting POSIX, UNIX, or FIPS 140-2 certified in today's world? We've moved on from when any of those things were important. It costs time/money and what customers would Microsoft attract? The US Gov't no longer sees those as important requirements.
- AlotOfReading 3y agoCertification isn't required to be compliant, and I'd argue that very few people actually care or refer to it in the real world. It meets the same bar that all of the other "mostly compliant" OSes listed on the POSIX wiki page meet: you can write code against a POSIX stdlib and it'll work without involving a VM as long as you stick to some subset of interfaces and behaviors. WSL1's compliance was actually larger than most of the OSes on that list. The last time I asked Mentor Graphics which parts of POSIX they supported on Nucleus they said "tell us what APIs your application needs and we'll implement them" (anything beyond PSE51 was largely unimplemented). Zephyr is nice enough to actually document their limitations, but the support is far from comprehensive either: https://docs.zephyrproject.org/latest/services/portability/posix.html https://docs.zephyrproject.org/latest/services/portability/p...
- jchw 3y agoWSL1 doesn't even handle userspace. It just ships Ubuntu. And certification or no certification, Ubuntu is very trivially not POSIX-compliant. Perhaps you can make it POSIX compliant, but there is no obvious way to do this; you would have to go point-by-point. I don't think that is any better than OSes that conform to some specific subset.
- Findecanor 3y agoWindows NT did have a POSIX subsystem to satisfy US government requirements, in addition to the win32 subsystem (and one more?). It had no relation to Linux whatsoever. There was also a POSIX file system API available to win32 programs, but I'm not sure how that was related.
- jonhohle 3y agoIt absolutely was related to government requirements. FIPS 151-2 required that certain government purchases be POSIX compliant.
- jchw 3y agoThe POSIX namespace in NTFS is important for implementing things like SfU and WSL1. That's how they get proper POSIX semantics for filenames and links. Win32 programs can technically use it too, but it's an NTFS-specific feature rather than just a Win32 one as I understand it. (It can also be used on Linux when using NTFS drivers. AFAIK, it's usually the default option for new files in ntfs3g.)
- trws 3y agoMy personal favorite irony is that by default “write” on windows is more posix compliant than any Linux install using ext4. If you need write atomicity, as posix guarantees, avoid ext4.
- Sprocklem 3y agoPOSIX only guarantees write atomicity for pipes and FIFOs, not for regular files.
- zevv 3y agoSilly article, comparing POSIX to the Amazon S3 API. POSIX is so much more than storage.
- klmr 3y agoIt’s pretty clear that the article is only comparing object storage with POSIX in the context of filesystems, not with all of POSIX.
- tgv 3y agoWell, Amazon is not very interested in making its APIs compatible with other cloud providers. But the whole thing is unrelated to POSIX itself. It makes just as much sense when you replace POSIX with e.g. HDMI cables.
- adolph 3y agoHard to say what Amazon is or isn’t interested in. The success of S3 is such that significant downstream client libraries are used by people who pay for S3, enough to provide a measure of api stability, simply out of customer inertia.
- PaulDavisThe1st 3y agoSigh. Another article written, it seems, by someone who thinks that all/most software development is on the web. "Storage systems" in the cloud ... it might make you feel good to pretend that this is really just a variant of storage systems on your local NVMe unit, and that therefore the APIs involved really ought to converge. But this is an illusion likely caused by insufficient native development experierence. The author needs to ask themselves: in this cloud technology stack, is there POSIX involved somewhere lower down, where I can't access it? The answer is, of course, "yes". The sort of cloud storage systems described all run on top of POSIX APIs. They provide convenience (cost efficiency is more debatable) compared to the POSIX alternative, but that's because they exist at an entirely different conceptual layer (hence the presence of POSIX anyway, just buried). There's about as much reason to expect a single API to access the filesystem attached to the PCI bus and an unstructured storage system as there is to have a single API to create a PDF of a document AND deliver it to the printer. Which is to say: the higher level abstraction will use the lower level anyway, but it exists for a reason, and isn't appropriate for everything.
- VyseofArcadia 3y agoThank you for phrasing this so much more politely than I would have. I found web development itself to be a pretty frustrating experience, and I am also starting to grow frustrated with web developers. Especially the clueless variety which is nicely on display here. Makes a guy reach for some impolite words. These days I'm favoring ones that end in "-wad".
- jeroenhd 3y ago"POSIX file system for the web" is kind of the whole deal for the company that wrote this. They make something to mount object storage as a filesystem. This isn't a random programmer philosophising about POSIX, it's an ad for a product.
- cuno 3y agoHi, author here. Yes, we're a startup. With cunoFS, we've made it possible to leverage the lower cost and higher throughput of object storage like S3, and make it work transparently with functions like e.g. mmap(), chmod(), execve(), renameat2().
- deleted 3y ago[deleted]
- squarefoot 3y agoTl;Dr, admittedly, but skimmed quickly and did a search for "socket", "timer" and "thread", and the text contains no mention of any. POSIX is a lot more than cloud storage. Some may not like it, but I've been thankful a couple decades ago when I was writing a network routine on Linux/AIX following POSIX specs and it then compiled and worked beautifully on Win NT after changing just two lines.
- justsomehnguy 3y agoRelated: > Why don't more companies adopt ChromeOS as an option. (self.sysadmin) > submitted 5 days ago by psuedononymoose > Why spend your time dealing with AD, malware, ransomware, patches etc? I run an org with over 800 adults on ChromeOS and I find myself on an island. I however see a lot of questions and concerns on here that would completely be alleviated by using ChromeOS. What is the hold up? Most everything is a web app now. Honestly trying to understand besides management won't do it https://old.reddit.com/r/sysadmin/comments/177def3/why_dont_more_companies_adopt_chromeos_as_an/ https://old.reddit.com/r/sysadmin/comments/177def3/why_dont_... Disclaimer: emphasis is mine
- im3w1l 3y agoThis seems like the future. Shit that just works with barely any maintanence or config. As the comments show, we aren't quite there yet.
- jonhohle 3y agoSchools have gone this route, specifically for students, and it has pluses and minuses. Offline mode is a thing, but does not work consistently. There is no conceptual distinction regarding why some apps work offline and some don’t. Certain things that nearly every computer can do, like say print a file, become impossible. Every app uses its own unique set of widgets and UI concepts. No two apps, even from the same company work consistently or have the same key bindings and capabilities (Gsuite is mostly consistent, but not with Gmail, and other Google apps, move off of Google and it gets much worse very quickly). On the other hand, my kids can log in on any device and have their environment (as spartan as that might be) the way they left it. Until they get to older grades they don’t have to learn concepts like folders and files (for better or worse). For businesses this seems awesome. Call center workers, for example, that get kiosk mode systems that run the CRM, KB, and nothing else seems great, basically like a more flexible POS system, but for every role.
- Affric 3y agoYep. Chromebooks for the call centre will come… may god have mercy on our souls.
- butterisgood 3y agoNot for the reasons in the article, but ... I'm not sure POSIX matters so much anymore. The BSDs, Mac OS included, have ways to do things that are not in POSIX, and they're usually the best way to get that specific thing done. Linux is the same, but doesn't follow the BSDs lead on those APIS (epoll, inotify, kqueue/kevent etc). io_uring is awesome, but there's no analog for FreeBSD etc. Fuchsia, Windows and other platforms offer Linux compatibility, not as focused on specifically POSIX. So, is Linux the new POSIX? I don't know... ... but I think about this monthly at least.
- twistercool 3y agoTo be fair, POSIX gets updated and eventually follows the implementations. Just like the newer C standards usually just officially adopt things that gcc and sometimes clang have already been doing for decades.
- pjmlp 3y agoThere are other C compilers which WG14 also takes into account. https://en.cppreference.com/w/c/23 https://en.cppreference.com/w/c/23 That list isn't exhaustive.
- baudaux 3y agoPOSIX and web are not incompatible thanks to emscripten and the use of musl. I am creating a UNIX-like operating system running in a web browser https://www.exaequos.com https://www.exaequos.com
- pjmlp 3y agoSince POSIX requires fork, threads and signal handling, looking forward to it.
- justsomehnguy 3y agoOkay, I tried to read TFA... > Object storage is not a filesystem, and was developed with different use cases in mind. Unlike the filesystems POSIX is built to interact with, object storage is unstructured, making it readily scalable, including by pooling storage across different locations My porn collection[0] is an unstructured object storage, making it scalable because it includes pooled storage across different locations. [0] Jokes on you, I turned vanilla and offloaded all my requirements to the famous Orange-Black, unstructured, pooled, scalable site. But I have other things what still fit this definition. > Object storage is usually accessed using RESTful HTTP APIs and is an example of how files can be interacted with in the absence of POSIX. Somebody, tell the author about SMB and what network access, storage and file storage are all different things. > At cunoFS, we’ve worked with a number of developers on diverse object-storage-backed solutions for high performance and big data purposes [Even if didn't notice where this article is hosted] Ah, another pitch from a company deeply interested in you using theirs product?
- flohofwoe 3y agoWeird blog post. Yes POSIX mostly sucks and is outdated, but what has this to do with storage systems? POSIX is not some magic portability pixie dust which makes your code automatically work across platforms, especially when Windows is one of the target platforms. It's almost always a better idea (and not much work) to write your own thin specialized glue layer between your application code and operating system APIs.
- klmr 3y ago> but what has this to do with storage systems? The article is about POSIX compliance (or lack thereof) of storage systems. And the article does not imply that “POSIX … sucks”. On the contrary: the answer to the rhetoric question in the title is obviously “no”. > It's almost always a better idea … to write your own thin specialized glue layer between your application code and operating system APIs. Oh, definitely. But writing good abstractions that work equally well with POSIX-compliant filesystems and with object storage is basically impossible without massive trade-offs. That’s the entire point of the product that’s advertised here: it provides a link between object storage and POSIX-compliant file access that manages these trade-offs extremely well, and it allows users to use their existing glue code for POSIX without having to deal with object storage altogether. (COI disclaimer: I used to work on this product; but I no longer have any stakes in it, financial or otherwise.)
- cuno 3y agoHi, author here. The problem is that it's actually really hard to write you own specialized glue layer,and so most developers who do that have poor implementations with low performance and/or incompatibilities with non-AWS solutions. In the context of object storage, we've found lots of applications have tried to add S3 support, and while they work with AWS S3 and have basic functionality, they fail on a lot of other S3-compatible solutions. So they end up tied to AWS, and you can't use them on Microsoft Azure Storage, or often on Google Cloud Storage (despite its S3 gateway), or others. For instance, a key workhorse of the genomics field is `samtools`, which works with AWS S3 in some ways, but not others (like Amazon Resource Names[1]). Our approach works across vendors transparently, and on S3, is much faster compared to such native implementations. [1]: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-a...
- throwaway71271 3y agoThere are very few things as hard as persisting data (especially if you want certain order of operations to be respected).
- shortrounddev2 3y agoUnpopular opinion but I like Microsoft's API design of having types for most things and using structs and C++ classes more than the Unix/Posix design of most things being an integer handle (yes I know Win32 has HANDLE objects). For me this translates to DirectX's everything-gets-a-type being preferable to OpenGL's everything-returns-GLuint
- alexvitkov 3y agoI don't believe there's a single person on this planet that likes using ioctls on a int fd. I'd say Vulkan is the best API that follows the Microsoft API design - the initialization process is always "fill out this struct and call vkCreateWhatever", and the struct fields are actually documented well, not "HANDLE handle - this is the handle".
- jonhohle 3y agoWhenever I run into a situation where ioctl is necessary it makes me think the authors either hadn’t thought their design through enough, or couldn’t convince enough people that a sys call was justified. What an abhorant interface.
- alexvitkov 3y agoNon-blocking IO? Surely that doesn't have enough value to justify a decent API, just throw in an ioctl, people will figure it out.
- pjmlp 3y agoWhich for anyone diving in VMS manuals, it is quite similar in concepts. As for COM all over the place, specially after Vista, the idea is great, the execution from multiple C++ libraries, and poor VS tooling, since the OLE 1.0 days not so much. VB 6 and .NET are the best developer experience for dealing with COM, but WinDev rather impose on us dealing with C++ and clunky tooling.
- shortrounddev2 3y ago
- turminal 3y agoPOSIX has many, many problems, but this post misses all of them somehow and then proceeds to talk about object storage? Weird article.
- DannyBee 3y agoI sort of get it, but are there really people willing to run something that works this way in production? It does LD_PRELOAD based dynamic syscall interception - which is dangerous enough, but also doesn't work for a lot of cases. So they have a JIT ELF translator that will redirect calls for static binaries. While all this is cool technically, this is not a recipe for stability of your binaries.
- klmr 3y ago> this is not a recipe for stability of your binaries I see the point in theory, but it works incredibly well in practice. The specific technology has been used in production by major companies for years. It even carefully works around buggy software that makes incorrect assumptions for undefined behaviour. (COI disclaimer: I used to work on this product; but I no longer have any stakes in it, financial or otherwise. I do still use the product, because it’s vastly superior to the alternatives.)
- DannyBee 3y agoCertainly it can be made to work, I spent years on things like it, etc. I actually did similar in production at Google, which i suspect is one of the companies you are referring to. I'm even overall a fan of using JITted code in production for normally "static" languages. But - i've never seen this sort of thing break through the significant resistance/feeling of taboo that often exists around doing that kind of thing in production, long term. You will find companies here and there willing, sure. But writ large? It eventually goes away, even at companies willing to try it. I do hope they get past all that, i just ... am skeptical.
- cuno 3y agoHi, author here. Yes we have many large companies (Fortune Global 500) down to small organisations using our software with this kind of interception (see for example https://cuno.io/about-us/ https://cuno.io/about-us/). It took us a decent sized team a lot of years to get right, because it is so very hard a problem to crack. But we think it is worth it. And for those who don't want to use such interception, we do offer a FUSE layer as well that still offers much higher performance than alternatives.
- trollerator23 3y agoNo. [1] -- [1] https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
- HippoBaro 3y agoI can't entirely agree with this, but I like how the authors think about the issue (S3 being a de-facto standard without anything formal to back it up). POSIX is outdated and problematic. It's outdated because it was conceived when hardware was vastly different than today. Storage used to be orders of magnitude slower than compute. Today, it's the opposite. POSIX APIs make squeezing all the juice out of the underlying hardware impossible. A standard duplex 100Gbps network link will carry ~300M small IP frames per second. You'll be lucky if you can do more than a few 10k/s using POSIX APIs. That's a massive bottleneck. And it's not something that can be fixed with clever implementations. None of the POSIX APIs are async. So, to drive concurrency, programmers have to resort to threads that don't scale. That's a fundamental issue that no hardware improvement and/or software trickery will ever fix. Today's reality is that software is seldom written against POSIX but against Linux, which offers many more APIs. Linux is, likewise, not formally standardized. It dodges the problem of S3 because it's open-source and ubiquitous. But that's not a good solution: it stifles innovation. For that reason, there hasn't been any new (production-ready, serious) kernel in decades. We are at a deadlock, and POSIX is part of the problem.
- gustavus 3y agoThat's funny. I was listening to this video (https://www.youtube.com/watch?v=bzkRVzciAZg&t=1s https://www.youtube.com/watch?v=bzkRVzciAZg&t=1s) Node.js is badass rockstar tech just barely, and one of the exact quotes is "Threads don't scale". I assumed it was just a joke, but here was see Poe's law in full effect.
- HippoBaro 3y agoI think there are a few misunderstandings there (the video is funny, btw). The kind of async IO I'm referring to exists one layer below whatever Apache and node are using. Both are event-driven, actually. They both use some flavor of epoll (see https://httpd.apache.org/docs/2.4/mod/event.html https://httpd.apache.org/docs/2.4/mod/event.html). Historically, buffered IO was sufficient to circumvent slow threads. Simply because buffered IO operations usually don't block (you merely memcpy, and the kernel flushes asynchronously in the background). That can only take you so far, however, and it's apparent today that hardware can go much further and that the gap is widening. It's a valid point, though, to question whether that additional performance is even needed. John Ousterhout (https://www.youtube.com/watch?v=o2HBHckrdQc https://www.youtube.com/watch?v=o2HBHckrdQc) is currently working on a new network protocol to alleviate some of the problems TCP creates in software wrt performance, and he also questions whether there is even a need for very fast networking for real-world applications. IMO, the mere existence of stuff like DPDK is proof enough. Many folks use it and would rather use the kernel if it could provide comparable performance.
- gumby 3y ago> “Over the years, we’ve done lots of nice “extended functionality” stuff. Nobody ever uses them. The only thing that gets used is the standard stuff that everybody else does too.” — Linus Torvalds Linus’s quote in the article isn’t really true. It’s true in that small, incremental changes are often ignored in the interest of portability (I’d rather my app worked on both macos and linux so will use generic facilities when at all possible; the system-specific ones may be easier and better but I’ll just have to write something different for the other system. But when the change is a big one, the calculus is different. Consider io_uring: it’s a big win so worth writing special code to use. But the trend in these cases is to write a higher level library , or modify an existing library to work with io_uring. Not a lot of people use system calls directly, except perhaps `stat` and a few other filesystem calls like that. Another case is the procfs, because you can use it directly from the shell.
- siliconc0w 3y agoKinda Content marketing for another POSIX on S3 product, though I like the API interception vs FUSE approach. I'm curious how you get performance with object store latency without sacrifices unless you're intermediating. Other solutions typically run at least a fast metadata service.
- cuno 3y agoHi, author here. Yes, we've had to do a lot of things to deal with object storage latency. Since cunoFS is running inside a given process itself, it has greater visibility into what actions it can take and is likely to take. This means we can make huge improvements in our prediction logic, so that we can prefetch within and across files much better, thus hiding latencies. For POSIX metadata, we have a caching mechanism which is shared between processes, and we've invented a better way to encode this metadata so that it is retrieved alongside the LIST operation.
- duped 3y agoThe problem with POSIX file APIs are the semantics in the presence of multiple concurrent writers. Object storage (kind of) gets around this because you can't really have multiple concurrent writers to the same object. Another classic example is that POSIX does not specify what happens when one program opens a directory stream and starts calling readdir/seekdir and then another program adds entries to the directory. Does the first program get entries in its stream for those members? Who's to say, that's up to the file system implementer. I don't actually know if S3 guarantees that if a new stream is created with ListBuckets/ListObjects that the stream will return any new bucket/object created before the stream is closed by the client. Are those semantics defined, or is it left up to the implementer too?
- mjb 3y ago> The problem with POSIX file APIs are the semantics in the presence of multiple concurrent writers. That sure is a problem with the file APIs, but far from the only one. Other issues include weird asynchrony, weird scatter/gather, lack of standard control over exposing parallelism to the device, broken fsync() and fdatasync() error semantics, just enough default buffering features to cause confusion but not avoid most performance bugs, lack of exposing device atomic write units, and many other things. It's an old API we've had for a long time. Made sense 40 years ago. But today it's just too low level to be easy, and too high-level to be fast.
- AtNightWeCode 3y agoPosix is actually pretty terrible. It is funny how Linux people still defend it. My criticism. Inflexible. Poor ACL management. All this recursive bs that I still can't wrap my head around. User groups, not a flat hierarchy? Poor observability. Windows is terrible in many ways but with files and in comparison to Posix Windows actually got it right. EDIT: I did not mention the article. It is silly to compare S3 to Posix. However. Azure and other cloud providers that did offer Posix storage have dropped those offerings.
- ilyt 3y agoThe question is compared to what ? Yes, POSIX-like file access have plenty of rough edges but alternatives are mostly trading this for that, not straight up upgrade. I'd like to see deburred version (cutting all the edge case crap with fsyncing and such, among other problems), but good luck getting everyone on board of that Every feature comes with drawbacks. For example ability to just lock the file might be great from app perspective but it is PITA from any distributed backend perspective. Ability to change it after write comes with similar problems so S3 and other cloudy ones tend to skip that. ACLs will always be fucking mess because the more powerful ones you need the more messy access control becomes. And it always becomes married with whatever underlying system uses for authentication. Like, you can rewrite app to use S3 but suddenly you now can't rewrite header of the file without going full read-modify-write cycle because modifying an object would be hard at scale so Amazon decided to just not do it. So stream-encoding MP4 file directly to S3 (which at end of encoding requires writing some stuff in header) can't be done directly on S3 and you need a temporary file (guess in what? POSIX local filesystem) before the upload, or use different format. > Poor observability. What that has to do with anything ? It's just API, you can observe it as any other API... hell, it's actually far more observable than app using S3 as you can't strace that but you can strace filesystem operations.
- cuno 3y agoHi, author here. Funny you should give the stream-encoding MP4 example, because yes that is what people's experience has been for S3. We've solved that - no temporary local file needed - all streamed directly to S3, for example using ordinary ffmpeg. The trick is a deeper understanding of how multi-part upload works, and if necessary, server-side copy semantics on those parts.
- msarrel 3y agoI don't understand why an ad for cunoFS is running on hacker News.
- deleted 3y ago[deleted]
- wrs 3y agoAssertion: You can’t just put a POSIX API over cloud storage, because the semantics are fundamentally different. You can translate the POSIX API operations to S3 operations, but the client author will have to be completely aware of the translation, it can’t possibly be transparent to them except in very limited circumstances. The problems with this approach date back all the way to AFS in the 80s, which was a full-file transfer with a local cache much like an S3 layer has to be. Simple example: it was immediately discovered that nobody ever checks the return code of close(). In a network upload situation you can definitely get an error from close() and you have to deal with it.
- cuno 3y agoHi, author here. Yes agree that you can't "just" put a POSIX API on S3, but that doesn't make it impossible. For the sake of keeping the article to a reasonable size, I left a lot of things out. There are tradeoffs that occur between POSIX semantics, consistency and performance. Each application/process has different needs but the great thing about running right inside the process is that we can see what those needs are and adapt. For example, many applications have no need for random access writes - the only libc calls and syscalls exposed are purely sequential. Some processes have both random access writes and POSIX record locks around them to protect them from other concurrent processes - and we can see that. That means we treat these applications/files differently, with some corresponding performance implications. This is very different to a normal filesystem that has to treat every process the same way because it is a "black box". You're right that AFS, and for that matter NFS, can in principle return error on close which many existing applications unfortunately aren't written to handle. However, that doesn't mean that NFS isn't practical - it is very widely used. Our customers mostly run workloads in the same region as the object storage (whether in cloud or on-prem) typically with very high availability. As an essentially networked file system, you're right that it can't make much stronger guarantees than the NFS protocol itself does, but operating inside cloud infrastructure you typically see 4 9s availability.
- wrs 3y agoI’m sure you’re aware of the issues, and this looks like highly useful work! But I’ve seen enough human nature to know that a lot of people will see “POSIX API” and assume they can just run anything on it without further thought. I know this because for years I’ve seen people run things on AFS and NFS, see weird concurrency behavior or data loss or latency, and blame the filesystem for not performing miracles, rather than blaming the application for not taking nonlocal storage into account. The strongest argument for using a different API for object storage is that you don’t get that excuse. The API presents the true semantics and failure conditions and the application needs to think them through. (And your position that it may not be a strong enough argument is perfectly valid.)
- 0xbadcafebee 3y agoPOSIX was outdated at its inception. But it turns out that's fine. Lots of people have gotten plenty of good use out of POSIX. It does basic things in a straightforward way and it's easy to implement. Cloud-based systems are basically the new UNIX, in that they are all completely different and non-standard and it's impossible to write something portable for more than one cloud provider. It would be great to have a "new POSIX" designed for the Cloud era.
- CodeNest 3y ago[dead]
- dathinab 3y agoplease don't extend POSIX but let POSIX die in peace create new standards, sure but preferable standards with more narrow scopes, e.g. a remote block storage API standard, which is just that and nothing more
- deleted 3y ago[deleted]