Please wait...
I don't think Alpine is ready for prime-time on the desktop (it uses a ground-up reimplementation of libc, which has had compatibility issues at times, so arguably it is not Linux in the traditional sense) but it is a good fit for certain Dockerized workloads.
WSL 2 is little more than a VM, and if I'm going to run a VM, I might
as well run real Linux.
And one that moves you onto HyperV at that, with all the implications thereof for your Windows host. It might not be the best if you like to run games, although that may not be as true as it used to be as Microsoft has begun to enable it by default.
GNOME 3.36.2:
"Due to the COVID-19 pandemic, the development team also re-enabled support for the TLS 1.0 and 1.1 protocols in the glib-networking component."
maybe something was broken and there was not enough manpower to get a proper fix? who the actualfuck knows.
PCI compliant sites are not supposed to be using TLS1.0 anymore. I'm not even sure 1.1 is legit these days, I'd have to check.
Sun May 24 2020 15:33:07 EDT from LoanShark @ Uncensored
I don't think Alpine is ready for prime-time on the desktop (it uses a ground-up reimplementation of libc, which has had compatibility issues at times, so arguably it is not Linux in the traditional sense) but it is a good fit for certain Dockerized workloads.
It uses musllibc, which is quite awesome as it allows full static linking. We never had problems with it.
In the past there were some widespread, well-documented compatibility issues between python modules and musllibc. For a while, python on Alpine had to disable the binary download mechanism for Python packages and force everything to be recompiled locally. That appears to have been done away with, but the fact remains it's a different implementation. DNS lookups also behave a bit differently, I hear, and although this conforms to the letter of the RFC's I've heard it can be unhelpful at times. I'd be wary of running it in a use-case where it was expected to have broad, generalized compatibility with the entire Linux ecosystem, but it's great for containers.
It always depends on the use case. If you want to target a broad range of embedded systems glibc will be a pain up the a* because it does not allow full static linking. For instance we can successfully execute some of our binaries on android devices and other SoC based systems.
$ gcc -static hello.c -o hello
$ ldd ./hello
not a dynamic executable
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=27d3d47a630b097110f0f432f28109b609c6b5d5, not stripped
(After the quick test, I'm still not sure what you mean by that. Maybe applies only to ARM/Android?)
If you depend on getaddrinfo or iconv (which you will quite fast when using other 3rd party libraries) you will run into troubles.
If your application uses for instance getaddrinfo and you compile with -static gcc will give you a big warning, that you will only be able to execute this binary on systems with the exact same glibc version. (It will use dlopen to load needed libraries even tho its is statically linked)
Once again, this is a reason people are putting things into containers now.
Yeah, but containers are not avaiable for every platform, thats why working with musl is quite cool :) You can for instance compile GUI programs with fltk, completely statically link the X11 stack and execute it then on a generic android device. There are some X11 servers for android out there to display your program.
In other news [ https://tinyurl.com/y4krklpr ] from the "well obviously" department, India Business Machines, the former technology company, has started swinging the axe in the Red Hat department. Apparently they're doing a reasonable job keeping it quiet, but if you go looking, the reports are that "typical IBM" behavior is happening. Red Hat's culture is being replaced by IBM's, their patented breed of Manager Cancer is creeping in everywhere, layoffs are happening in Raleigh, and hiring is happening in India.
If you're still relying on Red Hat, CentOS, or Fedora ... "do the needful" and switch to something else while you have the time to do it at a relaxed pace. Fedora is reportedly "increasingly being left out of the loop" so its utility as an unofficial prequel to RHEL is probably not going to happen for much longer. CentOS is nice because it's basically just a respin of RHEL with the branding and proprietary bits removed, but how much longer will Big Blue allow that?
Thankfully, the Linux world will adapt, as it always does...