Hacker Newsnew | past | comments | ask | show | jobs | submit | linuxorbust's commentslogin

I've worked for exactly one startup on a devops team of three. The coders next door to us were mostly fresh out of university and most of them thought they were the cat's pajamas. They worked for a fairly crusty former military cyber dude who had likely forgotten more about programming then they would ever know. Military dude told us that code checks were an eye-opener for these guys. There's boot camps, university, and then the real world. The real world is often not what these kids think it is. Same kids were shocked when I told them the company ran the back end on Bash and Python. They were incredulous we weren't using Golang, Haskell, or some other flavor-of-the-month language. I told them to go ask what runs their bank. None of them had the faintest idea it was COBOL. The one COBOL programmer I know is in his 60s, already retired and comes out as needed for the princely sum of $200/hour every couple of months for contract work. Beer money as he calls it. Guy retired a millionaire from COBOL but you'd never know it looking at his modest house and hatchback car.


I don't get the modern (?) obsession with having the latest tech in your resume.

Knowing how to solve problems for someone willing to pay you a lot for it seems to trump knowing how to solve problems in a specific way. I've improved my salary more by putting work towards fixing things for existing code bases than I have by building brand new things on brand new technology.

With that said... having been in the position of the hot-headed junior engineer full of ideas, I don't think that position's without merit either. The trick is to balance new ideas for the employer, personal knowledge growth, improved performance for the employer, and making the right kind of mistakes.

In that latter bit, I don't think _anyone_ has figured it out, yet. Not in a way that's easily repeatable, anyway.


Not a programmer, but a sysadmin/devops. Once had an interview at about my 15-year mark as a Linux/Unix admin working for some household names. Punk kid interviewer asks me if I know how to add a user to a Linux server via command line and, if so, please take the marker and write the command on the whiteboard. Same kid asked me why I would choose Bash over the far superior zsh and other nonsense. Kid didn't, likely still doesn't, understand that methods don't often matter, results do. Needless to say, I didn't want the job working with people like him. I found a better job working for a government contractor doing more interesting stuff working for people who just wanted results, methods not even a consideration.


I'm a senior sysadmin/devops guy. I'm not a programmer per se, but I can and do write a fair amount of code, usually Bash, Python, some PowerShell. I had an interview not terribly long ago whereby the interviewer was asking me as a sysadmin if I could write and compile programs in C++, Python, and a few other languages. I told him that my role historically didn't include these things. I told him I write code to primarily automate things. He asked if I could write programs from scratch--systems stuff and turn out MSIs. I told him no. End of interview. I've never stated I'm a programmer, it doesn't appear on my resume as anything other than scripting for automation or writing small tools to do something weird or odd that the built-in tools cannot do. Anymore, it seems that companies want people to be able to do everything. Same guy asked me about how good I was at setting up a router and switches from scratch. Networking is voodoo. It always has been. Sysadmins typically are not networking guys. Networks need to be run by dedicated network admins. It's a full time job in and of itself. I miss the late 90s and early 2000s when things were more clear cut in terms of roles. Editing to say that so many people in "leadership" positions don't understand the nature of scripting. They conflate it with systems programming. The two are vastly different. I was taught in college to keep scripts as small as possible. This has been echoed by mentors over the years. One mentor who was a veritable scripting rock star who now works at Google told me that if it's over a couple of hundred lines, it needs to be in a systems language, even things like Python. Compiled programs, of course, always run faster. But that's not my world. I live and breathe making servers run, tuning, etc.


It does get used, though. There are some very intractable issues with modern software implementations, especially with OpenShift container storage. Unless you've worked with it tons, it's not exactly something a first-year sysadmin can solve. Personally, I tend towards Debian for infrastructure because while I have experience with RHEL, I prefer the Debian layout, package management, and freely-available help from very knowledgeable people. Not saying that RHEL are pillars of intransigence, they're not, but I've found it easier to solve my own issues. As an almost 3-decade senior sysadmin/devops guy, I know where to go and who to speak with if I run into something really odd. Fortunately, that's rare. Once you've used Linux from a sysadmin POV for a few years, things begin to make sense from a file system, maintenance, and overall "keeping everything alive" approach. I was mentored back in the 90s by a Debian guru at our local LUG. He's since passed into eternity, but much of what he taught me and others still applies. The beauty of POSIX systems. Now... when systemd got released, I didn't know what to make of it, but now after many years, I've gotten used to it. I still prefer the old BSD-style init files and non-binary approach, but what to do with modernity? It will pass you by if you don't embrace it.


Stability. The kernels contain tons of backported goodies and bug fixes. RHEL users dislike change. We use Debian where I work, and it's stable, but not as stable as RHEL. When it absolutely needs to be rock solid, RHEL. I've used Red Hat since 1998. Fedora for personal use. You'll find some people using Debian Stable for some important things, but with Red Hat paid support, you can get help with seriously intractable problems. With Debian, there is no paid support except for third parties. Loads of corporations like having a throat to choke when the SHTF. Forgot to mention that tons of hosting companies using Red Hat/CentOS/variations of RHEL use cPanel. It doesn't run on anything else.


mid-skill level admin here, mostly linux. I put up a Debian server on racked hardware for a consulting client, did almost nothing else but check on it from time to time.. uptime was past 800 days when I took it down (?) .. not one reboot. I updated the openssl and related, that was about it. AMD64


3 years of uptime might sound impressive, but this means you keep running the same kernel, and towards the end of that streak, that kernel is pretty much guaranteed to have a widely-known local privilege escalation vulnerability.


you sound smart and are probably technically correct, but the reality is, what replaced this setup was ephemeral VMs with outsourced India contractors.. there was spam coming from their setup within weeks of the transition.. Admin as in, I share my root password with the crew of contractors in my small company .. like that..


The very reason I will never work for a shop that outsources anything. Especially fintech stuff. You just never know who is going to have access. RBAC is huge where I work.


It would be interesting to see what percentage of meaningful security vulnerabilities couldn't be fixed via live patch. Of course that does require that you invest the significant effort required to get live patching to work, but it is possible.


I only recently learned to use RHEL (did the RHCSA) and from before I've used debian and Slackware. RHEL is really polished, more so than the competition. I asked around why more people aren't using RHEL in Scandinavia, and the reply I got was that it was mostly cultural.

In Europe it's Debian or SUSE, and in the states it's RHEL. I don't have a preference (but Slackware is awesome).


Years ago for kicks me and a few friends did the Gentoo thing starting at Stage 1 tarballs. Took my then Toshiba Satellite 12 hours to bootstrap. When I got it all up and running, it looked like anything else. I was happy for the experience, but even with all the tweaks for my specific chipsets, RAM, etc., it was no better than Red Hat or Slackware.


There’s a clear trend of migrating from SUSE to RHEL in Sweden at least


So the LTS kernels have back ported features as well? My understanding was they only got bug fixes, but my knowledge primarily comes from Wikipedia.


The notion that RH kernels are stable is patently false. RH constantly backports features to "stable" kernels, and it does cause problems.

I was on the forefront of this when they were backporting container tech to their 2.6.32 kernel.

I've also seen them break userspace repeatedly with kernel changes for selinux within a stable kernel.

But as you say, you can pay for support so you have someone to scream at when things go south.

When it comes to ABI stability, I'd trust the vanilla kernels more than RHEL.


Yeah, Suse has a better kernel method IMHO.

Yelling at RH is about as effective as screaming at paint to dry faster in my experience. Their support can be very effective, but it's so slow it's mostly useless. They put you through afew layers of "are you this dumb" before you can get anywhere.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: