"The claim was that we needed to set up containers in our developer machines in order to run tests against a modern glibc." At first you are absolutely correct that you don't need containers for that. But then on the other hand, hey I wouldn't work for a company where I need to provide an explanation to get containers on my developer machine.
Luckily, the company at play does not require an explanation to use containers on developer machines.
But when you are in charge of a remote execution service, CI pipelines, and production builds… well, this is not about a single developer machine anymore and containers may not be the right solution when you know about the details of how the software is put together.
“Containers aren’t always the right solution” is a rather unsatisfying reason to reject them. Nor, really, is the use of disk space, since disk has been cheap as chips for decades. Since you’re going against the grain of the industry, it would be useful for you to elaborate on the reasons against just using containers.
Yes when you are in charge of that then it is something different.
In our company we luckily have the possibility to run containers at all those stages (we are also developing container images for customers) but as developer it's still a good thing to know alternatives. It may save you time because requiring containers decides whether your build can only run on 10 new linux build agents or on all 80 that are currently deployed.
If you use Home Assistant you just need a cheap zigbee adapter instead of the ikea thing. If not use something like zigbee2mqtt which provides you an api.
As long as none of your csv producers are using microsoft products or live outside the US. In europe csv is terrible with different delimiter depending on system language and such nasty things just because of excel.
have you seen the script? It's super intrusive and reconfigures your entire system, including personal config files.
The usual argument against curl|bash scripts is that they don't respect program boundaries, may do unknown system configuration that would affect other programs, and could be impossible to remove.
And "initial system setup" scripts like this one do all those things _on purpose_.
Maintaining that kind of monstruosity of shell scripts that have to work on all kind of OS or linux distros must be a giant PITA compared to the simplicity of making an appimage/flatpak and a set of deb/rpm packages for the most popular distros and clear instructions for port maintainers to do the same for archlinux and BSD systems.
One should never pipe curl output into `sudo bash`, but I think you've got things quite backwards here. Barring some extreme edge cases, putting binaries in /usr/bin, icons in /usr/share/icons, config files in /etc, libraries in /usr/lib and so on, are standard across the the Linux workd, and simple utilities that are just archives of binaries, docs, and auxiliary files can easily be deployed to most distros with a common install script.
This is far, far less complex than having to maintain and distribute an entire bundled runtime environment, deal with inconsistent behavior with the local config, etc. Flatpak and AppImage have their use cases, but by no means are they simpler than just putting binaries in the right places -- they are in fact an entire additional layer of complexity.
That's a reasonable practice, yes, if you're doing a manual direct install. In situations like this, though, I typically just write a quick PKGBUILD script so the package manager can manage it, which means pointing things at the direct /usr/* paths, not /usr/local/*.
I don't recall ever seeing this approach with sudo. Is it really becoming popular?
It used to be just bash, e.g. `curl ... | bash`. But now there is nothing stopping you from putting sudo in that bash script and expecting with a high probability that NOPASSWD: is also there ;)
It depends on your goal. If you want to build the bomb and survive in the long run, it will be difficult. If you just want to make a big bang with no other requirements, unfortunately it's pretty easy to do.
We could be happy about the two things that it is not that easy to get enough plutonium in the required purity and that most people love their lives.
Is it possible that most terrorist groups understand the cost/benefit trade off? In other words, if you have folks capable of designing and/or assembling a nuclear device, those aren’t people you just throw away.
I understand that terrorists don’t value lives highly, but you don’t see experienced bombmakers actually conducting suicide attacks for a reason. They’re valuable alive.
Jump to New Location Saving Return Address: JSR [1]
Jumps to a subroutine
The address before the next instruction (PC - 1) is pushed onto the stack: first the upper byte followed by the lower byte. As the stack grows backwards, the return address is therefore stored as a little-endian number in memory.
PC is set to the target address.
