Before you call me lazy for not patching, there are a lot of vendors that have very long patch times. If you have an environment that is mission critical, you would be well advised to not use x86 at all in the server environment. My entire income is based on cryptocurrency, so if I get owned it would result in large uninsurable losses.
Having non-x86 machines makes your life harder
41–50 of 100 posts
Re: Having non-x86 machines makes your life harder
#42[flagged]
Even though the blog appears to be by someone who doesn’t have much of a clue, this is gatekeeping. Just like in the Unix world of old before the rise of open source, many system administrators never compile any binary. And that is fine.
Re: Having non-x86 machines makes your life harder
#43Earlier quoted context omitted.
My Chromium compile and test is still running... 2 days later...
Having never built it myself, I wonder why the hell is it so slow to compile? I've built Firefox many times, including multi-stage builds with PGO, and it takes maybe 30 minutes tops on my 2015 era desktop. Is it because they use a lot of vendored code?
Re: Having non-x86 machines makes your life harder
#44This doesn't say anything meaningful. It just states some obvious things with some sort of implied value judgement with no information about how it's supposed to be bad, aside from the author's lack of experience. "you'll almost certainly wind up with a mixed setup". So what? It's not bad just because you say it is if you don't say why it's supposedly bad. It's also factually incorrect: "If you try to share things ac…
Re: Having non-x86 machines makes your life harder
#45Earlier quoted context omitted.
My Chromium compile and test is still running... 2 days later...
Having never built it myself, I wonder why the hell is it so slow to compile? I've built Firefox many times, including multi-stage builds with PGO, and it takes maybe 30 minutes tops on my 2015 era desktop. Is it because they use a lot of vendored code?
They aren't so concerned about someone building it on one machine. (to be fair, they do document ways regular folks like me can do distributed builds too)
Re: Having non-x86 machines makes your life harder
#46Earlier quoted context omitted.
Even though the blog appears to be by someone who doesn’t have much of a clue, this is gatekeeping. Just like in the Unix world of old before the rise of open source, many system administrators never compile any binary. And that is fine.
It’s not gatekeeping in any sense. Technical skills are required to do technical jobs, and this person asked for any criticism or feedback given by posting a public blog that has, for some bizarre reason, gotten to the front page of hacker news. Wtf. Technical incompetence must be addressed head first, or we risk real world problems
Given there's always been a chronic shortage of qualified and experienced technical staff, isn't the the "real" real-world problem here the raising of the barriers-to-entry for sysadmins jobs? I think most companies would rather employ someone who can at-least try to get something done rather than having no-one at all.
One of the reasons why "the cloud" is so popular among businesses today is because it frees them up from having to run their own systems and infrastructure (who needs a *nix sysadmin when the AWS and Azure portals let you do everything through a GUI?) - whereas I'm sure many (most?) of those same businesses would honestly prefer retaining possession and sovereignty over their data and applications (especiallly latency-sensitive stuff) - and we all lament how the cloud giveth and the cloud taketh-away - but here we are.
Re: Having non-x86 machines makes your life harder
#47Especially if you have to maintain many machines (which is mostly implied in the post, but also explicitly mentioned here and there).
Hosting and maintaining a custom package repository for your self-compiled binaries so you don't have to do it on every single machine manually (maybe compiling everything from scratch might take days or the machine couldn't do it on its own anyways) is also obviously making your life harder.
My personal small scale experience, developing a small service on my laptop and running it on my local pi for testing, already ran into many of the problems. Some packages I wanted to use didn't exist, some containers I used locally weren't available for ARM. Are those unsolvable, or even hard, problems? No. But! They are time sinks that make a very simple thing more complex, more brittle and more annoying, than if I just used a homogeneous x86 setup, even if I were a skilled sysadmin (which I am not) or enjoyed fixing those differences and maintaining the fixes (which I do not).
Re: Having non-x86 machines makes your life harder
#48Implied in this: The expectation to copy binaries between machines and having them work. Less of an issue if you compile from source.
I've never put much thought into this but given a "linux x86" binary package, on what range of machines is it supposed to work? for instance, what's x86 mean exactly? I suppose all x86 processors have slightly different sets of instruction. Also, different linux kernels may have different sets of syscalls?
However, if you need more modern stuffs, then obviously you need a higher minimum version. For example, some software require SSE; or docker will only run on a modern Linux kernel.
Re: Having non-x86 machines makes your life harder
#49[flagged]
No serious systems administrator is going full Gentoo on their entire setup. It's a waste of time and effort to do so.
Obviously the author knows they could compile Firefox themselves. It's not even that hard, you just need to download a whole bunch of dependencies to your machine and wait for half an hour. That's not how sysadmins people get their software, though.
Re: Having non-x86 machines makes your life harder
#50Implied in this: The expectation to copy binaries between machines and having them work. Less of an issue if you compile from source.
Compiling from source is easier said than done for many big open source projects. In practice, they compile only with specific versions of GCC, CMake and libc.
That's pretty easy nowadays thanks to container.
You don't have to muck around with environment variables to get the build system to detect your custom toolchain anymore.