Devuan releases a candidate.. finally?!

I've just heard from The Register4: "systemd-free Devuan Linux hits version 1.0.0".

My views on systemd still stand. I was hoping to be proved wrong, perhaps in the long-run. But sadly what I see, has only just served to entrench those views. Gnome & systemd proponents are imposing a bad attitude on the open-source philosophy, trying to hijack & lock out everything else outside their ecosystem. Everything within their ecosystem seems to be completely dependent on them. Hence why I prefer not even attempt to use those two.

Arch was the first casualty.. quickly followed by Debian. It is amazing how code maintainers seem to have become gods wrt users. My long journey through alternatives.. seems to have ended with gentoo, which seems to have become my only choice for now. However, I still need a few alternatives to recommend to others not that technical or keen to spend time getting to know internals. Now, I think I have something in that stack with Devuan, which has just released a stable release candidate (1.0.0-RC)3. "If all goes as planned, this will be our first Devuan stable release and our first long term support (LTS) release as well."

The Devuan story began with a vision to fork debian2 - "Devuan should be a minimal, stable system which honors Debian history and embraces innovation while maintaining backwards compatibility and interoperability."

The Debian decision-makers of that time spread so much FUD, when they decided it was systemd or nothing1. A "one-size-fits-all vision" only fits the decision-makers. There are alternatives. There are always alternatives. There should always be alternatives.

I might wait a while till the RC becomes final. I don't need to, as I expect a smooth transition henceforth.. to final and LTS. If anyone is thinking of debian, try devuan instead.


Ubuntu Phone is dead.. Long live The Phone!

Mark Shuttleworth writes2 about the end of Ubuntu Phone.. apparently NOT "widely appreciated both in the free software community and in the technology industry... In the community, our efforts were seen fragmentation not innovation."

I think he refers to the Gnome community. There are many communities not part of the Gnome establishment.

One of the more promising efforts to bring open-source to mobile devices has been killed. Wonder why? Closed-source can conceal covert initiatives by folks behind the scenes.

I'm a bit sad that the only promising effort towards a Linux Phone has died. I kept seriously looking at Ubuntu Phone/Tablet, waiting for it to mature1.. even maintaining a few Ubuntu desktops just for this purpose. Unfortunately, their strategy didn't include the wider community. If you didn't have Ubuntu desktop, you couldn't have Ubuntu Phone emulator or dev.

My recommendation to folks on Ubuntu is Xubuntu. Lubuntu could be beautiful and streamlined, but looks ugly right now. When Lubuntu switches to LXQt, my recommendation will switch to Lubuntu.

I was never a big fan of Unity, and an even lesser fan of Gnome, to which Ubuntu has been pushed. I personally think the folks behind Gnome have been, and continue to be, some with the worst attitudes in open-source..

With this, Ubuntu goes back to become one of the also-rans. I don't see what differentiates Ubuntu from any other Gnome distro.


busybox .config in gentoo

busybox can be configured, just like the kernel. and we can do so in gentoo, with USE=savedconfig.

$ emerge -pv busybox

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild   R    ] sys-apps/busybox-1.25.1::gentoo  USE="static -debug -ipv6 -livecd -make-symlinks -math -mdev -pam -savedconfig (-selinux) -sep-usr -syslog -systemd" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

gentoo savedconfig is the name of the package, and located here:
$ ls -lh /etc/portage/savedconfig/*/busybox*
-rw-r--r-- 1 root root 26K 2016-12-21 10:43 /etc/portage/savedconfig/sys-apps/busybox-1.25.1

we can edit this file manually. but it is much easier/safer to manually configure it the busybox way.

$ ebuild /usr/portage/sys-apps/busybox/busybox-1.25.1.ebuild fetch clean unpack
$ cd /var/tmp/portage/sys-apps/busybox-1.25.1/work/busybox-1.25.1
$ cp -vi /etc/portage/savedconfig/sys-apps/busybox-1.25.1 .config
$ make menuconfig
$ sudo cp -vi .config /etc/portage/savedconfig/sys-apps/busybox-1.25.1

emerge busybox with savedconfig useflag.

$ sudo rm -rf /var/tmp/portage/sys-apps/busybox-1.25.1
$ USE="savedconfig" sudo emerge busybox

reboot gentoo to test it fully. if everything works, add savedconfig flag to sys-apps/busybox in /etc/portage/package.use.

to revert back, emerge busybox without savedconfig useflag.

Phasing out Arch Linux

ref: Phasing out i686 support

Arch Linux is great at what it does.. i.e. only offering bleeding edge and providing no choices to it's users. I don't want either of that, and I am now phasing out arch from my stacks.

I liked arch for a while in the past, and seriously considered migrating over from debian. That spot has been taken over now by gentoo, which gives me endless choices without restriction -- Gentoo Foundation Principle #1.

I can not completely migrate away from i686. I am also not completely convinced that systemd is better, smaller, or even faster compared to others like runit, or openrc.

I still think arch has a great community, and the arch wiki is one of the best in appearance & contents, and I might continue to participate or lurk there. The gentoo community is very helpful too and growing on me, but the gentoo wiki is disappointing.

runit openrc gentoo

I decided to have another go at runit, this time on my gentoo.

I had been thinking about this, since I noticed this in the Gentoo Wiki article on OpenRC:
It does not function as a replacement for the /sbin/init

I keep wanting to trim everything down, and have been integrating busybox to replace userspace utilities. The gentoo wiki says:
Busybox can be used to replace most of the userspace utilities needed by OpenRC (init, shell, awk and other POSIX tools), by using a complete Busybox as shell for OpenRC all the calls that normally would cause a fork/exec would be spared, improving the overall speed. This process is not yet streamlined.
Please note that there are currently many Busybox applets that are incompatible with OpenRC.

It was that last bit which concerned me, and I didn't want to risk hacking it too much.

But I could hack /bin/init provided by sys-apps/sysvinit. I do like runit, and decided to install sys-process/runit which provides /sbin/runit-init.

The install was pretty simple:
# emerge --ask sys-process/runit

I was very surprised when my regular clean up routine asked to unmerge sys-apps/sysvinit.

# emerge --depclean --ask 
>>> Calculating removal order... 

>>> These are the packages that would be unmerged: 

    selected: 2.88-r9 
   protected: none 
     omitted: none 

All selected packages: =sys-apps/sysvinit-2.88-r9 

>>> 'Selected' packages are slated for removal. 
>>> 'Protected' and 'omitted' packages will not be removed. 

Would you like to unmerge these packages? [Yes/No] n

Was it not needed anymore?

Wanting to see what gentoo does out of the box, I rebooted, and appended init=/sbin/runit-init to the kernel cmdline boot prompt.

My system booted up cleanly, and I could login and startx.

However, I had no network. But I could manually start my network, and all was fine.

# /etc/init.d/net.wlp3s0 start

Subsequently, I realised that none of my other services had started. I narrowed them all down to the default runlevel.

It seems that all the services in sysinit and boot runlevels had started, but the default runlevel had not been triggered.

So this was the only thing to do, in order to have runit instead of sysvinit on gentoo out of the box. Impressive!

I had a look at runit's runlevel 1.

$ cat /etc/runit/1                                                                                                                                                                                   
# system one time tasks


RUNLEVEL=S /sbin/rc sysinit
RUNLEVEL=S /sbin/rc boot

touch /etc/runit/stopit
chmod 0 /etc/runit/stopit

It looks like runit runlevel 1 is triggering the openrc runlevels sysinit and boot, but default is not listed there. So I just added it in there.

$ cat /etc/runit/1                                                                                                                                                                                   
# system one time tasks


RUNLEVEL=S /sbin/rc sysinit
RUNLEVEL=S /sbin/rc boot
RUNLEVEL=S /sbin/rc default

touch /etc/runit/stopit
chmod 0 /etc/runit/stopit

I rebooted again to test. All my services were working, and I had no errors or warnings.

I decided to go for broke, and remove sysvinit with a bit of trepidation, but knowing that I could put it back as it was.

# emerge --ask --depclean sys-apps/sysvinit

With a clean slate, I rebooted again and was pleasantly surprised. Everything seems to be well on my system.. Well, almost!

sysvinit had disappeared along with shutdown, reboot, halt, poweroff, etc. So I had created them.

# vi /usr/local/sbin/runit-shutdown
case "$(basename $0)" in
  reboot) /sbin/runit-init 6 ;;
    /sbin/runit-init 0 ;;
# cd /sbin
# ln -s /usr/local/runit-shutdown shutdown
# ln -s /usr/local/runit-shutdown poweroff
# ln -s /usr/local/runit-shutdown halt
# ln -s /usr/local/runit-shutdown reboot

And all is well again. Powerbutton is working, as are my other i3 keybindings.

As the runit article on gentoo wiki says:
It can be used in conjunction with OpenRC as an alternative to sysvinit or even replacing OpenRC as service manager.
Runit can also replace OpenRC as the service manager.
which means runit can do everything on it's own. I have seen it being very dependable & stable in voidlinux.

Now why didn't the linux lords consider lean, clean & simple runit, when deciding about systemd?

I am usually very critical of systemd. But kudos where it is due, for systemd removing much accumulated garbage/cruft like *bus *kit etc.

For now, I will keep openrc as service manager, and runit as system init. Too much hacking at the gentoo core might take me too far away.

$ pidof runit

most popular posts