Slashdot Mirror
Linux Is the Largest Software Development Project On the Planet: Greg K-H (cio.com)
sfcrazy writes: Greg Kroah-Hartmant, the Linux superstar, delivered a keynote at CoreOS Fest where he gave some impressive details on how massive is the Linux project. Kroah-Hartman said the latest release (4.5) made two months ago contains over 21 million lines of code. More impressive than the amount of code, and what truly makes Linux the world's largest software project is the fact that last year around 4,000 developers and at least 440 different companies that contributed to the kernel. Kroah-Hartman said, "It's the largest software development project ever, in the history of computing -- by the number of people using it, developing it, and now using it, and the number of companies involved. It's a huge number of people."
That is because unit tests are useless and so is most QA/QC. Let me guess, you think Agile development improves quality too. By the time you have defined all your "unit tests" we have already built the entire system and have it running in the real world.
Only if you think nine 5's is acceptable reliability.
Some of us have higher standards than that.
Because when you build systems of systems, it doesn't take many constituent systems built with the attitude that "unit tests are useless and so is most QA/QC" to turn the entire assemblage into a steaming pile of unreliable shit.
But hey, if you like producing steaming piles of unreliable shit, go right ahead.
Just get of your damn high horse - because it's stinking up everything with horse shit.
"Greg Kroah-Hartmant, the Linux superstar,"
Uh, what? There are only two superstars in Linux: Linus and the guy who came up with systemd.
You mean there is one superstar, and one cackling super villain. I'll let you figure out which is which.
Oh look: another butthurt QA person who is jealous because he doesn't make as much money as a prima donna developer! I've been writing software for decades that you are currently using every day. Guess how many units tests Linus has written? Zero.
I'd say having a university programming project become one of the biggest operating systems in history, and with the vast number of contributors and collaborators, all for a project that you can freely download, yeah, that's a pretty impressive badge of honor.
If Linus died tomorrow, he'd be viewed as one of the pantheon of great computer innovators, not so much because he produced anything in and of itself unique, but rather because he transformed the *nix ecosystem, and lead to greater penetration than I suspect Unix's original creators could ever have imagined.
The world's burning. Moped Jesus spotted on I50. Details at 11.
You have a way over optimistic view of Agile as generally implemented.
I contribute to a project that has CI going to run unit tests on every commit. Those unit tests take hours to complete. I have not seen those unit tests catch a single bug (other than style formatting issues, which are non-functional). The human testers have. The problem being that people equate hours of test as the sole metric of quality. The quantity of test does not by itself assure quality of test. The other facet of this is the phrase '100% coverage', which I've seen *many* project managers jump up and down all excited. I have seen QA teams *fired* at that milestone, because it's a misleading phrase. When management sees '100% automated test coverage' they think 'Human QA is no longer needed'. They don't understand those unit tests are just as likely to have problems, and almost certainly will not be all-encompassing (in fact unit tests tend to hit the corner cases that the developer *recognized* would be tricky, and had those edge cases in mind as they wrote the code anyway)..
My problem is less that unit tests are a waste of time or that they can't be good, it's that too many advocates of the process oversell the benefit and lead to poor decisions with respect to quality based on overconfidence in the process. The conundrum is that in practice, either you oversell it and cause these bad consequences, or you try to describe it accurately and project management will express frustration on 'wasted effort' in writing unit tests since they can't really replace human testing.
Incidentally, the sentiment that the project burdened by unit tests will be beaten to market is a likely consequence. It's not necessarily a *good* thing, but if 'good enough' hits the market before 'truly good', most will ignore 'truly good'.
XML is like violence. If it doesn't solve the problem, use more.
In electrical engineering circles we call these two aspects of testing 'verification' and 'validation'. Verification is verifying that the code matches the specification. Validation is making sure that the specification is really what we want in the first place.
Fortunately, us real engineers demand complete specifications, and when we find mistakes in those specifications we make sure they get fixed. Doing things in your haphazard land of writing code by the seat of your pants must be stressful at times.
that's about right for mature software predominated by small bug fixes, which take a long time to track down and verify
I have never, and will never, work for the government. Real engineers use specifications and test against them.
I notice you didn't include things like servers, routers, automobiles, industrial machinery, televisions (esp. the "smart" TVs), all the IoT shit (e.g. thermostats), avionics systems, and etc.
The embedded stuff outnumbers smartphones and 'PCs' by at least a factor or two... and nearly 50-60% of those run some embedded variant of Linux... embedded Windows ekes out maybe a sliver of that market.
Quo usque tandem abutere, Nimbus, patientia nostra?
You're making one big mistake, and that's equating software development with construction. It's not. Software has achieved automation of construction of final artifacts based upon detailed specs: it's called compilation. What programmers do is much closer to creating specs than to construction according to specs. People writing recipes are not cooking.
Of course mine will work and do what its supposed to do, yours will be buggy, not meet the design requirements, not function as expected in random ways.
Exactly true. I've found over many years of engineering that there is a vast difference between something that nominally works and something that works perfectly under all conditions. Once you've achieved the former, you've done perhaps 1/3 or less of the work required to get to the latter.
Well, you HAD more mod points, but they are in some binary log format, and good luck finding them.
Sigh. I get it no one likes systemd, blah blah. But believe it or not as time has moved on, the binary logs are quite resistant and the format is fairly simple in nature. Likewise, most emergency boots now include journalctl. A simple journalctl --file some_log_file will allow you to browse ad-hoc any file you toss as it so long as it is uncompressed (which as an aside, if you compressed syslog you'd be no better at this point) Even the ones that journalctl --verify says are corrupt. The corruption most of the time post version 205 is that an index was not written. And even if that's not the case, you can force it to display what it can read.
I think the binary argument is a hollow argument at this point. The logs are pretty good at not becoming corrupt and tools are pretty much included now in most recovery tool sets. I see it as no different as say when a PostgreSQL database becomes corrupt. And if you really just hate the idea of binary, you can configure journald to use syslog, and no that doesn't require a recompile.
If you want my arguments of anti-systemd it would be the team that develops it is one of the worse teams to work with and the amount of scope creep is frightening. I think we can all agree that those two things pose the most headache to systemd than this notion of "oh the files are in binary, you boned brah!" Is systemd an ideal solution, nope. But as much as everyone tried, upstart and the like of init replacements were going nowhere fast. At some point, the haters are going to have to realize, they're still working on systemd and they are still making changes to make the tools better and the formats more resilient. Does that mean there will be 0 corruption, no. But you do have to realize that the project is still being actively maintained and they are addressing or have addressed many concerns the enterprise customers have had with it. There's real money being toss at the project to work things that people don't like out of it.
TL;DR - I'm not a huge fan of systemd mostly because of the crazy scope creep, but c'mon the binary argument is so behind us now.
I've been writing software for decades
I'm the new RPGLE programmer in an AS400 shop and I'm surrounded by developers like you. Long story short, the 20+ year old code base is crap, none of the neck breads know what the hell is going on in the system and then blame it on bad data. Everything in the system from a user's perspective is confusing. And after a few years of using the system these folks wrote, our clients scream for SAP or RedPrairie. And these folks keep telling themselves, "They don't know what they're missing! We can roll out changes in days not months! They'll be sorry!" All the while I sit there and see our company bleeding money out because people like you think you can do no wrong and are artist and the code you write is somehow magical.
I'm not saying unit test and agile development fix bad programmers, but what I am saying is the free roam model of programming leads to a lot of crap and loss of money. And the self righteous nature means they'll never understand why our clients go elsewhere and never return. It just is so frustrating to work with people like you because you all believe that you can do no wrong. People want software that works. Sometimes that means unit testing, sometimes it doesn't, but if just go around yelling, code is art and the users exist only to ruin it! You're just blowing your company's money out the window. Just bloody hell, and you wonder why they keep outsourcing? Well just look in the mirror one day, there you go. Please never work within a 500 mile radius of Atlanta.
I'll take my troll mod now. For this person it was worth it. And trust me bud, I know that everything I've said has fallen on deaf ears.