This is why the Linux kernel runs and will continue to run the world.
The No men is all that stands between us and the Yes men.
Praise and salutations to the No men, God bless you.
The No men is all that stands between us and the Yes men.
Praise and salutations to the No men, God bless you.
I think what you mean is "I get the idealism but you also need to be realistic." It's not pragmatic to stand your guns and ask a multi-million dollar company to change the code they submit to your open-source project.
All of these people pretty much contribute their free time to it.
If they can't make basic architectural decisions that improve the worst kinds of work (driver authorship and maintenance is awful drudgery) how can you expect them to feel any kind of ownership over their fate?
You're asking unpaid people to do the work people get paid for. Even worse, when this work just gets dumped on those unpaid people by people who are paid quite well.
[0] 4.5 Development statistics https://lwn.net/Articles/679289/. Just google lwn Development statistics for more.
Oh but it is in their employers' interest. It's the price of admission for mainline. And if they want in on mainline, wether simply to harvest PR or to net a contract that demands a mainlined kernel; they have to pay it. Just another case of the well-known "cost of doing business".
In the case of AMD I believe they want to reap the benefits of mainline (that is, not having to support the breakage that comes with being out of tree) and to be able to compete better with Nvidia; since AMD is unlikely to ever develop an OpenGL implementation as good as theirs but Nvidia cannot or is unlikely to be able to open source their driver.
In my opinion the existing AMDGPU code isn't exactly spectacular as it is. They barely have comments or commit messages and there's a ton of duplication. Linux has issues with keeping driver contributions up to snuff as it is, without enormous vendor-specific HALs everywhere.
What I see here is (sadly, again) two groups of developers unwilling to meet halfway and understanding each others problems. Expecting AMD to support a completely separate driver just for Linux is unrealistic. Expecting a 100kLOC code dump do be accepted is unrealistic as well. I don't see anyone talking about how to get over this hurdle on lkml, I just see the single least constructive word: "No."
Meanwhile, 3D support in Linux will remain a crappy tire fire which works well only if you use a completely proprietary nVidia driver.
-Dave Airlie, in TFA.
1. There is absolutely value in rejecting bad, or even good but unmaintainable code from your codebase. How is this even an argument?
2. The 'devs' don't just all meet and then decide to blow each other off anyway, AMD is simply in a position with Steam where they want it to "just work" for most games at the lowest investment cost possible. They took a gamble and lost.
3. A updated proprietary driver is not ideal, but works better than making the OS worse. Again, not sure you can really disagree.
It is a lose-lose situation for a developer. If I write open source software, people will demand more and more from me. If I say, "screw this, I'm just gonna release a blob." they will ridicule me while ignoring the fact that I am releasing the blob only because they pushed me to. /rant
The maintainer explains the pragmatism explicitly:
> AMD can't threaten not to support new GPUs in upstream kernels without merging this, that is totally something you can do, and here's the thing Linux will survive, we'll piss off a bunch of people, but the Linux kernel will just keep on rolling forward, maybe at some point someone will get pissed about lacking upstream support for your HW and go write support and submit it, maybe they won't. The kernel is bigger than any of us and has standards about what is acceptable
Rejecting half-assed patches is pretty pragmatic, no matter who the author is. Maintaining standards is pragmatic because 'your open-source project' is the one that will be maintaining (refactoring/rewriting) the code in the future, not the muliti-million dollar company.
That has basically been Linus' Torvalds job for the last 20 years. People want to contribute to the Linux kernel to get support for the thing that they are interested in, but often the code that they are offering should not be accepted as-is, because it will make Linux as a whole that bit worse. See DBus for an example where clever people strongly put forward useful functionality, and got push-back. The end result was that they went back to the drawing board, and designed something better.
AIUI, the reason that the AMD and nVidia proprietary graphics drivers are a terrifying mass of hacks on top of hacks is trying to say yes to everything. Years later, the vendors can only move forward by setting fire to the whole lot.
The majority of APIs are not exposed to NDK users, only to OEMs.
Google could release lets say Android 8 with another POSIX compliant kernel and the only apps that would notice are the ones using non official APIs.
Currently, Android is released using Linux kernel, ELF executable format, POSIX API's, and so on. There is no Android/kFreeBSD, nor Android/NT.
Android games can be launched on Linux using android libraries (not all, but some works pretty well, see: http://www.shashlik.io/showcases/ ).
Linux tools can be launched on Android systems (including X based tools, if X server is running).
For most of practical purposes, Android is Linux.
Debian user space isn't the same thing as a kernel.
Android kernel doesn't expose the same syscalls as a standard Linux.
I am really keen in having Google replacing Linux with Magenta, then we can carry on this discussion about what Android is supposed to be.
And, frankly, if Google decided to swap out Linux for, say, DragonflyBSD, almost no-one would notice or care.
Where in Android, you just get Java and a tiny bit of C and C++.
Check the NDK documentation, Google provides a list of the set of APIs any NDK application is allowed to use.
Since many used to ignore that list, starting with Android 7, any app that uses unauthorised native libraries will get killed.
Fork Android OSP and fix that. I'm sure that CyanogenMod will allow me to use native libraries as much as I want.
Compiling and using a vanilla kernel instead of the distro one is straightforward and easy job for people with basic knowledge of source building. It's not a job for "very few brave souls". The reason many people use distro kernels is because they're good enough.
OTOH any consumer Android device requires millions of loc patching to a several years old version of Linux kernel just to boot.
BTW. I'm not sure if my distro (Fedora) will work with vanilla kernel without Redhat patches. There was times when it wasn't. I compiled kernel myself with my own patches and configuration in between 2001-2008.
What I'm trying to tell is it being possible doesn't mean it is practically possible.
Android specific API or subsystems are one part of it, then there is device specific patches. Kernel and patches being open source makes it possible to switch to a new kernel version but I've almost never seen that exercised. Few years ago the stats were that a typical consumer phone contains millions of line of patches on top of the selected upstream kernel version. It is not feasible to rebase a typical device to use a newer kernel version, and it really shows: I've seen only few phones that got a newer kernel version than it originally shipped with, switching from an ancient kernel version to only slightly newer but ancient kernel version.
> BTW. I'm not sure if my distro (Fedora) will work with vanilla kernel without Redhat patches. There was times when it wasn't. I compiled kernel myself with my own patches and configuration in between 2001-2008.
I'm pretty sure it'll. Linus himself uses Fedora and he likes his kernel pure vanilla :)
There's a lot of people that care about gaming, even if you don't.
The gaming and demoscene cultures don't care 1 second how much their tools cost, the openess of hardware and software tooling, rather the achieved results and getting their stuff on the hands of users, regardless how.
The GNU/Linux culture is all about the ideology of having stuff for free, replicating a desktop experience as if CDE was the epitome of UX, fulled with xterms.
Of course I am generalising and might get tons of counter examples, just noting my personal experience regarding friends and co-workers.
Yeah, no. Having free stuff (as in speech), yeah. Having stuff for free ? That's not the UNIX culture...
Uh, no. It's about having the freedom to fix, improve, or otherwise modify the software you use. Being free-as-in-beer happens to be a requirement for that, but it isn't the goal. Think about it this way: free software developers get paid to do work, instead of getting paid for having done work like proprietary software developers. You pay me to implement feature X, which is then released to the world for further improvement in the future.
No point trying to play D. Quixote attempting business on the desktop with such mentality.
When they're equivalent products there's really not much to pay for though. That should push the costly product to improve more or else lose sales.
("Do users do X often?" isn't the question; "do they get annoyed when they can't?" is the question, and hardcore gamers tend to have one computer for gaming and oftentimes other computers for other stuff; if they were even using Linux on those it'd be a paradigm shift)
And before anyone mentions Android and ChromeOS, Google can replace the kernel and only OEMs writing drivers, most of them closed, would notice.
Nothing to do with Windows and OSX being bundled with the hardware /s
I'd be willing to bet that most people really only want windows to appear quickly, scrolling in web pages to work well, and to watch videos online.
Lots of casual gaming has moved to mobile, and never left the consoles. Hardcore gaming -- not most people.
In any case, why are you updating the kernel version every month?
Video tearing has been a constant problem if you use any type of compositer like Compton or the one that comes with XFCE or GNOME. I tried it on various systems and the tearing is there. A lot of people don't seem to mind though. For some reason, the Ubuntu maintainers don't think my hardware (or rather all laptops) should have the capability to hibernate to disk so they disable the /sys/disk (Im not sure I got the correct filename) which enables suspend to disk (this is one of the reasons why I need to use mainline anyway). PulseAudio doesn't play nice with DACs, ALSA is a pain to set up.
I really like Linux (so much that I keep 'ricing' my system) but these are the kinds of things that I'd rather not spend my time on.