5 ms·

It's disappointing that most of the computers I use are running an OS that lacks several highly beneficial features because they would have taken up too much me

It's disappointing that most of the computers I use are running an OS that lacks several highly beneficial features because they would have taken up too much memory on a PDP-7 in 1970. Consider: a kernel and userspace written in a more memory-safe language (Multics was written in PL/I and had essentially zero buffer overflows); ring security; long/human-readable command names in addition to terse abbreviations; multiple entry points for programs; etc.. See also: https://multicians.org/myths.html https://multicians.org/myths.html

aflag 4y ago
Goes to show how being easy to understand and change is important for a project's success
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
pjmlp 4y ago
Given the hardware used for JOVIAL in 1958, or Burroughs B5000 with ESPOL/NEWP in 1961, making C safer would have been doable. Even if not, by the time we reached 1980, with the pleothara from PL/I dialects, BLISS, Modula-2, Mesa, Object Pascal,..., it was more than possible to fix C. Or 50 years later, where WG14 keeps ignoring the issue related to bounds checking aware types and fat pointers.
- hashar 4y ago
  Slightly related is C language using null terminated strings which is the source of buffer overflows. From what I remember the assembly languages of whatever platform they were using relied on NUL, an alternative was to use a leading single byte to set the length of the string, so "hello_world" which is 11 bytes would be: 0x0A h e l l o _ w o r l d But that limited the length of strings to 255 characters and using two bytes rather than one would add memory pressure. Dennis Ritchie then went with null terminated strings which has the advantage of allowing any size of strings and is consistent with the assembly they were used with. The drawbacks is decades of buffer overflows :) Eventually I found an abstract on https://en.wikipedia.org/wiki/Null-terminated_string#History https://en.wikipedia.org/wiki/Null-terminated_string#History and there is a 2011 paper about it: Communications of the ACM - Volume 54 - Issue 901 - September 2011 - pp 42–44 - https://doi.org/10.1145/1995376.1995391 https://doi.org/10.1145/1995376.1995391 . Direct link to the PDF https://dl.acm.org/doi/pdf/10.1145/1995376.1995391 https://dl.acm.org/doi/pdf/10.1145/1995376.1995391
  - pjmlp 4y ago
    Safer systems programming languages relied on character arrays for lengths greather than 255, as a kind of good enough compromise, since most use cases could fit in 255, and with the help of string libraries it wasn't much of a pain to deal with character arrays instead of strings. Eventually fat pointers were used instead. Which even Denis himself proposed for WG14 during the C89 standardization, and wasn't accepted. https://www.bell-labs.com/usr/dmr/www/vararray.pdf https://www.bell-labs.com/usr/dmr/www/vararray.pdf
- deleted 4y ago
  [deleted]
trasz4 4y ago
They didn't take too much memory, they mostly were just a bad ideas. "Ring security" doesn't really do anything; long command names are unwieldy and counterproductive (see PowerShell) etc; memory-safe languages have always been there in UNIX. And it's not like C can't be memory-safe, as shown by CHERI/Morello (shameless plug). It depends on hardware.
- 0x445442 4y ago
  > long command names are unwieldy and counterproductive (see PowerShell) Going to have to disagree here. PowerShell reminds me of Lisp Machines/Emacs in this regard. As long as the shell supports completions this isn't an issue and aids in habituation and discover-ability IMHO.
  - MisterTea 4y ago
    devils advocate: command completion is bloat. discoverability papers over poor documentation. All of this enforces the bad habit of expecting the software to hold your hand everywhere.
  - icedchai 4y ago
    I like PowerShell conceptually - basically, manipulating structured objects instead of unstructured text - but the commands themselves always feel overly verbose/awkward. Maybe it's just me.

aflag 4y ago

Goes to show how being easy to understand and change is important for a project's success

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]

pjmlp 4y ago

Given the hardware used for JOVIAL in 1958, or Burroughs B5000 with ESPOL/NEWP in 1961, making C safer would have been doable. Even if not, by the time we reached 1980, with the pleothara from PL/I dialects, BLISS, Modula-2, Mesa, Object Pascal,..., it was more than possible to fix C. Or 50 years later, where WG14 keeps ignoring the issue related to bounds checking aware types and fat pointers.

hashar 4y ago
Slightly related is C language using null terminated strings which is the source of buffer overflows. From what I remember the assembly languages of whatever platform they were using relied on NUL, an alternative was to use a leading single byte to set the length of the string, so "hello_world" which is 11 bytes would be: 0x0A h e l l o _ w o r l d But that limited the length of strings to 255 characters and using two bytes rather than one would add memory pressure. Dennis Ritchie then went with null terminated strings which has the advantage of allowing any size of strings and is consistent with the assembly they were used with. The drawbacks is decades of buffer overflows :) Eventually I found an abstract on https://en.wikipedia.org/wiki/Null-terminated_string#History https://en.wikipedia.org/wiki/Null-terminated_string#History and there is a 2011 paper about it: Communications of the ACM - Volume 54 - Issue 901 - September 2011 - pp 42–44 - https://doi.org/10.1145/1995376.1995391 https://doi.org/10.1145/1995376.1995391 . Direct link to the PDF https://dl.acm.org/doi/pdf/10.1145/1995376.1995391 https://dl.acm.org/doi/pdf/10.1145/1995376.1995391
- pjmlp 4y ago
  Safer systems programming languages relied on character arrays for lengths greather than 255, as a kind of good enough compromise, since most use cases could fit in 255, and with the help of string libraries it wasn't much of a pain to deal with character arrays instead of strings. Eventually fat pointers were used instead. Which even Denis himself proposed for WG14 during the C89 standardization, and wasn't accepted. https://www.bell-labs.com/usr/dmr/www/vararray.pdf https://www.bell-labs.com/usr/dmr/www/vararray.pdf
deleted 4y ago
[deleted]

trasz4 4y ago

They didn't take too much memory, they mostly were just a bad ideas. "Ring security" doesn't really do anything; long command names are unwieldy and counterproductive (see PowerShell) etc; memory-safe languages have always been there in UNIX. And it's not like C can't be memory-safe, as shown by CHERI/Morello (shameless plug). It depends on hardware.

0x445442 4y ago
> long command names are unwieldy and counterproductive (see PowerShell) Going to have to disagree here. PowerShell reminds me of Lisp Machines/Emacs in this regard. As long as the shell supports completions this isn't an issue and aids in habituation and discover-ability IMHO.
- MisterTea 4y ago
  devils advocate: command completion is bloat. discoverability papers over poor documentation. All of this enforces the bad habit of expecting the software to hold your hand everywhere.
- icedchai 4y ago
  I like PowerShell conceptually - basically, manipulating structured objects instead of unstructured text - but the commands themselves always feel overly verbose/awkward. Maybe it's just me.