C++'s runtime is worse than Java's in that sense. Most JVMs can run most Java bytecode, but your libstdc++ has to be from the same version of the same compiler that your application was compiled with.
It was quite surprising for me the first time I did a little embedded work and discovered I couldn't run binaries that were compiled against glibc on my musl-libc based system, and vice-versa. I had initially thought they all just supported the same c89 spec so should work...
C++'s runtime is worse than Java's in that sense. Most JVMs can run most Java bytecode, but your libstdc++ has to be from the same version of the same compiler that your application was compiled with.
It was quite surprising for me the first time I did a little embedded work and discovered I couldn't run binaries that were compiled against glibc on my musl-libc based system, and vice-versa. I had initially thought they all just supported the same c89 spec so should work...
C++'s runtime is worse than Java's in that sense. Most JVMs can run most Java bytecode, but your libstdc++ has to be from the same version of the same compiler that your application was compiled with.
It was quite surprising for me the first time I did a little embedded work and discovered I couldn't run binaries that were compiled against glibc on my musl-libc based system, and vice-versa. I had initially thought they all just supported the same c89 spec so should work...
C++'s runtime is worse than Java's in that sense. Most JVMs can run most Java bytecode, but your libstdc++ has to be from the same version of the same compiler that your application was compiled with.
It was quite surprising for me the first time I did a little embedded work and discovered I couldn't run binaries that were compiled against glibc on my musl-libc based system, and vice-versa. I had initially thought they all just supported the same c89 spec so should work...
Yep. It's 99% ABI compatible, but that 1% will kill you.
For that matter, as you allude even C has a runtime.
C++'s runtime is worse than Java's in that sense. Most JVMs can run most Java bytecode, but your libstdc++ has to be from the same version of the same compiler that your application was compiled with.
It was quite surprising for me the first time I did a little embedded work and discovered I couldn't run binaries that were compiled against glibc on my musl-libc based system, and vice-versa. I had initially thought they all just supported the same c89 spec so should work...
> That's the whole problem with the dev-ops ecosystem. None of these dev-ops people seem to have any ops experience. Thanks for painting all of us that do "devops" with a wide brush. If you're a dev shall we enumerate all of the XSS and SQL injection holes you've added to products over your career?
well, XSS and SQL injection comes from my experience from "devops" kind of developer, claiming to code without wishing to learn the basics (complexity, DB, ....). So well, tried, but troll does not work. And startup are made by "devops" kind of business men that don't care about computing correctly cost vs price because it is so XXth century.
You're absolutely right, about everyone in the industry. How did you become so astute with your observations?
With docker, as referenced in TFA... you can simply vet a base image, and use that for your application... upgrades? create a new/updated base image and test/deploy against that.
And how do you "simply vet a base image"?
Same as everything: look at how it was built. Many of the images are built by CI systems according to Dockerfiles and scripts maintained in public GitHub repos. Audit those, then use them yourself if you're worried about the integrity of the services and systems between the code and the repository.
That's the same for "wget|sh", apt-get, npm or any other system. Now, if the argument is that configure tends to break more often and for more obscure reasons, I can tentatively agree with that.
This is the reason why all these standalone things bundle everything into their installation process. The problem is installing 206 different pythons on my system just makes it more likely that something else is going to break.
… which is one of the pressures driving Docker adoption. Each process tree gets its own root filesystem to trash with its multitude of dependencies. DLL hell, shared library hell, JDK hell, Ruby and Python environment hell… a lot of it can be summed up as "userland hell". Docker makes it easy to give the process its own bloody userland and be done with it.
As I said, generally. All human languages have inconsistencies, the command line is by far one of the most consistent ones any of us deal with.
It may be more consistent, but is not easier - humans are generous with regard to input, they can infer intentions from context. I could type in "please unbork this" to a human and he'd know precisely that he has to a) untargzip it, b) change the directory structure and c) upload it to a shared directory for our team.
Welcome to working with computers that can't think; easier is not an option, they can't infer your intentions, so your point is what? Consistency is what matters when working with machines and the command line is a damn consistent language relative to other available options.
As a Windows/VMWare/Exchange/Cisco admin, this is all completely foreign to me. Does this indirectly make a case for paying a vendor real money to manage their product properly? All vendors we work with provide installers that handle installing any dependencies. Updates are a few clicks. Occasionally we run into a vendor who provides installation/upgrade instructions, that involve manually copying files and hand editing config files. We replace those vendors. Error-prone people should not be doing manual file copying/editing or dependency checking, tasks that computers are dozens or orders of magnitude more competent at. This is B2B stuff where businesses should manage their product or risk getting sued out of business. The current environment seems to be that using free or opensource products is "free, with purchase of a team of consultants". Why not just pay the money to a vendor to provide, and support, a real product? It seems backwards to call this a sad state of sysadmin. This is like Boeing providing its leftover parts and a 9000 page manual on 747 assembly, and people complaining about the "sad state of mechanics". That's backwards. Buy a 747 from Boeing if that's what you need.