Here's a little Intel: Beware of Linux graphics vendors bearing gifts of shared code – open-sourcer Intel's driver support for Linux is improving, but has raised an eyebrow or two within the open source community as a Mesa contributor noted that Chipzilla's code-sharing development model was not necessarily a win. Dave Airlie, a senior engineer at Red Hat, Linux kernel developer and contributor to the Mesa graphics project …
"A warning then to anyone wishing for more vendor code sharing between OSes it generally doesn't end with Linux being better off, it ends up with Linux being more fragmented, harder to support and in the long run unsustainable."
A sign of things to come.
Hopefully this sound warning will be taken into account.
And those responsible will act accordingly.
O.
Detach your expectations of open source philosophy and culture from your association with the phrase open source. Open source is no more useful a term than human to describe anyone other than by the lowest common denominator and changing the winge from your not sharing, to your not sharing properly seems a bit petulant
End of the day if the code is publicly available and licensed in a manner to allow modification and sharing free as in beer yadda yadda, it's open source, not all projects are community driven or even accept contributions from outside of the organisation, end of the day nothing stopping you forking the code and building a community from your fork (mariadb...), many different styles of open source out there really doesn't need to get religious and dogmatic over how each project/product is run. I dare say the org chart nightmare inside of Intels dev teams makes it community driven enough internally without needing to further complicate matters
I dont see how, in my experience a lot of open source talking heads mistake the community aspect for the open source part and do get quite religious and dogmatic about it, your not open sourcing properly, we dont want those sort of contributions, no you need to rework your contributed codebase to fit in line with our guidlines etc.
While the code style one i can understand, it also smacks of looking a gift horse in the mouth, view large org contributed code as donations, cus you can bet the politicking going on behind the scenes to get it to be allowed to made public was not inconsiderable, and there will be 0 interest from the org of changing things to fit a projects wishes if it means changes to workflow and day job effort. Best thing to do in my opinion here is rather than get upset that they are not community or what ever creed of open source they follow driven, take the donation and the community will work it into something, if it needs it, or just dont accept it into your main repo/distribution
In this case it seems more like they wish it was developed only for *nix as it would be more optimal (seems arbitrary hence religious and dogmatic), rather than more generalised but OS agnostic in places (which makes infinite sense as a strategy for intel to pursue; consolidating effort [for consistent bugs and 0 days on any platform ;)], and reducing code duplication etc., so why would they care about what an external project wants, this is about intel's efficiency ,management processes and ultimately shareholders, with the upshot that the source has been opened...)
I agree that public availability is good but my take from this is that the Intel process is a 'You get what you get' with no opportunity to have people understand how the code got to where it is which is critical for support or even forking. I have no idea what the level of commenting is inside the code which may explain thought processes which may make my point moot but even if the Intel devs are a complete souk it is still a single corporate structure and objective which will drive the code direction.
Apologies for the rambling incoherency, must be due more caffeine
Dave is the guy who has to deal with the integration problems this sort of throw-it-over-the-wall no-external-contributions code implies. It's a hell of a lot more work than it would otherwise be (and I can say this as someone who's been on both sides of that fence, both throwing code over the wall in a project my then bosses didn't allow me to open, and trying to integrate another such project with a larger system, which was much like trying to get blood out of a stone only less pleasant).
This isn't dogmatism, it's common sense.
For some, open source means "I have an idea and I want more resources to develop it; here is access if you want to help". For others, open source means "I am making a thing for myself with my own resources, but I think others may find it useful too; here it is if you want it". I don't see either position to be ethically superior to the other.
I can see that there are situations where one position is more _convenient_ for others than the one that is being taken. However, I think it's usually difficult for someone who is in one of those positions to switch to the other, and I think it's unfair to blame them if they won't. They are really rather different situations.
Somehow I think that when you look into the details, very few people outside Intel will actively develop drivers. People will submit bug fixes, but that doesn't require an involvement at the development stage, and the weekly or monthly drop will be fine.
I am certain that if someone as senior David Arlie wants to get involved, Intel would invite him into their office. They'd probably pay him for his time too. Is there a motivation to work on a public GitHub repo and expect significant patches to come in, though? For unreleased Intel graphics cards?
A complete GPU software stack that doesn't taint the kernel is worth having, whatever it takes.
By "complete" I mean a VDPAU equivalent, the same crypto-mining performance as the closed source driver, etc etc. (hopefully Intel won't even release a closed source driver... there's no point for a hardware company to stick to closed source).
The old Intel 3D hardware (from like 15 years ago) was great as far as GPL driver support - 3D screen savers worked out of the box without kernel tainting.
ATI (AMD?) tried and failed to get a proper open source GPU driver, and NVIDIA isn't even pretending to care about the GPL. Intel has always been better about this -- hopefully their new GPU line will finally make kernel-taint-free GPUs a reality.
"there's no point for a hardware company to stick to closed source"
hmm, except to keep a breakthrough industrial know-how out of the hands of yours competitors.
and i don't care about your crypto currencies.
fact is the manufacturer of yours microchips are the first to use the stock exchange. they don't give a shit about your war.
a war behind a screen is always easier than a real one ...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
