Debian User Forums

Posted: **2024-03-10 10:53**

I would like to present an 'init-diversity' spin of the current release of MX Linux 23.2

Download link:
MX-23.2_KDE_init-diversity-edition_UNOFFICIAL_20240222.iso
& torrent file:
mx-23.2-kde-init-diversity-edition-unofficial-20240222_archive.torrent

This spin includes 5 inits (sysvinit – systemd – s6-rc – s6-66 – runit), all able to run live & available to install.
This spin is in the MX distro’s spirit which is similar to Debian's spirit (systemd binaries fully present & utilised by other inits as well as systemd).

Credits should go to all contributors & testers of the original 'init-diversity' antiX-23 spin, especially @anticapitalista , aitor of Gnuinos, Eric of Obarun & of course @BitJam for his live initramfs patch which made this iso possible.

Posted: **2024-03-10 21:16**

Question - Why would I care?
Seriously. There is a few years old post on here that I ask that, no answers. It comes up still, still no answer really.

When I tried the various ways it all seemed like trying to tell the difference in chocolate milk. Was it stirred clockwise or counterclockwise, with a spoon or a fork or a spork, or was it shaken? I think if shaken there is a higher probability of getting flavor clumps and I don't know in this analogy what that means?

Both memory footprint and speed are not relevant, or significant anymore. It inits, it's done, so...?

I'd guess a custom kernel would have significantly better impact on low power machines. Past that I found no actionable or demonstrable advantage from one init to the other. I did find, or at least had the notion, that one or the other is more likely to lead to a future technical debt some may not anticipate. With some other recent post on "init-freedom' - could anyone tell me what is at stake?

Posted: **2024-03-10 22:35**

If you don’t care or don’t care enough to see why you might, don’t worry about it.

As for memory footprint and speed relevance, or significance I suspect you know as well as me that this was a major “selling point of systemd” back in the day. If it’s relevant now I don’t know or care. It’s not why I and others want init freedom. If systemd was just another init system no one would give a crap. Think window manager, editors, terminals etc. No body cares what someone else uses because it does not effect anything else. Systemd does that’s why it’s controversial.

What’s at stake? In a word. Choice.

I believe it’s more to do with individual user control, vs corporate control. Even Debian could not compete with the power of the big corporations pushing it. Their money meant they could over load the code base with such speed of change that a mere mostly volunteer powered entity like Debian could not keep up with them. This made the freeness of the software in effect irrelevant. Hence Debian in effect gave up the fight.

We see the same thing happening with wayland and the Linux kernel. We even have WSL doing the a similar thing. Reducing user power. This is about control. Nothing else. It used to be you ran “Windows” in a VM on top of Debian when you had to. Now Microsoft sponsors Debian and they run Debian on top of “Windows”. My newest laptop won’t boot. It has legacy mode that by default switches to UEFI. It’s so buggy that the CSM (compatibility support Module) won’t even boot the original Windows let alone Debian.

It’s all part of the same problem. Corporate power dictating to the individual by reducing or eliminating choice. Some people don’t like it, some people suck it up. Simple as that.

Posted: **2024-03-11 00:30**

Let's not start another init system flamewar here. The philosophical and practical concerns have been discussed endlessly in the past eg. - viewtopic.php?t=129881
Use what you like, there are options. Use the OP's respin if you want to try out some different ones. Use Devuan or Antix if that's what you're into.
For most people, including me, it's a non-issue and the default works fine.

Discuss the OP's offering in this topic if you wish. Keep your comments on topic.

Posted: **2024-03-11 02:20**

oswaldkelso wrote: ↑2024-03-10 22:35 What’s at stake? In a word. Choice.

This.

The actual goal is to bring the freedom to any Debian-based distro user to install & use any fully functioning init (even systemd if it is their choice), without them feeling that a specific init is being enforced, & without the need to have heated debates or GR in order to allow this.

Everybody here old enough would know about the heated 2014 GR which kinda led to a split, & the follow-up 2019 GR which was in the spirit to re-unite & allow supporting alternatives.
The problem at the time was that the s6 options were not mature enough to be seriously considered, so the debate was between the venerable but 'feature deficient' sysvinit & 'controversial' systemd.

Technically if you try the respin you will find each init works independently from each other (does not try & hijack folders & files used by other inits).
Debian can keep shipping with systemd linked to '/sbin/init' & the fully supported init, & interested parties can continue supporting other inits with relevant init scripts or frontend unit files...

Most users (myself included) do not mind using various systemd parts (or modules) on their systems.
However more than a few (myself included) simply want something else running as PID 1, & this spin's concept is in the spirit to address this.

Posted: **2024-03-11 03:05**

Already then!
With the existence of this distro variation, 6 years after the linked good read, means the situation is in good shape.

Code: Select all

$  ps 1
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:07 /sbin/init

Posted: **2024-03-11 12:54**

CwF wrote: ↑2024-03-11 03:05 Already then!
With the existence of this distro variation, 6 years after the linked good read, means the situation is in good shape.
Code: Select all
$  ps 1
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:07 /sbin/init

Wow - what a sarcastic post -- and from a Global Mod too

The init-diversity iso is a showcase of 5 init systems (3 of which are poorly supported in Debian). That is all.
All init systems on the iso have been built to work independently of each other and deb packages are available.
Therefore, it should be seen an an enhancement to Debian, not a competitor.

Posted: **2024-03-11 17:36**

anticapitalista wrote: ↑2024-03-11 12:54 what a sarcastic post

It was not meant as such. It is simply dropping the subject...

In sunrat's linked post, and some links from there, there is lots of good stuff on the subject. I could link some comments from those, or from my own above to do exactly what was discouraged...

IMHO, linux is paralyzed by excessive choice. That is a thing...

Posted: **2024-08-18 21:14**

Hi,
This respin is of interest to me for the following reasons. I'm trying to give runit (instead of systemd) a try. I tried AntiX-runit but find it too primitive for my needs. So ,in the first instance: thank you very much!

Accordingly I downloaded your iso image and proceeded to install the 'runit flavour'. The installation went fine , but when I restarted, I could not access the internet; in fact networking wasn't fully started; for example device 'eth0' was present but down.
This problem only seems to be present in the 'runit' version; if I start e.g. the 'sysv' version via the grub menu, everything works fine.

I got internet access working as follows...

root@felix:/var/log# ip link set up eth0
root@felix:/var/log# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 30:8d:99:7a:06:04 brd ff:ff:ff:ff:ff:ff
inet6 2a02:a44a:b0c4:1

99ff:fe7a:604/64 scope global dynamic mngtmpaddr
valid_lft 189336sec preferred_lft 102936sec
inet6 fe80:

99ff:fe7a:604/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether cc:3d:82:c8:5c:9e brd ff:ff:ff:ff:ff:ff
root@felix:/var/log#

.... and presumably I could get a 32-bit ip address via dhcp if only I knew the 'ip' command better!

And now the questions:
Is there a simple neat fix for this symptom which would make this variant work better?

Here is part of the so-called 'quick system information':

Code: Select all

Snapshot created on: 20240222_0159
System:
  Kernel: 6.1.0-17-amd64 [6.1.69-1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.1.0-17-amd64 root=UUID=<filter> ro quiet selinux=0 splash
  Desktop: KDE Plasma v: 5.27.5 wm: kwin_x11 vt: 7 dm: SDDM Distro: MX-23.2_KDE_x64 Libretto
    January 21 2024 base: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: Laptop System: Hewlett-Packard product: HP ZBook 15 G2 v: A3009DD10303
    serial: <superuser required> Chassis: type: 10 serial: <superuser required>
  Mobo: Hewlett-Packard model: 2253 v: KBC Version 03.12 serial: <superuser required>
    BIOS: Hewlett-Packard v: M70 Ver. 01.26 date: 03/03/2020
Battery:
  ID-1: BAT0 charge: 56.3 Wh (98.4%) condition: 57.2/57.2 Wh (100.0%) volts: 16.6 min: 14.4
    model: Hewlett-Packard Primary type: Li-ion serial: <filter> status: not charging
CPU:
  Info: model: Intel Core i7-4710MQ bits: 64 type: MT MCP arch: Haswell gen: core 4 level: v3
    note: check built: 2013-15 process: Intel 22nm family: 6 model-id: 0x3C (60) stepping: 3
    microcode: 0x28
  Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache: L1: 256 KiB
    desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB L3: 6 MiB desc: 1x6 MiB
  Speed (MHz): avg: 2769 high: 3365 min/max: 800/3500 scaling: driver: intel_cpufreq
    governor: schedutil cores: 1: 3078 2: 2512 3: 2502 4: 3365 5: 3146 6: 2516 7: 2497 8: 2542
    bogomips: 39908
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data status: Unknown: No mitigations
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB
    filling, PBRSB-eIBRS: Not affected
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort status: Not affected

Thanks for your attention,
Larry Myerscough (aka papahippo)

Debian User Forums

[Derivatives][Unofficial Respin] MX-23.2 KDE 'init-diversity' Edition

[Derivatives][Unofficial Respin] MX-23.2 KDE 'init-diversity' Edition

Re: [Derivatives][Unofficial Respin] MX-23.2 KDE 'init-diversity' Edition

Re: [Derivatives][Unofficial Respin] MX-23.2 KDE 'init-diversity' Edition

Re: [Derivatives][Unofficial Respin] MX-23.2 KDE 'init-diversity' Edition

Re: [Derivatives][Unofficial Respin] MX-23.2 KDE 'init-diversity' Edition

Re: [Derivatives][Unofficial Respin] MX-23.2 KDE 'init-diversity' Edition

Re: [Derivatives][Unofficial Respin] MX-23.2 KDE 'init-diversity' Edition

Re: [Derivatives][Unofficial Respin] MX-23.2 KDE 'init-diversity' Edition

Re: [Derivatives][Unofficial Respin] MX-23.2 KDE 'init-diversity' Edition