Live data from Hacker News

Having non-x86 machines makes your life harder

utcc.utoronto.ca

41–50 of 100 posts

Re: Having non-x86 machines makes your life harder

#41
Having non-x86 machines has actually made my life a lot easier -- most common exploits don't have the proper offsets and simply don't work.

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.

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.

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

Re: Having non-x86 machines makes your life harder

#43

Earlier 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?

My build directory is nearly 100G, with over 1 million files... I think it's just a huge old codebase with thousands of third party libraries which all need to be built too. And, being mostly C++, there is heavy use of templates which makes compilation very slow and the resulting binaries large.

Re: Having non-x86 machines makes your life harder

#44
post #3

This 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…

[flagged]

Re: Having non-x86 machines makes your life harder

#45

Earlier 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?

Google has a distributed build system that can built the whole thing in about 15 seconds on a large cluster of machines.

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

#46

Earlier 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

> 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

#47
I find it hard to disagree with this post, because the points are so broad, and the claim ("makes your life harder") is so low stakes. Most comments I read on here seem to interpret it as a form of "impossible." Sure you might not have some of those problems if you compile from source for all machines, but that is definitely harder than having pre-compiled options.

Especially 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

#48
post #4

Implied 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?

Linux Kernel userland ABI/API is very stable, and backward compatible: you can take a binary compile for Linux 1.0 and run it today. The same applies for CPU instruction, backward compatibility means stuff targeting i686 instruction sets will run on today CPU.

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]

That's ridiculous. Almost every large and small company has some kind of Microsoft server or cloud subscription. The Linux machines that do get deployed are absolutely full of pre-built distros, firmware images, and closed-source executables.

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

#50
post #5
post #4

Implied 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.

> 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.

Post reply on HN