4 ms·

I'd be curious to know what some of "missing" concepts were. Obviously they turned out not to be necessary. > Many familiar computing ‘concepts’ are missing fr

I'd be curious to know what some of "missing" concepts were. Obviously they turned out not to be necessary. > Many familiar computing ‘concepts’ are missing from UNIX. Files have no records. There are no access methods. User programs contain no system buffers. There are no file types.

jcelerier 6y ago
> Obviously they turned out not to be necessary. why would you believe that ? maybe computing would be 10x less painful today than it is if these missing concepts had been implemented. Or maybe 10x more.
- kps 6y ago
  There exist people who have used both.
  - taffer 6y ago
    And these people were not always happy[1] with the way things are in UNIX. An example of something missing from UNIX is a service or job subsystem, which is why SMF, launchd and systemd were invented. [1] https://web.mit.edu/~simsong/www/ugh.pdf https://web.mit.edu/~simsong/www/ugh.pdf
    - generalizations 6y ago
      And it seems that a lot of people aren't happy with it, either.
ryl00 6y ago
Probably referring to examples like VAX/VMS filesystems? I never worked on them much, and only very shallowly. Fortran file I/O has vestiges of record-oriented interfaces still in the standard, I'm assuming from co-evolution with file systems of the time.
rst 6y ago
Well, you've quoted a sentence that rattles off several of them. In prior operating systems, files were structured objects, often readable and writeable only in collections of fixed-length records; they often had attributes including a "type" (Windows file name extensions are a vestige of this), and had I/O APIs requiring a particular memory layout in program memory for data to be read or written. There were also, in some cases, files that could be accessed only through limited forms of database query ("access methods" -- see, e.g., ISAM for Indexed Sequential Access Method), and not as raw byte streams, or streams of records. Current mainframe programming environments retain a lot of this structure. Here's a writeup by someone trained on more Unix-derived environments who was self-teaching on the '60s legacy stuff: https://medium.com/the-technical-archaeologist/hello-world-on-z-os-a0ef31c1e87f https://medium.com/the-technical-archaeologist/hello-world-o...
indymike 6y ago
One of the more interesting parts of Unix is that there was not a system level way to have records. This was especially wierd given other systems in use at the time spent a lot of time dealing with this exact issue. Just the other day there was a discussion here on HN about file system APIs, and many of the comments were about this peculiarity of Unix: why isn't there one true way to store stuff that is smaller than a file? The answer is probably, well, different uses of data require different things smaller than a file. There isn't really one true way at that point. Also, storage media changes a lot over time. Coming to Unix from another (larger than a PC) OS was strange because it felt so stripped-down, yet capable, largely because of the extreme power the shell gave you to concatenate functionality. I've never read this particular document, an it does really explain this capability well.
lisper 6y ago
> Obviously they turned out not to be necessary. That is not at all obvious. There's a reason SQL is a thing. There's a reason that file name extensions are ubiquitous. There's a reason that security is a hot mess. It turns out that you really do need all these things, and if you don't provide them in the OS, then they will need to be provided at the user level.
hedora 6y ago
Microsoft Power Shell reintroduced records (in pipelines, not files), for what it’s worth. I think the big problem with records is that it opens a huge can of worms. How should we represent dates? Binary data? The type of a binary file? Mime types? All the answers to these questions should be designed to age gracefully over the next half century or so.

jcelerier 6y ago

> Obviously they turned out not to be necessary. why would you believe that ? maybe computing would be 10x less painful today than it is if these missing concepts had been implemented. Or maybe 10x more.

kps 6y ago
There exist people who have used both.
- taffer 6y ago
  And these people were not always happy[1] with the way things are in UNIX. An example of something missing from UNIX is a service or job subsystem, which is why SMF, launchd and systemd were invented. [1] https://web.mit.edu/~simsong/www/ugh.pdf https://web.mit.edu/~simsong/www/ugh.pdf
  - generalizations 6y ago
    And it seems that a lot of people aren't happy with it, either.

ryl00 6y ago

Probably referring to examples like VAX/VMS filesystems? I never worked on them much, and only very shallowly. Fortran file I/O has vestiges of record-oriented interfaces still in the standard, I'm assuming from co-evolution with file systems of the time.

rst 6y ago

Well, you've quoted a sentence that rattles off several of them. In prior operating systems, files were structured objects, often readable and writeable only in collections of fixed-length records; they often had attributes including a "type" (Windows file name extensions are a vestige of this), and had I/O APIs requiring a particular memory layout in program memory for data to be read or written. There were also, in some cases, files that could be accessed only through limited forms of database query ("access methods" -- see, e.g., ISAM for Indexed Sequential Access Method), and not as raw byte streams, or streams of records. Current mainframe programming environments retain a lot of this structure. Here's a writeup by someone trained on more Unix-derived environments who was self-teaching on the '60s legacy stuff: https://medium.com/the-technical-archaeologist/hello-world-on-z-os-a0ef31c1e87f https://medium.com/the-technical-archaeologist/hello-world-o...

indymike 6y ago

One of the more interesting parts of Unix is that there was not a system level way to have records. This was especially wierd given other systems in use at the time spent a lot of time dealing with this exact issue. Just the other day there was a discussion here on HN about file system APIs, and many of the comments were about this peculiarity of Unix: why isn't there one true way to store stuff that is smaller than a file? The answer is probably, well, different uses of data require different things smaller than a file. There isn't really one true way at that point. Also, storage media changes a lot over time. Coming to Unix from another (larger than a PC) OS was strange because it felt so stripped-down, yet capable, largely because of the extreme power the shell gave you to concatenate functionality. I've never read this particular document, an it does really explain this capability well.

lisper 6y ago

> Obviously they turned out not to be necessary. That is not at all obvious. There's a reason SQL is a thing. There's a reason that file name extensions are ubiquitous. There's a reason that security is a hot mess. It turns out that you really do need all these things, and if you don't provide them in the OS, then they will need to be provided at the user level.

hedora 6y ago

Microsoft Power Shell reintroduced records (in pipelines, not files), for what it’s worth. I think the big problem with records is that it opens a huge can of worms. How should we represent dates? Binary data? The type of a binary file? Mime types? All the answers to these questions should be designed to age gracefully over the next half century or so.