Future antiX Linux

[wildstar84Member]

Has the (first) antiX version# been decided on that will be based on Trixie (when Debian releases it as stable)?

[anticapitalXMember]

anticapitalista wrote:

Just some thoughts/plans about the future direction of antiX.
Note – this is not set in stone.

* antiX will continue to be Debian-based and free of systemd and elogind (at least on all our iso files).
* We will continue to provide (an) antiX custom kernel(s)
* antiX will ship only with window managers.
* ‘Pure’ Wayland support is a very long way (sic) away. Using Xwayland *might* be an option, but it will not be the default in the foreseeable future.
* Multiple init options. Building on the work started by Prowler.gr, we hope to offer s6 and s6-66 init options as well as our sysVinit and runit ones.
dinit *might* also be included as an init option. systemd will never be!
* Better/More ‘official’ support for community builds as long as they do not include systemd/elogind and they basically adhere to our values/code of conduct ie inclusive to all except racists, sexists, bigots.

Comments welcome.

Thank you for sharing the future plans for antiX. I appreciate the commitment to keeping antiX systemd-free and maintaining its core values. Here’s my feedback and suggestions:

Summary of the announced plans:
– Continuing as Debian-based while staying free of systemd/elogind
– Maintaining custom antiX kernels
– Focusing on window managers
– Staying with X11 for now, with possible Xwayland consideration in future
– Expanding init options (s6, s6-66, possibly dinit) while maintaining sysVinit and runit
– Supporting community builds that align with antiX values

Suggestions for consideration:

1. Enhanced Package Control Safety:
Add an option in antixCC to create restrictions/warnings for packages that attempt to install systemd, elogind, polkitd, or other restricted packages. This would help users maintain a clean, systemd-free system by preventing accidental contamination.

2. Integrated Backup Solution:
Implement a customized version of Timeshift specifically optimized for antiX, enhancing the existing backup and imaging capabilities to provide more robust system recovery options.

3. Flexible Full Installer:
Modify the full version installer to allow:
– Option to perform a minimal installation
– Package selection/deselection during installation
– Custom WM selection while avoiding unnecessary WM installations
This would eliminate the need to download separate base/core versions.

4. Memory Optimization:
Further optimize the memory footprint to enhance system performance, especially beneficial for older hardware.

5. Enhanced Service Management:
While maintaining the multi-init approach, implement a more user-friendly service manager interface to make service administration more accessible for users while keeping the system lightweight.

Additional suggestions:
– Consider implementing a system-wide profile for package management that could prevent installation of unwanted components by default
– Add built-in tools for easy system rollback in case of unwanted changes
– Enhance documentation for managing services across different init systems

I believe these improvements would further strengthen antiX’s position as a reliable, systemd-free distribution while maintaining its core principles of efficiency and user control.

^{Let's accept antiX as it is
Pure and Elegant by its nature}

[Brian MasinickModerator]

@anticapitalx those are some interesting suggestions, and they may be worth further discussion, investigation and inclusion. If by any chance you happen to have skills to contribute to any of these ideas and/or a sample “build” containing them, that would certainly help us out.

Take a look at some of the stuff that @calciumsodium puts together. While several of his builds are extensions NOT part of any official effort, quite a few of them have become popular. @ProwlerGr shared an “init-diversity” project with us about a year ago, which has been very useful as we have been considering additions to the init process that starts up in our Linux implementation of antiX. @techore has been very creative with his builds, and he created aXd, a respin with a dwm modified window manager called “Dusk”; he had previously shared a dwm respin with us. @christophe has demonstrated how to build an effective distribution from antiX Core, and the list goes on. @abc-nix has provided us with a few monthly snapshots.

These examples are helpful to others; some people like me make our own private builds with things we are personally interested in. I share my contributions in testing and forum moderator activities. With a decent group of forum volunteers, we’ve assisted our very small development team with our ideas and our code snippets and samples. This has proven to be valuable; thanks to our live builds and excellent tools, it’s pretty easy to customize and remaster our own systems.

--
Brian Masinick
Alternate "Search B":
This search page

[stevesr0Member]

re: anticapitalX post.

1. Concerned that there might be confusion between anticapitalista and anticapitalX. Perhaps anticapitalX could append something to make the username more distinctive?

2. Warning or restrictions to the install of packages that make antiX less than perfectly pure nosystemd. First, we would need an “official” statement about what that was, updated as the situation changes. With that in mind, a file could be created, containing a “current” list of packages to be avoided, with instructions on how to implement for noobies. The latter might include examples of use of apt-mark hold or pinning.

[sybokMember]

2. Warning or restrictions to the install of packages that make antiX less than perfectly pure nosystemd.

I think a potential script to do that coupled with apt hook (?) was suggested elsewhere.

@masinick: It raises several questions.
First and foremost, what does @anticapitalista think about it?
Should be there at all; present: opt-in (would not that make it a potential bloatware?) vs. opt-out; should the people handle it by themselves by installing a corresponding DEB package that someone would be willing to create & maintain?

[anticapitalistaForum Admin]

We already have point 2 in place – look at /etc/apt/preferences.d/00systemd

If users are running sid/testing, as I have mentioned before, you really should know what you are doing without any hand-holding.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[ProwlerGrMember]

Maybe late to the party, but I believe people that have used my spins would guess my opinion:
– No more separate sysvinit or runit versions, just unified iso’s that allow the user to choose which single or combination of init(s) to install & which one to make default (/sbin/init).
– I’d also suggest to limit the number of iso’s to a barebones net version (with good wifi support) and a full version (which allows selection of net/core/base/full in the installer).
Maybe explore if an ARM version is possible (I might explore this in the future with a raspberry Pi).

[Xunzi_23Member]

PPC Wrote

There’s a “new” script that allows to connect antiX to android devices via usb cable waiting to replace the current version for quite a while now. When possible, that would be a nice addition to antiX, replacing the current one

The inclusion would save many headeaches as it works with all the phones tested rather than a select few. Has been included on the local user setups, no complaints since.

antiX Conky manager GUI (that can edit many settings on the default conky or simply replace it with a more modern one) also ready for quite some time (that could replace the current “Conky” Control Centre entry)

Easier for new, gui centric users, so a nice to have, we may have more users with no linux experience coming due end of win 10 support.

The suggestion by ProwlerGR for full version with multi init rather than separate images would, if release ready be a very elegant option.

Default options exfat has caused some pain, again changing default good for users. Unless anything important speaks against it.

EXT4 is another never ending story, I have also hit problems due lack of backward compatibility, assume no easy fix for that.

Memory Optimization: Maybe a control center setup switch for zram zswap, if anyone else considers it as useful.

[Anonymous]

As a user that has done a lot of testing and making respins with multi-init systems,

and as someone who is fan of multi-init systems,

I still think it needs more testing from more users.

There is still the sound and logging issues that I have encountered in my testing.

Therefore, as one user, I would like to say that I think that the main antiX25 Trixie,

if that would be the name, should still be single init sysvinit and single init runit.

But we still continue to improve and do more testing with multi-init.

Thank you.

[anticapitalXMember]

Xunzi_23 wrote:

Memory Optimization: Maybe a control center setup switch for zram zswap, if anyone else considers it as useful.

I have already created a deb package for antiX memory manager .
please test it and report in the related topic .

if the deb doesn’t work as expected, please use this script instead .
it’s a link to antiX-memory-manager-v0.9h , which is the latest maintained version .
so far we didn’t work on adding antiX memory manager to the control centre.
maybe this is the time for you to take the project further , if you have that knowledge.

^{Let's accept antiX as it is
Pure and Elegant by its nature}

[vitforlinuxMember]

I am happy and reassured that antiX 25 based on Debian 13 will be like, almost, the 23; I am always afraid that things will stop working, so it is a nice thing.

I am sorry for the 32-bit machines; I believe the only solution is to extend the life of antiX 23 as much as possible.

Fortunately, there is still time for the complications with Wayland.

Sorry for my spaghetti english, i'm italian. Happy XORG user. GNOME? No thanks!

[Brian MasinickModerator]

Brian Masinick wrote:

@anticapitalx those are some interesting suggestions, and they may be worth further discussion, investigation and inclusion. If by any chance you happen to have skills to contribute to any of these ideas and/or a sample “build” containing them, that would certainly help us out.

Take a look at some of the stuff that @calciumsodium puts together. While several of his builds are extensions NOT part of any official effort, quite a few of them have become popular. @ProwlerGr shared an “init-diversity” project with us about a year ago, which has been very useful as we have been considering additions to the init process that starts up in our Linux implementation of antiX. @techore has been very creative with his builds, and he created aXd, a respin with a dwm modified window manager called “Dusk”; he had previously shared a dwm respin with us. @christophe has demonstrated how to build an effective distribution from antiX Core, and the list goes on. @abc-nix has provided us with a few monthly snapshots.

These examples are helpful to others; some people like me make our own private builds with things we are personally interested in. I share my contributions in testing and forum moderator activities. With a decent group of forum volunteers, we’ve assisted our very small development team with our ideas and our code snippets and samples. This has proven to be valuable; thanks to our live builds and excellent tools, it’s pretty easy to customize and remaster our own systems.

Just in case any of this is misunderstood, while our leadership has the freedom to do whatever they want, I am not advocating the automatic inclusion of any of these very interesting projects into our development team supported effort; our small team has plenty to do without pouring more on the top. @anticapitalista has expressed interest in a few things; if those are things that are chosen, that’s fine to me.

Regarding the many interesting projects noted above, I’m interested in them too; I just don’t want to place responsibility for those projects on the main team – unless of course those creators join the team and take responsibility themselves for doing and supporting whatever they’ve built, but even then, that’s only if that is approved by the leadership; otherwise these fun and interesting things simply highlight what is possible to build on top of our standard offerings.

--
Brian Masinick
Alternate "Search B":
This search page

[Brian MasinickModerator]

Anonymous wrote:

As a user that has done a lot of testing and making respins with multi-init systems,

and as someone who is fan of multi-init systems,

I still think it needs more testing from more users.

There is still the sound and logging issues that I have encountered in my testing.

Therefore, as one user, I would like to say that I think that the main antiX25 Trixie,

if that would be the name, should still be single init sysvinit and single init runit.

But we still continue to improve and do more testing with multi-init.

Thank you.

As I suggested above, I agree with you. I enjoy these projects, but to me, there are a lot of things to resolve before including this work in the core projects; also there is more than enough work for the current team to handle, so unless adding features to a future release is the choice of the leadership, I’m with you; great stuff, we’re both interested, but at this point, they are community projects of interest with more to understand, learn, and improve.

--
Brian Masinick
Alternate "Search B":
This search page

[Brian MasinickModerator]

One thing that will eventually be a requirement, but it’s been slowly and very gradually adopted, is the adoption of DEB822-style repository sources.

Here are a couple of references for this:
https://forums.debian.net/viewtopic.php?t=138415
https://manpages.debian.org/stretch/apt/sources.list.5.en.html

NOTE that this repository style has NOT been made a requirement, at least not yet, but recently the use of this format with a few of the EXTRA repositories I added to my own system actually helped me resolve one of my own mistakes; I failed to copy in some required GPG package keys into the smart, revised location in /usr/share as documented in the references above.

The bottom lines – and justification for eventually adding in this style is:
1) Improved Security

[opinion: improved debugging and resolution of unsigned or missing keys].

The DEB822 format separates each element into a separate line; for example:

/etc/apt/sources.list.d/sources.sources
Types: deb
URIs: https://deb.debian.org/debian/
Suites: stable
Components: main contrib non-free non-free-firmware
Enabled: yes
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

While I haven’t seen this forced into compliance, (no hint of this in Trixie), I have seen it gradually appearing; some apps are already adding it. Once we get used to using it, I think it’ll actually improve the ease of adding, updating, or replacing package keys, and it most certainly will assist in problem solving in these areas, plus, as protected files in each respective directory, there is an incremental improvement in the safe and secure placement and management of keys and resources.

--
Brian Masinick
Alternate "Search B":
This search page

[Author]

Posts