My only feedback is that this is unrealistic because today developers wouldn’t try to debug something, they’d just destroy the instance, push a commit and hope it fixed something infra related then recreate it. Why would you need to understand how something works? Just use containers. /s
Developers just need to understand everything because we need developers to do everything and meet all deadlines. We wouldn't dare consider a support role that could troubleshoot it because then there would be no point to having developers that can do everything! /s
Show HN: SadServers – Test your Linux troubleshooting skills
101–110 of 133 posts
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#102Re: Show HN: SadServers – Test your Linux troubleshooting skills
#103>Practice for your next SRE/DevOps interview. Are SREs and DevOps tasked with administration of operating systems?
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#104Re: Show HN: SadServers – Test your Linux troubleshooting skills
#105Earlier quoted context omitted.
I never cease to be amazed at how few people really realize just how little hardware is often required for getting real work done. You'd be surprised just how much that 2GB vm with a couple cores can handle!
I started with a single 1xx MHz core and 16MB of RAM. And I'm sure some with even less, lol. Supporting your point: Hardware is awesome if you use it wisely.
It's amazing how bloated today's software is...
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#106Earlier quoted context omitted.
Why not spin up containers instead of VMs? Seems to me containers would fit much better than VMs.
Containers have a history of escape vulnerabilities, for reasons like sharing a kernel with the host and other containers. VMs are designed from the ground up to isolate guests, rather than focusing on application deployment. Firecracker is the modern container alternative in untrusted compute scenarios, with Fly.io even converting container images into Firecracker VMs.
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#107Based on your architecture diagram it looks like you're spinning up an instance per-user? As you're probably finding now, you will hit AWS limits quickly. You might instead want to have a smaller pool of (larger) servers that you run co-resident VMs on with https://firecracker-microvm.github.io/ . That will avoid account limits and also keep your AWS costs more predictable.
That's kinda nice use case for the WASM machine/linux emulators, then you just need to provide image and user can run it in the browser > You might instead want to have a smaller pool of (larger) servers that you run co-resident VMs on with https://firecracker-microvm.github.io/ . That will avoid account limits and also keep your AWS costs more predictable. I'd imagine (still waiting for it to load lmao) most of it c…
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#108Earlier quoted context omitted.
This is actually a good idea for this -- the user wants the education, they can pay for it with their own hardware. Keep your costs low!
Probably a better experience for everyone. You just have to distribute the image (rather than running vms) and the user gets instantaneous responses.
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#109Earlier quoted context omitted.
Probably a better experience for everyone. You just have to distribute the image (rather than running vms) and the user gets instantaneous responses.
If it is hosted on AWS the bandwidth of distributing the images is likely more than the cost of the compute.
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#110Really cool idea. After choosing a problem, the endpoint you poll at https://sadservers.com/celery-progress/xxxx repeatedly returns {pending: true, current: 0, total: 100, percent: 0} for me.