8 ms·

Unix Delenda Est (2015)

66 points by networked 11y ago

msie 11y ago
Ok, really, that's nice. Come back to me with a working system and we'll talk.
anthk 11y ago
>We are not NASA. RHEL had 30 million lines of code, 71% of them C, in 2001! How many hundred vulnerabilities lurk there, unseen by human eyes? As if with "modern" languages you would be safer. Poor new delusional kids.
- vpkaihla 11y ago
  > As if with "modern" languages you would be safer. Poor new delusional kids. That's a rather amazing quip. How would I, in my mid-thirties, accidentally write a buffer overflow in Haskell or Rust?
  - imglorp 11y ago
    Wait, what, these things have no bugs, you say? All software has bugs, unintended side effects, untested code paths, and other cruft at the lower layers, especially when interfacing with the OS. Look how many vulnerabilities have been found in the JPG libraries alone, and that's just a bitmap; how hard could it be, right? http://stackoverflow.com/questions/498234/vulnerability-in-the-functional-programming-paradigm http://stackoverflow.com/questions/498234/vulnerability-in-t...
    - icebraining 11y ago
      Interesting choice of a link, since all the answers essentially say that it may be easier to make it consume lots of memory, leading to a possible DoS. That's not pleasant, but hardly a major problem compared to remote code execution. All software has bugs, it's true, and language runtimes included. But that doesn't mean some languages can't be safer.
  - chris_wot 11y ago
    I guess it depends on how imaginative you are.
anthk 11y ago
>Sandboxes make a much better security primitive than sudo, file permissions, etc. which are useless for protecting a single user’s data. Is not only sudo, but sudo AND polkit. Are you sure you know what are you talking about? And about your sensitive data, AppArmor is more than capable. For the other sensitive data, create a folder out of /home and "chattr +i" your content recursively, giving proper permissions first. And you rely in Plan9 for your speech, which is more UNIXy than UNIX and everything IS a filesystem in a more hardcore way (something you look as obsolete), altough factotum and namespaces are a complete different beast.
- rwmj 11y ago
  I don't think anyone is disputing that Linux has many encrusted layers of permissions systems, some of them Turing complete. And a terrible reporting mechanism -- your system call returns -EPERM, now you have to work out which of the many layers you tripped over. Or you can try decoding audit.log or remember which of the many SELinux tools you need to invoke. The question is if we can do better, and the answer is obviously yes because research OSes have existed for many years, like EROS, KeyKOS etc. However rewriting all our software is not going to happen, so the question is how to get from where we are now to better systems.
- legulere 11y ago
  Many unix systems are used by just one person (Desktops, Smartphones, Tablets). Most unix systems that are used by more people are servers and don't use the unix user system to discern between users. The fewest unix systems out there have several users connecting to it with each user having a different unix user account. But exactly this is what the unix user system was designed - nothing else. Everything else like root or users for services is just a dirty hack, because unix wasn't designed to offer real isolation of applications. AppArmor doesn't work because users creating profiles about what syscalls are allowed is out of touch with reality. The only unix systems partially offering the isolation actually needed today are Android and iOS. You could still improve them massively though.
  - bluejekyll 11y ago
VLM 11y ago
The problem with hierarchical filesystems is people who can't organize in a hierarchical manner, regardless of presence or absence of excuse or responsibility, make a mess of size X. And likewise the problem with tagged data is likewise the people who can't organize tags is arguably an equal or larger group and they end up with a huge steaming mess, although its of size 1000 times X especially WRT human effort required to clean up and curate. The classic analogy is you unleash genealogists on a village cemetery and have them produce a family tree and the output is actually useful information. Unleash the same team and ask them to digitally tag tombstones, and you just get a pile of useless, error filled data, packed with duplicates and weird capitalization issues. This is a classic "information vs data" misunderstanding. Another problem with hierarchical vs tagged is we have somewhat obtuse yet usable set of tools to handle truly immense spammy hierarchical filesystems, but strategies for handling and scaling tagged filesystems usually are hand waved away with "it'll never happen" or "we'll sprinkle magic AI dust on it, then it'll evaporate away". A classic "make the simple easier, while making the more difficult impossible". No thanks. Much as there's nothing really new under the sun in IT, a generation or two ago this was "sure sendmail configuration is complicated, but all it needs is a GUI because in the small subset of problem domains that are a match for GUIs and people with a problem simple enough to be handled in a GUI, it works well, therefore its perfect for everyone to do everything in" Also data typing is just a subset of tagging. Or rephrased a type is a very poorly implemented limited single tag. Ditto the above with a "decent shell language" again we're dealing with people who can't handle paper calendars without a book telling them how (GTD, 42 folders, etc). They're just going to mess things up quicker with automation, while people who can handle the cognitive challenge will likewise jump into org mode or crontab without any serious effort on their part... You "could" write a noob gui for a nuclear reactor, or a UI for even newborn babies to use matches, but you probably shouldn't. As a meta observation this is a classic "future is already here just unevenly distributed" problem, I use databases and git all the time. However see the comment about the GUI for sendmail... Much like some people are unqualified to be handed an acetylene cutting torch or a beryllium-Pu neutron source, some people should not be handed relational DBs or KV stores or version control, and if they had the background to understand and safely use those tools, the existing tools aren't really all that hard to use for folks of adequate cognitive level.
- 11y ago
oldmanjay 11y ago
I'm midway through the article and I don't get the point at all. Is this person trying to explore the limits of the usefulness of uninformed opinion in the guise of meandering rants? Maybe the second half resolves the mystery.
makmanalp 11y ago
Inspiration for the title: https://en.wikipedia.org/wiki/Carthago_delenda_est https://en.wikipedia.org/wiki/Carthago_delenda_est
chris_wot 11y ago
You know, this is all said very earnestly but the problem is that it tends to ignore the fact that many, many great things have been achieved with current technology. The linked to "worse is better" article I have read before, years ago. The criticism of the failure mode of Unix is invalid. If you hit an error condition, then unless you have have kept your systems state for an indeterminate period of time, it's often not feasible to back out of the program to where the error occurred. In terms of tagging, that's never taken off. Why? Because it turns out tagging things is harder than you might think, because you can call the same thing by different names, which is somewhat ironically a major problem with hierarchical file systems. You basically end up with needing to be able to locate all the tags that are synonyms of each other. At the very least, a file system comes with a convention. I know where configuration files are on Unix - I go the the /etc directory. If I want to find my executables, I go to either /usr/bin or /bin. For my files, I'm under /home/chris. If I was to tag stuff, I'd also need to stick to a convention, or chaos reigns. I know, I've tried this before. I basically ended up with a hierarchical tagging structure. That's not too say tagging is awful, only that it's not a panacea to all perceived ills. As for version control - git is honestly the best example of a versioning system that does everything you describe - content addressing, versions control, snapshots... And guess what? It's all in a DAG. Oh, and one more thing: all that "untyped text" that is a "bad persistence model" firstly ignores the fact that it's not untyped, that every file system contains metadata, and that a file name is no different to a tag that is a label.
- blablabla123 11y ago
  >In terms of tagging, that's never taken off. Why? ... >because you can call the same thing by different names I guess for software packages some sort of hierarchy seems essential. At least for documents I always imagined that tags would be perfect. It seems that documents always fit in multiple hierarchies... On the other hand, if you really want no hierarchy in software packages, some standard tags are necessary. Like 'ConfigFile', 'Active', ... Also one should keep in mind that data in software is also in most cases not hierarchical. Hierarchical databases are a weird animal that nobody uses. Maybe hierarchical filesystems have constraint our minds so much that we cannot easily imagine some other way. Regarding the rest... I think as well that Unix has some problems, mostly due to old design. Having to use regexes to match file names is so error-prone, I think only for document file names that would be okay. I really like the innovative approach of Windows Power Shell eventhough the syntax is still too weird.
jstimpfle 11y ago
> A single global, mutable tree of untyped text is a bad persistence model. In a strict sense, almost all software accessing standard hierarchical file systems is even just broken -- it breaks for certain concurrent operations, and there is no way to forbid them. But still hierarchical filesystems are the best usable-by-default model I know. It's a humane approach from a cognitive standpoint: the real world of "things that exist only once, in one place" is inherently hierarchical. For different needs, it's often easy enough to flatten data a bit and use tools like filename globs or regular expressions, to get a performant, good enough solution that is also maintainable. For very specific needs, you can always use a relational, or whatever, DB.
- bluejekyll 11y ago
  I think the default indexing features in our modern OSes are already getting us into the DB filesystem mode. I use search more often these days than traversing the hierarchical tree.
jstimpfle 11y ago
> A single global, mutable tree of untyped text is a bad persistence model. In a strict sense, almost all software accessing standard hierarchical file systems is even just broken -- it breaks for certain concurrent operations, and there is no way to forbid them. But still hierarchical filesystems are the best usable-by-default model I know. It's a humane approach from a cognitive standpoint: the real world of "things that exist only once, in one place" is inherently hierarchical. For different needs, it's often easy enough to flatten data a bit and use tools like filename globs or regular expressions, to get a performant, good enough solution that is also maintainable. For very specific needs, you can always use a relational, or whatever, DB.
bluejekyll 11y ago
After starting to become more interested in microkernels/exokernels/unikernels, I've started wondering if POSIX in all of its glory (and I've always been a huge POSIX fan) is perhaps holding us back from a different and better development model. What I like about this post is that it's trying to point out some specific things that are perhaps the most constraining, though I'm not sure the solutions or conclusions are correct. The question is the right one though.
- tremon 11y ago
  Which question is that? I've so far only skimmed the article, but I haven't been able to find a central theme or discussion point.
  - bluejekyll 11y ago
    I guess more specifically, the question is does the UNIX/POSIX principle/specification currently constrain our development methodology such that we are building software that could otherwise be simpler?
- seagreen 11y ago
  Thanks for the nice words. I'm not sure about my conclusions either -- I'm particularly unhappy with how I described the type system for the data store. Type systems need more than ten minutes thought. As other people have pointed out in this thread pretty much everything I talk about has been implemented by one program or another. It hasn't all been collected into one user environment though, and without doing that it's hard to envision the details of how things in that environment should fit together.
pampa 11y ago
Some of the complaints seem reasonable. But how did he make the jump from the web-faxmachine to unix? did i miss something? Web pages being saved as blobs and not providing raw data is not a problem technologists can fix unfortunately.
- seagreen 11y ago
  Sorry the intro moves so fast. The answer is here: But if web browsers are so bad, why do they keep spreading? [...] mainly because the alternative is defective. The startup, academic and open source communities all have their weight behind Unix, but Unix is a dead end. Like many people I used to do everything in the browser (using windows, but treating it like a Chromebook). When I became I programmer I switched to Unix and tried to use the command line for everything I could. It was amazing! I wanted other people to share this experience, but couldn't make any converts. It turned out that it was only working for me because I was willing to plow hours into fixing problems. For most non-programmers, command line Unix isn't a good enough user environment to be a competitor to the web. And we really need that competitor.
  - pjmlp 11y ago
    Xerox PARC, that is the real competitor. I am also a programmer, know UNIX before Linux was a thing, as my introduction was with Xenix. But I was already versed in systems like the Amiga. The CLI might be interesting, but a REPL environment is so much more powerful. POSIX is stuck with UNIX System V. It hardly changed anything in terms of OS architecture and they don't seem to be adding anything new, in terms of modern systems.
  - pampa 11y ago
    I still think it is a very big stretch to go from web browsers (which suck on many levels) to unix bashing. Most non-programmers don't come anywhere close to a terminal window, despite running some form of unix on their devices. I agree that a unix command line is not a good interface for non-programmers, but it is good for people who have to work with large quantities of textual information, and source code IS text. I think that the main problem is that there is not much (commercial or academic) interest in empowering non-technical users. There are some specialty tools for non-programmers like excel macros, or task automation in photoshop, but general purpose system that let the average user program the computer without actually programming it never took of.
qwertyuiop924 11y ago
Yeah, UNIX sucks. We know this. The problem is, there isn't really anything better. Oh, plenty of things have TRIED, but it's the elisp curse: It's not the most elegant system, but it's easier to try and hack what you need on top of it than make a better one. >Tagged Filesystems While not in common use, these exist now. And you can run them on your unix machines. Look up BeFS. >Typed Data ...I'd rather have 1000 ops on 1 crappy data structure than 10 ops one 100 good data structures. And that's what you usually end up with, regardless of what you're trying for. >Immutable Data: This is actually something I'd like to see. OH WAIT, I have, it's called git. Now we just need to integrate it into an FS. It's also called Nix, for packages specifically. >Server First: Plan9 did it, It's been emulated in userspace, It should have caught on. >Decent Shell Lang: Python and Ruby anybody? We really should make those defaults. >Reasonably Secure. Yeah, we need to fix this. We need less C. >Better Security Model We'll implement it if somebody can design one that Fking works, and isn't Fing SELinux. >Browsable Executables. Yeah. >Sandboxes THE DOCKER REVOLUTION HAS ALREADY COME.
- nextos 11y ago
  I think the winning solution could be Nix-like package management (like NixOS, GuixSD or to a lesser extent GoboLinux) PLUS lightweight containers. You get the best of both worlds, good package management within containers, reproducibility, etc. With Docker or apt you only get half baked solutions.
  - qwertyuiop924 11y ago
    Meh. Containers are pretty heavy compared to nix/guix.
    - nextos 11y ago
      Lightweight ones? Guix already supports its own jails-like containers and they are a breeze. So are systemd ones offered by Nix.
      - qwertyuiop924 11y ago
otabdeveloper 11y ago
If you want usable tags, then you first need a good ontology hierarchy. Inventing good ontologies is a problem that's orders of magnitude harder than a problem of making a filesystem hierarchy searchable. Look at Wikipedia -- despite all this time and all this truly immense planet-size effort, they still haven't figured out a good categorization system!

66 points by networked 11y ago

msie 11y ago

Ok, really, that's nice. Come back to me with a working system and we'll talk.

anthk 11y ago

>We are not NASA. RHEL had 30 million lines of code, 71% of them C, in 2001! How many hundred vulnerabilities lurk there, unseen by human eyes? As if with "modern" languages you would be safer. Poor new delusional kids.

vpkaihla 11y ago
> As if with "modern" languages you would be safer. Poor new delusional kids. That's a rather amazing quip. How would I, in my mid-thirties, accidentally write a buffer overflow in Haskell or Rust?
- imglorp 11y ago
  Wait, what, these things have no bugs, you say? All software has bugs, unintended side effects, untested code paths, and other cruft at the lower layers, especially when interfacing with the OS. Look how many vulnerabilities have been found in the JPG libraries alone, and that's just a bitmap; how hard could it be, right? http://stackoverflow.com/questions/498234/vulnerability-in-the-functional-programming-paradigm http://stackoverflow.com/questions/498234/vulnerability-in-t...
  - icebraining 11y ago
    Interesting choice of a link, since all the answers essentially say that it may be easier to make it consume lots of memory, leading to a possible DoS. That's not pleasant, but hardly a major problem compared to remote code execution. All software has bugs, it's true, and language runtimes included. But that doesn't mean some languages can't be safer.
- chris_wot 11y ago
  I guess it depends on how imaginative you are.

anthk 11y ago

>Sandboxes make a much better security primitive than sudo, file permissions, etc. which are useless for protecting a single user’s data. Is not only sudo, but sudo AND polkit. Are you sure you know what are you talking about? And about your sensitive data, AppArmor is more than capable. For the other sensitive data, create a folder out of /home and "chattr +i" your content recursively, giving proper permissions first. And you rely in Plan9 for your speech, which is more UNIXy than UNIX and everything IS a filesystem in a more hardcore way (something you look as obsolete), altough factotum and namespaces are a complete different beast.

rwmj 11y ago
I don't think anyone is disputing that Linux has many encrusted layers of permissions systems, some of them Turing complete. And a terrible reporting mechanism -- your system call returns -EPERM, now you have to work out which of the many layers you tripped over. Or you can try decoding audit.log or remember which of the many SELinux tools you need to invoke. The question is if we can do better, and the answer is obviously yes because research OSes have existed for many years, like EROS, KeyKOS etc. However rewriting all our software is not going to happen, so the question is how to get from where we are now to better systems.
legulere 11y ago
Many unix systems are used by just one person (Desktops, Smartphones, Tablets). Most unix systems that are used by more people are servers and don't use the unix user system to discern between users. The fewest unix systems out there have several users connecting to it with each user having a different unix user account. But exactly this is what the unix user system was designed - nothing else. Everything else like root or users for services is just a dirty hack, because unix wasn't designed to offer real isolation of applications. AppArmor doesn't work because users creating profiles about what syscalls are allowed is out of touch with reality. The only unix systems partially offering the isolation actually needed today are Android and iOS. You could still improve them massively though.
- bluejekyll 11y ago

VLM 11y ago

The problem with hierarchical filesystems is people who can't organize in a hierarchical manner, regardless of presence or absence of excuse or responsibility, make a mess of size X. And likewise the problem with tagged data is likewise the people who can't organize tags is arguably an equal or larger group and they end up with a huge steaming mess, although its of size 1000 times X especially WRT human effort required to clean up and curate. The classic analogy is you unleash genealogists on a village cemetery and have them produce a family tree and the output is actually useful information. Unleash the same team and ask them to digitally tag tombstones, and you just get a pile of useless, error filled data, packed with duplicates and weird capitalization issues. This is a classic "information vs data" misunderstanding. Another problem with hierarchical vs tagged is we have somewhat obtuse yet usable set of tools to handle truly immense spammy hierarchical filesystems, but strategies for handling and scaling tagged filesystems usually are hand waved away with "it'll never happen" or "we'll sprinkle magic AI dust on it, then it'll evaporate away". A classic "make the simple easier, while making the more difficult impossible". No thanks. Much as there's nothing really new under the sun in IT, a generation or two ago this was "sure sendmail configuration is complicated, but all it needs is a GUI because in the small subset of problem domains that are a match for GUIs and people with a problem simple enough to be handled in a GUI, it works well, therefore its perfect for everyone to do everything in" Also data typing is just a subset of tagging. Or rephrased a type is a very poorly implemented limited single tag. Ditto the above with a "decent shell language" again we're dealing with people who can't handle paper calendars without a book telling them how (GTD, 42 folders, etc). They're just going to mess things up quicker with automation, while people who can handle the cognitive challenge will likewise jump into org mode or crontab without any serious effort on their part... You "could" write a noob gui for a nuclear reactor, or a UI for even newborn babies to use matches, but you probably shouldn't. As a meta observation this is a classic "future is already here just unevenly distributed" problem, I use databases and git all the time. However see the comment about the GUI for sendmail... Much like some people are unqualified to be handed an acetylene cutting torch or a beryllium-Pu neutron source, some people should not be handed relational DBs or KV stores or version control, and if they had the background to understand and safely use those tools, the existing tools aren't really all that hard to use for folks of adequate cognitive level.

11y ago

oldmanjay 11y ago

I'm midway through the article and I don't get the point at all. Is this person trying to explore the limits of the usefulness of uninformed opinion in the guise of meandering rants? Maybe the second half resolves the mystery.

makmanalp 11y ago

Inspiration for the title: https://en.wikipedia.org/wiki/Carthago_delenda_est https://en.wikipedia.org/wiki/Carthago_delenda_est

chris_wot 11y ago

You know, this is all said very earnestly but the problem is that it tends to ignore the fact that many, many great things have been achieved with current technology. The linked to "worse is better" article I have read before, years ago. The criticism of the failure mode of Unix is invalid. If you hit an error condition, then unless you have have kept your systems state for an indeterminate period of time, it's often not feasible to back out of the program to where the error occurred. In terms of tagging, that's never taken off. Why? Because it turns out tagging things is harder than you might think, because you can call the same thing by different names, which is somewhat ironically a major problem with hierarchical file systems. You basically end up with needing to be able to locate all the tags that are synonyms of each other. At the very least, a file system comes with a convention. I know where configuration files are on Unix - I go the the /etc directory. If I want to find my executables, I go to either /usr/bin or /bin. For my files, I'm under /home/chris. If I was to tag stuff, I'd also need to stick to a convention, or chaos reigns. I know, I've tried this before. I basically ended up with a hierarchical tagging structure. That's not too say tagging is awful, only that it's not a panacea to all perceived ills. As for version control - git is honestly the best example of a versioning system that does everything you describe - content addressing, versions control, snapshots... And guess what? It's all in a DAG. Oh, and one more thing: all that "untyped text" that is a "bad persistence model" firstly ignores the fact that it's not untyped, that every file system contains metadata, and that a file name is no different to a tag that is a label.

blablabla123 11y ago
>In terms of tagging, that's never taken off. Why? ... >because you can call the same thing by different names I guess for software packages some sort of hierarchy seems essential. At least for documents I always imagined that tags would be perfect. It seems that documents always fit in multiple hierarchies... On the other hand, if you really want no hierarchy in software packages, some standard tags are necessary. Like 'ConfigFile', 'Active', ... Also one should keep in mind that data in software is also in most cases not hierarchical. Hierarchical databases are a weird animal that nobody uses. Maybe hierarchical filesystems have constraint our minds so much that we cannot easily imagine some other way. Regarding the rest... I think as well that Unix has some problems, mostly due to old design. Having to use regexes to match file names is so error-prone, I think only for document file names that would be okay. I really like the innovative approach of Windows Power Shell eventhough the syntax is still too weird.

jstimpfle 11y ago

> A single global, mutable tree of untyped text is a bad persistence model. In a strict sense, almost all software accessing standard hierarchical file systems is even just broken -- it breaks for certain concurrent operations, and there is no way to forbid them. But still hierarchical filesystems are the best usable-by-default model I know. It's a humane approach from a cognitive standpoint: the real world of "things that exist only once, in one place" is inherently hierarchical. For different needs, it's often easy enough to flatten data a bit and use tools like filename globs or regular expressions, to get a performant, good enough solution that is also maintainable. For very specific needs, you can always use a relational, or whatever, DB.

bluejekyll 11y ago
I think the default indexing features in our modern OSes are already getting us into the DB filesystem mode. I use search more often these days than traversing the hierarchical tree.

jstimpfle 11y ago

bluejekyll 11y ago

After starting to become more interested in microkernels/exokernels/unikernels, I've started wondering if POSIX in all of its glory (and I've always been a huge POSIX fan) is perhaps holding us back from a different and better development model. What I like about this post is that it's trying to point out some specific things that are perhaps the most constraining, though I'm not sure the solutions or conclusions are correct. The question is the right one though.

tremon 11y ago
Which question is that? I've so far only skimmed the article, but I haven't been able to find a central theme or discussion point.
- bluejekyll 11y ago
  I guess more specifically, the question is does the UNIX/POSIX principle/specification currently constrain our development methodology such that we are building software that could otherwise be simpler?
seagreen 11y ago
Thanks for the nice words. I'm not sure about my conclusions either -- I'm particularly unhappy with how I described the type system for the data store. Type systems need more than ten minutes thought. As other people have pointed out in this thread pretty much everything I talk about has been implemented by one program or another. It hasn't all been collected into one user environment though, and without doing that it's hard to envision the details of how things in that environment should fit together.

pampa 11y ago

Some of the complaints seem reasonable. But how did he make the jump from the web-faxmachine to unix? did i miss something? Web pages being saved as blobs and not providing raw data is not a problem technologists can fix unfortunately.

seagreen 11y ago
Sorry the intro moves so fast. The answer is here: But if web browsers are so bad, why do they keep spreading? [...] mainly because the alternative is defective. The startup, academic and open source communities all have their weight behind Unix, but Unix is a dead end. Like many people I used to do everything in the browser (using windows, but treating it like a Chromebook). When I became I programmer I switched to Unix and tried to use the command line for everything I could. It was amazing! I wanted other people to share this experience, but couldn't make any converts. It turned out that it was only working for me because I was willing to plow hours into fixing problems. For most non-programmers, command line Unix isn't a good enough user environment to be a competitor to the web. And we really need that competitor.
- pjmlp 11y ago
  Xerox PARC, that is the real competitor. I am also a programmer, know UNIX before Linux was a thing, as my introduction was with Xenix. But I was already versed in systems like the Amiga. The CLI might be interesting, but a REPL environment is so much more powerful. POSIX is stuck with UNIX System V. It hardly changed anything in terms of OS architecture and they don't seem to be adding anything new, in terms of modern systems.
- pampa 11y ago
  I still think it is a very big stretch to go from web browsers (which suck on many levels) to unix bashing. Most non-programmers don't come anywhere close to a terminal window, despite running some form of unix on their devices. I agree that a unix command line is not a good interface for non-programmers, but it is good for people who have to work with large quantities of textual information, and source code IS text. I think that the main problem is that there is not much (commercial or academic) interest in empowering non-technical users. There are some specialty tools for non-programmers like excel macros, or task automation in photoshop, but general purpose system that let the average user program the computer without actually programming it never took of.

qwertyuiop924 11y ago

Yeah, UNIX sucks. We know this. The problem is, there isn't really anything better. Oh, plenty of things have TRIED, but it's the elisp curse: It's not the most elegant system, but it's easier to try and hack what you need on top of it than make a better one. >Tagged Filesystems While not in common use, these exist now. And you can run them on your unix machines. Look up BeFS. >Typed Data ...I'd rather have 1000 ops on 1 crappy data structure than 10 ops one 100 good data structures. And that's what you usually end up with, regardless of what you're trying for. >Immutable Data: This is actually something I'd like to see. OH WAIT, I have, it's called git. Now we just need to integrate it into an FS. It's also called Nix, for packages specifically. >Server First: Plan9 did it, It's been emulated in userspace, It should have caught on. >Decent Shell Lang: Python and Ruby anybody? We really should make those defaults. >Reasonably Secure. Yeah, we need to fix this. We need less C. >Better Security Model We'll implement it if somebody can design one that Fking works, and isn't Fing SELinux. >Browsable Executables. Yeah. >Sandboxes THE DOCKER REVOLUTION HAS ALREADY COME.

nextos 11y ago
I think the winning solution could be Nix-like package management (like NixOS, GuixSD or to a lesser extent GoboLinux) PLUS lightweight containers. You get the best of both worlds, good package management within containers, reproducibility, etc. With Docker or apt you only get half baked solutions.
- qwertyuiop924 11y ago
  Meh. Containers are pretty heavy compared to nix/guix.
  - nextos 11y ago
    Lightweight ones? Guix already supports its own jails-like containers and they are a breeze. So are systemd ones offered by Nix.
    - qwertyuiop924 11y ago

otabdeveloper 11y ago

If you want usable tags, then you first need a good ontology hierarchy. Inventing good ontologies is a problem that's orders of magnitude harder than a problem of making a filesystem hierarchy searchable. Look at Wikipedia -- despite all this time and all this truly immense planet-size effort, they still haven't figured out a good categorization system!