fatmac wrote: Interesting reading through this thread, so I'm getting the impression that 'core' now has/sets up wifi(?).
It is one reason that I always resorted to 'base' - I could just add 'X' , fluxbox & browser to get going. :)
(That would make things about as easy as I find setting up OpenBSD.)

core could always do wifi, assuming your drivers were part of the kernel and didn't require any non-free firmware.  my netbook was quite happy with it using an atheros chipset.   Its the"non-free" stuff that gets you.    even intel wifi drivers requires non-free firmware.

Ah, maybe that was it, maybe I needed the non-free, still, it'll be worth another look when 17 comes out. :)

I had forgotten about the non-free.  But setting up wireless on the command line with ceni is a breeze (here).

Is there a short list of packages that contain that non-free stuff needed for wireless?   I could add it to the list of suggested packages in cli-aptiX.  You'd need a wired connection to get them.  I wonder if we could/should put them in a tarball on page with the iso files?

wicd-curses will let you do wifi from text mode (vt) even if x isnt installed.

figosdev wrote: wicd-curses will let you do wifi from text mode (vt) even if x isnt installed.

Wicd is not installed on the core system but ceni is.   Have you tried using wicd-curses?   It was highly unintuitive (at least for me).  As I said, ceni works like a champ here.

ive used wicd-curses extensively. the best explanation for not being more familiar with ceni is the lack of support (or preference) in the devuan world. i think there was debate about ceni ages ago.

i think probably"their" ceni is not the same as"your" ceni. you have different approaches, i think its fine that there are two of you doing two different things-- sometimes they choose methods that dont make a lot of sense, like"we could do this right now, but instead lets do something better that will take 10 years." the logic works out sometimes, other times... ????? i like their attitude about long-term solutions, but sometimes i think they need to patch *before* they spend years fixing. and they seem to be always far behind because they rarely do that. im sure ceni"works" in devuan, but i dont know if its reliable based on the history of network application choices in the distro.

an aside, they also have too many wannabe gatekeepers in the community-- apart from fsmithred, i dont like dealing with any of them. ive stopped paying attention to devuan and pretty much follow refracta only; which typically uses wicd-gtk, but ive used wicd-curses at least as often.

BitJam wrote: I had forgotten about the non-free.  But setting up wireless on the command line with ceni is a breeze (here).

Is there a short list of packages that contain that non-free stuff needed for wireless?   I could add it to the list of suggested packages in cli-aptiX.  You'd need a wired connection to get them.  I wonder if we could/should put them in a tarball on page with the iso files?

The main thing are the non-free firmware files, which the gnu-kernel used on antiX-core cannot utilize.  Its baked into the gnu-kernels not to allow non-free firmware to even load.  You can install them, but they won't be used.     I happened to cover this issue on my first antiX-core video series.  I had to change kernels to get my intel wifi to work (iwlwifi). 

that said, the antiX-net iso does not (or didn't) use a gnu-kernel, so in the second"build your own antiX-mate" series, I did not need to change kernels because I started with the net-iso.

ew, its one thing to not support non-free (which is the way i lean anyway) but its another to block non-free using some kind of program mechanism, requiring someone to either a. change kernels or b. defeat/workaround the almost-but-not-quite-drm-like exclusion mechanism.

a plugin like librejs that can simply be uninstalled (but doesnt require switching browsers) doesnt bother me-- tying that blocking feature directly into the kernel just seems... un-gnu-like, no matter what your opinion of the designers is. id love to know how the kernel is supposed to tell a libre compiled kernel module from a non-free compiled kernel module... this is the weirdest gnu tweak ive ever read about-- and i got to debian via trisquel and gnewsense. i even prefer a libre kernel, but not like that! it doesnt seem very freedom 0 at all.

figosdev wrote: ew, its one thing to not support non-free (which is the way i lean anyway) but its another to block non-free using some kind of program mechanism, requiring someone to either a. change kernels or b. defeat/workaround the almost-but-not-quite-drm-like exclusion mechanism.

a plugin like librejs that can simply be uninstalled (but doesnt require switching browsers) doesnt bother me-- tying that blocking feature directly into the kernel just seems... un-gnu-like, no matter what your opinion of the designers is. id love to know how the kernel is supposed to tell a libre compiled kernel module from a non-free compiled kernel module... this is the weirdest gnu tweak ive ever read about-- and i got to debian via trisquel and gnewsense. i even prefer a libre kernel, but not like that! it doesnt seem very freedom 0 at all.

I don't disagree.  I think the kernel can load the driver modules, they just don't work without the firmware, which apparently the kernel can distinguish somehow.

ive just sent polite-but-critical feedback (and questions about how it works) to alexandre oliva, this is fascinating news to me. ive been using the debian kernel ever since it went blob-free, and missed the point at which this happened.

my reasons for switching to debian from trisquel were mainly that trisquel didnt update often/quickly enough, and included some stupid things from ubuntu-- two birds, one stone. for years i was happy with debian, up until late 2014-- but im still happy with their kernel so far. if core could/did use the debian (blob-free) kernel i think it would be a major improvement for antix. i probably wouldnt ever use linux-libre with this"feature."

a plugin like librejs that can simply be uninstalled

it's not a plugin (aka NPAPI). It is an addon (a"system extension").
Bundled as a system extension, user cannot"simply" uninstall it.
This ("system extension" bundling) is identical to the baloney LinuxMint  pulls ~~ bundling a non-user-removable"Mint SearchEnhancer" ~~ user might click a feelgood tickbox to"disable" the extension, but is powerless to"uninstall" it.

Contrary to the propaganda they spew, this clearly is not an excercise in preserving user's freedom (freedom of choice).
They've made the choice, they enforce/preserve their choice in users' installed systems ~~  our way or the highway.

What has the"you can install non-free kernel modules, but they will be silently ignored" accomplished?
It has induced user confusion, and has caused untold wasted manhours across various linux user forums, across a span of years.

i just (now) heard from the project maintainer-- this is *not* a feature of linux-libre, its actually a very stubborn bug. theyre not sure its fixable (im still working to understand the reply which is in perfectly good english, but about a very technical subject im simply not familiar enough with) though i can provide some of the links ive received for more information. someone probably ought to create a separate topic about it if theyre interested.

its not a conspiracy, its not by design, they dont even love the bug that almost looks like a stallman-like move. i never thought it was a good idea software-freedom-wise-- they didnt do it on purpose. what i would like to know is-- if debians own blob-free stock kernel doesnt have this problem, why isnt it easier to fix in linux-libre? i would look into more information about the bug before i even asked for more of their time.

I'd love to see those links.   BTW: the kernel in core is not a stock Debian kernel, it was made by antiX, just like the others we use.  In antiX-17.b3_x64-core-libre it is:

BTW: the kernel in core is not a stock Debian kernel, it was made by antiX, just like the others we use

i know. thank you for the uname output/equivalent. here is the explanation and link:

Request for comments

A number of our users have expressed legitimate dissatisfaction with a consequence of the method we've used to stop the kernel from inducing users to install non-Free firmware. It is not our goal to prevent users from loading or running non-Free firmware, but the only way we thought of to avoid inducing users to run non-Free firmware had the side effect of making it impossible to use the non-Free firmware just by installing it.

In Linux, several drivers call request_firmware with a blob name. This request is logged, including the blob name, and passed on to a userland program, supposed to locate a firmware file with that name and upload it to the kernel. Given the logs, in addition to existing and potential behavior of the userland program, this amounted to Linux telling its user to install a specific non-Free program, which is unacceptable.

Linux-libre releases since generation 2 replace the blob name with a name that the firmware loader is unlikely to match, and that could be recognized in userland to inform users about the lack of Free firmware for some hardware component of the system. We also reject whatever response the firmware loader produces for such requests, to minimize the risk of accidental matches and hardware damage.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.fsfla.org/ikiwiki/anuncio/2010-03-Linux-2.6.33-libre.en.html"
linktext was:"http://www.fsfla.org/ikiwiki/anuncio/20 ... re.en.html"
====================================


ive located the recent (detailed) talk about solutions (or why they generally wont work) here:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://lists.gnu.org/archive/html/gnu-linux-libre/2017-08/msg00038.html"
linktext was:"https://lists.gnu.org/archive/html/gnu- ... 00038.html"
====================================


one solution is rejected because it would actually add to the same problem it tries to fix. for me, the solution is to use one of the distros that uses parts of the tools used to make linux-libre into their own blob-free kernels:

Distributions that compile a free Linux kernel

These distros don't use the packaged Linux-libre but instead completely deblob the proprietary Linux kernel with some of the tools to make Linux-libre. The source is then compiled and the resulting free Linux kernel is used by default in these systems:

BLAG[23]
-> Debian[24] <- <- <- <-
gNewSense[25]
Ututo[26]

Linux-libre as an alternative kernel

Distributions in which Linux is the default kernel used and which propose Linux-libre as an alternative kernel:

Arch Linux[27]
Canaima[28]
Gentoo Linux[29][30]
Slackware[31][32]

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://en.wikipedia.org/wiki/Linux-libre"
linktext was:"https://en.wikipedia.org/wiki/Linux-libre"
====================================


a note-- having read the mailing list post, i can provide an amusing summary until someone educates me further:

tl;dr: oliva seems to think that some distros like debian could meet the political and technical requirements (thats basically what ive proposed as well.) the reason linux-libre cant load blobs isnt deliberate or a feature, but the reason that its hard to fix is (it seems) political.

the reason that debian isnt a"solution" here is political. i dont turn my nose up at efforts to make our software free, but the largest caveat of using debians non-free kernel seems to be that it logs the blobs non-loading as an"error" in its log output, and i can deal with that.

would it be better to rephrase it somehow that acknowledged it wasnt an error? yes. would i stop using the debian kernel over it? unlikely. but i would still like there to be a solution the someday fixes this bug and also satisfies the linux-libre people.

Thanks for the info!   ISTM they are up against legitimate technical issues and are not balky due to politics.   I think it is legitimate to have the choice of a kernel that will never load non-free software.   It's also legit to have a kernel that does not come with non-free software but will load it, likewise a kernel that contains non-free software is also legit.  It's not all clear to me but this quote from the 2010 link sounds encouraging:

Thus, if the user insists on installing this firmware, Linux-libre will work with it, but it is very unlikely anyone will install the firmware because of Linux-libre.

In the past few years the kernel did greatly alter the way it handles loading firmware and modules so any solutions based on the old way go out the window.  I think it should be possible to adapt them to the new way but I'm not 100% certain.

My questions are: which class does the antiX libre kernel fall into?  Also, how is this implemented?  Is it a software patch plus a config parameter that can be switched on and off?   Can it be switched on and off via sysctl?