4 ms·

The software at that time was just much smaller. The size of most projects, anything above a toy program is in megabytes and will be impossible to "write down

The software at that time was just much smaller. The size of most projects, anything above a toy program is in megabytes and will be impossible to "write down" as single file.

tgv 3y ago
OTOH, there were practically no examples to draw from. There was no virtual memory class in their OS-101 course. These people pioneered OS design.
- adrianN 3y ago
  I often find it easier not to introduce bugs while I pioneer something than when I integrate with a mountain of existing stuff.
  - subtra3t 3y ago
    Of course, since then you can label bugs as unintended features :)
  - Ringz 3y ago
    The current JavaScript dilemma.
LAC-Tech 3y ago
I'm sorry but the line of business software most of us work on is not more impressive than writing a major component of a file system from scratch.
kragen 3y ago
i was surprised to find that my natural-language notes from my electronics notebook from the last month total a quarter megabyte already. about 37000 words of markdown a small fraction of that is urls for electronic parts, but nearly all (90%, say) is just english text. another 10% is stuff i quoted from other people (web pages, manufacturer app notes, books, etc.) it is a single file and will probably continue to be a single file forever, at least for the rest of the year. if i continue at the same pace, that will be 12 megabytes. there is nothing impossible about that at all (if you're interested, git clone http://canonical.org/~kragen/sw/leatherdrink.git http://canonical.org/~kragen/sw/leatherdrink.git. it's currently almost 200 megs because i checked in the avr toolchain. there are also photos and videos and schematics and stuff) in a programming language the growth would be fewer bytes per month, but perhaps by a factor of five
coldtea 3y ago
>The software at that time was just much smaller. Do go check the code: https://multicians.org/vtoc_man.html https://multicians.org/vtoc_man.html This is both bigger and more complex than most stuff people work on today (which is glorified glue code for bullshit CRUD/REST/etc). It might be smaller than the overall LoC of their project, but it's more than the units they deal with (and this is part of an overal OS code anyway). This is a whole "manager, to manage file description information. It had to transport the file information between disk and memory, manage a shared memory buffer pool, and manage space on disk for the information." Dare most current programmers to write such a thing, with the requirements and semantics it has on his version, today, in their language of choice. Most would be lost at even contemplating that. Much less write it in paper and type it in and have it work.

The software at that time was just much smaller. The size of most projects, anything above a toy program is in megabytes and will be impossible to "write down" as single file.

tgv 3y ago

OTOH, there were practically no examples to draw from. There was no virtual memory class in their OS-101 course. These people pioneered OS design.

adrianN 3y ago
I often find it easier not to introduce bugs while I pioneer something than when I integrate with a mountain of existing stuff.
- subtra3t 3y ago
  Of course, since then you can label bugs as unintended features :)
- Ringz 3y ago
  The current JavaScript dilemma.

LAC-Tech 3y ago

I'm sorry but the line of business software most of us work on is not more impressive than writing a major component of a file system from scratch.

kragen 3y ago

i was surprised to find that my natural-language notes from my electronics notebook from the last month total a quarter megabyte already. about 37000 words of markdown a small fraction of that is urls for electronic parts, but nearly all (90%, say) is just english text. another 10% is stuff i quoted from other people (web pages, manufacturer app notes, books, etc.) it is a single file and will probably continue to be a single file forever, at least for the rest of the year. if i continue at the same pace, that will be 12 megabytes. there is nothing impossible about that at all (if you're interested, git clone http://canonical.org/~kragen/sw/leatherdrink.git http://canonical.org/~kragen/sw/leatherdrink.git. it's currently almost 200 megs because i checked in the avr toolchain. there are also photos and videos and schematics and stuff) in a programming language the growth would be fewer bytes per month, but perhaps by a factor of five

coldtea 3y ago

>The software at that time was just much smaller. Do go check the code: https://multicians.org/vtoc_man.html https://multicians.org/vtoc_man.html This is both bigger and more complex than most stuff people work on today (which is glorified glue code for bullshit CRUD/REST/etc). It might be smaller than the overall LoC of their project, but it's more than the units they deal with (and this is part of an overal OS code anyway). This is a whole "manager, to manage file description information. It had to transport the file information between disk and memory, manage a shared memory buffer pool, and manage space on disk for the information." Dare most current programmers to write such a thing, with the requirements and semantics it has on his version, today, in their language of choice. Most would be lost at even contemplating that. Much less write it in paper and type it in and have it work.