Are there blobs in antiX and what can be done about it?

Ulysses_ · 11-24-2019, 12:55 AM

Quote:

Originally Posted by jamison20000e

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.

freemedia2018 · 11-24-2019, 05:27 PM

Neither a joke, nor an entirely serious suggestion but--

Debian has all the source-- why not just Compile Debian?

Ulysses_ · 11-25-2019, 01:31 AM

Because antix works with less ram and cpu usage. At least the version I tried a few years ago did. It even booted on year 1999 hardware.

Ulysses_ · 11-25-2019, 01:37 AM

That was antiX-13.2_386-full Luddite 4 November 2013 on a Celeron at 400 MHz with 384 MB of ram.

rokytnji · 11-25-2019, 09:43 AM

Quote:

Originally Posted by freemedia2018

Neither a joke, nor an entirely serious suggestion but--

Debian has all the source-- why not just Compile Debian?

Since systemd creep on ram usage and cpu usage has been documented on the net over the years since sysytemd was adopted.
Citation: link

Why rebuild something already tweaked and polished?

http://yatsite.blogspot.com/2009/07/...-old-gear.html

Some kid bought the above for street cred in high school . After I fixed it.

ondoho · 11-26-2019, 01:26 AM

Quote:

Originally Posted by Ulysses_

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.

freemedia2018 · 11-26-2019, 08:36 PM

Quote:

Originally Posted by rokytnji

Since systemd creep on ram usage and cpu usage has been documented on the net over the years since sysytemd was adopted.

That's a good reason for me, though I'm trying to figure out Ulysses's reasoning.

You and I are on the same page regarding systemd-- that, or I like it even less than you do.

Ulysses_ · 11-27-2019, 12:44 AM

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.

Jan K. · 11-27-2019, 10:50 AM

You *could* of course dwell a bit on the antiX documentation to see, what's it about...

Have a feeling though, you're probably guessing right...

rokytnji · 11-27-2019, 10:54 AM

Quote:

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.

cynwulf · 12-04-2019, 10:22 AM

Quote:

Originally Posted by Ulysses_

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.

metaBLAG · 07-17-2020, 05:06 PM

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."