Suggested alternative title: FreeBSD has Removed GCC from Build Infrastructure.
[0] https://github.com/freebsd/freebsd-ports/blob/master/Mk/bsd....
Suggested alternative title: FreeBSD has Removed GCC from Build Infrastructure.
[0] https://github.com/freebsd/freebsd-ports/blob/master/Mk/bsd....
As others have pointed out "FreeBSD has removed GCC from the. base system" would be a better title.
It's as if MacOS decided to stop shipping bash by default. Of course you'll still be able to install it yourself, but it's not part of the OS anymore and you can't rely on it being available and supported.
FreeBSD is not Linux, it's a full OS, not just a kernel. There's a very clear line between what's part of the base system and what's not.
More precisely, it’s as if macOS stopped shipping GCC in the CLT.
Oh wait, they did exactly that already, the last one being gcc 4.2 on Darwin 11, after that a GCC command is still present but it’s just a front to llvm.
https://github.com/archmac/packages/blob/master/core/apple-g...
They switched from tcsh to bash, so it's not out of the question.
edit: looks like tcsh is still available, but not the default.
That excludes the bulk of this site's readers.
Edit: This comment was not meant to be snarky.
Maybe we could compromise with "FreeBSD has removed GCC from its base system" or something similar.
I think this would make the best headline.
Which would make the headline that is most in accordance with the guidelines here:
"remove GCC 4.2.1 build infrastructure"
I think it's significant news, and I have no connection to FreeBSD. It's a significant milestone for Clang, which makes it significant news to C programmers.
> It's not some sort of war.
Well, these compilers are competing with each other. It's a bit like the browser war, such as it is. If there were a respectable BSD-licensed browser, I'm sure the various FreeBSD-on-desktop distros would favour it.
> It's not even much of a change, considering that the actual concrete change, switching compilers, happened a while ago.
As a nail in the coffin moment I'd say it's still significant.
Imagine this:
"Microsoft has removed Notepad from Windows!"
"You dummy, no it hasn't; you can still get a Notepad for Windows from the Microsoft Store! Microsoft only removed it from the base installation of Windows, not from Windows as such."
Doh? If that happened, you would no longer be able to rely on any installation of Windows to have Notepad.
Yes, they are -- your understanding was correct. The FreeBSD OS now exclusively builds with clang, and clang is also the compiler shipped with the system.
You can, of course, still install GCC, and many other packages, from the ports tree, but it is no longer part of the OS.
Title was clear to me - yes, perhaps more clear as you say it though.
Is there a reason that you’d be relying on what’s included in the FreeBSD base system? If I were building a piece of software and developing a FreeBSD target for it, I’d probably just write a port manifest for it and contribute it; and in so doing, I can have my port manifest declare a dependency on the GCC port.
Just like if I create an Ubuntu PPA, I can depend on Ubuntu system packages, or even other people’s PPAs. (And it’s even less arduous than the Ubuntu PPA case, because PPAs are all their own third-party package repos that you have to add, while Ports is one flat namespace. As long as it’s “in ports”, you can depend on it without asking the user to do the equivalent of `sudo apt-repository add ...`)
If you don't have execute permissions, then, well, you're not going to be "installing" any software in any practical sense—you might be able to compile sources or copy files around, but you can't make the resulting binaries executable. Nor are you going to be doing much software development, for the same reason.
So why, at that point, would you need a compiler to exist on the box? It'd be like having GCC in a busybox installation.
Savy UNIX IT can take care of it, apparently the experience of what meant working in UNIX shops with thin terminals is now lost.
% bash -version
=> GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
Indeed- "external toolchain" includes gcc6[0] and gcc9[1] ports that can be used specifically for building the FreeBSD base system. These are mostly easy to use, install the flavor for whatever architecture you're building and specify CROSS_TOOLCHAIN=<arch>-gcc6 when you build. More/better/complete information (and examples!) at [2].
[0] https://www.freshports.org/devel/freebsd-gcc6
lapack, for example, has USES=fortran[1]. That invokes Uses/fortran.mk[2] and accepts the ports-default fortran compiler, FORTRAN_DEFAULT, which is definedin bsd.default-versions.mk[3] as gfortran (GCC).
[1]: https://svnweb.freebsd.org/ports/head/math/lapack/Makefile?r...
[2]: https://svnweb.freebsd.org/ports/head/Mk/Uses/fortran.mk?rev...
[3]: https://svnweb.freebsd.org/ports/head/Mk/bsd.default-version...
P.S. You can disagree with me and state your point, but you do not have to downvote me.
Not only that, but even proprietary software can be built with a GPL compiler, the binaries produced by the compiler are not considered derived work that must be covered by the same GPL license, so if Microsoft wanst to build Windows with GCC for example they can do that, provided that they don't link in the executable produced GPL code (e.g. glibc).
But there are technical reasons to avoid using GCC nowadays as well.
The GNU people have built in shitty anti-features into GCC suite, ostensibly to limit the ability of proprietary software to incorporate GCC into their products.
LLVM, which is what CLang uses, was partially a response to the artificial technical limitations intentionally imposed on users by the GNU GCC authors.
The main issue with GPLv3 is the so-called Tivoization clause. It basically states that if you have a product that ships with any GPLv3 software, you need to give your users the ability to install a modified version of anything you included that's GPLv3. Which basically means you can't lock down your device. That's a big security risk on an embedded system - both from an IP protection point of view, and also from a botnet/pwning point of view.
FreeBSD (and others presumably) don't want their users to need to worry about accidentally installing something from the core system and finding themselves in violation of the GPL.
If a company is interested in "protecting their IP" by closing the source then it's questionable why they would have even wanted to use GPLv2 software at all. The OEM's IP situation is also not related to the security of the customer. Maybe it matters to the security of the OEM, but that's different.
>and also from a botnet/pwning point of view
Complying with the GPLv3 doesn't mean the device becomes vulnerable to botnets. All it means is that the customer who purchased the device has to get access to the hardware keys. For their own device. That they purchased.
I can't speak for other engineers. But at companies I've worked in, a common product model is "embedded Linux with GPLv2 software, and some proprietary secret-sauce binaries". At those companies, they usually do send patches to upstream open-source projects and they try to contribute. Also they usually provide full source-code on request, for everything except the proprietary stuff.
The net effect of GPLv3 has been that GNU packages basically don't exist on embedded devices any more. Which means that engineers like me don't have the professional opportunity to contribute features and patches. It sort of isolates GPLv3 projects into a walled garden, which I feel like is the opposite of what GPL was intended to foster. Instead, I can only have the professional opportunity to contribute on GPLv2 or permissive-license projects.
> Complying with the GPLv3 doesn't mean the device becomes vulnerable to botnets. All it means is that the customer who purchased the device has to get access to the hardware keys. For their own device. That they purchased.
I sympathize with the intent behind this. There are also just some practical realities that are tough. At my current company, the team working on our next embedded Linux product is pretty small. We don't have infinite time or resources to make sure that our own code is 100% intrusion-resistant - all we can do is try our best.
It's a big ask for us to support _two_ methods of firmware-update (local and over-the-network) with different keys/security requirements for each. We just plain don't have the manpower to support that, not when we can be developing features to improve our product instead.
And if you have access to the filesystem, it's that much easier to comb through it and look for vulnerabilities in our network updater (for example). And it's easier to pick apart the proprietary bits with Ghidra or something. Could you do it anyways, even without our help? Maybe. But it's much harder.
Can we design a system that's robust enough to allow you to install whatever you want on your unit? Maybe. Probably. Hopefully we're already there. But I'm not going to risk my company's livelihood on it just to ship GPLv3 software, especially considering that there are almost-as-good alternatives for a lot of it. We just don't have the resources to make sure we cover every security angle on an open-box system.
The developers who relicensed to GPLv3 don't care that some companies won't contribute. From their perspective, any of those contributions would be unusable to them. I feel a similar way with my open source projects -- why would I as an outsider maintain code that nobody outside of your company will ever have any possible way to test in a real production scenario? It's a waste of my time. Yes I might be missing out on minor bug-fixes but I don't really care about that. Like you said, feature development is more important.
As far as firmware-updating goes, to be in compliance the user just needs to have some way to get access to the keys. You don't need to make separate keys, it can be the same method that you use.
I should clarify - what I meant is that if we're shipping GPLv2 software like Busybox, then I'm able to spend billable time improving Busybox and upstreaming my patches. That's labor that could be going to GNU coreutils instead, if it was the userspace on my product. But since I'm not shipping it, that means I don't find bugs or need features very often. Which means I have way less of an opportunity to pitch in.
I'm not making this up either. Even in my personal life I own lots of random devices that I know for a fact are running Linux and Busybox. But I have to go out of my way to find a device that I actually have a chance to get a toolchain running on and can actually start working on patches. It's usually limited to old devices that had no security or had their security broken. So any contributions I make are limited to things that only work on insecure old legacy hardware, stuff that is not going to be of interest to your company working on the next new hotness. There is a real problem here that's in-part solved by the GPLv3, but you have to actually acknowledge that it's a problem.
Ease of contribution is a problem for sure, and it's one that GPLv3 was intended to address. My main point is that the changes from GPLv2 actually had the opposite effect for a whole group of developers.
Instead of encouraging -more- development, I feel like maybe it's just driven developers away and onto GPLv2, MIT, or BSD equivalents. Maybe this is intended behavior, and not an accidental side-effect. I don't know. But it's hard to dispute that it reduces the pool of potential contributors to GPLv3 packages.
GPLv3 components just aren't an option for a lot of products, regardless of whether GPLv3 is better for users (I agree that it is). I think it's really harmed the FSF a lot. With fewer installations of FSF packages, the FSF sees less participation and loses some of its clout. And that makes me sad :(
But you don't have to do two different systems. You can use the exact same update mechanism, just with the cryptographic validation controlled by the owner of the hardware.
Look at how Secure Boot is implemented on most x86 platforms. Default installed keys from the OEM, can not be changed from the OS, but can be disabled or replaced by the end user.
Chromebooks offer another example of how to do it well with their "Developer Mode" switches. With the switch (which is not accessible on an operating system) in the default position it will only boot Google signed images. With the switch in developer mode it notifies the user of this on every boot, but no longer verifies signatures. The device is factory reset when switching modes to ensure that the unsigned mode can not be used to compromise a stolen device.
Android phones with unlockable bootloaders work similarly, they just have a software toggle in the first-stage bootloader rather than a physical switch.
---
There are plenty of low-effort ways to provide cryptographic verifiability to end users while still following not just the letter but the spirit of the GPL.
Obviously most of us would prefer something like the first example where a user could replace the stock keys with their own and sign their own code to maintain full security when going off on their own, the second and third options are nearly trivial to implement. One switch or jumper, a single input pin, and however much code it takes to check the state of that pin when performing any boot validation.
People can create any number of embedded system which are locked down so no one can change the software. The key here is nobody. Not the user, not the manufacturer, not some backdooring third party.
People are free to argue that allowing manufacturers access to devices after sale but not the actually owners is a security feature to prevent botnets and pwning, but that is a harder sell.
And what about Dell EMC Isilon OneFS, which uses FreeBSD as the base of their product? Or Panasas or NetApp? Juniper? Sony and their PlayStation 4? Netflix?
* https://en.wikipedia.org/wiki/List_of_products_based_on_Free...
FreeBSD is not just looking at themselves, but also at their users, which my have issues with GPLv3.
That said: it's good to remember how much of a breath of fresh air clang was way back when. Error messages in that era of GCC were _terrible_. Clang showed up with colorized error messages and ASCII art arrows and it felt like magic. So, sure, licensing alone would have been a fine reason for base to do what it did, but I don't think it's fair to characterize it as _just_ licensing. GCC has made huge improvements since then, but those are only visible in ports (which has always had and continues to have modern GCC). Which I guess you could argue makes it a licensing issue? :-)
I disagree; I think clang set a trend and now GCC's error message are worse than they used to be. In the recent days I've seriously considered patching them out because I'm getting really tired of the wall of text of useless suggestions, macro expansion, etc. that hides the actual error. 99% of the time I just need to see which line my error originates from (before any macro expansion) and I can follow the chain manually in the remaining 1% of cases.
What's happening now is that I have a line with an error, and I get 50 lines of trash output among which the actual error is buried. And trying to jump to the error in my editor has me jump through headers, #include rows, and other garbage, sometimes missing the original error line entirely!
It's ridiculous. The suggestions are also largely either wrong or so obvious that they have only negative value. It's just clutter. Same goes for the ascii art arrows. Just clutter, making it harder to see relevant things.
I can see these messages being helpful for a total newbie who's still acquainting themselves with the standard library and figuring out the basics of the language, but for me (writing C daily for a living, and as a hobby for the past 15+ years) it's just getting in the way.
But the clang switch was not motivated by its C++ error messages, to my knowledge.
The default colour is restored after the newline, rather than before it.
* https://github.com/llvm-mirror/clang/blob/6803cc1958b56e0bd5...
I have recently set DECSCNM on in my terminal(s), which inverts everything, effectively swapping the foreground and background colours. The clang error messages now come out with unsightly large streaks of extraneous colour, as freshly erased lines caused by scrolling fill with the colour that clang has not yet turned off. clang was always doing this. But when it's the background colour it's more visible.
It would be such a simple fix, that's actually in line with code elsewhere in the same class. I wonder how many years it will take to get it changed.
I have heard that the LLD (LLVM linker) is much faster than either ld.bfd or ld.gold.