Are there blobs in antiX and what can be done about it?
antiX / MX LinuxThis forum is for the discussion of antiX and MX Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Transparent is not more vulnerable then anything you make it to be...
I nearly crashed trying to decode this one. Where did I imply transparent is more vulnerable? I'd go for LFS-based Arya Linux any time if it worked with debian packages and was maintained as well as debian.
Antix's ability to run on older hardware is an attractive feature
...and I strongly suspect that this entails shipping with non-free firmware at the very least, maybe even non-free drivers.
Quote:
But my core motivation in this thread is security and privacy. Without sacrificing ease of use.
Oh, those two sentences.
They cannot be reconciled, only a compromise is possible.
Quote:
Antix is also attractive because it is perceived as a people's distro, as opposed to a corporation-serving one. But then I have no idea who finances its development and decides things. Who does?
Pretty sure there's very little finance involved apart from running the servers for the web pages / download mirrors, the rest is an ongoing community effort and the mothership debian of course.
But it would be interesting to hear anticapitalista's statement.
Or one might wonder: why not just compile devuan (debian without systemd). Because antix is faster and needs less ram. Could configure devuan with the same packages but there must be more to antix than a collection of packages.
but there must be more to antix than a collection of packages.
Bitjam and Dave are giants in human form. Lot's of custom scripting going on. Anti is like the rock we all live on.
A lot of free flowing tweaking goes on even after a release.
Just a thankful opinion though.
Edit: cringing after I posted this. I abhor main stream. Ubuntu and Mint can keep it.
Are there blobs in antiX and if yes, what can be done about it?
Look at what is installed and then perhaps try to discern what it actually is:
Quote:
Originally Posted by anticapitalista
Code:
amd64-microcode Processor microcode firmware for AMD CPUs
atmel-firmware Firmware for Atmel at76c50x wireless networking chips.
bluez-firmware Firmware for Bluetooth devices
broadcom-sta-dkms dkms source for the Broadcom STA Wireless driver
firmware-amd-graphics Binary firmware for AMD/ATI graphics chips
firmware-atheros Binary firmware for Atheros wireless cards
firmware-bnx2 Binary firmware for Broadcom NetXtremeII
firmware-bnx2x Binary firmware for Broadcom NetXtreme II 10Gb
firmware-brcm80211 Binary firmware for Broadcom/Cypress 802.11 wireless c
firmware-intelwimax Binary firmware for Intel WiMAX Connection
firmware-ipw2x00 Binary firmware for Intel Pro Wireless 2100, 2200 and
firmware-iwlwifi Binary firmware for Intel Wireless cards
firmware-libertas Binary firmware for Marvell wireless cards
firmware-linux-nonfree Binary firmware for various drivers in the Linux kerne
firmware-misc-nonfree Binary firmware for various drivers in the Linux kerne
firmware-myricom Binary firmware for Myri-10G Ethernet adapters
firmware-netxen Binary firmware for QLogic Intelligent Ethernet (3000
firmware-qlogic Binary firmware for QLogic HBAs
firmware-realtek Binary firmware for Realtek wired/wifi/BT adapters
firmware-zd1211 binary firmware for the zd1211rw wireless driver
intel-microcode Processor microcode firmware for Intel CPUs
midisport-firmware Firmware loader for M-Audio's MidiSport devices
b43-fwcutter utility for extracting Broadcom 43xx firmware
firmware-b43-installer firmware installer for the b43 driver
firmware-b43legacy-installer firmware installer for the b43legacy driver
iucode-tool Intel processor microcode tool
Those emphasised above are device firmware/microcode for those devices. The binaries mostly live in /lib/firmware and they are in most cases part of the Linux kernel sources.
There are a few important points you should consider with regard to these:
1) None are Linux binaries, so they cannot be executed by the host OS.
2) If you don't own that particular hardware, they will never be used.
3) Some devices, by design, have their firmware/microcode loaded by the host OS.
4) Many other devices on a typical x86 system have the same (closed source, proprietary) firmware already loaded onto the device. The system BIOS/UEFI, CPU microcode, the IME/PSP firmware and other firmware in devices such as hard disks and network controllers are just a few examples.
5) Once loaded, the firmware runs on the device, not on the host OS - which is exactly the same as any firmware already installed on any other devices.
It boils down to:
Do you have any of that hardware?
If so, do you want it to work?
You can remove the packages and get some "feelgood", or you can just leave them there...
Those I have not emphasised are not part of the kernel, but in particular, the broadcom/b43 related packages are to do with drivers for certain wifi chips. If you have those devices, you either install the required driver or don't use the device (but presumably continue using the rest of your hardware with it's embedded firmware - ignorance is bliss?).
x86 is what it is, if you want totally free, then you need different - open - hardware.
This was a fascinating conversation that I constantly find myself referring to as it incorporates concepts than I'm learning, applying & turning over in my head regularly regarding privacy, software freedom, etc.
I do know for a fact that AntiX would not be happily running on my WinXP-era HP Pavillion w/out some of those "blobs" particularly the broadcom ones...so in that regard I must be pro-blob.
On the side, there's my librebooted X200 running a certain liberated legacy-era distro well enough but there are issues (w/the browser's ability to handle the modern web, to be more specific) that keep me from going all in with the libre camp for now.
Lots of Smart People, some even on this forum ;-) are ok with binary blobs. They believe that the dangers are negligible to non-existent and that leaving no binary blob unturned is a rabbit hole from which there is no escape. I can see that, although I think we can all agree that things like the Intel ME are a truly unsettling trend.
But as cynwulf notes, open hardware offers the only true escape from "the blobs."
As far as I know, "anticapitalista" makes the final decisions, but cedes to trusted volunteers, if that tells you anything.
I am going to guess that antiX and Devuan are on similar levels in terms of being secure. I would take the one that has non-free binaries removed over the one that doesn't. Neither remove those by default.
In the Sparky linux aptus package(control center) there is an option to "remove all non-free". You might have a look at that
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
