5 ms·

CP/M was nice, it's a shame we got saddled with MS-DOS for decades.

by Neil44 4y ago

pjmlp 4y ago
Having started my MS-DOS path with version 3.3, and used all MS-DOS versions, also the DR-DOS 5.0 and 6.0 versions, experienced CP/M on the Spectrum +3A, I fail to see how CP/M was better.
- mongol 4y ago
  Which directory separator did it have?
  - Doctor_Fegg 4y ago
    CP/M didn't have sub-directories, though it did have 16 "user areas" on a disk.
    - II2II 4y ago
      MS-DOS did not have directories at first either. It was a feature in version 2.0, when hard drive support was added. Directories seem to have been a foreign concept among early home computer operating systems and I suspect its adoption was driven by the adoption of hard drives. For example, the Apple II did not gain directory support until ProDOS was introduced and the Macintosh only gained folders with the introduction of HFS. I don't recall directories existing for the Commodore 64 either.
      - jasomill 4y ago
        Technically, the original Macintosh filesystem supported folders as "an illusion maintained by the system software"[1] in spite of its flat directory structure. [1] https://developer.apple.com/library/archive/documentation/mac/Files/Files-85.html https://developer.apple.com/library/archive/documentation/ma...
      - egypturnash 4y ago
        Directories just weren’t worth it on discs that stored less than 200k. You organized stuff by putting the floppies in the right place in their storage boxes.
    - aidos 4y ago
      Oooo, question for those that might know a little more about this. I had an Amstrad (CPC6128 running CP/M) and I found that if I did cat to list disk contents without a disk in the drive enough times in a row it would eventually list out really random contents. Anyone know what might have been going on.
      - Doctor_Fegg 4y ago
        CAT would have been AMSDOS, not CP/M (it was DIR in CP/M). Not sure what was happening in that case though - it sounds like a bug, but not one I ever recall encountering!
        aidos 4y ago
        Oh interesting. I swear it was cp/m; cat I’m more hazy on (though I feel like I didn’t use dir until ibm dos). I had to really hammer on the command, and it would actually be trying to read either the hardware. I wonder if it was actually a physical issue that triggered it.
        atq2119 4y ago
        Sounds like whatever check that was used to determine whether a floppy was present or not had some small probability of giving a false positive. Maybe because without a floppy, the head would read random data that could pass some integrity check by chance.
  - pjmlp 4y ago
    The same as always \, while CP/M didn't even had directories, it was a flat file systems.
  - pavlov 4y ago
    I believe CP/M always used the forward slash as the CLI modifier argument prefix (where Unix would use a dash). MS-DOS inherited this. When directories were eventually added, the forward slash couldn’t be used as a separator because it was already used for modifiers.
    - ratboy666 4y ago
      CP/M does not use forward slash as the CLI modifier. Examples - from the standard CP/M utilities (CP/M 2.2) ASM FILE.ABC .ABC encodes options. Source file for ASM is always .ASM STAT uses $ - STAT FILE $R/O sets file to read-only PIP A:=B:[G0] - PIP (copy, "peripheral interchange program"), uses [ for options, as do later Digital Research programs (like the linker). Basically /no/ Digital Research use of / as option separator. Microsoft used / - for example the command line L80 FILE,FILE/N/E - which means link FILE.REL (relocatable), naming the output FILE.COM, and link and exit. CP/M 2.2 introduced "user areas" - a disk could be divided into 16 user areas (USER 0 to USER 15). There was no "searching" until CP/M 3. CP/NET (Digital Research networking) used [ as a separator. Examples (from CP/NET documentation) A>RMAC SNIOS A>LINK SNIOS[OS] LOGIN {password}{[mstrID]} LOGIN secret[01] would log in to server 01, with password secret NETWORK B:=D:[F] assigned B: to server 0F, drive D: The lack of directories was not such a loss, as the maximum disk size for CP/M 2.2 was 8MB. Remote drives with CP/NET could be much larger (I have used up to 1TB).
    - WorldMaker 4y ago
      Forward slash as a modifier prefix was IBM's desire because it was what they used in Mainframe OSes at the time. A lot of MS-DOS things were for "compatibility" with IBM Mainframes at the time. Supposedly, Microsoft was lightly against the forward slash as command argument because they preferred Unix machines at that point as development mainframes and liked the POSIX defaults for forward slash as directory separator. (Which is why MS-DOS even from the early days of the file system often supported both for directory slash in first party commands, even if individual app argument parsers from third parties did not.)
      - skissane 4y ago
        > Forward slash as a modifier prefix was IBM's desire because it was what they used in Mainframe OSes at the time. A lot of MS-DOS things were for "compatibility" with IBM Mainframes at the time Not true. On IBM mainframes, options are generally specified in a NAME=VALUE or NAME(VALUE) format. For example, here is a TSO command to allocate a dataset: ALLOCATE DATASET(ALLOC.FILE1) NEW DIR(4) TRACKS SPACE(2,3) DSORG(PO) RECFM(F) LRECL(80) BLKSIZE(800) CATALOG VM/CMS uses an open parenthesis to introduce options instead, for example: LISTFILE (LABEL The forward slash option style does not come from IBM mainframes. Nor (despite what many people think) does it come from CP/M – CP/M's own option style was to put options in square brackets: PIP B:=A:*.COM [G9 V] Not sure exactly where CP/M gets that from, but may be very vaguely inspired by IBM mainframe conventions (especially VM/CMS), with square brackets replacing parentheses for whatever reason, and using single characters to save memory and typing. What I actually believe happened: forward slash comes from DEC via Microsoft. Microsoft's development tools for CP/M used that option style, which Microsoft got from DEC, because they didn't like CP/M's native option style. QDOS/PC-DOS/MS-DOS 1.0 copied that Microsoft option style. Yes, IBM did tell Microsoft not to change it from / to - between PC-DOS 1.0 and PC-DOS 2.0. But that was simply because IBM cared more about backward compatibility between DOS 1.0 and DOS 2.0 than Microsoft themselves did. It was nothing to do with mainframes. The only thing about DOS which shows any strong direct IBM influence, in terms of actual syntax/terminology/concepts/etc, is code pages.
  - mananaysiempre 4y ago
    Note that the OEM README[1] for MS-DOS 2 (the first version with a hierarchical filesystem) suggests that it was at IBM’s insistence that MS-DOS used backslash for directories and slash for options, rather than slash for directories and hyphen-minus for options (even though Microsoft’s own programs for CP/M apparently used slash for options due to DEC influences, instead of the brackets used by CP/M itself[2], so this is a bit of a tangle). The documentation and examples for CONFIG.SYS[3] also bear an evident Unix influence, note in particular AVAILDEV and SWITCHAR. The MS-DOS-specific calls for file descriptors (as opposed to CP/M-compatible calls for FCBs) are called “XENIX file calls” in the source[4]. (All DOS system calls for files accepted either separator, but the option parsers would retrieve SWITCHAR[5] and give it precedence.) [1] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/README.txt https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/... [2] https://news.ycombinator.com/item?id=30510935 https://news.ycombinator.com/item?id=30510935 [3] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/CONFIG.txt https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/... [4] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/XENIX.ASM https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/... [5] http://www.ctyme.com/intr/rb-2752.htm http://www.ctyme.com/intr/rb-2752.htm
    - kiwidrew 4y ago
      Yep, there was a (brief) period of time -- before MS-DOS became wildly popular -- when Microsoft was pitching Xenix as the future operating system for the PC. (Also worth noting is that MS-DOS 2.0 was a nearly complete rewrite of the 1.x codebase...)
    - lproven 4y ago
      > it was at IBM’s insistence that MS-DOS used backslash for directories and slash for options I think this is a misinterpretation. See the footnote in this article: http://www.os2museum.com/wp/why-does-windows-really-use-backslash-as-path-separator/ http://www.os2museum.com/wp/why-does-windows-really-use-back... Look at the positions of `\` and `/` on this keyboard: https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:IBM_Model_F_XT.png https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:I... Both were easy-to-type characters on US-layout keyboards, not requiring shift or any other control key.
  - lproven 4y ago
    I am not sure if you are being facetious or not. CP/M did not support subdirectories, so it did not have a directory separator. Its design was derived from a multiuser minicomputer OS (or several of them, principally DEC OS-8) and so it had user areas instead: A1: B6: C3: http://www.primrosebank.net/computers/cpm/cpm_cookbook_user.htm http://www.primrosebank.net/computers/cpm/cpm_cookbook_user....
    - mongol 4y ago
      I am not facetious. I wonder how things would have turned out if CP/M "won".
      - lproven 4y ago
        OK, fair enough. I suppose it's fairly natural to assume from the POV of the 3rd decade of the 21st century that computers from 50 years ago had basic facilities like hierarchical directories... but not all of them did. Big ones like high-end minicomputers did. I learned on VAX/VMS at university in the 1980s, and it did. Cheap low-end minis didn't, and nor did the early 8-bit machines whose design was inspired by low-end minicomputers. The main influences on CP/M were DEC OSes: OS/8 and TOPS-10. https://en.wikipedia.org/wiki/OS/8 https://en.wikipedia.org/wiki/OS/8 https://en.wikipedia.org/wiki/TOPS-10 https://en.wikipedia.org/wiki/TOPS-10 The 2nd is mentioned here: https://en.wikipedia.org/wiki/CP/M#Early_history https://en.wikipedia.org/wiki/CP/M#Early_history I have never used either -- I'm not that old -- and I am not sure but I don't think either supported hierarchical subdirectories. The closest thing that evolved into something that did was the DEC OS RSX-11, which influenced VMS. They used a filesystem called DEC Files-11: https://en.wikipedia.org/wiki/Files-11 https://en.wikipedia.org/wiki/Files-11 So that did end up supporting hierachical directories, but there isn't a "directory separator" per se. That's a UNIX-ism that MS-DOS 2.0 copied. A VMS file in its folder might have been called something like: VAXA$DKA100::[USERS.LPROVEN.SOURCE.FORTRAN]WUMPUS.FOR;42 In other words, devices had multicharacter names that had meaning (e.g. what type of controller board, then which controller, then which disk), possibly after a cluster node name, then in square brackets a folder path separated by dots, then a filename, then another dot, then a 3-letter extension, then a semicolon, then a version number. Looks baroque compared to the dead simple UNIX name style... /home/lproven/source/fortran/wumpus Every time you save a file, the version number increments automatically. And path specs combined with device names and cluster names mean that the filename could point to another disk on this controller, or another disk on a different controller, or a disk on another node in the cluster, or a disk on any node in a named cluster. You can't do that so easily with the Unix naming system. So the sysadmin has to mount folders from other machines into this one's filesystem, and that means also setting up some kind of distributed authentication like NIS or YP or LDAP, and then some PAM modules or something... and it all gets very complicated. In other words, the simplicity of the UNIX design doesn't take complexity away: it just hides it. It's still there but it becomes someone else's problem. Whereas the DEC way of doing things sort of puts the complexity right there in front of you, but in return, you got rich facilities right there. Much less need for Git when files are versioned and you can go back to an older version before you broke something just using info encoded into the filename. Much less need for NFS mounts when the filesystem knows about controllers and networking and clusters and lets you address them. Much less need for bolted-on fancy authentication when that's built into the OS because the designers thought about stuff like networks, clusters, and authentication, when all that got taken _out_ of UNIX and then had to be bolted back on later. So, yeah, the UNIX way is simpler, but OTOH that also means it's poorer. Poorer as in less rich. As in the DEC system was richer: being richer lets you do more. CP/M evolved into multitasking multiuser OSes in time, but DR didn't get to re-invent all this stuff. Maybe if DOS had never happened, DR would have prospered and bought DEC instead of Compaq buying DEC, and this stuff would have made it into PC OSes. Who knows...
- Neil44 4y ago
  To be fair I was thinking about the way MS-DOS solved problems that came along later like having lots more RAM and larger file systems. 640k, expanded memory, extended memory, file size limits. Things that I don't think CP/M was developed long enough to have to solve, so maybe it's not really fair to compare the two.
  - Ekaros 4y ago
    It would have probably ended up in similar mess with some different trade-offs and design decisions. Not in anyway certain it would have been better.

CP/M was nice, it's a shame we got saddled with MS-DOS for decades.

by Neil44 4y ago

CP/M was nice, it's a shame we got saddled with MS-DOS for decades.

Having started my MS-DOS path with version 3.3, and used all MS-DOS versions, also the DR-DOS 5.0 and 6.0 versions, experienced CP/M on the Spectrum +3A, I fail to see how CP/M was better.

mongol 4y ago
Which directory separator did it have?
- Doctor_Fegg 4y ago
  CP/M didn't have sub-directories, though it did have 16 "user areas" on a disk.
  - II2II 4y ago
    MS-DOS did not have directories at first either. It was a feature in version 2.0, when hard drive support was added. Directories seem to have been a foreign concept among early home computer operating systems and I suspect its adoption was driven by the adoption of hard drives. For example, the Apple II did not gain directory support until ProDOS was introduced and the Macintosh only gained folders with the introduction of HFS. I don't recall directories existing for the Commodore 64 either.
    - jasomill 4y ago
      Technically, the original Macintosh filesystem supported folders as "an illusion maintained by the system software"[1] in spite of its flat directory structure. [1] https://developer.apple.com/library/archive/documentation/mac/Files/Files-85.html https://developer.apple.com/library/archive/documentation/ma...
    - egypturnash 4y ago
      Directories just weren’t worth it on discs that stored less than 200k. You organized stuff by putting the floppies in the right place in their storage boxes.
  - aidos 4y ago
    Oooo, question for those that might know a little more about this. I had an Amstrad (CPC6128 running CP/M) and I found that if I did cat to list disk contents without a disk in the drive enough times in a row it would eventually list out really random contents. Anyone know what might have been going on.
    - Doctor_Fegg 4y ago
      CAT would have been AMSDOS, not CP/M (it was DIR in CP/M). Not sure what was happening in that case though - it sounds like a bug, but not one I ever recall encountering!
      - aidos 4y ago
        Oh interesting. I swear it was cp/m; cat I’m more hazy on (though I feel like I didn’t use dir until ibm dos). I had to really hammer on the command, and it would actually be trying to read either the hardware. I wonder if it was actually a physical issue that triggered it.
        atq2119 4y ago
        Sounds like whatever check that was used to determine whether a floppy was present or not had some small probability of giving a false positive. Maybe because without a floppy, the head would read random data that could pass some integrity check by chance.
- pjmlp 4y ago
  The same as always \, while CP/M didn't even had directories, it was a flat file systems.
- pavlov 4y ago
  I believe CP/M always used the forward slash as the CLI modifier argument prefix (where Unix would use a dash). MS-DOS inherited this. When directories were eventually added, the forward slash couldn’t be used as a separator because it was already used for modifiers.
  - ratboy666 4y ago
    CP/M does not use forward slash as the CLI modifier. Examples - from the standard CP/M utilities (CP/M 2.2) ASM FILE.ABC .ABC encodes options. Source file for ASM is always .ASM STAT uses $ - STAT FILE $R/O sets file to read-only PIP A:=B:[G0] - PIP (copy, "peripheral interchange program"), uses [ for options, as do later Digital Research programs (like the linker). Basically /no/ Digital Research use of / as option separator. Microsoft used / - for example the command line L80 FILE,FILE/N/E - which means link FILE.REL (relocatable), naming the output FILE.COM, and link and exit. CP/M 2.2 introduced "user areas" - a disk could be divided into 16 user areas (USER 0 to USER 15). There was no "searching" until CP/M 3. CP/NET (Digital Research networking) used [ as a separator. Examples (from CP/NET documentation) A>RMAC SNIOS A>LINK SNIOS[OS] LOGIN {password}{[mstrID]} LOGIN secret[01] would log in to server 01, with password secret NETWORK B:=D:[F] assigned B: to server 0F, drive D: The lack of directories was not such a loss, as the maximum disk size for CP/M 2.2 was 8MB. Remote drives with CP/NET could be much larger (I have used up to 1TB).
  - WorldMaker 4y ago
    Forward slash as a modifier prefix was IBM's desire because it was what they used in Mainframe OSes at the time. A lot of MS-DOS things were for "compatibility" with IBM Mainframes at the time. Supposedly, Microsoft was lightly against the forward slash as command argument because they preferred Unix machines at that point as development mainframes and liked the POSIX defaults for forward slash as directory separator. (Which is why MS-DOS even from the early days of the file system often supported both for directory slash in first party commands, even if individual app argument parsers from third parties did not.)
    - skissane 4y ago
      > Forward slash as a modifier prefix was IBM's desire because it was what they used in Mainframe OSes at the time. A lot of MS-DOS things were for "compatibility" with IBM Mainframes at the time Not true. On IBM mainframes, options are generally specified in a NAME=VALUE or NAME(VALUE) format. For example, here is a TSO command to allocate a dataset: ALLOCATE DATASET(ALLOC.FILE1) NEW DIR(4) TRACKS SPACE(2,3) DSORG(PO) RECFM(F) LRECL(80) BLKSIZE(800) CATALOG VM/CMS uses an open parenthesis to introduce options instead, for example: LISTFILE (LABEL The forward slash option style does not come from IBM mainframes. Nor (despite what many people think) does it come from CP/M – CP/M's own option style was to put options in square brackets: PIP B:=A:*.COM [G9 V] Not sure exactly where CP/M gets that from, but may be very vaguely inspired by IBM mainframe conventions (especially VM/CMS), with square brackets replacing parentheses for whatever reason, and using single characters to save memory and typing. What I actually believe happened: forward slash comes from DEC via Microsoft. Microsoft's development tools for CP/M used that option style, which Microsoft got from DEC, because they didn't like CP/M's native option style. QDOS/PC-DOS/MS-DOS 1.0 copied that Microsoft option style. Yes, IBM did tell Microsoft not to change it from / to - between PC-DOS 1.0 and PC-DOS 2.0. But that was simply because IBM cared more about backward compatibility between DOS 1.0 and DOS 2.0 than Microsoft themselves did. It was nothing to do with mainframes. The only thing about DOS which shows any strong direct IBM influence, in terms of actual syntax/terminology/concepts/etc, is code pages.
- mananaysiempre 4y ago
  Note that the OEM README[1] for MS-DOS 2 (the first version with a hierarchical filesystem) suggests that it was at IBM’s insistence that MS-DOS used backslash for directories and slash for options, rather than slash for directories and hyphen-minus for options (even though Microsoft’s own programs for CP/M apparently used slash for options due to DEC influences, instead of the brackets used by CP/M itself[2], so this is a bit of a tangle). The documentation and examples for CONFIG.SYS[3] also bear an evident Unix influence, note in particular AVAILDEV and SWITCHAR. The MS-DOS-specific calls for file descriptors (as opposed to CP/M-compatible calls for FCBs) are called “XENIX file calls” in the source[4]. (All DOS system calls for files accepted either separator, but the option parsers would retrieve SWITCHAR[5] and give it precedence.) [1] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/README.txt https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/... [2] https://news.ycombinator.com/item?id=30510935 https://news.ycombinator.com/item?id=30510935 [3] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/CONFIG.txt https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/... [4] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/XENIX.ASM https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/... [5] http://www.ctyme.com/intr/rb-2752.htm http://www.ctyme.com/intr/rb-2752.htm
  - kiwidrew 4y ago
    Yep, there was a (brief) period of time -- before MS-DOS became wildly popular -- when Microsoft was pitching Xenix as the future operating system for the PC. (Also worth noting is that MS-DOS 2.0 was a nearly complete rewrite of the 1.x codebase...)
  - lproven 4y ago
    > it was at IBM’s insistence that MS-DOS used backslash for directories and slash for options I think this is a misinterpretation. See the footnote in this article: http://www.os2museum.com/wp/why-does-windows-really-use-backslash-as-path-separator/ http://www.os2museum.com/wp/why-does-windows-really-use-back... Look at the positions of `\` and `/` on this keyboard: https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:IBM_Model_F_XT.png https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:I... Both were easy-to-type characters on US-layout keyboards, not requiring shift or any other control key.
- lproven 4y ago
  I am not sure if you are being facetious or not. CP/M did not support subdirectories, so it did not have a directory separator. Its design was derived from a multiuser minicomputer OS (or several of them, principally DEC OS-8) and so it had user areas instead: A1: B6: C3: http://www.primrosebank.net/computers/cpm/cpm_cookbook_user.htm http://www.primrosebank.net/computers/cpm/cpm_cookbook_user....
  - mongol 4y ago
    I am not facetious. I wonder how things would have turned out if CP/M "won".
    - lproven 4y ago
      OK, fair enough. I suppose it's fairly natural to assume from the POV of the 3rd decade of the 21st century that computers from 50 years ago had basic facilities like hierarchical directories... but not all of them did. Big ones like high-end minicomputers did. I learned on VAX/VMS at university in the 1980s, and it did. Cheap low-end minis didn't, and nor did the early 8-bit machines whose design was inspired by low-end minicomputers. The main influences on CP/M were DEC OSes: OS/8 and TOPS-10. https://en.wikipedia.org/wiki/OS/8 https://en.wikipedia.org/wiki/OS/8 https://en.wikipedia.org/wiki/TOPS-10 https://en.wikipedia.org/wiki/TOPS-10 The 2nd is mentioned here: https://en.wikipedia.org/wiki/CP/M#Early_history https://en.wikipedia.org/wiki/CP/M#Early_history I have never used either -- I'm not that old -- and I am not sure but I don't think either supported hierarchical subdirectories. The closest thing that evolved into something that did was the DEC OS RSX-11, which influenced VMS. They used a filesystem called DEC Files-11: https://en.wikipedia.org/wiki/Files-11 https://en.wikipedia.org/wiki/Files-11 So that did end up supporting hierachical directories, but there isn't a "directory separator" per se. That's a UNIX-ism that MS-DOS 2.0 copied. A VMS file in its folder might have been called something like: VAXA$DKA100::[USERS.LPROVEN.SOURCE.FORTRAN]WUMPUS.FOR;42 In other words, devices had multicharacter names that had meaning (e.g. what type of controller board, then which controller, then which disk), possibly after a cluster node name, then in square brackets a folder path separated by dots, then a filename, then another dot, then a 3-letter extension, then a semicolon, then a version number. Looks baroque compared to the dead simple UNIX name style... /home/lproven/source/fortran/wumpus Every time you save a file, the version number increments automatically. And path specs combined with device names and cluster names mean that the filename could point to another disk on this controller, or another disk on a different controller, or a disk on another node in the cluster, or a disk on any node in a named cluster. You can't do that so easily with the Unix naming system. So the sysadmin has to mount folders from other machines into this one's filesystem, and that means also setting up some kind of distributed authentication like NIS or YP or LDAP, and then some PAM modules or something... and it all gets very complicated. In other words, the simplicity of the UNIX design doesn't take complexity away: it just hides it. It's still there but it becomes someone else's problem. Whereas the DEC way of doing things sort of puts the complexity right there in front of you, but in return, you got rich facilities right there. Much less need for Git when files are versioned and you can go back to an older version before you broke something just using info encoded into the filename. Much less need for NFS mounts when the filesystem knows about controllers and networking and clusters and lets you address them. Much less need for bolted-on fancy authentication when that's built into the OS because the designers thought about stuff like networks, clusters, and authentication, when all that got taken _out_ of UNIX and then had to be bolted back on later. So, yeah, the UNIX way is simpler, but OTOH that also means it's poorer. Poorer as in less rich. As in the DEC system was richer: being richer lets you do more. CP/M evolved into multitasking multiuser OSes in time, but DR didn't get to re-invent all this stuff. Maybe if DOS had never happened, DR would have prospered and bought DEC instead of Compaq buying DEC, and this stuff would have made it into PC OSes. Who knows...
Neil44 4y ago
To be fair I was thinking about the way MS-DOS solved problems that came along later like having lots more RAM and larger file systems. 640k, expanded memory, extended memory, file size limits. Things that I don't think CP/M was developed long enough to have to solve, so maybe it's not really fair to compare the two.
- Ekaros 4y ago
  It would have probably ended up in similar mess with some different trade-offs and design decisions. Not in anyway certain it would have been better.