4 ms·

I think everyone here remembers that time they wrote a simple HTTP server, that just works, and would continue to work today. If anything, I hope that we can r

I think everyone here remembers that time they wrote a simple HTTP server, that just works, and would continue to work today. If anything, I hope that we can recognize that there has been advancements in computing. Back in the day you would be open to attacks left and right. It was the wild west back in the day. Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in. As long as you didn't add the SSH key to github or anything like that. We can have complex programs, as long as every-man doesn't have to know the details behind it, or implement it or risk losing access he previously had. I think new protocols that are extremely hard to implement falls under that, and I don't think Qemu or Linux does, as nobody loses anything when Linux adds new complex features. We have to make sure, at least, that we continue to support HTTP/1. I think we already lost a lot when we moved away from IRC.

Animats 6y ago
FCGI controlling Go programs, maybe front-ended by a load balancer and back-ended by MySQL/MariaDB/Postgres, can get an awful lot of work done cheaply. FCGI is an automatic "orchestration system" - it starts up more instances as needed, restarts them if they crash, shuts them down when they go idle, and restarts them once in a while in case they leak some resource. It's like the parts of Kubernetes you really need. Go is an OK language. Not a great language, but an OK language. It comes with almost everything you need for server-side applications. Also, the "goroutine" model means you don't have to fool with threads vs async. If a goroutine blocks on a lock, no problem; the CPU gets redispatched. If you need a million goroutines, that works, too. None of that "oh, no, the async thread made a call that blocked and screwed up the whole system". MySQL/MariaDB/Postgres have been around for decades, and they work pretty well. You can have replication if you need it. (NoSQL seems to have come and gone.) Get the stuff at the bottom right, instead of piling more cruft on top. It's cheaper.
bfb09 6y ago
What if 'advancements' were anything but? How would we know whether we're advancing a nascent engineering discipline in the best way possible? Is public cloud, an optimization for a certain calculus of engineering resources, the optimal form of computing delivery? There's an underlying presumption about computing progress that has weaseled its way into your thinking, and the devil of it is that there are vanishingly few people willing to question it (can hardly blame them, given this thread).
- freshhawk 6y ago
  You seem unfamiliar with the mystical energy force that always ensures the direction of "progress" is always positive for everyone. It's very un-techy to not believe in this, you need to immediately forget enough social science subjects so you can get back to the purity of ignorance.
  - 0xdeadbeefbabe 6y ago
    That demo from 1968 ruins everything (https://www.youtube.com/watch?v=yJDv-zdhzMY https://www.youtube.com/watch?v=yJDv-zdhzMY), like the illusion of progress.
  - bfb09 6y ago
    You jest, but there is an actual argument somewhere in this dumpster fire arguing that philosophy cannot explain the overall direction of technology, as evidenced by a particular software's choice of license and the underlying assumption that technology is "different" from any other human endeavor. Nebulous philosophical arguments do explain things. Quite readily, actually.
  - castillar76 6y ago
    James Mickens' 'Technological Manifest Destiny', cited at UseNIX 2018, is a real thing. At the time, listening to it, it was easy to chuckle, but I've since had a lot of sobering conversations with people in which I realized partway through that they really believed these things, and that's frightening. Technological Manifest Destiny: 1. Technology is value neutral and will therefore automatically lead to great outcomes for everyone. 2. If we delay the rollout of new technology than we would delay the distribution of the inevitably great impacts for everyone. 3. History is generally uninteresting because the past has nothing to teach us right now. (https://www.zachpfeffer.com/single-post/2018/11/27/Transcript-of-James-Mickens-USENIX-Speech https://www.zachpfeffer.com/single-post/2018/11/27/Transcrip..., ca. 37 minutes in)
einpoklum 6y ago
> Back in the day you would be open to attacks left and right. If you wrote your simple HTTP server well, then not really. > you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in. 1. It might still matter. 2. The virtualized/containerized version could well have its own security issues. 3. The virtualized/containerized version is heavy and expensive (relatively). 4. Why did you move away from IRC? Come back... :-(
jedberg 6y ago
> Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in This is a dangerous viewpoint to hold. Containers do offer some slightly better security, but they are not a silver bullet or anything close. There are still lots of ways to cause problems whether the software is in a container or not.
- amarshall 6y ago
  >> a VM > Containers These are not the same thing, and have different security guarantees.
  - jedberg 6y ago
    Since the whole article is about containers, I assumed they were using VM as shorthand for a container.
    - amarshall 6y ago
      Since they also mention QEMU, I do believe they actually meant VMs.
- falcolas 6y ago
  Short of CVEs, which are fixed after identification, can you point out other ways to "cause problems" with a tiny webserver serving static content in a container?
  - jedberg 6y ago
    Well, there have been many container breakout CVEs, and I'm sure there will be more: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=container https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=container But let me ask the question another way. What security do you gain by being in a container instead of on a server without a container?
    - 6y ago
cbsmith 6y ago
Except you could totally break in to it and cut through the VM layer so that it does indeed matter if someone breaks in. Some of this is an illusion of simplicity.

Animats 6y ago

FCGI controlling Go programs, maybe front-ended by a load balancer and back-ended by MySQL/MariaDB/Postgres, can get an awful lot of work done cheaply. FCGI is an automatic "orchestration system" - it starts up more instances as needed, restarts them if they crash, shuts them down when they go idle, and restarts them once in a while in case they leak some resource. It's like the parts of Kubernetes you really need. Go is an OK language. Not a great language, but an OK language. It comes with almost everything you need for server-side applications. Also, the "goroutine" model means you don't have to fool with threads vs async. If a goroutine blocks on a lock, no problem; the CPU gets redispatched. If you need a million goroutines, that works, too. None of that "oh, no, the async thread made a call that blocked and screwed up the whole system". MySQL/MariaDB/Postgres have been around for decades, and they work pretty well. You can have replication if you need it. (NoSQL seems to have come and gone.) Get the stuff at the bottom right, instead of piling more cruft on top. It's cheaper.

bfb09 6y ago

What if 'advancements' were anything but? How would we know whether we're advancing a nascent engineering discipline in the best way possible? Is public cloud, an optimization for a certain calculus of engineering resources, the optimal form of computing delivery? There's an underlying presumption about computing progress that has weaseled its way into your thinking, and the devil of it is that there are vanishingly few people willing to question it (can hardly blame them, given this thread).

freshhawk 6y ago
You seem unfamiliar with the mystical energy force that always ensures the direction of "progress" is always positive for everyone. It's very un-techy to not believe in this, you need to immediately forget enough social science subjects so you can get back to the purity of ignorance.
- 0xdeadbeefbabe 6y ago
  That demo from 1968 ruins everything (https://www.youtube.com/watch?v=yJDv-zdhzMY https://www.youtube.com/watch?v=yJDv-zdhzMY), like the illusion of progress.
- bfb09 6y ago
  You jest, but there is an actual argument somewhere in this dumpster fire arguing that philosophy cannot explain the overall direction of technology, as evidenced by a particular software's choice of license and the underlying assumption that technology is "different" from any other human endeavor. Nebulous philosophical arguments do explain things. Quite readily, actually.
- castillar76 6y ago
  James Mickens' 'Technological Manifest Destiny', cited at UseNIX 2018, is a real thing. At the time, listening to it, it was easy to chuckle, but I've since had a lot of sobering conversations with people in which I realized partway through that they really believed these things, and that's frightening. Technological Manifest Destiny: 1. Technology is value neutral and will therefore automatically lead to great outcomes for everyone. 2. If we delay the rollout of new technology than we would delay the distribution of the inevitably great impacts for everyone. 3. History is generally uninteresting because the past has nothing to teach us right now. (https://www.zachpfeffer.com/single-post/2018/11/27/Transcript-of-James-Mickens-USENIX-Speech https://www.zachpfeffer.com/single-post/2018/11/27/Transcrip..., ca. 37 minutes in)

einpoklum 6y ago

> Back in the day you would be open to attacks left and right. If you wrote your simple HTTP server well, then not really. > you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in. 1. It might still matter. 2. The virtualized/containerized version could well have its own security issues. 3. The virtualized/containerized version is heavy and expensive (relatively). 4. Why did you move away from IRC? Come back... :-(

jedberg 6y ago

> Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in This is a dangerous viewpoint to hold. Containers do offer some slightly better security, but they are not a silver bullet or anything close. There are still lots of ways to cause problems whether the software is in a container or not.

amarshall 6y ago
>> a VM > Containers These are not the same thing, and have different security guarantees.
- jedberg 6y ago
  Since the whole article is about containers, I assumed they were using VM as shorthand for a container.
  - amarshall 6y ago
    Since they also mention QEMU, I do believe they actually meant VMs.
falcolas 6y ago
Short of CVEs, which are fixed after identification, can you point out other ways to "cause problems" with a tiny webserver serving static content in a container?
- jedberg 6y ago
  Well, there have been many container breakout CVEs, and I'm sure there will be more: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=container https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=container But let me ask the question another way. What security do you gain by being in a container instead of on a server without a container?
  - 6y ago

cbsmith 6y ago

Except you could totally break in to it and cut through the VM layer so that it does indeed matter if someone breaks in. Some of this is an illusion of simplicity.