21–30 of 466 posts
[deleted]
it's also still standard practice in most companies to either read the source code of open-source stuff before deploying it to production Eh, no.
[deleted]
Reading the source code might be the case if you are in a large enterprise that can afford to keep those programmers busy or needs to actually vet the code but I honestly doubt it. Just check the loc count on something as common as Hadoop (close to 1 million [1]) and that is excluding the "stack" described in the article. I wanna bet you, because we all know how volatile the job market is that even the guys building or supporting the software did not write or read even half of that code.
[1] https://www.openhub.net/p/Hadoop/analyses/latest/languages_s...
[deleted]
I've worked in multiple large companies and even getting package signing turned on requires a lead pipe. Docker and tools can enable an org to move those types of responsibilities "over/down" to the developer as well, so that now there is no neck-beard encrusted gate at all.
make is the least-auditable build tool imaginable. You don't have to obfuscate a Makefile, they come pre-obfuscated; you could put the "own me" commands right there in "plain" Make. Not to mention that it's often easier to tell whether a Java .class file is doing anything nefarious than whether a .c file is. How many sysadmins read the entire source of everything they install anyway? Maven, on the contrary, is the bi…
The value of debian is not that they package (or repackage) everything into deb files but that they resolve versioning and dependancy conflicts, slip security fixes into old versions of libraries (when newer version break API/ABI), and make it possible to integrate completely disparate software into a system. They also have a great track record at it.
Maven does not do any of these things; Maven does nothing to protect the system administrator from a stupid developer, it just makes it easier for their code to breed and fester.
You must understand that the sysadmin has an enormous responsibility that is difficult for programmers to fully appreciate: You don't feel responsible for your bugs, you don't feel responsible for mistakes made by the developer of a library you use, and you certainly don't feel responsible for the behaviour of some other program on the same machine as your software, after all: Your program is sufficiently modular and scalable and even if it isn't, programming is hard, and every software has bugs.
But the sysadmin does feel responsible. He is responsible for the decisions you make, so if you seem to be making decisions that help him (like making it easy for you to get your software into debian) then he finds it easier to trust you. If you make him play whackamole with dependencies, and require a server (or a container) all to yourself, and don't document how to deal with your logfiles (or even where they show up), how or when you will communicate with remote hosts, how much bandwidth you'll use, and so on: That's what Maven is. It's a surprise box that encourages shotgun debugging and using ausearch features to do upgrades. Maven is a programmer-decision that causes a lot of sysadmins grief a few months to a few years after deployment, so it shouldn't surprise you to find that the seasoned sysadmin is hostile to it.
[deleted]
I've unfortunately had more than one mind numbing conversation where another administrator will tell me that it's a "script" and therefor, I don't know what it does, and that there "may be" some hidden black magic that will instantly pwn all of our systems. Attempting to explain that I verified the functionality line-by-line brings blank stares, as if it's utterly impossible for someone to derive the dark magics that are code.
Thankfully, I haven't run into many instances where software is blindly installed as the author relates, but his point in that "no one knows how it works" combined with the lack of attribution creates an environment of mistrust which greatly limits our ability to take advantage of open source software.
[deleted]
> As far as I know, it's also still standard practice in most companies to either read the source code of open-source stuff before deploying it to production (binary or build) or get a support contract from someone else who has. Reading the source code might be the case if you are in a large enterprise that can afford to keep those programmers busy or needs to actually vet the code but I honestly doubt it. Just check…
[deleted]
I've never, ever seen this happen.
Earlier quoted context omitted.
> As far as I know, it's also still standard practice in > most companies to either read the source code of open- > source stuff before deploying it to production (binary > or build) or get a support contract from someone else > who has I'm afraid I have no better, more cogent response for this than 'lol'.
At the risk of my karma I'll have to maintain that for companies who are subject to regulation (publicly-traded companies, banks, etc.) what I said is still standard. Unless you have any specific instances to the contrary you're willing to offer?
So, with regards to your assertion, the second clause (support contract)? Definitely. the first (code review), never.
That's the view from my side of the fence, anyways.