I don't know why this is downvoted, it's probably the best advice on this page. Learning a few things about deployment definitely helps to make better software.
Well, he did cherry-pick one joking comment out of a well-intentioned post in order to say I have a bad attitude, so that's not exactly welcoming. And very patronizing, considering I have actually done that kind of work with Salt Stack a few years ago, and just don't want to bother with it at the moment because I have other priorities.
I learn new things every day, and one day, Docker was that thing. I am now better at release engineering, cool! But I also lost a day of working on shipping value to users and actually having fun, which is less cool. That's why PaaS has been helpful to certain kinds of people; it makes the curve of progressive disclosure necessary to deploy stuff a little flatter. My hope is that we can make more kinds of things really easy to do the right way, and not yell at people who just want to have some fun.
Sure, that comment came a bit rough. But I'm not even sure it was triggered by the Docker comment, rather than the developer/release engineer opposition. At least that's how I see it. And maybe I just don't see the added value of PaaS because I've been spinning up public web servers for too long now ;-)
Yeah, that's fair, and it was bad phrasing on my part. The engineer type distinctions are completely imaginary. It just really threw me off to have people respond to me sharing something I thought was helpful with claims that I'm somehow opposed to learning, when this project is nothing but learning.
I do think people who have experience deploying software have a blind spot here, just like I have a blind spot for people who have never learned how to center a div. jUsT uSe FlExBoX
Hey there, I've never deployed anything but will be going to in the (very) near future. I'm self-taught and really haven't fooled around with servers, ever. So instead of just going down the PaaS way I was hoping to kind of turn my computer/raspberry pie into a server as a fun learning project.
Any cool, beginner friendly resources you can share? Many thanks
Agreed. Too much reliance on AWS, Heroku etc. can leave you without vital Linux skills. Linux cli tools are not just for getting a job done, though they're great at what they do. No, they're part of the *nix culture which is what open source software is based on. Only recently have I become aware that it was better to have entered software development in or before the early 2000s, ie. before The Cloud took off. You were forced to learn Linux/BSD cli tools just to swim in the water. I can't imagine, back then, knowing Perl and not knowing Linux or FreeBSD.
I used slackware linux. I wrote assembly code when I was a teenager. I use 'perl -i -pe' constantly. I still don't want to learn a bunch of arcane flags from a bunch of tools with a million gotchas. Sorry. I'd rather focus on the code craft that gives me joy these days.
Sorry, I detest this attitude of: "Well I was hazed so why aren't you hazed too?"
Did I mention that Russ Cox and I used to write C code with pen and paper? https://news.ycombinator.com/item?id=32874759 If you haven't, are you even qualified to discuss what vital skills others are missing?
Or maybe because I learned perl because it was simpler than tr and awk, I should STFU? Give me a break.
> I used slackware linux. I wrote assembly code when I was a teenager.
Lol are you me?
I grew up with Slack/assembler/softice/etc and I used to host everything on Slack boxes on Linode (bless them for having a pre-built image). But I left it a while ago because I got sick of dealing with hand upgrades and compiling everything from scratch. I feel the same way about other things. I could probably out-CLI most of the people here saying "you should learn linux!" but sometimes I just need to get something done.
If I'm trying to get something out the door, I don't give a rat's ass about the details. It's fun and interesting when you're a teenager and it's 4am on a summer night and you've got nothing better to do, but these days I have strict time, limited energy, and I'm not going to spend more time fiddling with things than I need to.
I mean, you can just put it into automation and never have to repeat same linux cmdline dance to do the same thing again. There are plenty of configuration management tools to do so. Hell, I outright forgot some skills because I encoded whatever I will ever need from a given tool in Puppet manifest and didn't had a need to touch the internals again.
Docker, k8s and friends are essentially just level above the "just CM", still just use basic linux primitives but with some coordination.
The "new toys" are essentially abstractions on what sysadmin would do (anyone remember building chroots ? Yeah I don't liked it either, even if it felt "cool" the first time I did it) and every abstraction will leak which means once you are big and complex enough you will need to debug it. Just that random hobby project probably won't get there and even for work it probably might be someone's else job to debug that
> I should STFU? Give me a break
...you probably should, your whining and bragging doesn't add anything to discussion. "Oh I played with cool kids few decades ago, look at me Mr. Important"
I didn't spend six years on a PhD to be called Mr. Important.
I'm joking.
Okay, bringing this conversation back to a normal tone: I have specific needs and want to get specific things done. I agree everyone should learn basic unix. I also think people should get as low to the metal as possible so they understand performance.
But can you acknowledge that there is a near infinite number of things people should learn, and that the priority of that list might be different for other people? That for some, and their technical goals, they might not have the time to prioritize multi-server web app dev when they're focusing on figuring out how to get GPUs to do DDP correctly? I never learned k8s because I all my web apps have super low usage. e.g. data annotation frameworks. I don't know JS and I guess maybe I'd love to, but I'd also like to wait until the field stops moving so correctly so that I could just pick a great framework and not have to relearn everything constantly. HTMX is cool and gives me joy.
Can you acknowledge that building tooling that allow devs to focus on what gives them joy is actually a nice thing? We have enough problems in the work we like that we end up spending endless hours debugging. If someone refuses to learn what they need to solve their main technical pursuits, yeah that's a moral failing, but nonetheless there's a finite surface area we can cover and I prefer to focus on learning the things that come up in the line of duty.
p.s. what are you working on? Maybe we can play together. I am not being snarky. I'm collaborative and maybe you're cool too. :)
>I don't know JS and I guess maybe I'd love to, but I'd also like to wait until the field stops moving so correctly so that I could just pick a great framework and not have to relearn everything constantly.
/js rant start
I think when that happens it won't be because JS stopped moving, it will be because people will just go "fuck it" and replace it wholly with <favourite language> + WASM.
At least that's how I managed how to not learn JS properly for years. Web frontend work is just drudgery, and I only did it few times when we decided trying to explain a frontend developer ops stuff to make admin page out of is more complex that stitching some shitty code together.
And every single time it was miserable experience and I think only thing that I made and is still in supported framework is fucking jQuery, because every other one seems to shit on backward compatibility and decide to just make new framework. Then call it same name but just increase the number after the name.
/js rant end
> Can you acknowledge that building tooling that allow devs to focus on what gives them joy is actually a nice thing?
I did just say that yes we have those tools and it is fine that dev might not care about internals, I just want to highlight that the whole "I don't care what's underneath as long as it works" might eventually bite, so doing the boring part of understanding something about underlying system might save a lot of effort going forward.
Especially if that bit extra effort allows for overall simpler architecture, as easier debugging usually comes with it. "Just look in logs" or see what process is doing in system directly using installed tools is infinitely easier than fucking with docker/k8s CLI, sidecars and other methods to observe the app in container.
Recent example: A bunch of devs in company we provide infrastructure for got starry eyed for k8s and we just recently had to re-explain that no, the "just give us big POSIX filesystem mounted everywhere" on dozens of nodes isn't gonna work well, and the fact you can tell k8s "give me storage with ReadWriteMany" won't just work. That was after they tried to make shared block device and run XFS on it, which fell apart for obvious reasons
That after same company had year+ long migration from "a big GFS2 volume that was slow as fuck because GFS2 is slow as fuck when you have dozens of nodes for it" to plain S3.
One meeting later and they figured out they don't even need shared storage in the first place, but nobody researched that before and their solution "worked" on test 1 node k8s cluster (for obvious reasons). While a bit of research would have saved the whole ordeal
So less communicative company might just go "right on, we will set up CephFS for you and go ahead" then get more maintenance and the inevitable "this clustered filesystem doesn't work EXACTLY like my XFS partition on ubuntu" problems. It would probably be better for billable hours tho...
More low-scale example: My VPS just have few systemd services for few apps I put there. unattended-upgrades and it is near-zero maintenance for years. Granted, I knew how to do it because that's my day job but I have 100x less complex setup on my VPS. Maybe I should write blog about it...
> p.s. what are you working on? Maybe we can play together. I am not being snarky. I'm collaborative and maybe you're cool too. :)
Well, pandemic/nearby war kinda fucked up every project I started
I was working on midi2sid chip eurorack module. Which was delayed for year+ just waiting to get parts. I think they might be available again, maybe I should resurrect it. It did ran in rust and actually played notes, I just ran out of pins on the MCU I used so I had nice big board with bigger MCU and some niceties added, made it ready to be assembled... right as the chipaggedon started.
I was also working on car datalogger, even got prototype working, except recent economic fuckery put any track days on hold. The plan was to finally get a house, the inflation put any sensible mortgage out of question for at least nearby future so all the fun money are going to the savings now.
The other plan was to replace car's radio with something newer and integrate that with it (via dumb "just send rPi HDMI image thru the infotainment screen" probably), but yeah, can't really do that without garage in the first place...
I experimented with home automation a bit and had some ideas (involving embedded Rust, it is surprisingly palatable) but, well, again, the plans involved having a home, and not really that much possible to do in rented apartment
In meantime like 30 projects that scratch itch nobody else but me have and were not touched after scratching part started to work fine.
I did decide to implement the CPU from The Art of Computer Programming. But it looked annoyingly weird so I just made Go Z80 "emulator". Then rewrote it in Rust as exercise (both in ImGui as frontend). Then realized that getting the other chips than Z80 "right" is a ton of work and.... not that fun work to boot so I called it learning experience for Rust and ImGui and left it alone. It did run enough assembly to do something tho. No longer runs after Rust version upgrade tho. So much for backward compat...
But currently nothing really interesting. I have those cycles, where if work is interesting I spend a most of free time in brainless/semi-brainless fun bracket, and if work is boring I do the interesting hobby stuff, and, well, recent company buyout and some other changes made sure I'm having all the "fun" at work I can take so I haven't been touching hobbies much.
