31–40 of 92 posts
Just keeps getting better and better every release. I wish they would add an easy encryption option in the installer. You can enable full disk encryption, but you have to mess with the bioctl settings, which potentially scares off new users.
> Fixed support for amd64 machines with greater than 1023GB physical memory. Don't I wish. What would be the memory test time for something like that?
Love the release poster for this one.
> Disabled gcc in base on armv7 and i386. Is gcc disabled in base on amd64? Are the OpenBSD distributions for amd64 compiled with gcc or clang?
gcc is still included in base on amd64 for now, but the default system compiler on amd64 (and i386) has been clang since OpenBSD 6.2. If you use the /usr/bin/{cc,c++} symlinks, you get clang. Nothing uses the base-gcc now, but it being kept as a convenience for porters to test with as some architectures have yet to switch to clang. The change mentioned is only that gcc4 (base-gcc) will no longer been installed alongs…
Did clang derive from gcc?
> Fixed support for amd64 machines with greater than 1023GB physical memory. Don't I wish. What would be the memory test time for something like that?
I recently set up a Dell workstation with that much memory for a lab at work. The first time I booted it I was afraid that it was dead out of the box. It probably took ~5 minutes to POST and get to the Dell logo. Dells also have this weird thing where they turn on for a couple of seconds after you turn on the power, and it took me half an hour to figure out why it kept shutting down when I tried to boot it.
https://github.com/librecore-org/librecore/wiki/Understandin...
Earlier quoted context omitted.
gcc is still included in base on amd64 for now, but the default system compiler on amd64 (and i386) has been clang since OpenBSD 6.2. If you use the /usr/bin/{cc,c++} symlinks, you get clang. Nothing uses the base-gcc now, but it being kept as a convenience for porters to test with as some architectures have yet to switch to clang. The change mentioned is only that gcc4 (base-gcc) will no longer been installed alongs…
Do you know what sparked the change that uprooted gcc's "dominance"? I know the GNU libc added a lot of "opinionated" pieces, but I thought that was mainly opt-in. I'm curious why gcc "lost its crown" and clang gained all of the attention. Did clang derive from gcc?
The clang compiler is a part of the LLVM collection, it is not derived from gcc at all.
As for GCC, The GNU project changed the license for their compiler sometime after the 4.2.1 release to the GPLv3. Meanwhile, up until the Clang 9.0.0 release, Clang was developed under a permissive license (NCSA). We're facing a similar problem now with LLVM/CLang, with their re-licencing to the non-permissive Apache 2.0 license.
Earlier quoted context omitted.
gcc is still included in base on amd64 for now, but the default system compiler on amd64 (and i386) has been clang since OpenBSD 6.2. If you use the /usr/bin/{cc,c++} symlinks, you get clang. Nothing uses the base-gcc now, but it being kept as a convenience for porters to test with as some architectures have yet to switch to clang. The change mentioned is only that gcc4 (base-gcc) will no longer been installed alongs…
Do you know what sparked the change that uprooted gcc's "dominance"? I know the GNU libc added a lot of "opinionated" pieces, but I thought that was mainly opt-in. I'm curious why gcc "lost its crown" and clang gained all of the attention. Did clang derive from gcc?
I've really been enjoying using OpenBSD full time, both on my desktop (AMD Ryzen build) as well as laptops (Lenovo X230, X1 Carbon). Everything literally "just works", the documentation is impeccable, and I love being able to install a new kernel and base system with one simple command ("sysupgrade"). About the only thing I still use Linux for is a browser with U2F support and Bluetooth - both are disabled in OpenBSD…
> Bluetooth [is] disabled in OpenBSD for security A clarification on that point: OpenBSD's bluetooth stack was unmaintained and removed due to code rot; it's not that bluetooth as a protocol is inherently insecure.
Bluetooth is a ridiculously complex protocol. Complexity is the enemy of security. There's no fixed threshold beyond which complexity makes something "insecure", and Wi-Fi and even USB aren't exactly simple (both have had their share of implementation exploits across operating systems), but AFAIU there's a strong sentiment that Bluetooth is far too complex for the benefit it brings, which perhaps explains why OpenBSD's stack was unmaintained.
I've really been enjoying using OpenBSD full time, both on my desktop (AMD Ryzen build) as well as laptops (Lenovo X230, X1 Carbon). Everything literally "just works", the documentation is impeccable, and I love being able to install a new kernel and base system with one simple command ("sysupgrade"). About the only thing I still use Linux for is a browser with U2F support and Bluetooth - both are disabled in OpenBSD…
Earlier quoted context omitted.
gcc is still included in base on amd64 for now, but the default system compiler on amd64 (and i386) has been clang since OpenBSD 6.2. If you use the /usr/bin/{cc,c++} symlinks, you get clang. Nothing uses the base-gcc now, but it being kept as a convenience for porters to test with as some architectures have yet to switch to clang. The change mentioned is only that gcc4 (base-gcc) will no longer been installed alongs…
Do you know what sparked the change that uprooted gcc's "dominance"? I know the GNU libc added a lot of "opinionated" pieces, but I thought that was mainly opt-in. I'm curious why gcc "lost its crown" and clang gained all of the attention. Did clang derive from gcc?
That's also not to discount some of the other efforts that clang made to make developer's lives easier with better error messages and for a decent amount of time, better static analysis tools (they're fairly comprable now). Those definitely helped but I don't believe that they drove nearly the same amount of time and resources compared to the above points.
EDIT: missed the bit about the libc stuff in parent comment
GNU libc and gcc are completely separate. As the sibling stated, the BSDs and other systems didn't use them and gcc doesn't require or directly use it either. There is a libgcc that gcc usually needs, that provides a bunch of boilerplate/other stuff to bring up the executable but that isn't part of either the C language or the C library. It's things like a definition of the _start() entrypoint and things to handle setting up static variables during initialization and that kind of thing. It's also got a GPL exception specifically in it's license to avoid conflicts with having to link with it. It is possible to build things with gcc without linking to that library, but you end up having to provide it all yourself. This is how gcc usually gets used on smaller embedded systems that don't need all the things it provides otherwise.