6 ms·

That is far, far more than transferring a byte of data. It's not the future though of course, this was well established in the 80s, it just so happens that it's

That is far, far more than transferring a byte of data. It's not the future though of course, this was well established in the 80s, it just so happens that it's a decent model for managing remote machines that outlasted over-engineered distributed designs like Plan9, VMS, MOSIX, etc. It's much more meaningful and useful than "something simple" "running little functions floating in the void" which just sounds like some vapid marketing pitch. The great thing about Linux as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it.

verisimilitudes 4y ago
That is far, far more than transferring a byte of data. Educate me. It's much more meaningful and useful than "something simple" "running little functions floating in the void" which just sounds like some vapid marketing pitch. That was a quick response to what I thought would be better than administrating a UNIX system on an Amazon machine. Don't be an ass. I've no experience with the real distributed computing systems created before UNIX. The great thing about Linux as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. No, that's the vapid marketing pitch. The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. Hey, Brainfuck also facilitates more specialized layers to be implemented on top of it. Now, what's stupid about doing that, however?
- kortilla 4y ago
  > Educate me. You forgot an entire direction of input and focused on just a return code. > The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. No it doesn’t. It’s not random and it’s configurable. Turn off overcommit if you want malloc to fail when memory runs out.
- vanviegen 4y ago
  > The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. If you want to disable overallocation and the OOM killer, be my guest. You'll want to install some extra banks of RAM though. Or is there a better way, provided by other OSes?
  - gumby 4y ago
    Sure, you push the failure into the processes, and most OSes I've used do this. Thus (to use unix terminology) sbrk and fork() fail and it's the program's responsibility to handle that, gracefully or not as it wishes. You also degrade more slowly via paging. You shouldn't get to the point where a perfectly innocent process is killed to reclaim memory. A process can die, or even (in some cases) recover cleanly from running out of memory -- that should be the process's choice.
    - throwawaylinux 4y ago
      Which OSes have you used that do that? In Linux you can do that -- disable overcommit (although I'm not sure if that's 100% foolproof). But that's often not preferred because that way does lead to "perfectly innocent" processes being killed: whoever allocates the next page when memory has run out loses. And how do they get to decide? What if a failure path requires paging in one more page of code from disk? Or causes a store to a COW page?
- throwawaylinux 4y ago
  > Educate me. Not sure if I'm being trolled... It finds a remote machine by name, and routes a connection to it. It authenticates and establishes a secure connection with the machine. It sends a command to the remote machine, the remote machine executes it, and the result is returned. It then puts the result into a form that can be used programmatically by the local shell. > That was a quick response to what I thought would be better than administrating a UNIX system on an Amazon machine. It was content-free. > Don't be an ass. What's good for the goose... > I've no experience with the real distributed computing systems created before UNIX. And already the expert. Impressive. > No, that's the vapid marketing pitch. No, that's the reality. That's why Amazon, Google, Azure, and everybody else offer it in their clouds and use it on their internal infrastructure. > The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. I'll take that over "running little functions floating in the void", it actually exists and works.
  - verisimilitudes 4y ago
    I'm being trolled by someone who finds a DNS lookup and an encrypted TCP connection to send a textual command to another machine is somehow impressive, rather than entirely basic and, again, unimpressive. It then puts the result into a form that can be used programmatically by the local shell. That does sound better than returns one octet with two well-defined values, sure. And already the expert. Impressive. I know UNIX is shit with a legion of cultists. Hey, if we live in the best of all possible worlds, explain the market dominance of Windows. Did MicroSoft give Windows away for nothing, to poor unsuspecting university students who decided to hack on it instead of learn what a real computer is, until none remained?
    - throwawaylinux 4y ago
      You seem quite unhinged for a self-proclaimed expert. Maybe it's time for a break from the internet.
      - verisimilitudes 4y ago
        It's easy to support the status quo, until someone points out numerous issues with it, I know. At least read my website before calling me unhinged.
- bakugo 4y ago
  > No, that's the vapid marketing pitch. The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. You sound like someone who wants some sort of magical fantasy abstraction level where errors never happen and you can just write code without ever caring about said errors or really anything that happens at a lower level or outside of your code. Sorry, but that doesn't exist and never will. Code runs on computers, it doesn't run in a "void".
gumby 4y ago
> The great thing about Linux as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. The great thing about x86 instruction set as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. Only a handful of programmers develop at a layer below the x86 instruction set, or even at that level for that matter. We have to get our heads out of that mire.
- throwawaylinux 4y ago
  Poor analogy. You're welcome to address what I wrote directly if you'd like though.
  - gumby 4y ago
    It's quite an appropriate analogy. We used to write a lot of code in assembly code. I used to write microcode and even modified a CPU. But it's been decades since I last wrote microcode (much less modified an already installed CPU!) and now the instruction sets of MPUs like x86 and ARM are mostly just abstractions over a micromachine that few people think about. And an OS it the same: it used to be quite common to write for the bare iron, to which an OS is by definition an abstractional interface. I still do that, but it's an arcane skill frankly not in huge demand. Which is probably a good thing. Nowadays most code is written at nosebleed levels of abstraction, which frankly is a good thing, even if I don't like doing it myself. But still, as developers do it, they are often dragged back down the stack to a level that these days few understand. I think the person/company that cracks this will be the dominant infrastructure play of the decade.
    - nairboon 4y ago
      Are you advocating for more abstraction or less? As in a cloud without all the modern OS layers and cruft.
      - 4y ago

verisimilitudes 4y ago

That is far, far more than transferring a byte of data. Educate me. It's much more meaningful and useful than "something simple" "running little functions floating in the void" which just sounds like some vapid marketing pitch. That was a quick response to what I thought would be better than administrating a UNIX system on an Amazon machine. Don't be an ass. I've no experience with the real distributed computing systems created before UNIX. The great thing about Linux as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. No, that's the vapid marketing pitch. The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. Hey, Brainfuck also facilitates more specialized layers to be implemented on top of it. Now, what's stupid about doing that, however?

kortilla 4y ago
> Educate me. You forgot an entire direction of input and focused on just a return code. > The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. No it doesn’t. It’s not random and it’s configurable. Turn off overcommit if you want malloc to fail when memory runs out.
vanviegen 4y ago
> The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. If you want to disable overallocation and the OOM killer, be my guest. You'll want to install some extra banks of RAM though. Or is there a better way, provided by other OSes?
- gumby 4y ago
  Sure, you push the failure into the processes, and most OSes I've used do this. Thus (to use unix terminology) sbrk and fork() fail and it's the program's responsibility to handle that, gracefully or not as it wishes. You also degrade more slowly via paging. You shouldn't get to the point where a perfectly innocent process is killed to reclaim memory. A process can die, or even (in some cases) recover cleanly from running out of memory -- that should be the process's choice.
  - throwawaylinux 4y ago
    Which OSes have you used that do that? In Linux you can do that -- disable overcommit (although I'm not sure if that's 100% foolproof). But that's often not preferred because that way does lead to "perfectly innocent" processes being killed: whoever allocates the next page when memory has run out loses. And how do they get to decide? What if a failure path requires paging in one more page of code from disk? Or causes a store to a COW page?
throwawaylinux 4y ago
> Educate me. Not sure if I'm being trolled... It finds a remote machine by name, and routes a connection to it. It authenticates and establishes a secure connection with the machine. It sends a command to the remote machine, the remote machine executes it, and the result is returned. It then puts the result into a form that can be used programmatically by the local shell. > That was a quick response to what I thought would be better than administrating a UNIX system on an Amazon machine. It was content-free. > Don't be an ass. What's good for the goose... > I've no experience with the real distributed computing systems created before UNIX. And already the expert. Impressive. > No, that's the vapid marketing pitch. No, that's the reality. That's why Amazon, Google, Azure, and everybody else offer it in their clouds and use it on their internal infrastructure. > The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. I'll take that over "running little functions floating in the void", it actually exists and works.
- verisimilitudes 4y ago
  I'm being trolled by someone who finds a DNS lookup and an encrypted TCP connection to send a textual command to another machine is somehow impressive, rather than entirely basic and, again, unimpressive. It then puts the result into a form that can be used programmatically by the local shell. That does sound better than returns one octet with two well-defined values, sure. And already the expert. Impressive. I know UNIX is shit with a legion of cultists. Hey, if we live in the best of all possible worlds, explain the market dominance of Windows. Did MicroSoft give Windows away for nothing, to poor unsuspecting university students who decided to hack on it instead of learn what a real computer is, until none remained?
  - throwawaylinux 4y ago
    You seem quite unhinged for a self-proclaimed expert. Maybe it's time for a break from the internet.
    - verisimilitudes 4y ago
      It's easy to support the status quo, until someone points out numerous issues with it, I know. At least read my website before calling me unhinged.
bakugo 4y ago
> No, that's the vapid marketing pitch. The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. You sound like someone who wants some sort of magical fantasy abstraction level where errors never happen and you can just write code without ever caring about said errors or really anything that happens at a lower level or outside of your code. Sorry, but that doesn't exist and never will. Code runs on computers, it doesn't run in a "void".

gumby 4y ago

> The great thing about Linux as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. The great thing about x86 instruction set as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. Only a handful of programmers develop at a layer below the x86 instruction set, or even at that level for that matter. We have to get our heads out of that mire.

throwawaylinux 4y ago
Poor analogy. You're welcome to address what I wrote directly if you'd like though.
- gumby 4y ago
  It's quite an appropriate analogy. We used to write a lot of code in assembly code. I used to write microcode and even modified a CPU. But it's been decades since I last wrote microcode (much less modified an already installed CPU!) and now the instruction sets of MPUs like x86 and ARM are mostly just abstractions over a micromachine that few people think about. And an OS it the same: it used to be quite common to write for the bare iron, to which an OS is by definition an abstractional interface. I still do that, but it's an arcane skill frankly not in huge demand. Which is probably a good thing. Nowadays most code is written at nosebleed levels of abstraction, which frankly is a good thing, even if I don't like doing it myself. But still, as developers do it, they are often dragged back down the stack to a level that these days few understand. I think the person/company that cracks this will be the dominant infrastructure play of the decade.
  - nairboon 4y ago
    Are you advocating for more abstraction or less? As in a cloud without all the modern OS layers and cruft.
    - 4y ago