12 ms·
>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future vers
by catern 6y ago
>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers.
This is a massive step back for open source. The fact that Linux doesn't have a binary-compatible driver interface is a good thing: It means hardware vendors have a very strong incentive to get their drivers upstream into the kernel. And indeed, on servers and laptops and desktop machines, this has largely happened. But on mobile platforms, with Android, it has not happened. For various reasons, but nothing fundamental.
We would all benefit if Android hardware drivers were upstreamed. This would allow for a much more competitive, and higher quality, software and hardware ecosystem on mobile platforms.
But Fuschia is going in the exact opposite direction: It makes it possible to build proprietary drivers. It's for this reason that I hope Fuschia is not successful. We already have a high quality kernel: Linux. If Fuschia is "not a science experiment", but instead intended to use proven ideas, then any improvement that could be added to Fuschia could be added to Linux. We don't need a new operating system whose only advantage is that it's easier to write proprietary drivers.
- ptomato 6y ago> For various reasons, but nothing fundamental. "Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason. Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option. The open source community is not, for example, going to make their own high performance gpus.
- snazz 6y agoPlus, better isolation between driver code and other kernel code (which Fuchsia seems to bring; correct me if I'm wrong) would be good for everyone, since you can be relatively assured that running vendor-provided driver blobs is safe.
- zozbot234 6y ago"Isolation" of driver code that can talk to on-SoC hardware is just not very meaningful. You can only have real driver isolation if it's enforced on the hardware side via some IOMMU mechanism (or by keeping the hardware isolated on the USB bus, etc.), otherwise you're just adding pointless overhead for no real benefit.
- goodthenandnow 6y agoHere you go: https://blog.quarkslab.com/playing-around-with-the-fuchsia-operating-system.html#process-isolation https://blog.quarkslab.com/playing-around-with-the-fuchsia-o...
- entha_saava 6y agoI didn't get it. Don't we want, for example, wifi driver not to be able to access and corrupt (due to some bug) GPU driver's memory?
- michaelmrose 6y agoDoes this actually happen?
- gigatexal 6y agoI’m sure it does when used to exploit devices.
- exged 6y agoIt's desirable, but typically hardware devices have DMA-capable buses that can read / write to arbitrary physical memory. So a buggy or malicious WiFi driver may be able to use the WiFi DMA hardware to write into the GPU driver's memory, and no pure software mechanism can stop it from doing so. IOMMUs solve this problem by giving hardware devices their own virtual address spaces.
- cycloptic 6y agoI would not say that is a fundamental reason. They have been willing to do it when the proper incentives are there. The incentive to keeping it closed source is primarily part of a strategy to sabotage their competitors, which I hope is not a behavior that anyone here is complicit in. Please don't work for hardware companies that do this, there are plenty of companies out there that know how to spend their money in other ways. >Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? Neither of those are good options because even in the second case, there are still vast swaths of code that upstream is not going to touch out of fear of breaking things, the end result being that you still get stuck with unfixable kernel and driver bugs. >The open source community is not, for example, going to make their own high performance gpus. The open source community includes a lot of companies. The high-performance GPU companies are welcome to join this community any time they like.
- dontblink 6y agoThat is an assumption. I think the simpler case is it's more work and exposes potential security vulnerabilities they don't care to patch or maintain. Function > all.
- deleted 6y ago[deleted]
- fluffy87 6y agoThis claim is wrong. It’s not about sabotaging competitors, it’s about being afraid that your competitors would steal your IP they gives you an advantage. Every Nvidia and Intel competitor (AMD) is probably already reverse engineering their binary drivers and binary libraries trying to steal their IP, so Intel and Nvidia’s fears are imo justified. If NVIDIA or Intel could easily protect their open source code from being stolen from AMD, the story would be different. But you can’t prevent somebody from reading even GPL code, being “inspired” by it, and writing something different enough that does the same thing with the same ideas. Like just look at the LLVM project were people look at what GCC code does every now and then for “inspiration”.
- lain-dono 6y ago> The open source community is not, for example, going to make their own high performance gpus. I think we should lower the entry threshold first. The open source and free GPU project was the first thing that came to my mind when I saw http://llhd.io/ http://llhd.io/. After all, one of the main problems with OpenHardware projects is the closed FPGA ecosystem.
- sam_bristow 6y agoIt's pretty amazing how far the open source FPGA tooling has come in the last few years. I'd even go so far as to say some parts of the open source ecosystem have surpassed the commercial tools. Still a long way to go of course, but I'm pretty positive about the direction things are heading.
- NOGDP 6y ago> The open source community is not, for example, going to make their own high performance gpus. Of course it will.
- VikingCoder 6y agoThe first GPU came out twenty one years ago. Why on Earth do you think all of a sudden we're going to get something we've never gotten before?
- pabs3 6y agoThe RISC-V community is already working on GPUs, some of them open: https://github.com/felsabbagh3/Vortex https://github.com/felsabbagh3/Vortex https://news.ycombinator.com/item?id=22492902 https://news.ycombinator.com/item?id=22492902 https://libre-riscv.org/3d_gpu/ https://libre-riscv.org/3d_gpu/
- sharpneli 6y agoDoesn’t look that good to me. The Vortex is not a GPU. They call it GPGPU, meant purely for running OpenCL kernels, doesn’t have a graphics pipeline at all, which is kinda important part of a GPU.
- liuliu 6y agoI am not so sure about that. GPU has been slowly moving away from having a fixed graphics pipline at all in the past a few years. See the recent Nanite technology from Unreal 5: http://c0de517e.blogspot.com/2020/05/some-thoughts-on-unreal-5s-nanite-in.html http://c0de517e.blogspot.com/2020/05/some-thoughts-on-unreal...
- sharpneli 6y agoThey use compute shaders for triangles that cover 1 pixel as rasterization always does 2x2 due to derivative calculations etc so there is overhead. For larger triangles they do go trough the rasterization pipeline as usual because it is so much faster. Another crucial thing is texture mapper. That thing is really fast and usable even in the compute pipeline. Image support is (was?) largely optional in OpenCL. Also I remember the last time people talked about this. PS3 was not originally supposed to have a GPU at all because the Cell processor was so powerful. In the end they had to ram in an actual GPU. While the Cell was just fine for vertex processing it did choke terribly in rasterization due to lack of TMU and dedicated HW rasterizer. EDIT: I also want to emphasize the difference of target markets. On AMD one can go to the Nanite path for some of the rasterization. One must remember that it is a non battery powered device. Memory bandwidth is really power hungry. For mobile, the likely target market for the Vortex and similar, one really wants to do tile based rendering. Ideally the way IMG does it. Even though theoretical flops of modern mobile GPU’s is higher than some old discrete ones their memory bandwidths are way lower, so no running Crysis on modern mobile even though flops would indicate it would match a good discrete GPU back in the days.
- naasking 6y ago> Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option A phone in which the kernel never needs to be updated, like with the seL4 microkernel.
- terminalcommand 6y agoMost BIOS are also closed source. If I used a microkernel primitive enough not to require changes, I could live with not updating the kernel unless there is a security bug. A third solution could be to require device manufacturers to share their source code with a trusted third party (such as google/certification authority). This third party will make sure that the driver does not include any harmful code and provide signed binaries. Binaries could also be updated for newer versions that way, even if the original manufacturer loses interest/goes bankrupt. If the IP gets stolen, the device manufacturer could sue this third party, therefore business people will also feel secure. It is not ideal, but I could be able to live with this solution.
- CJefferson 6y agoWhile I understand why you want open source drivers, the situation hasnt improved for 10 years, and this is one of the major reasons many phones end up not getting Android updates, which makes Google/Android look bad.
- est31 6y ago> the situation hasnt improved for 10 years But it has. * I remember having major issues with printer drivers on Linux 10 years ago. Nowadays thanks to IPP support I don't need any drivers any more. I had to help my dad with installing a windows driver while on my Linux laptop it just worked. * My Laptop from 13 years ago didn't have free network drivers. I had to jump through hoops to install them. Now they are all free. * AMD has started maintaining really good open source driver support for their GPUs * Even for Android there is improvement, with e.g. free Mali drivers being built. It's slow and not enough, but improvement.
- rohan1024 6y ago> the situation hasn't improved for 10 years I believe its meant in context of Android.
- pjmlp 6y ago> AMD has started maintaining really good open source driver support for their GPUs Still waiting for them to reach parity for my laptop GPU, it used to be OpenGL 4.1 with hardware video decoding, nowadays I just get OpenGL 3.3 with the open source driver, the antithesis of really good.
- bgorman 6y agoI believe the situation is a bit better now that there are LTS releases of the Linux kernel.
- damnyou 6y agoA big reason why Fuchsia exists is governance — Google wants to make a kernel that it controls. Linux cannot provide that advantage unless Google forks it.
- ReactiveJelly 6y agoIt's a negotiation, and the hardware vendors seem to be 100% happy stepping away from the table and letting old hardware suffer. They have a lot more leverage than we FOSS supporters do.
- AnthonyMouse 6y agoWhat this is really about is Qualcomm. They have inadequate competition and that allows them to abuse everybody else. In a competitive market, open source drivers win. Look at the desktop market -- nearly everything is open source, and the biggest holdout is nVidia, because for a while there nobody was challenging them on performance. Now that AMD has competitive GPUs again, not only does that provide a competitive option with open source drivers, nVidia is now losing market share to them. OEMs don't really like proprietary drivers. They're a pain. Whenever new driver versions come out, it becomes the OEM's problem to test and distribute them instead of having the Linux kernel team deal with that hassle. The open source drivers also generally have fewer bugs (because anybody can fix them), which leads to fewer support calls and more satisfied customers who make repeat purchases. And customers naturally prefer hardware with longer hardware support, when it's available. What we need is more competition for Qualcomm. Google could do that if they wanted to -- throw some money at making competing phone chips. Apple does it, why can't they? And then publish open source drivers and sell the chips to anybody. We also have AMD as a dark horse now. The Ryzen 4000 series goes down to 10 watts -- it's so power efficient you could squeeze it into an Android tablet as-is (and then be a lot faster than most tablets), and it wouldn't take much on AMD's part to do something that could work in a phone. Android is an open source system with apps that run on the JVM, so the architectural difference shouldn't matter much. Or we could get the antitrust authorities to stop letting Qualcomm buy every competitor that springs up, which they've been doing for years. But you solve the competition problem and you get open source drivers. Along with all the other benefits of real competition.
- zozbot234 6y agoQualcomm has plenty of competitors. Mediatek, Allwinner, Samsung, Broadcom etc. They all have the exact same issues wrt. driver support: they do the minimum work required to bring up their board with one heavily-patched kernel version, and that's it. Allwinner now has quite decent support from the mainline kernel, but only because of 3rd-party efforts. It's not just Qualcomm: these problems are shared by every embedded SoC to date, with very limited exceptions.
- netdur 6y agosorry but that's just naive idealism, my wife has android flagship, a Samsung s10, she will receive one more year of updates, then she will be on her own, my daughter has iPhone 6S, this old device will receive iOS 14 soon. my wife do not care about updates, she will not hesitate a second to get iPhone once she knows her social media or pictures is not safe on her android device, this is the issue Android have and Fuchsia have to fix.
- plerpin 6y agoI'm pretty sure Qualcomm not giving a shit about supporting their SoC is why my Android watches were practically EOL'd within months.
- zozbot234 6y agoNot sure how Fuchsia is supposed to solve this. If you can port those Qualcomm SoC drivers to the fixed Fuchsia interface, you could just as easily port them to the mainline Linux kernel and submit them upstream.
- plerpin 6y ago"Easily"? Some things can only be shipped as binary blobs. For example, you won't get open source audio drivers that support patent-encumbered codecs like Dolby Atmos. Windows has a stable binary ABI which means that my drivers don't go stale when Microsoft pushes out a minor rev to the NT kernel. Windows does its updates and my peripherals [mostly] work just fine.
- StreamBright 6y agoExactly. It is kind of funny how IT people look through their tech glass and think that the rest of the world (99.9999%) does the same. Nobody cares about software, everybody cares about user experience. Linux proved the point that having unstable driver interface has nothing to do with the success of the platform.
- 6y ago
- uluyol 6y agoOnce upon a time, Linux had terrible support for laptop hardware. Remember ndiswrapper? That thing you used to get Windows wifi drivers working on Linux. Or how about when ATI (AMD) provided only the most buggy drivers. How about printers? These days Linux has better hardware support (imo) than Windows. Solving it for laptops was about creating the right incentives for hardware manufacturers. It can happen for mobile too.
- zaat 6y agoI wouldn't say Linux has better hardware support than Windows. When your hardware is properly recognized and supported by Linux than yeah, I do feel it operates much better, more stable and have more knobs. However, not all hardware works at all. For example, as of now, the hardware sensors on my x590 board are not recognized. LED control is not a thing, even on most old/established boards (you can argue if LEDs are nice or ugly, but if they are there I want to control them). Even enterpriseish devices, like Lenovo's X1 laptops, that are CERTIFIED by both Red Hat and Ubuntu, have limited hardware support at best. Fingerprint scanners on 3 year old models are still not recognized, and there seems to be zero will from synaptic to ever support it. Sleep states were terrible for a long long time, finally fixed in a fashion that requires different firmware for optimal sleep performance on Windows or another one for Linux. So no, my experience is that still hardware vendors are not giving me as a Linux user the support and value for the good money I pay for their products. Obviously they don't deliver the expected level of support any reasonable consumer would expect, and most probably won't deliver it in the future either, since they get away with it so easily.
- zozbot234 6y ago3 year old hardware is still very new by Linux standards. Especially wrt. hardware classes for which a unified support framework has yet to be provided, including RGB LED's and fingerprint scanners. The sleep performance thing is an interesting example, since the whole issue was caused by hardware OEM's deprecating the old ACPI "sleep" state and deciding that OS's should manage standby states entirely on their own - this too will require a lot of really hard work to be supported properly across zillions of devices.
- cameronbrown 6y agoI really want to agree with you, and in principle, it would be far better for hardware manufacturers to upstream their drivers. In practice this hasn't happened and will never happen, because there's no incentive to support hardware no longer making money (a chip is only sold once, after all). I think the mounting cost of e-waste is a far bigger deal. Think of the unimaginable amount of carbon impact from the millions of trashed Android phones out there. Do we really want to continue down this path, until there's billions of obsolete machines sitting in landfills (there probably already is)? Updatability can save devices for much longer, and now people are upgrading less often, there's a huge opportunity for impact there. Disclosure: I work for Google, but not on the Android OS or Fuchsia.
- dahfizz 6y ago> Updatability can save devices for much longer I'm skeptical of this. People buy new phones because they are faster, or because they did update and the new version of the OS is very slow on old hardware. People buy new hardware because they want new hardware. Most non-tech people I know actively avoid updating their phones because it's annoying. They will ignore the notifications and choose older software over the inconvenience of updating and rebooting their phone.
- terminalcommand 6y agoHardware has its limits of course, but sometimes if you can’t upgrade your OS, you can’t install apps. You’ll be stuck with a screen saying “This application requires IOS X and higher”. When that frequently happens, you are forced to upgrade your phone, even if you’re content with the hardware. Avoiding updates and ignoring notifications could stem from a different reasons. People may not want to take the time and maintain their phones. I consider myself a techy person, but I also put off updating my phone, taking good care of it, upgrading it. I also dread tidying up my room, getting a hair cut, shopping for clothes, eating healthy, sleeping well etc. It could be a personality trait. Avoidance conserves energy :)
- VikingCoder 6y agoI think your take on this is very wrong. An open source driver written once will work for all future versions of Fuschia. Right? That reduces the effort for open source developers enormously. Most security flaws come in above the driver level. Right? Being able to update the OS, despite the hardware manufacturer's laziness, is a huge boon for everyone. Fuschia is open source. Drivers written for one Fuschia (say, the one Google controls) should work for another Fuschia (say, the one you and your friend forked.) Right? That's a huge win for you. Whatever incentives you have imagined that hardware manufacturers have, time has proven those incentives don't work. It's far better to take as much control away from them as possible. They will do the minimum amount of work necessary (write new drivers). Then we can all exploit the hardware + driver + Fuschia system. It has always, and will always, be possible to build propriety drivers. This is minimizing the blast radius of them never being updated, as much as possible. For these reasons and more, we should all hope Fuschia is successful. The Android developers who have tried to live on top of Linux are sick of the problems that Linux brings them. Fuschia is an open source direct response to those limitations. It's stunning to me that you would wish them to fail. "then any improvement that could be added to Fuschia could be added to Linux". Explain to me why we still have BSD? Not all problems are solved by Linux. The sooner you accept that, the better off we will all be. It's like you're wishing Clang would die, because we can always just improve GCC. That's demonstrably false. Just like saying everything good in Fuschia can be added to Linux. No, it can't. "We don't need a new operating system whose only advantage is that it's easier to write proprietary drivers." Wait, if it's easier to write propriety drivers, doesn't that lower the barrier to making low-cost phones? Well, Christ, sign me up. Do you have any idea how many billion people have a low-cost smart phone as their first computing device? If we lower the cost even more, that will broaden the reach even more. Do you seriously not get that the other major phone OS is completely closed source? Maybe put a little faith in the people who have developed the most successful competing operating system that's open source?
- josephcsible 6y ago> An open source driver Lost you already. Since Fuchsia uses a pushover license instead of a copyleft license, the vendors' drivers aren't going to be open source. Look how many companies today don't open-source their Linux drivers, and they're breaking the law by not doing so. It's going to be so much worse when there's "nothing" wrong with keeping them proprietary.
- sanxiyn 6y ago> We already have a high quality kernel: Linux. Linux is full of security bugs. It is ludicrous to suggest Linux is high quality. OpenBSD, maybe. Not Linux.
- gregkh 6y agoCitation needed :) Seriously, all software has bugs, how do you judge the quality of an operating system that is not finished?
- pjmlp 6y agoDoes Google itself help? https://events19.linuxfoundation.org/wp-content/uploads/2017/11/Sub-system-Update-Kernel-Self-Protection-Project-Kees-Cook-Google.pdf https://events19.linuxfoundation.org/wp-content/uploads/2017... https://outflux.net/slides/2019/lss/kspp.pdf https://outflux.net/slides/2019/lss/kspp.pdf Slides from 2018 and 2019 talks.
- thayne 6y agoI'm torn on the subject of a binary-stable driver interface. The idealist in me likes that it forces vendors to open source their driver code, but the pragmatist in me knows that some vendors (like a certain graphics card manufacturer in the desktop and server world) probably never will open source their drivers, and if they do, they may not be as high of quality as the proprietary version for other OSes. I wonder if there is some middle ground. Also, even with open source drivers, the lack of stability has downsides, such as requiring you to recompile all drivers whenever the kernel updates. Maybe where a subset of the ABI is stable, so it's possible to build driver binaries that work across kernel versions, but there is still some incentive for keeping drivers open source? > any improvement that could be added to Fuschia could be added to Linux This is not necessarily true. Some things certainly. But linux is constrained by keeping a backwards compatible user-space interface, and being mostly posix-compliant. For example, fuchsia doesn't have fork or exec (it has a single spawn function/syscall instead). Linux could add a new spawn syscall, but has to keep fork, clone, execv, etc. forever. And even if most new code moves to use the new syscall, the complexity around the old ones will be around forever.
- combatentropy 6y ago> any improvement that could be added to Fuschia could be added to Linux Not easily. If Linux has gone down a path far enough, it may be hard to reverse, especially if it is of fundamental design. For example, the separation of kernel space and user space is different. I am not an operating system engineer, but I would bet that certain things would be hard to change --- deep structural decisions mentioned in the article, like: - the kernel primitives are exposed to applications as object-capabilities - applications can interact only with the objects to which they have been granted access explicitly - applications interact with each other and the system using message passing > use proven ideas I would say in the realm of software there are still competing ideas, even if you narrow it to the subset of ideas that are good (secure, maintainable, fast, etc.). Linux chose some good ideas, but if you want to try out different ones, you may have to start from a clean slate.
- goodthenandnow 6y agoThere is also de fact that the concepts/model of Zircon's kernel API and Linux one are diferent and in some cases mutually incosistent if implemented in the same kernel
- kbumsik 6y ago> It makes it possible to build proprietary drivers. Even worse, Fuchsia aims to be BSD License, not GPL. Fuchsia is a complete disaster for hobby OS makers.
- pjmlp 6y agoApparently everyone is unhappy with GPL. In a couple of years the same people will understand why it exists in first place. I guess they are having fun running FreeBSD on their PS4s, thanks to Sony, hence why they aren't paying attention.
- StreamBright 6y agoI would say this is one of their biggest advantage over Linux. >> This would allow for a much more competitive, and higher quality, software, and hardware ecosystem on mobile platforms. I have no idea why you think that. Any proof? How would you measure it? >> It makes it possible to build proprietary drivers End users do not care about opensource vs closed source, they care about the user experience. Based on your thesis, Linux would be the best operating system with the most market share out there because it features everything you say, yet it has a negligible share on desktop. Empirically proving your thesis being wrong.
- pjmlp 6y agoEveryone is having their go at this, blame younger generations for fighting GPL, while favouring other license models. GPL is the only reason Linux still exits, not for long though, when even Linux Foundation has decided to go with something else for IoT, namely Zephyr, which is neither Linux based, nor under GPL license. In about 20 years we will be back at shareware and public domain, enjoy what is left while it lasts. It doesn't matter if Fucschia is a success, Android is already like this, since Project Treble, Linux drivers are "legacy" drivers on Android, all new drivers use a microkernel approach with Android IPC, basically how Fuschia drivers work.
- ahartmetz 6y agoThe Linux Foundation has a misleading name: it's essentially the Megacorporations Linux User Group. It wants whatever its member companies want. It does not really want to promote Linux or, say, enforce the GPL.
- pjmlp 6y agoIndeed, and while I am mostly a user of commercial software, I appreciate the work that Stallman and FSF have placed on the GPL. Whatever non-copyleft licenses allow for, it was already available via public domain and shareware like licenses. Yes, GPL makes is very hard for certain kinds of business models like games or desktop software in general, however when people complain about its existence, most seem to blind to the fact that they only have Linux and GCC because of GPL, and clang wasn't around until 2007. Had it not been for them, and most likely all commercial UNIXes would still be around.
- henearkr 6y agoI agree with what you said, however what is even more adding to the confusion is that the Linux Foundation is Linus Torvalds' employer...
- ahartmetz 6y agoI left that out to avoid opening a can of worms, but yeah... If I was Linus, I might also avoid raising a stink because the Linux foundation does a few things that need to be done, and the damage it is doing might be less bad than what happens after discrediting it.
- fluffy87 6y agoThis has only happened on Linux for commodity hardware. But Nvidia and others (hpc interconnects, routers,...) usually ship their own proprietary drivers, or even Linux forks.
- rwmj 6y agoI guess that Linux will quickly get an "NDISwrapper" equivalent that can run Fuchsia binary blobs. We'll all be a little bit worse off as a result, but with mostly working peripherals.
- BiteCode_dev 6y agoI'm a strong FOSS proponent, most of my software is released under MIT, I use Linux daily and help others to use open source as much as I can. And yet I find this idea total BS. The reason I could even migrate to Linux when I was a teen was compatibility. It's because free softwares (VLC, Firefox, OOo...) were ported to Windows, a proprietary plateform, so that I could then feel at home later on Linux. And I made a definitive switch thanks to Ubuntu, because it made using most hardware easy, by accepting to use proprietary drivers when required. Strong arming the industry into Libre never worked. The GPL is one of the least popular licences for this very reason. I, myself, never uses it. Representing close source as evil doesn't work either. It's like being vegetarian (which I am) and guilt triping people about meat. It's completly counter productive. The result we got is that the year of Linux on the desktop never happened, because playing on Linux is hard, because the last cool gadget doesn't work, because you have to carefully chose your laptop to be sure it will work with it (E.G: my XPS 2-in-1 webcam doesn't work on Linux). It also adds a lot of work to the kernel devs to try to keep up with the outter world, but they have a limited bandwith. So Linux BT still sucks (even more than regular BT). Wifi is still not on part with the XP on other OS. Batter life is abysmal (I'm dual booting, and the difference is X2). All for an ideal we never reached anyway. Help and encouraging for FOSS makes a better world. Being pushy about it hurts us.
- ryukafalz 6y agoI disagree. For starters, strong arming the industry has worked in a number of cases; this has been covered in a few other comment threads so I won't retread them too much here, but the state of free drivers on Linux is significantly better than it was just a few years ago. More broadly though: what kind of world do you want to live in? A world where it's easy for companies to create new proprietary software, or a world where it's easy for the users to shape their computing experience? Look around you, at the consumer devices you own. Can you name one that's: 1) aimed at consumers (i.e. not a dev board, Raspberry Pis and such don't count here) and 2) that you have most or all of the source code to? Look, if your goal is just "make better software" in general, maybe permissive open source has been a success. But if your goal is to increase practical user freedom, it's been an abject failure. It's just helped companies to make proprietary software more cheaply. And sure, there's some interesting technology that comes out of that for developers, but in the vast majority of cases the users don't see the benefits! Surveillance capitalism marches on, bolstered by the free labor of the community. This is why I've been so disheartened that parts of the community have turned so anti-copyleft recently. In a world of permissively licensed software, the incentives are stacked against free software for end users. In a world of GPL'd software, you can release your code as GPL too, or you can pay more to write it all yourself.
- _ph_ 6y agoThe fact that Linux doesn't have a binary-compatible driver interface is a good thing: It means hardware vendors have a very strong incentive to get their drivers upstream into the kernel. I think it is a horrible thing and a reason to deter hardware vendors from supporting Linux at all. Even with the best intentions and open source drivers, it adds maintenance burdons to the hardware manufacturers. And some hardware vendors cannot go open source at all, as they might have licensed other code to implement their drivers or have other valid concerns not to open up their drivers entirely, like for IP protection.
- tbodt 6y ago*Fuchsia