Matthew Garrett: How-To Drive Developers From OS X To Linux

[Guest]

Nope! Here is the killer with Linux, new hardware requires new distros, often bleeding edge distros, to support that hardware. This support for new hardware has never been as good as what Apple does and frankly Apple is at best slow fully supporting new hardware.

Good joke. To run newer games and software people have to upgrade their shitty os x. Linux is far superior when comes to number of supported hardware. Apple has better driver support in some cases, but drivers don't belong to apple. Only idiot will buy a mac which has terrible performance and broken graphic drivers.

[zanny]

2). A company with enough clout and interest to bring Linux to the mainstream desktop.
Valve is the answer to #1 and likely the answer to #2.

How is Valve bringing desktop linux to the mainstream? The Steambox has Gnome, but it boots to Big Picture Steam and requires the wherewithal to know you can get to an actual desktop. It also targets consoles, not personal computers. When they are in stores, nobody will equate Steamboxes with personal desktops.

We need a company that can put laptops running Linux (since Valve uses it, why not Debian? The other options all have their own corporate interests) next to Windows laptops and Apple ones in stores. That requires huge capital nobody seems to want to put on the table - Dell and HP, the current frontrunners who are the closest to this goal, do not seem to have any motivation to do so since they already dominate the in store Windows space. Why replace devices they are already selling with new devices they would certainly hear more customer support demands from just because its not Windows? The only reason they would ever do it is because of Windows 8, but that horse already has pretty much left the stable. If Windows 9 is even worse, there is always another chance, but again it requires a third party company to jump in right when the wave is at its peak.

[chrisb]

I doubt there would be success. Ubuntu isn't all it is cracked up to be.

You might say the same thing about Chrome OS. Anyway, the distribution isn't really important, what is important is the concept of pre-installing on supported hardware. Acer sold millions of netbooks running Linpus Linux, nobody knew what Linpus was, but they still bought the netbook running it. And they didn't need to mess around trying to get a downloaded iso booting, repartition a drive, install a boot loader, configure their sound card, or install video or wifi drivers, or any of the other Linux problems. It just worked.

I'd be willing to suggest that 20% is pretty optimistic. I have never seen a Chrome device in public.

21% is surprising, especially when Chrome OS is such a new platform, the figure comes from NPD. Interestingly, nobody seems to be disputing the figure, so until someone does it is reasonable to assume that it is accurate. The only qualifier is that it refers to "US commercial sales" - by which they mean commercial sales of preconfigured (not bare) laptops in the US.

Their graph of sales of all devices (desktop+notebook+tablet):



Good year for Chromebooks (50x growth over 2012), Android tablets, bad year for desktops and Windows notebooks.

[Del_]

Permissive licensing is the norm when the priority is to establish a standard implementation with broad adoption. I think X has been pretty successful in that regard.

Remember that X grew up in the days of proprietary Unix workstations, where binary distribution was the norm, and that the workstation vendors contributed (heavily AFAIK) to the development of X implementations. In order to get the broadest adoption (ie on both proprietary and open source target systems) the permissive licensing was a hard requirement.

I believe your logic fails at its core here. Linux, alsa, pulseaudio, systemd are all counter examples. They are gaining broad adoption, and whether proprietary Unix uses them or not is not very interesting. Moreover, what is left of Unix has already adopted GPL desktops, so copy-left for the xserver was really no obstacle.

Regarding your recollection of workstation vendors contributing, I would need some documentation. What I have been able to dig out paints a rather bleak picture. I checked up XFree86 (which is what succeeded most in broad adoption I believe). From what I see it started out with licensing controversy (sure to scare off some contributors):

http://en.wikipedia.org/wiki/David_Dawes

Moreover, counting by the ohloh numbers the project failed to gather large interest from any developers beyond the founders:

http://www.ohloh.net/p/xfree86/contributors?page=1

finally, Dawes seems to be the only contributer with a really large number of commits (could be that some of the other commits hid massive efforts of course, so I am only portraying indicators, very much appreciate if anybody can provide more accurate account). Conclusively I have seen no indication that your account of the events are close to representative.

First off... Big Whoop on FreeBSD using ZFS, Linux is just as guilty on the filesystem front with ext4 and Btrfs being under GPL and thus unusable by the BSDs, and further it's vindictive to exclude the BSDs on something that is kernel agnostic like a display server protocol..

Stop right there. Luke, you are way smarter than this. Let me just address this, and if you still have a point, then please repeat it. The BSD's already heavily depend on copy-left code to be anywhere near useful. Whether the BSDs use a GPL'ed display server or not is irrelevant for any practical purpose. ZFS is copy-left, remember?

Second off you're presuming that
A). There are developers who are refusing to work on wayland because it's not copy-left
B). That there are individuals forking wayland and not making the source available
Please show evidence for either of these cases

Some people would probably see Mir as a wayland fork, but I won't argue that with you. Whether more developers would join? That is up to you to figure out, I am simply asking the question and looking at various indicators.

Whether Quartz or surfaceflinger counts as forks I honestly don't know. Neither of them have interested me enough to take a close look. However, it is very clear that the "standard implementation with broad adoption" for Wayland is so far out the window that one may ask what incentive there is left to go permissive.

[Luke_Wolf]

How is Valve bringing desktop linux to the mainstream? The Steambox has Gnome, but it boots to Big Picture Steam and requires the wherewithal to know you can get to an actual desktop. It also targets consoles, not personal computers. When they are in stores, nobody will equate Steamboxes with personal desktops.

They might bring it by the success of SteamMachines causing OEMs to try out SteamOS gaming laptops and desktops, which is why it's likely the answer and not for sure.

We need a company that can put laptops running Linux (since Valve uses it, why not Debian? The other options all have their own corporate interests) next to Windows laptops and Apple ones in stores. That requires huge capital nobody seems to want to put on the table - Dell and HP, the current frontrunners who are the closest to this goal, do not seem to have any motivation to do so since they already dominate the in store Windows space. Why replace devices they are already selling with new devices they would certainly hear more customer support demands from just because its not Windows? The only reason they would ever do it is because of Windows 8, but that horse already has pretty much left the stable. If Windows 9 is even worse, there is always another chance, but again it requires a third party company to jump in right when the wave is at its peak.

Valve and SteamOS are the droids you're looking for here :P While the OEMs don't care two whits about Joe Schmo Linux Distribution, 4 or 5 years from now the idea of riding the wave of Valve's success by selling AlienWare Laptops running SteamOS is going to occur to Dell (and for the other Gaming brands), which will be the foot in the door from which things can trickle down. Also it has to be at least a half-rolling release distribution because the average individual isn't going to be willing to go through a complex upgrade process.

[bridgman]

I believe your logic fails at its core here. Linux, alsa, pulseaudio, systemd are all counter examples. They are gaining broad adoption, and whether proprietary Unix uses them or not is not very interesting. Moreover, what is left of Unix has already adopted GPL desktops, so copy-left for the xserver was really no obstacle.

I don't get the connection. I'm talking about ability to customize a common code base and distribute the result as part of a proprietary Unix system. You're talking about GPL-licensed Linux and software products used with Linux. Dismissing Unix as "not very interesting" is fine, but when the rationale for choosing the license was based in those Unix systems is a problem

Regarding your recollection of workstation vendors contributing, I would need some documentation. What I have been able to dig out paints a rather bleak picture. I checked up XFree86 (which is what succeeded most in broad adoption I believe). From what I see it started out with licensing controversy (sure to scare off some contributors):

http://en.wikipedia.org/wiki/David_Dawes

Moreover, counting by the ohloh numbers the project failed to gather large interest from any developers beyond the founders:

http://www.ohloh.net/p/xfree86/contributors?page=1

finally, Dawes seems to be the only contributer with a really large number of commits (could be that some of the other commits hid massive efforts of course, so I am only portraying indicators, very much appreciate if anybody can provide more accurate account). Conclusively I have seen no indication that your account of the events are close to representative.

You're talking about a different group and a different timeframe. No wonder you came to different conclusions

I'm talking about roughly the first decade of X development... X work started in the early 80s but XFree86 didn't start until the 90's and IIRC the XF86 code base (specifically Keith's fork off it) didn't become dominant for almost another decade after that.

Take a skim through the following and let's see if that brings us closer to a common view:

http://old.lwn.net/lwn/1998/0409/xstate.html

[Del_]

I don't get the connection. I'm talking about ability to customize a common code base and distribute the result as part of a proprietary Unix system. You're talking about GPL-licensed Linux and software products used with Linux. Dismissing Unix as "not very interesting" is fine, but when the rationale for choosing the license was based in those Unix systems is a problem

Well, you seem to be jumping over my comment that proprietary Unix was very eager to provide KDE, as CDE was going nowhere. In 2006, CDE was even put under copy-left licensing.

You're talking about a different group and a different timeframe. No wonder you came to different conclusions

Indeed, you are right. Back then it was very difficult to see how copy-left would work out.

[Luke_Wolf]

I believe your logic fails at its core here. Linux, alsa, pulseaudio, systemd are all counter examples. They are gaining broad adoption, and whether proprietary Unix uses them or not is not very interesting. Moreover, what is left of Unix has already adopted GPL desktops, so copy-left for the xserver was really no obstacle.

I'm going to quibble with this.

ALSA, Pulseaudio, and systemd are not meant for broad adoption. ALSA and systemd are meant to be run specifically with the Linux kernel, and Pulseaudio is meant to run on top of ALSA. Monolithic Kernels such as Linux are impossible to be designed to widely adopt, you need a microkernel for that.

That said due to systemd's unit file based design it's the closest thing to being designed to be widely accepted as you can reasonably get with a service manager/init system, because the files are declarative and thus they can exist as a universal format with OS specific service managers being written so that you have a systemd-bsd, systemd-solaris, systemd-AIX, etc..

Strong Copyleft (Copyleft that cover derivative works) is an extreme obstacle to adoption if it were to cover a display server as any application written for an OS running with that display server is then tainted by the display server's license. It needs to be Weak Copyleft or more permissive in order to prevent this.

Stop right there. Luke, you are way smarter than this. Let me just address this, and if you still have a point, then please repeat it. The BSD's already heavily depend on copy-left code to be anywhere near useful. Whether the BSDs use a GPL'ed display server or not is irrelevant for any practical purpose. ZFS is copy-left, remember?

Yes ZFS is under CDDL, and yes FreeBSD promotes it, however UFS is their default filesystem, and HAMMER2 is their future. And yes the BSDs have copy-left software in their trees in particular various bits of the GNU userland they haven't managed to replace yet, however the fact that they go out of their way to rewrite various tools and utilities in order to have them under a permissive as opposed to copy-left license speaks to how much they like having copy-left in their tree.

In any case the point here is that while yes the BSDs have at various points gone with/written software that excludes linux, Linux has done the same thing towards them, which isn't always a bad thing but it is something that both communities are guilty of. However it is not something to be done just for the sake of doing it.

Some people would probably see Mir as a wayland fork, but I won't argue that with you. Whether more developers would join? That is up to you to figure out, I am simply asking the question and looking at various indicators.

In order for Copyleft to bring in more contributors vs Permissive licenses on a project requires 1 of 2 things:
A). A greater number of people with a philosophical disagreement with permissive licenses vs the number of people with a philosophical disagreement with copyleft licenses to the point where they refuse to contribute
B). Individuals forking the project and either not releasing code at all or releasing under a hostile license which you then can't use without tainting your codebase (e.g. imposing copy-left on a permissively licensed codebase. See Apache Open Office vs LibreOffice)

Whether Quartz or surfaceflinger counts as forks I honestly don't know. Neither of them have interested me enough to take a close look. However, it is very clear that the "standard implementation with broad adoption" for Wayland is so far out the window that one may ask what incentive there is left to go permissive.

Based on what I know of it's history Quartz is not, and Surface flinger is very much it's own thing targeted at the singular usage case of mobile devices.

It's honestly not that far out in case you haven't been paying attention 2015 will be the year of the Wayland Desktop on Linux as both Gnome and KDE are set to be ready then, and Wayland has already been ported to work with BSD, and I expect FreeBSD is going to wait on NVidia to support it though.

[Del_]

ALSA, Pulseaudio, and systemd are not meant for broad adoption. ALSA and systemd are meant to be run specifically with the Linux kernel, and Pulseaudio is meant to run on top of ALSA.

I would argue wide adoption is already there, they are all establishing themselves as the canonical solution across all distributions. Whether the BSDs or Unix'es of this world bends is irrelevant to me. I am more than happy to see BSD keep their friends in 4front as far away from us as possible.

Monolithic Kernels such as Linux are impossible to be designed to widely adopt, you need a microkernel for that.

I am rather pragmatic. Looking at the overwhelming empirical evidence I would say that you are as wrong can be here. Look around, now tell me again that linux is not widely adopted? OK then, feel free to place your bets on minix.

Strong Copyleft (Copyleft that cover derivative works) is an extreme obstacle to adoption if it were to cover a display server as any application written for an OS running with that display server is then tainted by the display server's license. It needs to be Weak Copyleft or more permissive in order to prevent this.

A simple exception would probably do, similarly to linux. I do agree that we need to allow proprietary applications.

Yes ZFS is under CDDL, and yes FreeBSD promotes it, however UFS is their default filesystem, and HAMMER2 is their future. And yes the BSDs have copy-left software in their trees in particular various bits of the GNU userland they haven't managed to replace yet, however the fact that they go out of their way to rewrite various tools and utilities in order to have them under a permissive as opposed to copy-left license speaks to how much they like having copy-left in their tree.

In any case the point here is that while yes the BSDs have at various points gone with/written software that excludes linux, Linux has done the same thing towards them, which isn't always a bad thing but it is something that both communities are guilty of. However it is not something to be done just for the sake of doing it.

What you are saying does not make sense. As long as the BSD or Apache crowd ensures GPL compatible licenses, the linux distributions of this world has no problem taking in their code, and have no intention of rewriting it (maybe they should though, but that is another discussion). Likewise, nothing prevents BSD from using copy-left software, and indeed they all do in huge quantities (and I am not sure at all that those quantities go down over time). Your concept of the two shutting each other out makes no sense. On the contrary, efforts are typically made to keep licenses compatible. CDDL was the creation of some misguided individuals in Sun, who thought they were being clever, only to discover they were out of work in hordes shortly after. When it comes to FreeBSD I only see them go out of their way to provide users with whatever software is out there. I have never seen them contribute much to the wider ecosystem. They seem to leave all that to the openbsd crowd. (not that I find anything wrong in that, simply commenting on your choice of words "go out of their way")

[Luke_Wolf]

I would argue wide adoption is already there, they are all establishing themselves as the canonical solution across all distributions. Whether the BSDs or Unix'es of this world bends is irrelevant to me. I am more than happy to see BSD keep their friends in 4front as far away from us as possible.
I am rather pragmatic. Looking at the overwhelming empirical evidence I would say that you are as wrong can be here. Look around, now tell me again that linux is not widely adopted? OK then, feel free to place your bets on minix.

We're using "Widely Adopted" different, you only care about the microcosm of Linux, I'm speaking of the macrocosm of OSes in general which makes all the difference in the world.

A simple exception would probably do, similarly to linux. I do agree that we need to allow proprietary applications.

just going straight LGPL would be a lot safer, rather than trying to force GPL + Exceptions

What you are saying does not make sense. As long as the BSD or Apache crowd ensures GPL compatible licenses, the linux distributions of this world has no problem taking in their code, and have no intention of rewriting it (maybe they should though, but that is another discussion). Likewise, nothing prevents BSD from using copy-left software, and indeed they all do in huge quantities (and I am not sure at all that those quantities go down over time). Your concept of the two shutting each other out makes no sense. On the contrary, efforts are typically made to keep licenses compatible. CDDL was the creation of some misguided individuals in Sun, who thought they were being clever, only to discover they were out of work in hordes shortly after. When it comes to FreeBSD I only see them go out of their way to provide users with whatever software is out there. I have never seen them contribute much to the wider ecosystem. They seem to leave all that to the openbsd crowd. (not that I find anything wrong in that, simply commenting on your choice of words "go out of their way")

Yes GPL projects are fine using Apache or BSD code, but BSD or Apache projects cannot take GPL code even of fixes to their own project without tainting their codebase. While this isn't a particularly common occurrence it does happen (which speaks in favour of permissive licensing), the biggest example being the LibreOffice vs Apache Open Office split.

Also From the FreeBSD 10 Changelog http://www.freebsd.org/releases/10.0R/relnotes.html

On platforms where clang(1) is the default system compiler (such as i386, amd64, arm), GCC and GNU libstdc++ are no longer built by default. clang(1) and libc++ from LLVM are used on these platforms by instead. GCC 4.2.1 and libstdc++ are still built and used by default on pc98 and all other platforms where clang(1) is not the default system compiler. [r255321]
*snip*
GNU patch has been removed from the base system, and replaced by a BSD-licensed patch(1) program. [r255191]

GNU sort has been removed from the base system, and replaced by a BSD-licensed sort(1) program. [r241511]

Berkeley yacc (byacc) has been imported from invisible island. This brings bison compatibilities to yacc(1) while preserving full backwards compatibility with previous version of yacc(1). [r235723]
*snip*
make(1) has been replaced with the ?Portable? BSD make tool (bmake) from NetBSD. [r250699]
*snip*
BSD-licensed versions of ar(1) and ranlib(1), based on libarchive(3), have replaced the GNU Binutils versions of these utilities.

BSD-licensed versions of bc(1) and dc(1) have replaced their GNU counterparts.
*snip*
BSD-licensed version of cpio(1) based on libarchive(3), has replaced the GNU cpio. Note that the GNU cpio is still installed as gcpio.

Given ~20% of their listed userspace changes are just ripping out GNU software and replacing them with BSD licensed software... they do have clear preferences. The difference is they're pragmatic enough to where they're willing to live with copy-left licensed software if there's not an equivalent.