4 ms·

There's a whole lot of current computing that is just hacked together on top of unscalable bad-in-retrospect ideas from the 70s and 80s. If I had a couple billi

There's a whole lot of current computing that is just hacked together on top of unscalable bad-in-retrospect ideas from the 70s and 80s. If I had a couple billion dollars I'd be interested in hiring a small group of very bright people to see what building a computing platform and infrastructure from scratch with no concern for compatibility with the current paradigm would look like.

TheBigSalad 4y ago
Honestly it would probably be just as bad, but in different ways.
- dexterdog 4y ago
  One way would be that it would not even exist in a usable state for at least 15 years. Then it would have the mastodon problem.
chasd00 4y ago
Isn’t that Plan9?
eru 4y ago
I'm not sure the situation is all that dire. Remember eg the battle of RISC vs CISC? These days we accept that a reduced instruction set is a better idea, but those bloated instruction sets barely take up any any space on the chip anymore compared to all the caching we do.
- AnIdiotOnTheNet 4y ago
  A couple examples of the kind of thing I'm talking about: Why is vsync still a thing? Originally it came from how broadcast TV worked with CRTs, but the fundamental technologies are different today. Yet, we still update the entire screen, all at once, on a fixed rate timer with blanking intervals[0]. I'm certainly not an expert in how LCDs work, but my understanding is that there is no fundamental reason we cannot update different parts of the screen at completely different rates or on-demand. We just don't do that, because the convention is a stream of pixel data from top left to bottom right. Or take process memory isolation and remapping. There's a lot of overhead there, and the whole thing looks like a solution to make a program think it has all the memory to itself and no other processes exist, and then we have to work around that specially to let them share it, and still have to add extra complication to deal with malicious jumps, and now timing attacks. What if there were a better way, so long as your programs didn't essentially act like they were running on a Commodore 64? What could something like Unicode look like if it had never had to deal with any kind of legacy nonsense, han unification, or the UCS2/UTF-16 debacle? Oh and if it didn't have such an obsession with emoji. Those are just off the top of my head. Undoubtedly my lack of expertise in these domains means I'm probably missing or misunderstanding some things, but I think there is practical value in occasionally re-examining all of our assumptions and starting from scratch. [0] Free/Gsync exists now, but we still update the entire screen.
  - dns_snek 4y ago
    Would updating smaller sections of the screen provide any tangible advantages over updating the entire screen?
- marcosdumay 4y ago
  RICS vs CISC was never about the size of the instruction set. It's about human usability vs. bare expressivity. The unusable, highly orthogonal, composable sets are more efficient than the usable, interdependent, all in one piece instructions. At least with our current compiler tech.
  - elygre 4y ago
    Yes, exactly. Not a reduced set of instructions, but a set of reduced instructions.
bell-cot 4y ago
If you only had mid-5-digit dollars to spend, I'm thinking that a well-thought-out ESMTP protocol enhancement, submitted RFC, and implementation in a few open-source email client and server software packages would be well within reach. Basic server-side implementation could mostly be done with existing-language scripts - "IF( Total_Message_Size > 50M ); THEN..."

TheBigSalad 4y ago

Honestly it would probably be just as bad, but in different ways.

dexterdog 4y ago
One way would be that it would not even exist in a usable state for at least 15 years. Then it would have the mastodon problem.

chasd00 4y ago

Isn’t that Plan9?

eru 4y ago

I'm not sure the situation is all that dire. Remember eg the battle of RISC vs CISC? These days we accept that a reduced instruction set is a better idea, but those bloated instruction sets barely take up any any space on the chip anymore compared to all the caching we do.

AnIdiotOnTheNet 4y ago
A couple examples of the kind of thing I'm talking about: Why is vsync still a thing? Originally it came from how broadcast TV worked with CRTs, but the fundamental technologies are different today. Yet, we still update the entire screen, all at once, on a fixed rate timer with blanking intervals[0]. I'm certainly not an expert in how LCDs work, but my understanding is that there is no fundamental reason we cannot update different parts of the screen at completely different rates or on-demand. We just don't do that, because the convention is a stream of pixel data from top left to bottom right. Or take process memory isolation and remapping. There's a lot of overhead there, and the whole thing looks like a solution to make a program think it has all the memory to itself and no other processes exist, and then we have to work around that specially to let them share it, and still have to add extra complication to deal with malicious jumps, and now timing attacks. What if there were a better way, so long as your programs didn't essentially act like they were running on a Commodore 64? What could something like Unicode look like if it had never had to deal with any kind of legacy nonsense, han unification, or the UCS2/UTF-16 debacle? Oh and if it didn't have such an obsession with emoji. Those are just off the top of my head. Undoubtedly my lack of expertise in these domains means I'm probably missing or misunderstanding some things, but I think there is practical value in occasionally re-examining all of our assumptions and starting from scratch. [0] Free/Gsync exists now, but we still update the entire screen.
- dns_snek 4y ago
  Would updating smaller sections of the screen provide any tangible advantages over updating the entire screen?
marcosdumay 4y ago
RICS vs CISC was never about the size of the instruction set. It's about human usability vs. bare expressivity. The unusable, highly orthogonal, composable sets are more efficient than the usable, interdependent, all in one piece instructions. At least with our current compiler tech.
- elygre 4y ago
  Yes, exactly. Not a reduced set of instructions, but a set of reduced instructions.

bell-cot 4y ago

If you only had mid-5-digit dollars to spend, I'm thinking that a well-thought-out ESMTP protocol enhancement, submitted RFC, and implementation in a few open-source email client and server software packages would be well within reach. Basic server-side implementation could mostly be done with existing-language scripts - "IF( Total_Message_Size > 50M ); THEN..."