Google: Linux kernel and its toolchains are underinvested by at least 100 engineers Google's open security team has claimed the Linux kernel code is not good enough, with nearly 100 new fixes every week, and that at least 100 more engineers are needed to work on it. Kees Cook, a Google software engineer who has devoted much of his time to security features in the Linux kernel, has posted about continuing …
I suspect the problem is not with the financial cost of employing more developers, but finding suitable ones. Of the hundreds of developers I've worked with over nearly thirty years, I can only think of three that *might* be suitable. It's a very different proposition to the kind of systems most programmers work on.
When I was younger I was seriously considering doing Kernel development, but who would pay me?
Doing work so that then big corporations can make billions off of it without paying a penny is a fool's errand.
The way Google is addressing the issue also sounds disrespectful. Engineers are not cattle.
> Doing work so that then big corporations can make billions off of it without paying a penny is a fool's errand.
I disagree. I contribute to free software because I consider it a public good.
And there's nothing inherently wrong with making billions of dollars in of itself if you are providing something of value. There are many, many companies out there making a more moderate income from free software, and that's perfectly fine with me.
It's wrong to use someone's work without payment though. I get some people are privileged and they can afford to donate their time, but this creates inequality.
If you are able to commit time, you are enforcing a pattern where a big corporation does not have to pay workers for some of the work and that creates an expectation that developers' work is not worth any money.
People from poor background then are excluded from participation in those areas, because they have to work for money to put food on the table.
This is similar problem to unpaid internships, where the places were snapped up by children coming from wealth (as they didn't have to work for money and parents paid rent, food etc) and that excluded working class children from having a path to getting better jobs.
Using someones work without payment != Open Source.
1) I mainly code to solve my problem, open sourced, so others can use it.
I've already solved my problem, so why prevent others from benefiting.
2) I code on FOSS at work, usually some issue that $JOB has, it's patched and returned to upstream.
In this case I was paid, secondly it solved some business needs, tangible ROI.
1 - contains the small oversight, that I use vastly more FOSS then I'll live long enough to write.
2 - contains the obvious point, that most FOSS code is written by professionals who are competing at a level above the S/W being FOSS.
For example, I sell widgets, I host on EC2. Common Stack being Nginx and Terraform.
Fixing a terraform bug doesn't help me sell widgets - keeping the fix in house increases chance we'll have to maintain the fix into the future.
Adding a lua module to nginx, might make it a bit easier to standup a new endpoint, but won't drive customers.
In short, zero commercial sense in proprietary software, with exceeding rare exceptions.
But what if someone approached you about one of the codes that you had open sourced years ago after fixing your problem X, and said angrily, "I found a bug when applying your code to problem Y. You must fix this bug in your code immediately, for it is preventing me from making millions out of it!"
You would expect them to either 1) fix it themselves (and hopefully contribute back their fix) or 2) pay you a small portion of those $millions to fix it for them.
Unfortunately many companies do neither - they get very angry and upset about bugs in open source code that they are making millions (or billions) off the back of, but contribute no resources towards fixing them.
(never mind actively maintaining the code they used, or contributing back their custom extensions)
Some companies (or rather, some managers) have the mentality that open source = nobody to blame when it goes wrong, so they avoid it altogether and go for a proprietary black-box solution which is LESS secure/stable, but they can point the finger of blame at someone else when it goes wrong.
Re: Some companies (or rather, some managers) have the mentality that open source = nobody to blame when it goes wrong, so they avoid it altogether and go for a proprietary black-box solution which is LESS secure/stable, but they can point the finger of blame at someone else when it goes wrong.
Actually, the company I work for prefers to use bought in solutions (even if they use Open Source) for a simple reason. Not only do they have a defined person or organisation to take action against if the system should fail, but because they've bought in something, the law offers various protections in the event that the system fails in some way.
If they've bought the software, the same applies. If they haven't, they have some protection given by the fact they paid for a service, but that service provide can legitimately argue they are not liable for bugs in the software. When a company is potentially spending thousands on a new system, they are likely to want all the protection they can get.
I'm no lawyer, so I could be wrong, but that's my understanding of the system.
The other thing is what guarantees of continuity of service do they have? When specifying a new system, you don't want to go to all the effort of designing, testing and installing it, only to find development of some core component is abandoned a year or two after you start using it. Admittedly, that won't happen to Linux anytime soon, but I've pushed Open Source as much as I can, and this has happened to me a few times. Enough that any time I try and introduce Open Source into a new project, it's bought up. Generally, if you are paying Enterprise prices for software, you get reasonable warning if they are going to shut down development.
However a major company abandoned its accounting software even though it was paid for and major company still exits. Just did not make enough money perhaps. Eventually issue da solution as a free download, but not maintained and not open-source. This caused a lot of tax and bookkeeping problems to many companies who bought software because it was from a reputable major company.
Commercial software is not always a long term benefit.
At least if it is FLOSS or just open source the user has an opportunity to keep going without a problem with tax authorities, and possible company failure.
"Not only do they have a defined person or organisation to take action against if the system should fail, but because they've bought in something, the law offers various protections in the event that the system fails in some way."
Believing that is what comes from not reading the EULA.
It's wrong to use someone's work without payment though.
It's wrong to use someones work in a way they don't intend. If I licence my work in a way you may use for no financial payment, that's upto me. Or are you saying that I shouldn't be able to release software I write in a way I choose?
I get some people are privileged and they can afford to donate their time, but this creates inequality.
I'm not sure how priviliged you have to be here? I grew up in a family that wasn't rich, but as computer programming is my hobby it's something I've always found time for. I also got my first work as a programmer because of a company seeing some software I'd released for free. (Mind you, I've always credited this with my love of programming, my friends at the time had C64s and Spectrums with games, I got a second hand ZX81 that put a 'K' on the screen, and that was about it.... so I taught myself to program it).
Also, these days a good proportion of open source software is funded by large companies. Most of the full time kernel developers aren't doing it for free. It's their job.
This is similar problem to unpaid internships, where the places were snapped up by children coming from wealth (as they didn't have to work for money and parents paid rent, food etc) and that excluded working class children from having a path to getting better jobs.
No, that's an entirely seperate problem. That's unpaid labour, which as you say favours those of means. But as an intern you are also expected to do as the company your interning for requires; that's the distinction.
> Or are you saying that I shouldn't be able to release software I write in a way I choose?
I am.
You can release code in any way you like but if you expect the community to identify and fix the bugs in your code then the community has the right to fix them in the way it thinks is best.
And if fixing bugs is 'unsexy' so that there aren't enough volunteers then paying developers a wage to do it is fine by me.
> I've re-read FIA's post again. I still can't see where he says he expects "the community to identify and fix the bugs in [his] code". Perhaps you could point that out
It's implicit in his post: if he releases some code under some sort of free licence then he must also accept all the consequences of doing so.
One of those consequences is that there will be a bug-fixing process that works in its own way. He can't expect impose any sort of restriction that requires bugs to be fixed by unpaid volunteers rather than paid developers.
I was pointing that out because it's not immediately obvious.
> It's wrong to use someone's work without payment though.
It is isn't wrong to use work that I give freely for others to use because I consider it a public good.
> I get some people are privileged and they can afford to donate their time, but this creates inequality.
How can software freely available to all create inequality? That's just daft.
your statement strikes at the heart of Economics. It creates externalized costs, in other words freeloading which causes most Economic models to fail as it creates an unmeasurable part of the economy. You can't do policy with those models.
It also suppresses wages. I don't care if you are donating part of your wages. But if in the process you you suppress mine I do mind.
Not everything in life is valued in 'money', and not all valuable things have a monetary value.
A reductionist approach to life seldom leads to happiness, and certainly doesn't lead to a wholesome understanding.
'Linux' (kernel and stack) is, of course, not 'free' of cost, whether financial or otherwise, but the user certainly has freedom to access it, adapt it, share it and use it in ways that those tied to proprietary systems are largely excluded from. Perhaps that is what makes it worth the 'cost' for many of its users.
Yes open source was targeted at users (not corporations) who couldn't afford to pay extortionate price of enterprise software.
They didn't predict that the work of so many contributors will be appropriated by corporations, sold and not reimbursed.
Basically if Google wanted to incorporate e.g. Linux in their product, they should pay all contributors for use.
If you wanted to incorporate Linux to control temperature in your shed, then you should be free to do so.
Corporations should never be allowed to use someone's work without payment.
The Linux license could be changed to distinguish between commercial and non-commercial use.
BUT that's a slippery slope that would change Linux forever and I hope we never consider it.
The developers here who work as independent contractors (presumably for pay) are as commercial as anyone else.
> They didn't predict that the work of so many contributors will be appropriated by corporations, sold and not reimbursed.
So what? It is given over to the public for their use. It is just a tool and you are assuming that the company making all that money is just selling the software and providing no additional value which is rarely the case. But secondly, if they are merely selling the software then that's find also as long as it is inline with the intentions of the original author.
> Basically if Google wanted to incorporate e.g. Linux in their product, they should pay all contributors for use.
Again why? This is a very needy and entitled perspective. If you write software and it satisfies a need that you have and you release it to others in the hope that they will also find it useful, then that is fine. I really don't see a problem in that.
The best analog I can think of recently was the legal story of the guy who tipped his waitress with lottery tickets. When he discovered that the waitress won a big pot of money on one of the tickets, he took her to court to try and get a share of the winnings. It is a very entitled and bizarre position and the guy was a complete dick.
If you truly give something to someone (or everyone) with no expectation of return (it's what we call charity or a goodwill contribution to the public good) then you can hardly complain when someone does exactly that.
"Corporations should never be allowed to use someone's work without payment."
Could you quote any of the open source licences which say this? Because unless the licence makes that stipulation they are allowed to do so. They're allowed by the developers who release the code that way. It might personally offend you your opinion only counts if you're one of the developers and somehow I don't think they care about taking advice from you.
Do you even know why the GPL came about? It was because RMS got pissed off with his work being taken closed by a corporation for no payment. He devised the GPL so that no corporation could do that again - not the "without payment" bit, but the taking it closed. That's what matters in the open source world.
"It was because RMS got pissed off..."
Not just RMS.
If it had been the mad rantings of one geek, GPL would never have gotten traction in the way that it did
GPL exists _BECAUSE_ of widespread abuse of previous opensaucery efforts - and even today there's a lot of FUD claiming "opensource == public domain"
"They didn't predict that the work of so many contributors will be appropriated by corporations, sold and not reimbursed."
Actually they did. What you're describing is essemntially the BSD licensing model
GPL forces that code used be left open, not "appropriated" and claimed by corporates (It's happened to me, thast's why i switched to GPL many years ago) who in some cases then litigate the original authors for copyright (this has happened before now. CDDB being a case in point)
"Not everything in life is valued in 'money', and not all valuable things have a monetary value."
Well, most companies have a value placed on each employee's head, and insurance companies only exist because somebody's existance has value. Citizens have an associated GDP, cattle have a cost to farming corps and slaughterhouses, etc. Everything is in fact valued in money, and all valuable things have a monetary value. To suggest otherwise is ludicrous.
Statements like that are just people burying their heads in the sand because it turns out capitalism, a system that incentivizes the accumulation of as much wealth as possible for the minimum amount of effort, shockingly(!) comes with some downsides. Collectively, as a world, we've accepted those downsides as worth it, and pretending that human lives are somehow not appraisable is just cognitive dissonance. It literally cannot jive with the basic economic gears of the world.
It is very far from 'ludicrous'. That very attitude demonstrates the validity of my point - failure to understand that 'value' is not necessarily based on money. The fact that some people choose to try and make that attribution contributes significantly to the ills of humanity.
Yeah, sure, you can put a price on anything, but does that monetary value necessarily reflect true 'value/worth', no of course not. Just as compelling someone to put a price on their work, if they choose not to do so is grossly oppressive - who are you to tell me that I must put a price on what I do?
'Materialism' is a very ancient problem, one that goes to the heart of the human condition. It leads to treating people as objects, and defining objects only in terms of what monetary value they are ascribed.
This post has been deleted by its author
..."failure to understand that 'value' is not necessarily based on money."
You're missing the point. Just because things have value besides money, doesn't mean it doesn't have a monetary value. Pumpkins don't quit being squash just because they're also orange. The point was that things if consequence are never without a dollar value. You can't put a price in the love from your family, but nobody wants to buy that. At least not specifically. I know for a fact that you can pay a fake family to hang around you.
The point is that the 'monetary value' too easily - for some people - becomes the defining value, whereas in fact it may be the least important value, or even utterly irrelevant to what ever that value has been attached to.
We too easily become obsessed/distracted by monetary value, as though it is the most important thing - very often it isn't, which ends up causing a distortion in understanding and behaviour, sometimes with tragic consequences.
"What's that bit of forest worth - I'll give you 2 million"
"Deal!"
"Okay, get the chainsaws going. This needs to be cleared for ranching by the end of the year."
Kiss goodbye to a unique five million year old ecosystem, but then it was only 'worth' 2 million notes.
"We too easily become obsessed/distracted by monetary value, as though it is the most important thing..."
All meaningful decisions made by wealthy individuals, governments, and corporations (i.e., the only peopel with decision making power of any note) are based on money. Since those decisions have the greatest effects on the greatest number of human and animal lives, and on the environemnt itself, it means that money is, in fact, the most important thing. You don't have to like it or agree with it (I don't), but it is the state of affairs, and there is little chance of that changing peacefully or quietly.
> ... it means that money is, in fact, the most important thing.
Just because corporations have to consider making money as their primary aim does not mean individual people have to be motivated only by money. Fair enough, a large corporation has far more power than most individuals, but individuals can act collectively, and thus have significant influence. I presume such collective action is why environmental concerns are politically influential. For example, it is not that cleaning up rivers profits environmentalists in financial terms. It is just the most people would prefer their rivers not be used as waste dumps.
Corporations do not have to consider making money as their primary aim. They have to act in the interest of the shareholders. Too many people mix this up. This is made even worse by share price not being linked to profit. Most shareholders make money through selling, not dividends, therefore any action that may increase share price can be viewed as in their interests. It may even be the shareholders are not individualistic rand worshipers and want a corporation to have a social conscience.
Everything is in fact valued in money, and all valuable things have a monetary value. To suggest otherwise is ludicrous.
Hopefully one day you'll understand why that's wrong, and you'll be happier.
Accountancy means everything is valued in money that needs to be relatable, but that's just capitalism, as you said. But for some things value really isn't that easy to ascribe in money. eg, I value a short commute over a larger pay check, but I'm not sure I could tell you at what point the money would overcome that resistance to sit on a train. Ten times my salary, sure, but double... not so sure... whereas there are plenty of people who will do that commute for a fraction more than I earn now. (An accountant would work out some kind of average, but that is then only an average value across everyone).
Statements like that are just people burying their heads in the sand because it turns out capitalism, a system that incentivizes the accumulation of as much wealth as possible for the minimum amount of effort
Nope, when that happens capitalism has gone wrong and should be regulated. A proper market will guard against this. Capitalism is actually about self interest, but in an open market it's in your best interests to do a good job, as then you'll get more work and accrue more money. If market forces aren't ensuring this then there's a problem.
If you hire a tradesperson, and they do a good job are you more or less likely to hire them again than the one that left you feeling like you'd been ripped off??
The problem is we've allowed certain player dominence in markets so they no-longer have to play 'fair' in order to profit. That's when capitalism breaks down and needs regulation.
For example, I listened with awe to someone describing how they could pay amazon to hold stock for them, and they'd been convinced this was a good thing. Now when you've got shops charging the stock to sit on the shelfs then things have gone wrong. (yes, I get it's more nuonced than this but basically it seemed to be a system where Amazon got paid quite a lot...)
"Hopefully one day you'll understand why that's wrong, and you'll be happier."
Perhaps. Ignorance does bring a certain happiness. I know I'm a lot happier realizing that to the only things in the world with any influence (corporations and governments) place a dollar value on my life. I like knowing that daddy Amazon or PM in no way has my back when I'm in trouble, and that they'd recycle me for feed if given the chance. It's a lot safer.
Of COURSE security issues are, fundamentally, bugs. EVERY program issue fundamentally gets reduced to an improperly coded function - every one.
That, however, does not for a single iota reduce the impact of Google's statement. Just the opposite, in fact, as that was the distilled talking point: more *coders* could find more bugs and therefore fix security problems.
In other words, Linus' quote was a form of double-speak.
EVERY program issue fundamentally gets reduced to an improperly coded function - every one.
This is only supportable if you allow "improperly coded" to include errors in system design, errors in requirement discover or specification, and other concerns which are far from coding in the levels of abstraction. Even then it's probably not valid. How is a change in requirements "improper coding", for example?
In short, it's nonsense. And so is Linus's statement. Being intelligent and having strong opinions does not make someone automatically correct.
How many times do we have to say this? By far the greatest part of the Linux kernel comes from the contributions of these companies. Intel, Red Hat/IBM, Google etc.
The practicalities are not tricky. For Intel, for instance, they're helping to create a market for cores. For others they're able to help create something better then they could if they worked independently. It's collaborative development that benefits everyone. They can see the benefits even if you can't. If it didn't work like that it wouldn't exist.
While I think the guy makes a reasonable point, I'm not convinced by the proposed solution. Firstly, kernel engineers aren't lying around waiting to be called up and secondly, they don't necessarily scale.
In the near future I think we'll see more proof of concepts as to whether kernel code can be ported to Rust and whether this brings any of the hoped for improvements in memory safety, etc. In a sense, the work might be valuable in itself as an exercise in shining a light on less illuminated parts of the code base. If this does work, it also provides a model for how more companies might contribute usefully by sponsoring specific kernel projects (as is already done in FreeBSD). And, of course, moving away from the monolithic kernel towards a microkernel might also become possible (and reasonable now that x86_32 and its poor context swapping no longer dominates). This is turn should make rolling releases easier for all too handle.
For companies it's much easier to argue for enlightened self-interest when talking about specific projects rather than providing engineers but being told you can't keep the code.
Certainly adding a hundred developers won't reduce the run rate of kernel fixes any time soon. Either they'll be fixing more bugs, or they won't be productive. So most of the issues raised by Cook – the rapid fix rate, the need to upgrade or backport fixes, and so on – aren't alleviated by adding kernel developers.
That doesn't mean kernel development isn't understaffed or doesn't need additional resources. It just means adding developers doesn't address most of Cook's list.
A couple of months ago 'Linux shouldn't be using their build process and e-mail, they should be using a (oh shock and surprise) Google developed solution instead'
What was said then applies now. If Google are so concerned, employ 100 developers and get them to supply fixes to upstream.
I would expect that given the wide number of platforms Linux supports that whilst Rust could be useful in some instances it's not going to handle all the necessary cases.
Well Google had better stop leeching and start getting more involved.
They pay for a relatively tiny number of developers and invest vastly more into their Android and Fuschia platforms which don't exactly help anything in the long run.
This is a little like those charity adverts where some rich celebrity has the audacity to tell us little peasants to "help out" when their wealth dwarfs any contribution of ours.
So, fsck off Google. The world really would be a better place without you.
It is just natural that if Google put in 100 more engineers just doing security, they will control the direction. Android is a perfect example. Ultimately, they will introduce security features that fit their requirements.
Microsoft has been doing this for some time now. It is a big bear hug. This may be Google's way of contracting the MS embrace.
Think of a python slowly squeezing the life out of free software.
Only if we LET them.
Only if their way of thinking takes over the project.
Only if Linus retires and hands over the torch to someone else who's on Google's payroll.
They are *WAY* *TOO* *QUICK* to blame the C programming language.
They are *WAY* *TOO* *EAGER* to change the management environment.
They OBVIOUSLY have an agenda here.
It is NOT going to be a GOOD thing, if they get their way.
'Nuff said, I think...
"What is the solution? Cook has a number of proposals, including moving away from the email-only workflow used for Linux development, introducing more automated testing and fuzzing, continuous integration, and other steps to make the development process "more efficient.""
But in his secret heart of hearts, Cook knows the best proposal is for Google to completely take over Linux development. For the good of the community. For the good of mankind. For the future of the Universe.
Why do I wince any time Google starts critiquing projects that are exterior to Google? It always feels creepy, like some old guy in a van offering candy to little kids.
I don't think Google is out to control Linux. But they do have very speicific requirements both of the software itself and of its development, testing and deployment that are not necessarily shared by others.
For Google, I think it's important to realise that this is all about their server infrastructure. If they think it's necessary they may well decide to fork or replace Linux. They certainly have the engineers to do this and, with Fuchsia at least, they have shown the willingness to to do. But the piece also shows that they understand the risks of going this way.
"projects that are exterior to Google"
Given that they're contributors to Linux this doesn't really make sense. It's like saying Linux is exterior to Intel, Red Hat and all the others. There seems to be a mind-set that doesn't grasp that the Linux kernel is to a large extent a shared project between a number of large corporations who compete at one level and yet gain by collaborative development.
It may help that the gatekeepers such a Linus and Greg K-H aren't employees of any of them and can thus be even-handed about what goes in.
"exterior to Google" meaning not owned, controlled, managed, branded, or sold by Google. Similar to how the Linux kernel is also "exterior to Microsoft". Both companies may contribute to it to help themselves (and entirely by happy side-effect, possibly help us users and the community in general), but it's still external to their core business. And with that in mind, it's not remiss to question their motives when they make such large-scale suggestions as this.
Just another Google whine to take over and control every aspect of the Internet.
.
The only solution is to continually update to the latest version of the stable release used, but Cook said that "performing continuous kernel updates... faces enormous resistance within an organization due to fear of regressions – will the update break the product?"
.
I am not a corporation, but every time * a new kernel doesn't work for me I restart and select the last kernel. A duff kernel doesn't break anything. Just revert.
I appreciate with big enterprises time is of the essence, but we are talking less than 3 minutes, and they are going to have some minute downtimes anyway, for instance when they upgraded the kernel before that. Perhaps even test beforehand.
Unless they are looking for an unchangeable kernel for evermore.
.
.
* Happened once, on Mint; but I always keep at least 3 kernels around.
Oh it takes you three minutes? I take it you are not a mega corporation with 150k engineers, millions of servers, and thousands of different computer configurations which may or may not detect a problem immediately, but only after a few months due to a freak occurrence which happens only every seven months, or possibly years...
Waiting for Torvalds’ death ray to discharge in Cook’s direction (still hoping for an uncensored, un-PC version) I will say that:
0) C is not difficult, it’s the opposite of that —that is what makes it a very good choice, possibly the best choice, for low level system programming. If you come around annoying the fsck out of people claiming that C is too difficult to do things securely (or: well) the solution is that neither you nor who trained you should touch it. Or the Kernel. Let alone opinate about them.
1) There are generally two ways to think about security: the first is the wrong one, in which you do stuff not thinking about it, then you pass it on to someone who just thinks about it and ruins your work’s performance and usability because hey, a safe box with the door welded shut is the best!
The second is to think about what you’re doing in the first place and design it so that it is decently secure without someone welding it shut for you —AFAIK, this is the Kernel approach. Which is constantly broken by pillocks at Google, btw.
2) Should Google contribute 100 engineers to the Kernel, I want 200 people checking their work for damn backdoors, since Google’s anus’ track record for improper, surreptitious access is really not clean.
"0) C is not difficult, it’s the opposite of that —that is what makes it a very good choice, possibly the best choice, for low level system programming"
Yet engineering managers at Amazon, Google, and Microsoft managing groups of engineers a hell of a lot more talented than random commenter on the internet, have all decided the benefits to switching to a better language are worth it for many projects. Go argue on their blog posts how dumb they are to move away from languages that enable several classes of bugs.
If C, C++, and Rust had been introduced at the same time, do you really think any programming would be done in languages other than Rust because they're "not difficult" to write secure code in?
I was kind of hoping for this kind of comment, because now I can unload further. Thanks!
In software engineering (engineering and life at large, if you will), there’s such a thing as the correct tool for the job.
There are things C sucks at, even before security concerns. Arguably, there are many of them. From my old field of expertise: data understanding and data analysis prototyping is one of them. If you are trying to make sense of a signal to noise ratio of 1e-7, the last thing you want is care about what exactly you’re doing with your memory. Failing to recognise this leads to monstrosities like CERN’s Root —interpreted, JIT-compiled C++ dialect… and you thought C was bad?
When it comes to system programming (from embedded to kernels), C is the way to go. Because it lets you free, unfettered range in exactly the things that matter (not even C++, C).
This also means that you are totally free to shoot yourself in the face with it if you’re not careful. So you need to be careful —or at least think about what you are writing.
People trained to connect their brains, have a think and then write are expensive, though, and there is a damn good reason why large corporations (one that does not do OSes, one that shamelessly leeches them and the other that has an effective monopoly on ElReg’s BORK!BORK!BORK!) are attracted to things that require less thinking —> less expensive people to deliver the same amount of risk.
So my point stands: if you do the Kernel, you need to be able to C well. If you can’t handle the latter, you’re unfit for the former. It’s as simple as that.
So, Google are saying that the FOSS coders aren't up to scratch and they should get a move on.
I think a general consensus that Google supplying the engineers to meet their own standards of expectation is worrying, in that it has much potential to taint and pollute the kernel (the prevention of which is down to the auditing of their code by others).
Google, if you're not happy with the process and results being produced, your best option is to fork off. You know best, after all.
[And like others here, I'm waiting on Linus' response with some enthusiasm!]
Icon: Google, please --->
Because if they aren't happy they are quite entitled to take a copy of the ball and go and find their own field, where they can play by their own rules.
I'm not suggesting they should do that, but one of the joys of 'open source' software is having the option to do that; that, and being able to suggest to whiners that they can always do one with a fork if they feel so strongly dissatisfied.
I have a hard time believing that re-coding ten to thirty million lines of C into Rust (or anything else) won't generate more problems, faster, than it fixes.
There are many simple ways to make a lot of C usage much safer, with overhead no worse than, and sometimes much better than, the overhead of mitigating SPECTRE etc. attacks. More than thirty years ago I wrote tiny functions to prevent out-of-bounds and use-after-free accesses in my accounting suite, and the re-coding which I did (in about 100,000 lines of C at the time) was largely automated. There are very similar functions (or macros) in things like Sendmail and in any case there are available safer versions of some of the standard library functions which are either drop-in replacements or very nearly so.
To make a serious contribution to security using these techniques wouldn't take a hundred coders (they're rarely what I'd call engineers) but it would need the will to get it done.
OTOH better documentation could probably make a much bigger contribution.
More than thirty years ago I wrote tiny functions to prevent out-of-bounds and use-after-free accesses in my accounting suite
Excellent idea.
How about incorporating that into the development language and make the compiler capable of making sure everyone complies?
how about using CODING STYLE GUIDES that are comprehensive enough, ONLY allow trusted devs to push their changes without peer approval, and basic project management control over things that are important enough to warrant it.
that, and the occasional code review.
Seriously NOT that hard. Spend time on fixing bugs, hardening security, and *NOT* *IMPLEMENTING* "New Shiny" and MOST bugs and security problems will disappear quickly.
Yeah it's boring, and less interesting than implementing your "wish list", but the rest of us WILL appreciate the lack of moving targets and force-down-the-throat "features".
Faster. stronger, a bit better, and NOTHING ELSE CHANGES (except hardware support). Isn't that the BEST thing that could happen to the Linux kernel?
Notwithstanding everyone's deeply held desire to please Google by Talking the Google Talk, most programmers are not engineers.
Engineers know how to plan and cost jobs. Engineers identify and address points of failure, figure MTBFs. Engineers document the steps from problem to solution to implementation. Engineers must have a thorough understanding of the science which underpins their disciplines.
For the half-century or so that I've been writing code, I've met maybe three programmers who were trained as engineers, and maybe twice that many not so trained but who understand the principles and practices of engineering.
That's nine or ten out of many hundreds. Programmers are, by and large, not engineers.
Engineers drive trains. When was the last time you saw a programmer driving a train?
Language changes. I don't care for the title "Engineer" for software developers myself – and it's in my official title – and I sympathize with the desire to keep "engineer" as a professional designation, though that's certainly not without problems. But this ship appears to have sailed.
Languge does not evolve it is abused and misused to elevate the ordinary in the eyes of others to something they can only aspire to
The same has happend with Architects, which in the UK requires a minmum 5 year training scheme in cluding two degrees and final exam/presentation, failure at any stage negates the possibility of calling yourself an Architect. Compare that with the requirements for a system or solution Architect, which is just a job title and is often just a recorder of what has been delivered, where the name has been hijcked to elevate the mundane to be seen at the same high level as those that have strived hard to be worthy of the title.
In the UK that might be the situation. What were the requirements in ancient Greece where the name, if not the role, originated? Applying your own definition, even by law, does not give you the rights you might think you have over language. ISTR a US state discovering that the hard way in respect of "engineer".
The issue with companies using open source components to support their propritry software is they don't care about their open source software, and the definitely don't support it. Whether that be a Linux kernal, tomcat, python or some other bit. Versions installed are often out of date when they first install it because that is what works, Linux Appliances are often not hardened at all with deprecated protocols like SSL or TLS 1.0 still left active and believe it or not SMB 1 still mandated. I still see companies shipping their own code with no digital signitures, what hope do you have of actually having secure code from them let alone supported Open source version that have regular updates released by them?
Often these companies attitude is if you need stuff patched go and patch it yourself we don't support patching.
They contribute nothing, they don't patch and they don't care, is it any wonder it is so easy for state sponsored hackers to walk in with out any problems to wherever they want?
How much support do Solarwinds provide to any Open source projects?
This is a typical corporate response to Linux -- its an Operating System so therefore it must be something large and impenetrable, an all singing, all dancing, monolithic entity. The idea of it being modular, a logical Lego kit that can be configured to taste, seems entirely alien, I'd guess because it would be something that would be difficult to possess (like a hand full of sand).
When someone says that "Linux needs work" I invariably ask "Which bit?". The most basic incarnation of the OS would be just a handful of components and those components can't all be irretrievably bad.
All the evidence of the stream of security fixes is that the commercial OS have the same problems, the developers are focused on rushing new glamour GUI stuff, not making the core OS secure. Old OS versions get abandoned very quickly, while still in use in many critical systems
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
