4 ms·

“It doesn’t make sense to put these types in the operating system” The OS doesn’t need to hardcode individual types, and to do so would defeat growth. It only

by hhas01 6y ago

“It doesn’t make sense to put these types in the operating system” The OS doesn’t need to hardcode individual types, and to do so would defeat growth. It only has to provide a standard mechanism by which files can declare the type of data they contain, and executables can declare the type(s) of data they consume and/or produce. BeOS, for instance, tagged files with MIME types. The original Mac OS used “four-char codes”. Even DOS had file name extensions, as awful as that particular design choice was. Storing arbitrary data with no way to indicate how that data is encoded is rank insanity. Saying “it’s the app’s job to deal with encodings” is not wrong, but if apps have no way to know what encoding a given file was written in, how can they know how to decode it? Please do not rationalize away the longstanding and well-known deficiencies of Unix. These deficiencies do not aid progress; they hinder it. As do apologetics.

gen220 6y ago
> files can declare the type of data they contain [...] executables can declare the type(s) of data they consume and/or produce. I think you're conceding that the OS would not be responsible for enforcing data's compliance with it's declared type. I'd be OK with this world, but I am not convinced that this hypothetical OS is substantially better than the UNIX descendants we have today. > Storing arbitrary data with no way to indicate how that data is encoded is rank insanity. I think we all can agree on this... it's just a matter of how we encode the data type. UNIX descendants follow the pattern of encoding data types with filename endings. While I agree that this approach feels primitive, it's hard to argue that it doesn't work, because it does. This is fundamentally identical to MIME-types, imo, because I believe extensions (and mime-types!) are fundamentally "names", and don't have much semantic above that, given the diversity of "name"-implementations, as stated earlier. I don't believe that we gain a lot of practical value from compelling executables to register their accepted "names" with the Operating System: I'm trying to imagine what big value this gives you, beyond transforming `some_program --out_type=json | jq` to `some_program | jq`. I hope you understand I'm not trying to apologize for UNIX. I agree that many things about it should be better. But I do think they got "everything is plaintext, from the OS's point of view" right. (I think it's good discussion and I want to learn from it)
- hhas01 6y ago
  “UNIX descendants follow the pattern of encoding data types with filename endings.” An ad-hoc arrangement with little formal support at the GUI level and none at all at the shell level. `some_program --out_type=json | jq` to `some_program | jq`. JSON only tells you how the data is encoded, not what it means. Contrast this MIME type: application/atom+json Knowing data is JSON-encoded only enables (unsafe) generic JSON operations. Knowing the data is, say, ATOM allows task-specific operations. Consider a search tool. Having precise type information enables format-specific parsing operations to be decoupled from generalized tree/table searching operations. Not only that, but looking up parsers and inserting them into the pipeline can be completely automated away. `some_program` doesn’t need to be told to output JSON; it can negotiate that itself with the program that follows, the shell acting as broker. (Content negotiation is one of the Great Ideas of HTTP; sadly utterly ballsed by the WWW, but that doesn’t mean others couldn’t do it right.) Or consider `ls`. How many options/arguments does that have? (If you don’t know off the top of your head, I totally understand and am happy to wait.) Now, how many out of those options relate to recursion, filtering, and presentation? Because none of those should be built-ins; they should all be separate, general, composable tools. How much duplication of effort would be eliminated across the entire Unix command line? How much easier would it be to learn the entire system? This is Unix Philosophy 101, yet even a simple standard tool like `ls` utterly fails it. Why? Because for effective, efficient, safe composition to be the easiest route, it needs to Just Work. Which it can’t do, because lack of IO typing and tagging means that What You See Is All You Can Get. Consider: for some consumers it’d make more sense for `ls` to output a list of inodes; for others, a list of full paths; for others, URLs. Outputting a list of file names is crap (assumes shared global state—cwd—that will not change between time of creation and time of use). Outputting a list of file names arranged in multiple vertical visual “columns” each offset by N spaces is insane. This is the very definition of Big Ball Of Mud. Like I’ve said, there is no point trying to “fix” Unix because fundamentally it does not want to be fixed; never mind whether or not fixing it is even technically feasible. But that’s fine: there’s value in stability and it is a sunk cost so nothing is lost. Just leave Old Unix to be itself, which is what it’s good at, and build a new system unencumbered by legacy baggage and baked-in mistakes, making full use of all the wisdom and resources gained over the decades since. Okay, so a brand new system will have to be radically better than the old in order to attract audience, but that’s totally doable. Heck, there were already way better CLIs forty years ago (VMS, Plan9, Symbolics Lisp, Smalltalk), so it’s not like there isn’t a wealth of knowledge and experience to purloin for free. It’s just a question of motive: who now benefits from propping up all the old complexity and makework vs who’ll benefit by completely disrupting it. And you just have to look at how an aggressive reborn Apple handed the mighty untouchable Microsoft its own ass back in the 2000s to work out the answer to that. Or Kodak. Or Xerox. Or the US car industry. Or the British Empire. And so on. Qui audet adipiscitur. She who dares, wins.

by hhas01 6y ago

gen220 6y ago

> files can declare the type of data they contain [...] executables can declare the type(s) of data they consume and/or produce. I think you're conceding that the OS would not be responsible for enforcing data's compliance with it's declared type. I'd be OK with this world, but I am not convinced that this hypothetical OS is substantially better than the UNIX descendants we have today. > Storing arbitrary data with no way to indicate how that data is encoded is rank insanity. I think we all can agree on this... it's just a matter of how we encode the data type. UNIX descendants follow the pattern of encoding data types with filename endings. While I agree that this approach feels primitive, it's hard to argue that it doesn't work, because it does. This is fundamentally identical to MIME-types, imo, because I believe extensions (and mime-types!) are fundamentally "names", and don't have much semantic above that, given the diversity of "name"-implementations, as stated earlier. I don't believe that we gain a lot of practical value from compelling executables to register their accepted "names" with the Operating System: I'm trying to imagine what big value this gives you, beyond transforming `some_program --out_type=json | jq` to `some_program | jq`. I hope you understand I'm not trying to apologize for UNIX. I agree that many things about it should be better. But I do think they got "everything is plaintext, from the OS's point of view" right. (I think it's good discussion and I want to learn from it)

hhas01 6y ago
“UNIX descendants follow the pattern of encoding data types with filename endings.” An ad-hoc arrangement with little formal support at the GUI level and none at all at the shell level. `some_program --out_type=json | jq` to `some_program | jq`. JSON only tells you how the data is encoded, not what it means. Contrast this MIME type: application/atom+json Knowing data is JSON-encoded only enables (unsafe) generic JSON operations. Knowing the data is, say, ATOM allows task-specific operations. Consider a search tool. Having precise type information enables format-specific parsing operations to be decoupled from generalized tree/table searching operations. Not only that, but looking up parsers and inserting them into the pipeline can be completely automated away. `some_program` doesn’t need to be told to output JSON; it can negotiate that itself with the program that follows, the shell acting as broker. (Content negotiation is one of the Great Ideas of HTTP; sadly utterly ballsed by the WWW, but that doesn’t mean others couldn’t do it right.) Or consider `ls`. How many options/arguments does that have? (If you don’t know off the top of your head, I totally understand and am happy to wait.) Now, how many out of those options relate to recursion, filtering, and presentation? Because none of those should be built-ins; they should all be separate, general, composable tools. How much duplication of effort would be eliminated across the entire Unix command line? How much easier would it be to learn the entire system? This is Unix Philosophy 101, yet even a simple standard tool like `ls` utterly fails it. Why? Because for effective, efficient, safe composition to be the easiest route, it needs to Just Work. Which it can’t do, because lack of IO typing and tagging means that What You See Is All You Can Get. Consider: for some consumers it’d make more sense for `ls` to output a list of inodes; for others, a list of full paths; for others, URLs. Outputting a list of file names is crap (assumes shared global state—cwd—that will not change between time of creation and time of use). Outputting a list of file names arranged in multiple vertical visual “columns” each offset by N spaces is insane. This is the very definition of Big Ball Of Mud. Like I’ve said, there is no point trying to “fix” Unix because fundamentally it does not want to be fixed; never mind whether or not fixing it is even technically feasible. But that’s fine: there’s value in stability and it is a sunk cost so nothing is lost. Just leave Old Unix to be itself, which is what it’s good at, and build a new system unencumbered by legacy baggage and baked-in mistakes, making full use of all the wisdom and resources gained over the decades since. Okay, so a brand new system will have to be radically better than the old in order to attract audience, but that’s totally doable. Heck, there were already way better CLIs forty years ago (VMS, Plan9, Symbolics Lisp, Smalltalk), so it’s not like there isn’t a wealth of knowledge and experience to purloin for free. It’s just a question of motive: who now benefits from propping up all the old complexity and makework vs who’ll benefit by completely disrupting it. And you just have to look at how an aggressive reborn Apple handed the mighty untouchable Microsoft its own ass back in the 2000s to work out the answer to that. Or Kodak. Or Xerox. Or the US car industry. Or the British Empire. And so on. Qui audet adipiscitur. She who dares, wins.