Yes, me too. I've used void linux quite a bit which does use some BSD components like mandoc but is still gcc and GNU coreutils. I can understand the logic of using the packaging system from Alpine. I rather like pkg on FreeBSD, it feels more consistent, predictable and simpler than either deb/apt or rpm/dnf.
i did intend to use pkg at first, however, after some experimenting apk turned out to be the better option (there are things pkg still doesn't support - such as version constraints, getting it to work on musl is a fair amount of patching, its shlib scanning is semi-broken on Linux, and its repo indexing is insufficient for my purposes)
As the most upvoted comment in this thread is wondering what could be the motivations for that (and I'm also wondering), could you explain why you wished it exist?
As someone who finds this a bit appealing and perhaps speaking for others with similar "taste", it's a mixture of this, but also the sense that the BSD userland is smaller and less bloated than the GNU userland. It's the flipside of what another commenter mentioned, GNU tools tend to be more feature filled, but at the expense of code size and complexity.
Similar to why some people want to use a musl libc userland. For some people, it's the licensing, for others it's about the design and simplicity of implementation.
I use the Alpine userland and so totally understand the reasoning of having less bloated tooling and the like. However, personally I prefer to apply this philosophy to stuff I have running in the background. If I'm using initscripts, I'd rather they be written using execline (and ideally running with s6) rather than bash, if it has to be a version of sh then I prefer dash over bash, builtins over external tools, nginx over apache, and so on.
But having used busybox utils on a daily basis I truly do not understand how people can use them daily and not go insane. The GNU utils are so much faster and more feature-filled. To me, reducing bloat makes sense for something running forever in the background. Interactive stuff ought to be as feature-filled as possible, stuff in the background as lean it can.
I realise others have different views about this, but I think I hew fairly closely to the mainstream thought about bloat.
> But having used busybox utils on a daily basis I truly do not understand how people can use them daily and not go insane.
There's a continuum here, and that's what makes this project interesting to me. Busybox is very minimal, because of its purpose of having "all that you need" in the smallest single statically linked executable possible.
The BSD userland is different, though. It isn't trying to be small for the sake of being small, but simply being simple. BSD utilities aren't nearly as spartan (in my experience) as, say, busybox, but they remain simple.
I'm not sure if I'd try to run this distribution "in anger" on anything, but I'm definitely gonna give it a spin, since I prefer the BSD userland, and am "stuck" with Linux because of device drivers. That's probably just my own bad tastes, though ;)
Based :) Alpine doesn't use dash by default, does it? :(
s6 is sweet but openrc is good enough for me. I won't use sysD on purpose anymore. I'd like to hear more from people using alpine on bare metal.
> But having used busybox utils on a daily basis I truly do not understand how people can use them daily and not go insane.
Busybox is meant to be used in embedded Linux systems, often found in routers, printers, cameras and etc. In those systems every megabyte of flash memory counts and every cost counts. Busybox (GPL license) encapsulates the whole non graphics userland in a single binary. An non-GPL alternative to it is Toybox which is used on Android since this tool has BSD license. Alpine distro was also designed for embedded systems, but it is now being used in containers due to the distro small footprint.
From a strictly licensing perspective, why though? As a user, what difference does it make unless you plan on somehow integrating `cp` et al into your source code?
Adopting the language is generally seen as a sign of in-group self-identification. The use-mention distinction is warranted. If skipped, one shouldn't be surprised if one is mistaken for espousing the views so stated.
True, but it doesn’t help the person who has is making this assumption to have an accurate view of the world. They are still wrong even as they smugly blame the person they have misunderstood for not communicating less ambiguously.
so what? People generally make all sorts of assumptions. They are not necessarily correct through. You pointing it out feels like you're trying to bully him into making an admission of guilt or lack there-of of wrong-think. I prefer to give people the benefit of the doubt.
Whether or not he agrees with the viewpoint he's paraphrasing is of no importance to me. I want to understand the point of view of people who think that way, in their own words. I have no interest in him filtering and watering it down to make it more palatable to you.
The point is, there is generally nothing to object to in the GPL unless you are specifically to constrain what consumers of your code candy do with it.
If it is "pollution" to you, that means it is an inconvenience and an obstacle to you executing your goals. The GPL has not been built to frustrate anyone except those who impinge on the fundamental set of Software freedoms. Part of that is the ability to have access to the source code of any tools you are reliant on.
So no, it isn't just assumptions. If you're frustrated by GPL, then either you're pissed because it thwarts your designs to create a captive userbase, or you're part of the legal/exec team trying to see if you can get away with the same. So which is it?
I'm a late enough arrival that I experienced the world with few other options than closed source programs and toolchains, and I'm not about to go chasing back after it. In fact, I'd be happy to see GPL go down in flames because we all finally came to our senses and ceased this IP nonsense in it's entirety to begin with.
Everyone thinks they're cool and everything for not using the GPL and related licenses, until Amazon (or another big player) comes and eats their lunch by offering a cloud-based version of your software (like elastic/elasticsearch)
> (Also your point is a bit flawed, only AGPL really saves you from the Amazon situation.)
I wouldn't be so sure, for this kind of tooling it's not like the software is exposed behind some API of some sort. When Amazon is renting you a virtual machine with those installed on top, are they distributing the software? It's not clear cut at all.
Any hobbiest who writes free software for the community’s benefit is doing the same community a disservice when they allow private corporations to profit from the community’s work without recompense or sharing their work back to the community. The corporations also get to use the community’s work to redirect effort away from the community to their own product and platform.
>when they allow private corporations to profit from the community’s work without recompense back to the community.
I'm not sure why this is frequently brought up in the context of the GPL. The GPL says nothing about that and has never held that as a concern at all. Communities who were using GPL with that intent have seemingly always been mistaken. From the text of the GPL: "the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program." It doesn't say anything about disallowing private corporations from profiting without recompense. If you want to force companies to pay you, you're better off with a closed source license.
The spirit of the GPL is to create and maintain a thriving community around free software. Profit or not, when private entities are allowed to use free software without adhering to the tenets of the GPL, it is destructive to the free software community.
According to the actual text of the GPL, that is not the spirit of it at all. Sorry to disappoint but this is a common misconception that I see. The word "community" appears zero times in the GPL. The community aspect might be a side effect that happens in some cases with it, but trying to use a license of some kind of panacea to maintain a community doesn't make any sense. That's not how communities work. It's the people who maintain your community, not the license.
Edit: The lack of enforcement of GPL is a different story, but you can trace that directly back to the very same community, including the FSF, who seem to have decided years ago that enforcing the GPL is not worth it anymore for some reason.
Have you read Stallman’s essays on the topic? If you’re interested in this stuff, he goes very in depth on the goals of the free software movement: https://www.gnu.org/doc/fsfs3-hardcover.pdf The GPL was created explicitly to advance those goals.
From Wikipedia’s summary of the essays:
The author proposes Free software licenses (mostly GPL) as a solution to social issues created by proprietary software and described in essays.
I am familiar with the various other things that are hosted on the GNU website. I'm referring to the actual authoritative legal text that gets copied alongside all the source code that you use, not any other essays on the subject. That text poses a different story than those essays. I'm also not sure why this is being brought up now, as the GP post you made acknowledged that the GPL was not even accomplishing that goal.
Edit: Since the license itself is vague on what those "social issues" actually are aside from sharing and changing the program, in my experience projects will tend to use it for whatever they feel like. Sometimes this is aimed towards community building but often isn't. To me the community building aspect mostly happens outside of these legal decisions, for example: closed source programs can have a community too, sometimes that community might even be hosted in the same places such as github.
> I am familiar with the various other things that are hosted on the GNU website. I'm referring to the actual authoritative legal text that gets copied alongside all the source code that you use, not any other essays on the subject.
you know that in case of actual litigation, judges will not only look at the actual text, but also at the intent surrounding it, right ?
Sure, but the "intent" in question would be the intent of the copyright holder that chose to use the GPL. My point is that the intent in a lot of cases is NOT to do what is being suggested.
>It's absurd to expect the word "community" to appear in the text of the GPL
I'm not sure why you're saying this? I don't expect that word to appear in the text.
It also seems mostly not possible to prove or disprove that "almost every person involved knew." Did you mean this as a personal anecdote with the people that you knew? If so, that's probably great for you and your community, but apparently those who were writing the legal document that governs said community didn't agree. Sadly it is possible for there to be oversights from day one.
Google is one of the earliest users of Linux. Microsoft, Amazon, Facebook all use Linux extensively as well. Only Netflix and Apple have a fixation on BSDs, but IIRC even Apple uses Linux internally for their servers.
Just because they tolerate Linux’s usage of GPL2 does not mean they are neutral or positive toward GPL-licensed code. You mention Google, Chromium is not GPL-licensed nor do they allow GPL code in their tree. Their new kernel, Fuschia, is not GPL.
Linux is a great success story of the GPL, its ubiquity has forced corporations to tolerate it and reciprocally contribute back to the community.
The irony is that without the GPL, most likely those folks would be stuck with the commercial UNIX clones many of us used during the UNIX wars.
While I mostly use commercial software, I definitely appreciate having had the opportunity to get Walnut Creek CD-ROMs with an OS that saved me 1h trip to fight for a vacancy on the university computer center.
> The irony is that without the GPL, most likely those folks would be stuck with the commercial UNIX clones many of us used during the UNIX wars.
386BSD (of which FreeBSD is based) is an independent lineage to GNU and was released under the BSD licence. Thus also independent to GPL. In fact for a period in the early to mid 90s, it was BSD which was used as the free "UNIX" with Linux seen largely as a hobbyist platform and Hurd little more than a pipe dream.
Linux might have since become the dominant POSIX server platform but to argue that GPL was the saviour of open source is a gross misunderstanding of the history of open source (and UNIX).
The reason Linux "won" was ironically because it was seen as more of a hacker OS. It was used more by kids because it was more fun to hack around with. Those hackers then grew up, got proper jobs in IT and continued to use what they were already experienced in...Linux.
People tend to forget that Linux was a small project that provided a gpl kernel for the GNU system - not the other way around (hence GNU/Linux, Android/Linux, GNU/kFreeBSD etc).
The desire for a non-gpl compiler is part of what drove the development of llvm. llvm is the default compiler on FreeBSD. Compilers are hard, and it took a while.
I don’t think anyone in this thread would have forgotten that fact. The Op themselves mentioned Hurd (what was and still is intended to be the GNU kernel) so they clearly weren’t obvious to your point.
That's an absurdly bold claim even by your standards. You can't predict how the industry might have evolved without Linux -- there's far too many variables. But even if you were to try, the fact that FreeBSD, OpenBSD and others are still thriving while Solaris is slowly dying off should be a massive clue that your statement isn't nearly as much of a certainty as your post makes out.
Good to know now I have standards to be measured against.
Solaris is dying because of Linux coming into the scene and Sun's mismanagement, being bought by Oracle that most cares about Unbreakable Linux, this wouldn't have happened in an alternative universe without Linux.
Plus it was only one example of UNIX, others could be given that were affected in similar ways.
FreeBSD, OpenBSD and others are surviving, hardly getting any upstream changes from Apple, Sony or plenty of others that take profit of the license, beyond some charity whenever they feel like, this isn't thriving.
It is no surprise that all POSIX clones competition against Linux on the IoT space, by those vendors not keen in upstream updates for Android, are using MIT/BSD and Apache licences.
Maybe this isn't up to my standards, yet it is what I believe.
> Those hackers then grew up, got proper jobs in IT and continued to use what they were already experienced in...Linux.
Honestly by the late 1990's Linux was what was being requested by a lot of employers, with Solaris being the most common system it was displacing (in my experience). BSD simply wasn't even on the radar for most employers/employees.
For no reason at all. The main requisite of the GPL license is that if you do some modifications to a GPL licensed software you must give back that changes to the community, i.e. publish the modified source code (only of the GPL licensed parts, not the whole source code of the project). To me it seems reasonable enough.
Apple not wanting to include GPL software doesn't make a lot of sense to me, since they still release the source code of the low level components as the Darwin project. And still they include some GPL software.
You don't actually need to give the changes back to the community, you only need to give the changed code to those you distribute the modified software to.
In other words:
- if you don't publish the modified software, you don't need to give the changed code to anyone
- if you distribute the modified software to a single entity, you only need to give the changed code to that single entity (and they absolutely do not need to publish it)
- etc.
I know people mostly view this through the eyes of large public projects, forks, etc., but there more to it then that.
If that was the case, why not advertise it as having no GPL licensed userland components? They way it's worded sounds more like they have something against the GNU organization.
And the linux kernel itself is licensed as GPLv2, so they aren't avoiding the GPL completely.
Let's hope thats it because the only logical alternative I can think of is that they want the ability to ship binaries with proprietary modifications, or allow others to do the same.
I never understood this. The GPL folks turned out to be right. Big tech is rife with forks of open source these days that contribute little or nothing back to the community.
But the forks often DO come back. At my employer, we open source our work on FreeBSD.
In addition to being full participants in the community, contributing our work back gives us a lot of other advantages. These include a wider audience for code review which improves code quality, much, much, much easier integration of fixes and features from upstream, the ability to collaborate with people from other employers, the ability hire contractors who are familiar with our code, etc.
Sometimes. But look at all the forks Amazon has done to various databases for instance. None of that work is ever coming back. And worse, they've fragmented the ecosystem by building incompatible features with the originals.
If those systems were GPL everyone would reap the benefits
Liking this or not is an immaterial feeling-based opinion. If you don't understand software licenses and their impact, then you need to read about their limitations on the stakeholders. (DDG is your friend.)
GPL3 prevents TiVoization. If you want to make a "TiVo" without other people dictating what you can do with your effort, GPL3 is a nonstarter. The easiest thing to do is swap the userland for something with a better license.
Rich autocrats like RMS promoting snowball's chance unreasonable utopianism, an giveaway, noncommercial self-righteousness is fine when you don't have to feed a family or keep 100 workers feeding theirs too. Such purity is a luxury of the privileged and those with nothing else better to do.
Apple is known to use GPLv2 versions of GNU tools to bundle with macOS. GNU userland and Linux Kernel are the strongest leverages that free software community has so this might be significant in that regard.
BSD have a different construction of user space and development tool chains. System libraries are made for sharing and tools are based more there than on direct kernel interfaces. To do all of this with clang and no gcc may smooth out some various complexities.
I guess they want to avoid GPLv3 provisions while still distributing a 'full' system with shell and CLI tools. Linux+BSD userland gives them a decently compatible GPLv2/BSD system.
From what I can tell, Clang+LLVM is where all the innovation is happening. Clang in particular has seen many new security features for a modern compiler like the implementation of SafeStack[1] and Control Flow Integrity[2]. Even just on the functional side of things Clang has thinLTO[3], which makes building link-time optimized binaries easier on lower-end systems. None of these features are currently planned for GCC.
the GNU tools have bigger featuresets, but from code quality aspect i much prefer the BSD ones
it's not targeted at embedded, but it is an experimental project for the time being (the motivation is a split between "because i could", "i wanted to provide polished ports of BSD software" and "i wanted to experiment with making a better package build system")
GNU software is not only hostile to integration from a legal perspective (GPL), it is hostile from a technical perspective. E.g. GCC is (was?) famously deliberately designed to be non-portable and made impossible to integrate into other tools. Maybe there's some valid historical reasons for the mistrust of systems that could be closed, but I can also see why some might be turned off witnessing the open hostility towards integration and collaboration that is GNU's defensive response.
GNU/GPL is carrying around emotional baggage of scars that its users were afflicted with at the hands of closed systems. Yes, maybe this strategy is protecting them from being hurt in the same way again in the future. But it's also closing the door on potential relationships. Love and trust requires opening yourself up to being hurt, yes, but that doesn't necessarily mean you should give up on it.
Maybe the swing back towards more openly-licensed software is an artifact of people forgetting the harms done in the past, or maybe it's an indication that GPL is an overcorrection and it's time to evolve again.
yes, i originally planned on making my own ports, but after seeing dcantrell's work, i decided to help out over there instead (i did a lot of the recent ports)
The choice of Python for writing the package management tool is curious. Besides the fact that writing such a tool from scratch is a large undertaking in and of itself. I wish more Linux distributions just adopted a transactional tool like Guix instead of rolling their own. Doing upgrades safely and being able to rollback easily is a huge benefit for end users that it's hard to believe more distros haven't adopted it. We shouldn't have to reinvent the wheel every time.
Python isn't that unusual, dnf and yum on Redhat are both written (primarily) in Python. Agree with you though, I get the appeal of writing your own package manager but...
It's a deceptively complex with a lot of edge cases. Dependency resolution is a difficult problem, as are transactional updates. And you want it to be something that is bulletproof, since broken packages are a nightmare. It's not that hard to get something usable, but it can take a lot of effort to get something competitive with what people have come to expect from existing mature package managers.
What's hard about dependency resolution? Aren't there off-the-shelf algorithms that solve this? At the very least, one could just lift code from other open-source tools, such as Aptitude or Yum.
Dependency resolution is NP-hard. There are existing algorithms and libraries that solve it adequately despite this, but because they usually rely on some heuristics or simplifications they come with steep tradeoffs and can be quite complex to use.
Sure you could lift code from other tools that do a good job. That's the point, if you start from scratch you have to recreate all that effort (which is considerable).
the reason python was used is because of its portability and robustness; it can be made to work (without problems) on pretty much any platform, plus it's omnipresent and has an extensive enough standard library to write things without pulling in tons of dependencies
it's also not actually a package management tool per se (that's handled by apk-tools) but really just a build system (it creates apk repositories) similar to ports, void-packages, etc.
i'm also a Void Linux developer, and the new system is based on my experiences with xbps-src (trying to avoid its problems)
I wish there were a Linux with GNU userland but structured and configured like FreeBSD and it wasn't a marginal retrograde sandbox with weak community and no support from app authors. Essentially I want a Manjaro or an Ubuntu but with BSD init and config. Because in FreeBSD (as I remember it, it has been a while) you just have some plain-text configs in well-established places and can easily understand when and what does run and it's more classic unixway. SysVinit was not bad but everything depends on systemd nowadays which I find a sacrifice fast booting isn't worth.
It's been a very, very long time (~17-18 years) since I last touched it, but as I recall, Slackware had an init system back then that was similar to FreeBSD's.
I'm getting a lot of mileage out of Void Linux. It's more like Arch than Ubuntu, but otherwise it fits your description. It's very easy to configure and administrate, mostly by virtue of doing nothing "weird" - just a simple init system, a powerful package manager, and utterly standard everything else (the Arch wiki works well for it).
Why use Arch and not Void? I am aware of several points of superiority - a better package manager, larger repos, wider architecture support and multiple libcs - and no points of inferiority. Well okay, one - Void's commitment to supporting musl occasionally leads to feature lags, since they won't push updates that break musl. The general feel of the system is more stable than Arch.
I wonder if you’ve run across the Slackware distro? It was my distro of choice in the late 90s / early 00’s but it’s still around.
It’s basically a linux kernel but a bsd userland & filesystem layout. That’s not strictly true in practice but close enough. Their other guiding ethos was to minimise package maintainer patches so you’d get more vanilla software than in other distros.
Having said that, i run FreeBSD 13 for a nas / firewall at home (only really so i don’t lose the muscle memory) but the bsd init system feels distinctly utilitarian to me in comparison to systemd / launchd (macos) or even smf (solaris - RIP).
As a developer systemd is very attractive, you get so much useful functionality for free, socket management, privs, capability management - stuff that you usually want to use but would rather outsource than write yourself.
Slackware was my first distro (and The first distro AFAIK) but it always felt rather exotic and unpolished. I use Manjaro now - it feels very compatible with everything out of the box, very polished and reasonably fresh, kind of a luxury var that has everything you would imagine and everything works almost flawlessly. Yet it doesn't give the satisfactory feeling of actually groking your system and having it under almost full control which I had with DOS while FreeBSD was very close to that.
Arch Linux circa 2011 had the text-based configuration aspect with an rc.conf file similar to the BSDs[1] but the folder structure was still very Linux.
Apart from Linux’ hardware support, is there any other major motivation behind this? Otherwise if you want a stable base and sane config, why not just install FreeBSD? :) I like the name Chimera btw. Underscores the hybrid nature of the project well.
For what its worth, the BSDs do have their own "make"[1]. Its just not compatible with GNU makefiles so for building 3rd party software you often need to install GNU's make on the BSDs.
i do use BSD make for a lot of components, but yes, there are a few where GNU make is not easily replaceable :) there are plans to change this eventually, but nothing has materialized yet
A big part of it is likely that many components are mostly stand-alone - even things like coreutils can be replaced at will so long as everyone is using POSIX/portable behaviors - but make(1) gets used by every package that you build, so if any of your packages are using GNUisms in their Makefile you need GNU Make. (Of course, you could declare gmake as a build dependency for 3rd party software that you're packaging, but that only allows you to kinda segment the problem out rather than solving it)
> Certainly not the Linux kernel itself, that relies too heavily on GCC quirks.
True, but there was a large effort to clone in LLVM nearly all the GCC extensions and quirks that the Linux kernel requires, so that nowadays the Linux kernel can be mostly compiled also with LLVM. See https://bugs.llvm.org/show_bug.cgi?id=4068 and its long list of dependencies to get an idea of what had to be done.
This was historically the case, but no longer. Several architectures can be built with clang now and there's one that is built exclusively with clang (for lack of a gcc-based toolchain).
Also, Nick Desaulniers and team from Google work on fixes to the toolchains and kernel to keep it that way. [1]
Funnily enough, the Linux distribution GamerOS, which is basically a game-console-experience distribution based on the idea of SteamOS (booting directly into the game platform), just rebranded to ChimeraOS last week.
114 comments
[ 5.0 ms ] story [ 106 ms ] threadMy experience managing many different flavors of *nix has been that the GNU utils are far superior, so I don’t understand wanting to replace them.
My first guess is this is targeted at embedded use, but that’s pure conjecture.
I'm not saying I like or understand this, but I have seen this attitude among a few in the community.
Similar to why some people want to use a musl libc userland. For some people, it's the licensing, for others it's about the design and simplicity of implementation.
But having used busybox utils on a daily basis I truly do not understand how people can use them daily and not go insane. The GNU utils are so much faster and more feature-filled. To me, reducing bloat makes sense for something running forever in the background. Interactive stuff ought to be as feature-filled as possible, stuff in the background as lean it can.
I realise others have different views about this, but I think I hew fairly closely to the mainstream thought about bloat.
There's a continuum here, and that's what makes this project interesting to me. Busybox is very minimal, because of its purpose of having "all that you need" in the smallest single statically linked executable possible.
The BSD userland is different, though. It isn't trying to be small for the sake of being small, but simply being simple. BSD utilities aren't nearly as spartan (in my experience) as, say, busybox, but they remain simple.
I'm not sure if I'd try to run this distribution "in anger" on anything, but I'm definitely gonna give it a spin, since I prefer the BSD userland, and am "stuck" with Linux because of device drivers. That's probably just my own bad tastes, though ;)
Busybox is meant to be used in embedded Linux systems, often found in routers, printers, cameras and etc. In those systems every megabyte of flash memory counts and every cost counts. Busybox (GPL license) encapsulates the whole non graphics userland in a single binary. An non-GPL alternative to it is Toybox which is used on Android since this tool has BSD license. Alpine distro was also designed for embedded systems, but it is now being used in containers due to the distro small footprint.
Whether or not he agrees with the viewpoint he's paraphrasing is of no importance to me. I want to understand the point of view of people who think that way, in their own words. I have no interest in him filtering and watering it down to make it more palatable to you.
If it is "pollution" to you, that means it is an inconvenience and an obstacle to you executing your goals. The GPL has not been built to frustrate anyone except those who impinge on the fundamental set of Software freedoms. Part of that is the ability to have access to the source code of any tools you are reliant on.
So no, it isn't just assumptions. If you're frustrated by GPL, then either you're pissed because it thwarts your designs to create a captive userbase, or you're part of the legal/exec team trying to see if you can get away with the same. So which is it?
I'm a late enough arrival that I experienced the world with few other options than closed source programs and toolchains, and I'm not about to go chasing back after it. In fact, I'd be happy to see GPL go down in flames because we all finally came to our senses and ceased this IP nonsense in it's entirety to begin with.
(Also your point is a bit flawed, only AGPL really saves you from the Amazon situation.)
I wouldn't be so sure, for this kind of tooling it's not like the software is exposed behind some API of some sort. When Amazon is renting you a virtual machine with those installed on top, are they distributing the software? It's not clear cut at all.
Any hobbiest who writes free software for the community’s benefit is doing the same community a disservice when they allow private corporations to profit from the community’s work without recompense or sharing their work back to the community. The corporations also get to use the community’s work to redirect effort away from the community to their own product and platform.
I'm not sure why this is frequently brought up in the context of the GPL. The GPL says nothing about that and has never held that as a concern at all. Communities who were using GPL with that intent have seemingly always been mistaken. From the text of the GPL: "the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program." It doesn't say anything about disallowing private corporations from profiting without recompense. If you want to force companies to pay you, you're better off with a closed source license.
Edit: The lack of enforcement of GPL is a different story, but you can trace that directly back to the very same community, including the FSF, who seem to have decided years ago that enforcing the GPL is not worth it anymore for some reason.
From Wikipedia’s summary of the essays:
https://en.wikipedia.org/wiki/Free_Software,_Free_SocietyEdit: Since the license itself is vague on what those "social issues" actually are aside from sharing and changing the program, in my experience projects will tend to use it for whatever they feel like. Sometimes this is aimed towards community building but often isn't. To me the community building aspect mostly happens outside of these legal decisions, for example: closed source programs can have a community too, sometimes that community might even be hosted in the same places such as github.
you know that in case of actual litigation, judges will not only look at the actual text, but also at the intent surrounding it, right ?
It's absurd to expect the word "community" to appear in the text of the GPL: it's a legal document, non a manifesto.
I'm not sure why you're saying this? I don't expect that word to appear in the text.
It also seems mostly not possible to prove or disprove that "almost every person involved knew." Did you mean this as a personal anecdote with the people that you knew? If so, that's probably great for you and your community, but apparently those who were writing the legal document that governs said community didn't agree. Sadly it is possible for there to be oversights from day one.
Facebook, Apple, Amazon, Netflix, Microsoft, Google...
Linux is a great success story of the GPL, its ubiquity has forced corporations to tolerate it and reciprocally contribute back to the community.
But fear not, Fuchsia already did its first deployment into production.
While I mostly use commercial software, I definitely appreciate having had the opportunity to get Walnut Creek CD-ROMs with an OS that saved me 1h trip to fight for a vacancy on the university computer center.
386BSD (of which FreeBSD is based) is an independent lineage to GNU and was released under the BSD licence. Thus also independent to GPL. In fact for a period in the early to mid 90s, it was BSD which was used as the free "UNIX" with Linux seen largely as a hobbyist platform and Hurd little more than a pipe dream.
Linux might have since become the dominant POSIX server platform but to argue that GPL was the saviour of open source is a gross misunderstanding of the history of open source (and UNIX).
The reason Linux "won" was ironically because it was seen as more of a hacker OS. It was used more by kids because it was more fun to hack around with. Those hackers then grew up, got proper jobs in IT and continued to use what they were already experienced in...Linux.
Is there a non-gnu c compiler? I could only find: https://github.com/386bsd/386bsd/tree/2.0/usr/src/usr.bin/gc...
People tend to forget that Linux was a small project that provided a gpl kernel for the GNU system - not the other way around (hence GNU/Linux, Android/Linux, GNU/kFreeBSD etc).
Had Linux not happened, most likely I would still be deploying Solaris into production.
Solaris is dying because of Linux coming into the scene and Sun's mismanagement, being bought by Oracle that most cares about Unbreakable Linux, this wouldn't have happened in an alternative universe without Linux.
Plus it was only one example of UNIX, others could be given that were affected in similar ways.
FreeBSD, OpenBSD and others are surviving, hardly getting any upstream changes from Apple, Sony or plenty of others that take profit of the license, beyond some charity whenever they feel like, this isn't thriving.
It is no surprise that all POSIX clones competition against Linux on the IoT space, by those vendors not keen in upstream updates for Android, are using MIT/BSD and Apache licences.
Maybe this isn't up to my standards, yet it is what I believe.
Honestly by the late 1990's Linux was what was being requested by a lot of employers, with Solaris being the most common system it was displacing (in my experience). BSD simply wasn't even on the radar for most employers/employees.
Apple not wanting to include GPL software doesn't make a lot of sense to me, since they still release the source code of the low level components as the Darwin project. And still they include some GPL software.
In other words:
- if you don't publish the modified software, you don't need to give the changed code to anyone
- if you distribute the modified software to a single entity, you only need to give the changed code to that single entity (and they absolutely do not need to publish it)
- etc.
I know people mostly view this through the eyes of large public projects, forks, etc., but there more to it then that.
And the linux kernel itself is licensed as GPLv2, so they aren't avoiding the GPL completely.
In addition to being full participants in the community, contributing our work back gives us a lot of other advantages. These include a wider audience for code review which improves code quality, much, much, much easier integration of fixes and features from upstream, the ability to collaborate with people from other employers, the ability hire contractors who are familiar with our code, etc.
Note that I don't speak for my employer.
If those systems were GPL everyone would reap the benefits
GPL3 prevents TiVoization. If you want to make a "TiVo" without other people dictating what you can do with your effort, GPL3 is a nonstarter. The easiest thing to do is swap the userland for something with a better license.
Rich autocrats like RMS promoting snowball's chance unreasonable utopianism, an giveaway, noncommercial self-righteousness is fine when you don't have to feed a family or keep 100 workers feeding theirs too. Such purity is a luxury of the privileged and those with nothing else better to do.
[1] https://clang.llvm.org/docs/SafeStack.html
[2] https://clang.llvm.org/docs/ControlFlowIntegrity.html
[3] https://clang.llvm.org/docs/ThinLTO.html
it's not targeted at embedded, but it is an experimental project for the time being (the motivation is a split between "because i could", "i wanted to provide polished ports of BSD software" and "i wanted to experiment with making a better package build system")
GNU/GPL is carrying around emotional baggage of scars that its users were afflicted with at the hands of closed systems. Yes, maybe this strategy is protecting them from being hurt in the same way again in the future. But it's also closing the door on potential relationships. Love and trust requires opening yourself up to being hurt, yes, but that doesn't necessarily mean you should give up on it.
Maybe the swing back towards more openly-licensed software is an artifact of people forgetting the harms done in the past, or maybe it's an indication that GPL is an overcorrection and it's time to evolve again.
https://github.com/dcantrell/bsdutils
The choice of Python for writing the package management tool is curious. Besides the fact that writing such a tool from scratch is a large undertaking in and of itself. I wish more Linux distributions just adopted a transactional tool like Guix instead of rolling their own. Doing upgrades safely and being able to rollback easily is a huge benefit for end users that it's hard to believe more distros haven't adopted it. We shouldn't have to reinvent the wheel every time.
Sure you could lift code from other tools that do a good job. That's the point, if you start from scratch you have to recreate all that effort (which is considerable).
it's also not actually a package management tool per se (that's handled by apk-tools) but really just a build system (it creates apk repositories) similar to ports, void-packages, etc.
i'm also a Void Linux developer, and the new system is based on my experiences with xbps-src (trying to avoid its problems)
It’s basically a linux kernel but a bsd userland & filesystem layout. That’s not strictly true in practice but close enough. Their other guiding ethos was to minimise package maintainer patches so you’d get more vanilla software than in other distros.
Having said that, i run FreeBSD 13 for a nas / firewall at home (only really so i don’t lose the muscle memory) but the bsd init system feels distinctly utilitarian to me in comparison to systemd / launchd (macos) or even smf (solaris - RIP).
As a developer systemd is very attractive, you get so much useful functionality for free, socket management, privs, capability management - stuff that you usually want to use but would rather outsource than write yourself.
[1] https://wiki.archlinux.org/index.php?title=Initscripts/rc.co...
[1] https://www.freebsd.org/cgi/man.cgi?make(1)
https://www.kernel.org/doc/html/v5.8/kbuild/llvm.html
"Linux version 5.13.0+ (x@x) (Debian clang version 13.0.0-++20210418105309+a0898f0cecc7-1~exp1, LLD 13.0.0) #6 SMP Thu Jul 1 10:22:40 CDT 2021"
True, but there was a large effort to clone in LLVM nearly all the GCC extensions and quirks that the Linux kernel requires, so that nowadays the Linux kernel can be mostly compiled also with LLVM. See https://bugs.llvm.org/show_bug.cgi?id=4068 and its long list of dependencies to get an idea of what had to be done.
Also, Nick Desaulniers and team from Google work on fixes to the toolchains and kernel to keep it that way. [1]
[1] https://clangbuiltlinux.github.io/
I was immediately confused.