Shape of things to come

Some of the people involved with linuxbasix in the past wonder if there’s interest in reviving the community. kwisher has a poll up in the forums here. If you think reviving the community is worthwhile, you can add a comment to the forums post.

There’s also the #linuxbasix channel on, where you can have real time interaction to discuss this. Use your favorite irc client or freenode’s web interface to their irc network here.

Bye, all

Got an email today from knuckle that he (as the domain owner) decided to archive the web site. Thanks for reading, thanks for contributing and hope y’all think what was done with was valuable.

til about ulatencyd

In irc a little while ago someone was having trouble with ftp’d files to a lighthttp server and mentioned apache had been taking up too much ram on the system, and I made a comment that ‘cgroups will solve that problem (ram usage), I’m told’. Someone else chimed saying ‘ulatencyd’, which I had never heard of, and frankly when I first read the word, thought it was a typo.

But no, lo and behold, ‘ apt-cache search ulatencyd ‘ on this debian testing machine returned two packages:

ulatency – scriptable latency regulator using cgroups (client)
ulatencyd – scriptable latency regulator using cgroups (server)

Jessie’s ulatencyd page has links to the maintainer’s page, bug reports and the popularity context statistics for ulatencyd. Pretty popular, afaict.

Poking around the ‘net for introductory information about ulatencyd, I cam across Linux Performance Improvements a blog post by Frederik Himpe, a 30-year-old Linux system administrator from Ghent, Belgium, working at the Vrije Universiteit Brussel. Much good stuff in that blog post, well worth a read.

Remember those 20 lines of code from a few years ago which were going to super-turbo-warp-drive everyone’s desktop? Tongue in cheek, ulatencyd is the Next Generation of that code:

ulatencyd is a daemon which uses cgroups to give hints to the kernel’s process scheduler CFS to improve desktop latency and make applications feel more responsive. It will prevent individual applications from hogging the system, slowing down other applications . This is somewhat simpler than the much hyped (but controversial) autogroup kernel patch but this solution is much more extensive in that ulatencyd knows different applications and desktops and knows how to configure the scheduler to improve responsiveness.

(from the blog post)

I don’t do the kind of fiddling involved in switching desktops, distro hopping and trying new applications anymore, but ulatencyd looks like it’s worth a try.

When you get a grub rescue> prompt and don’t have bootable media or printed documentation

A day or three ago, we lost power here. I was able to halt the system before the battery backup ran out, but when the electric company restored power, booting up threw me into a grub rescue> prompt along with ‘file not found’ or ‘no such file’ I forget which. No other machine available to get on the ‘net for instructions, and what I thought were bootable usb sticks would not boot (even after poking around in the bios settings for this Asus M4A89GTD-PRO/USB3 motherboard). No cd|dvd drive in the machine. I’m an ignoramus about what grub rescue> means and about how to boot from that prompt.

So, pulled off the case’s side panel to check the power and data cabling for the boot drive (and the other two drives while I was at it). Too much work to get access to the cables, so took a close look at the switches on the motherboard, maybe something’s in the ‘wrong’ position? This board has an AMD Phenom II X2 B55 Processor, but I’ve unlocked the cpu so it’s an X4. I noticed that the led’s next to the core unlocker switch and the turbo switch were not lit. Unplugged the power cable to the machine, flipped both those switches to the other position, reconnected the power cable and the system booted without a problem. No more grub rescue>.

Moral, print out grub rescue> how to’s, print out that motherboard pdf manual and have tested bootable media on hand.

Transparent decision making in Debian; the ongoing init discussion by the Technical Committee

The Debian project’s Technical Committee (TC) is showing us how to deal with an issue like sysvinit vs. systemd vs. upstart: an issue where positions are frequently presented in ways almost deliberately or gratuitously meant to provoke anger and retaliation. The TC is discussing the issue transparently, in public and without personal attacks. (And, since the discussion takes place on a mailing list, people do not top post, instead they post replies inline or at the bottom of the reply. With a mailing list, you also can have threaded sub-discussions.) Right now, the TC has 8 members. Debian’s Organizational Structure

The TC ‘makes the final decision on technical disputes in the Debian project’ and resolves disagreements, both technical and non-technical, including offering advice or overruling a Developer. See the section Technical Committee in the Debian Constitution. ‘Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the TC public discussion list.’ . Anyone can subscribe to the mailing list, and the TC mailing list archives are publicly available.

This discussion had begun months earlier on the debian-devel mailing list/ and on many other places on the ‘net. A resolution couldn’t be reached on -devel. Discussion of the relative characteristics of the alternatives on -devel had been going on for quite a while and didn’t seem to be getting any closer to a resolution. (When I say characteristics I don’t mean advantages since often people’s contributions to the discussion didn’t address the advantages, instead comments expressed opinions about motives and contained unbalanced remarks, like the PHB does in the 2014-01-03 Dilbert strip: ‘You are terrific but everything you do is exactly what a moron would do.’)

So, Paul Tagliamonte opened bug #727708 on the Bug Tracking System and while -devel continued their discussion, the TC began theirs. The second paragraph of Paul’s email says in part ‘it’s clear no consensus is coming out of the discussion.’ Way back on 31 Jan 2013, before a lot of this happened, Russ Allbery (a TC member then and now) wrote a blog post ‘Consensus Failure’.

Here’s a quote relevant to the init system debate:

toxic flaws at the heart of a consensus-based process completely destroyed [Usenet newsgroup creation] and, as a side effect, destroyed the community of people who had formed around it. I will never again invest my time and energy in a community that operates solely via a consensus process unless that community is small enough that consensus can actually work (which means not much more than twenty people). Consensus decision-making in large groups destroys communities and hurts people. … [O]n the surface, it may look like Debian also uses a consensus-based decision-making process. But while Debian decision-making has some problems, it’s much healthier for a few reasons that are useful to examine: … Debian operates less by mass consensus and more as a federation of semi-autonomous fiefdoms … there are several people in Debian who are perceived as having clear authority to make timely and relatively final decisions, who are almost never overruled, and who can therefore effectively end arguments … There is a well-established ultimate appeal (a General Resolution), the ultimate appeal process is very specific and concrete, there is little or no ambiguity or human interpretation involved in analyzing the results, it is time-limited, and it’s almost universally respected.

A project as large as Debian is cannot hammer out a consensus to reach a decision: if a consensus is required, ‘it’s impossible to ever end an argument, and there is no incentive for anyone to shut up. As a result, it is nearly impossible to get the decision-making to cohere into something that is timely, consistent, unambiguous, and final.’ Allbery believes maybe twenty people is the maximum for a workable consensus-based group. Twenty or less, fine, use consensus, more than twenty, use something else.

At this time, the TC votes look to be 3 for upstart and 2 for systemd. (upstart: Steve Langasek, Colin Watson, Ian Jackson; systemd: Bdale Garbee and Russ Allbery) Three TC members haven’t announced their decision, afaict.

If you aren’t subscribed to the debian-ctte mailing list, and you don’t want to read the bug thread via web mail you can download the thread in mbox format and use your favorite mail client to read the thread ( ‘ mutt -f bug_727708.mbox ‘ is what I do).

As to other projects, I’m an ignoramus about if a decision whether to move from sysvinit to something else was discussed transparently (publicly and with the opportunity for anyone to participate), who in the project decided, and how the decision was announced. If readers have information about other projects. please make a comment. Of course, if I’m wrong (especially if I’m hilariously wrong) about anything here, please correct me.