Joey Hess, Developer Of 18 Years With Debian Departs

The strife in the Debian community has had another casualty, Joey Hess.“If I have one regret from my 18 years in Debian, it’s that when the Debian constitution was originally proposed, despite seeing it as dubious, I neglected to speak out against it. It’s clear to me now that it’s a toxic document, that has slowly but surely led Debian in very unhealthy directions.” He’s been there working hard since nearly the beginning but he’s fed up with the bickering/second-guessing/friction involved in the process these days. In messages on the debian-devel list, he describes his frustration with arguing about systemd for nearly two years and now, just weeks before the freeze of Jessie, users are up in arms.

I can see his point, but users are not developers and don’t read debian-devel. I don’t usually. It’s not surprising that users vent the same frustrations about systemd that developers did. There are a lot more users than developers, thousands of times more, and they need to be considered in making radical change to their operating system, something near and dear… Still everyone’s life goes through stages and it may well have been time for Joey Hess to move on for other reasons as well. I expect Debian will survive and it may survive by taking some of Joey Hess’ advice. Probably the worst thing that could happen is more developers leaving, followed closely by some kind of fork and revolution in the splinter group.

Perhaps it’s time that Debian reform it’s social contract/internal procedures to deal with dissent by better means than personal attacks on the lists or departures of key people. Democracy/fairness works but sometimes gets off the rails when conflicting groups try to have their way at the expense of others. It’s not enough just to have a mechanism to break deadlocks. It’s important to respect minorities of users as it is to respect the majority of developers. One only needs to see the USAian government to see how extremism and disrespect can go way overboard. We don’t want Debian to go that way.

See so long and thanks for all the fish.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , . Bookmark the permalink.

27 Responses to Joey Hess, Developer Of 18 Years With Debian Departs

  1. TestPilotDummy wrote, “These things are not gradual introductions, they are disruptive forced ways.”

    Yes. I love change when some little thing gives huge benefit, but this lot is overkill for anything I do with IT and it gives huge complexity for zero gain as far as I can see. I like GNU/Linux when I can lift the hood and figure out how to do stuff. Soon, I will have to add an opaque layer of trying to please systemd and Poettering in order to get stuff done.

  2. TestPilotDummy says:

    Today is
    Tuesday 24th of FEBUARY, “2015”
    Looking back at this thread.. WOW..

    I am currently/today looking at my raqcop (486/1G ram/512MB CF /to IDE card) running debian and I Can COUNT the amount processes running on it on my hands and feet. When I do a ps aux I can read every entry and understand it. Fully. I can killall -9 and restart anything. I can script anything, I Can design a Web GUI which can use a wrapper and shell to control anything. I Can set up Port Knocking, I can remove that and setup SPA (Single Packet Auth)

    When I am looking at my Linux Mint 17.1 on my Dell 690 8 2.4Ghz cores/16GB ram/TerrorBytes of Disk and I see a bunch of unreadable GUID’s. They mean nothing to me. It could be connecting to the NSA/GCHQ/or MOSSAD right now and I wouldn’t know. a ps aux scrolls off the screen in an “terminology bash console” . I cant even figure out how to turn the dbus printer OFF! let alone other services.
    Hey lets try some GUI”s to control the services. OH WAIT they aren’t all listed. My service isn’t listed. YET IT’s RUNNING! I don’t have a problem with linux mint, I have a problem with upstart, just like systemd but worse.

    And you can pile on that disruption “Firefox” with “Australis for the GUI” now my Themes and Addons are all broken, and this time they WON’T COME BACK, I literally have to go to an insecure version of Firefox If I want to keep stuff.

    There’s the ESR 24.x There’s the Locked at 27.x version, there’s PALEMOON Fork based on ESR 24.x There’s the politics and arrogance.

    These things are not gradual introductions, they are disruptive forced ways.

    God bless you man.

  3. Finalzone wrote some helpful stuff…

    systemctl --failed status
    ● beast
    State: degraded
    Jobs: 0 queued
    Failed: 3 units
    Since: Tue 2014-11-11 22:51:35 CST; 7h ago
    CGroup: /
    ├─1 /sbin/init
    ├─system.slice
    │ ├─avahi-daemon.service
    │ │ ├─1041 avahi-daemon: running [beast.local
    │ │ └─1073 avahi-daemon: chroot helpe
    │ ├─dbus.service
    │ │ └─1051 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
    │ ├─cron.service
    │ │ └─1044 /usr/sbin/cron -f
    │ ├─nfs-common.service
    │ │ └─924 /sbin/rpc.statd
    │ ├─exim4.service
    │ │ └─2023 /usr/sbin/exim4 -bd -q30m
    │ ├─apache2.service
    │ │ ├─1151 /usr/sbin/apache2 -k start
    │ │ ├─1251 /usr/sbin/apache2 -k start
    │ │ ├─1252 /usr/sbin/apache2 -k start
    │ │ ├─1253 /usr/sbin/apache2 -k start
    │ │ ├─1254 /usr/sbin/apache2 -k start
    │ │ └─1255 /usr/sbin/apache2 -k start
    │ ├─xdm.service
    │ │ ├─1879 /usr/bin/xdm
    │ │ └─2046 /usr/bin/X :0 vt7 -nolisten tcp -auth /var/lib/xdm/authdir/authfiles/A:0-JMVrzw
    │ ├─systemd-journald.service
    │ │ └─229 /lib/systemd/systemd-journald
    │ ├─minissdpd.service
    │ │ └─1100 /usr/sbin/minissdpd -i 0.0.0.0
    │ ├─tftpd-hpa.service
    │ │ └─1308 /usr/sbin/in.tftpd --listen --user tftp --address 192.168.0.101:69 -p --secure -vvv /srv/tftp
    │ ├─clamav-freshclam.service
    │ │ └─1043 /usr/bin/freshclam -d --foreground=true
    │ ├─udisks2.service
    │ │ └─2468 /usr/lib/udisks2/udisksd --no-debug
    │ ├─upower.service
    │ │ └─2418 /usr/lib/upower/upowerd
    │ ├─nfs-kernel-server.service
    │ │ └─2064 /usr/sbin/rpc.mountd
    │ ├─ssh.service
    │ │ └─1049 /usr/sbin/sshd -D
    │ ├─systemd-logind.service
    │ │ └─1078 /lib/systemd/systemd-logind
    │ ├─libvirtd.service
    │ │ └─1077 /usr/sbin/libvirtd
    │ ├─mdmonitor.service
    │ │ └─347 /sbin/mdadm --monitor --scan
    │ ├─systemd-udevd.service
    │ │ └─247 /lib/systemd/systemd-udevd
    │ ├─polkitd.service
    │ │ └─2380 /usr/lib/policykit-1/polkitd --no-debug
    │ ├─mysql.service
    │ │ ├─1334 /bin/bash /usr/bin/mysqld_safe
    │ │ ├─1335 logger -p daemon.err -t /etc/init.d/mysql -i
    │ │ ├─1547 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql -
    │ │ └─1548 logger -t mysqld -p daemon.error
    │ ├─rpcbind.service
    │ │ └─915 /sbin/rpcbind -w
    │ ├─dictd.service
    │ │ └─1315 dictd 1.12.1: 0/
    │ ├─system-postgresql.slice
    │ │ └─postgresql@9.4-main.service
    │ │ ├─1135 /usr/lib/postgresql/9.4/bin/postgres -D /var/lib/postgresql/9.4/main -c config_file=/etc/postgresql/9.4/
    │ │ ├─1239 postgres: checkpointer process
    │ │ ├─1240 postgres: writer process
    │ │ ├─1241 postgres: wal writer process
    │ │ ├─1242 postgres: autovacuum launcher process
    │ │ └─1243 postgres: stats collector process
    │ ├─clamav-daemon.service
    │ │ └─1090 /usr/sbin/clamd --foreground=true
    │ ├─rsyslog.service
    │ │ └─1046 /usr/sbin/rsyslogd -n
    │ ├─smartd.service
    │ │ └─1047 /usr/sbin/smartd -n
    │ └─ntp.service
    │ └─1703 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 108:115
    └─user.slice
    ├─user-1000.slice
    │ ├─user@1000.service
    │ │ ├─2328 /lib/systemd/systemd --user
    │ │ └─2329 (sd-pam)
    │ └─session-c1.scope
    │ ├─2146 -:0
    │ ├─2331 /bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
    │ ├─2364 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
    │ ├─2367 /usr/bin/dbus-launch --exit-with-session x-session-manager
    │ ├─2368 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
    │ ├─2378 xfce4-session
    │ ├─2385 /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
    │ ├─2388 xfwm4 --display :0.0 --sm-client-id 117f000101000126131996400000163460000
    │ ├─2390 Thunar --sm-client-id 117f000101000126131996500000163460002 --daemon
    │ ├─2392 xfce4-panel --sm-client-id 117f000101000126131996400000163460001
    │ ├─2393 xfsettingsd --display :0.0 --sm-client-id 23fb018ca-6c55-4d8b-a9c5-d9a1f1676406
    │ ├─2394 xfdesktop --display :0.0 --sm-client-id 117f000101000126131996700000163460003
    │ ├─2395 /home/pogson/Downloads/firefox/firefox --sm-config-prefix /firefox-D1erZI/ --sm-client-id 25ba4e2a2-05bb
    │ ├─2396 xfce4-terminal --geometry=128x38 --display :0.0 --role=xfce4-terminal-1395720829-323683224 --show-menuba
    │ ├─2399 /usr/lib/gvfs/gvfsd
    │ ├─2406 xfce4-power-manager --restart --sm-client-id 2b1058985-3c0e-4d33-bb96-fda9261ac98c
    │ ├─2427 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libxfce4dict
    │ ├─2429 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libscreensho
    │ ├─2454 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libxfce4dict
    │ ├─2455 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libactions.s
    │ ├─2456 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libclipman.s
    │ ├─2457 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libmailwatch
    │ ├─2460 /usr/lib/x86_64-linux-gnu/xfce4/panel-plugins/xfce4-orageclock-plugin 19 18874404 xfce4-orageclock-plug
    │ ├─2463 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libweather.s
    │ ├─2466 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
    │ ├─2482 /usr/lib/gvfs/gvfsd-trash --spawner :1.8 /org/gtk/gvfs/exec_spaw/0
    │ ├─2490 gnome-pty-helper
    │ ├─2491 -bash
    │ ├─2495 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2
    │ ├─2500 /usr/bin/python /usr/bin/autokey-gtk
    │ ├─2504 unclutter -idle 15
    │ ├─2517 xscreensaver -no-splash
    │ ├─2518 xfce4-volumed
    │ ├─2522 /usr/bin/pulseaudio --start
    │ ├─2544 /bin/sh /usr/bin/start-pulseaudio-x11
    │ ├─2545 /usr/bin/xprop -root -spy
    │ ├─2556 /usr/lib/at-spi2-core/at-spi-bus-launcher
    │ ├─2560 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
    │ ├─2563 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
    │ ├─2663 systemadm
    │ ├─3169 gnumeric
    │ ├─3265 systemctl --failed status
    │ └─3266 pager
    └─user-0.slice
    ├─session-1.scope
    │ ├─1101 /bin/login --
    │ └─1572 -bash
    └─user@0.service
    ├─1568 /lib/systemd/systemd --user
    └─1570 (sd-pam)

    systemd-analyse should have been systemd-analyze
    systemd-analyze blame
    33.467s systemd-udev-settle.service
    21.465s mysql.service
    17.208s ntp.service
    16.737s postgresql@9.4-main.service
    11.079s apache2.service
    6.412s mdadm-raid.service
    6.209s systemd-fsck-root.service
    5.948s libvirtd.service
    4.035s networking.service
    2.131s alsa-restore.service
    2.103s binfmt-support.service
    2.035s lm-sensors.service
    1.988s rsyslog.service
    1.957s avahi-daemon.service
    1.726s edac.service
    1.646s rc-local.service
    1.104s dictd.service
    971ms exim4.service
    949ms dev-disk-by\x2duuid-e04e97d5\x2da3c1\x2d4d40\x2d8c00\x2d39e56485ac37.swap
    844ms systemd-tmpfiles-clean.service
    838ms nfs-kernel-server.service
    680ms upower.service
    672ms user@0.service
    672ms xdm.service
    649ms tftpd-hpa.service
    587ms mysql-ndb-mgm.service
    572ms keyboard-setup.service
    462ms systemd-tmpfiles-setup-dev.service
    418ms lvm2-activation-early.service
    402ms systemd-tmpfiles-setup.service
    395ms hdparm.service
    321ms dev-hugepages.mount
    320ms dev-mqueue.mount
    320ms systemd-logind.service
    311ms ebtables.service
    301ms sys-kernel-debug.mount
    284ms knockd.service
    275ms hddtemp.service
    271ms nfs-common.service
    263ms minissdpd.service
    258ms libvirt-guests.service
    250ms systemd-user-sessions.service
    246ms openbsd-inetd.service
    242ms citadel.service
    240ms rpcbind.service
    228ms polkitd.service
    226ms systemd-modules-load.service
    223ms systemd-sysctl.service
    220ms console-setup.service
    208ms var.mount
    208ms udisks2.service
    190ms kmod-static-nodes.service
    186ms home.mount
    182ms console-screen.service
    161ms postgresql.service
    160ms systemd-update-utmp.service
    147ms systemd-remount-fs.service
    143ms aumix.service
    114ms kbd.service
    100ms user@1000.service
    98ms php5-fpm.service
    91ms systemd-udev-trigger.service
    78ms systemd-random-seed.service
    47ms decnet.service
    45ms lvm2-activation.service
    32ms udev-finish.service
    27ms keymap.service
    23ms portmap.service
    22ms systemd-update-utmp-runlevel.service
    20ms clamav-daemon.socket
    20ms lvm2-monitor.service
    16ms systemd-udevd.service
    11ms firestarter.service
    7ms mysql-ndb.service
    5ms nbd-server.service
    5ms memcached.service
    3ms systemd-journal-flush.service
    1ms sys-fs-fuse-connections.mount
    1ms qemu-system-x86.service
    1ms mdmonitor.service

  4. Finalzone says:

    Robert Pogson wrote

    The desktop shows after a minute or so, just like XP on a P4… It turns out udev was waiting for two timeouts and X will not run until all the services have started up. Have to fix that…[…]
    sigh… So much rubbish accumulated over the ages. Systemd sure shakes things up, sometimes in a good way.

    That is a good sign and it seems systemctl command worked on your side. One intriguing serivce is hal.service which should be dropped because HAL is obsoleted long time ago. You can view which services failed with command:

    systemctl --failed status and investigate the slowndown with
    systemd-analyse blame

    Services can be masked with
    systemctl mask service and make sure to reboot to compare the result. You can document your progress iif you like.

  5. Finalzone wrote, “It seems the issues is specific to Debian implementation of systemd on Jessie which is still in development so some failure is to be expected.”

    In my case, I had not RTFM. I had systemd-shim installed. I purged that and all was sweetness and light after a reboot. Systemd is now my PID 1 and everything worked immediately except apache2. I was running in circles a bit because I could not see logs the old way but eventually I found that systemd had taken it upon itself to run nginx which I had installed but sabotaged the init scripts… So, the socket was unavailable for apache2. Fixed that by uninstalling nginx. It works fine now but there is a lot of stuff happening before the desktop shows. The console boot prompt happens in a few seconds… The desktop shows after a minute or so, just like XP on a P4… It turns out udev was waiting for two timeouts and X will not run until all the services have started up. Have to fix that…
    “after: apache2.service(running), aumix.service(exited), basic.target(active), citadel.service(exited), decnet.service(exited), dictd.service(running), edac.service(exited), hal.service(dead), hddtemp.service(exited), knockd.service(exited), local-fs.target(active), memcached.service(exited), minissdpd.service(running), mysql-ndb-mgm.service(exited), mysql.service(running), nbd-server.service(exited), nss-lookup.target(dead), ntp.service(running), openbsd-inetd.service(exited), php5-fpm.service(exited), remote-fs.target(active), slapd.service(dead), system.slice(active), systemd-journald.socket(running), tftpd-hpa.service(running), xfs.service(dead)
    before: graphical.target(active), multi-user.target(active), nfs-kernel-server.service(running), shutdown.target(dead), x-display-manager.target(active)”

    sigh… So much rubbish accumulated over the ages. Systemd sure shakes things up, sometimes in a good way.

  6. Finalzone says:

    DrLoser wrote:
    Yup, I really am confused here. Finalzone seems to have a good handle on what’s going on back there. Hopefully he can sort the details out for us.
    Mostly due to website like Linux Weekly News (http://www.lwn.net) and some comments from Phoronix which prompted me to watch Debian mailing lists. From my observation, the action and behaviour of one Debian developers notably Ian Jackson is the problem as he tried everything to stall the whole development to support SysVinit.

    Robert Pogson wrote:
    Further, systemd is still beta software. It is running on my systems and hasn’t done anything except clog up the update-queue. The systemctl command doesn’t even run on Beast. It does on this machine. I have no idea why/how. I like to know how my system operates.
    Systemd is actually stable enough for a while as evident with its deployment in enterprise environment as default i.e. both Red Hat Entreprise Linux 7 and SUSE 12. It seems the issues is specific to Debian implementation of systemd on Jessie which is still in development so some failure is to be expected.

  7. luvr says:

    Robert Pogson, “I think that [i.e., forking Debian] could be a mistake.”
    Agreed… And I would be surprised if it were to come to that (though, of course, I don’t have a crystal ball, so my guess is as good as yours).
    I have no idea how the jessie release will fare, and whether or not systemd will cause it any significant delays, but the decision to migrate to systemd at this time feels somewhat premature to me, and will likely make Debian go through a difficult time until things settle down—which I’m absolutely sure they will, eventually, somehow.
    In the meantime, however, we could well see either Debian 8 (“jessie”) or Debian 9 (“stretch”) get postponed seemingly indefinitely—just like what happened with Debian 3.1(“sarge”), which got released in 2005, i.e., three years after its predecessor.

  8. ram wrote, “Looks like Debian is going to fork.”

    I think that could be a mistake. Like nuclear fission, results are unpredictable in detail but generally there will be a lot of heat and light and garbage produced. I’m very concerned about the infrastructure, all those mirrors. I doubt they can magically double during a split so the new branch would be very weak. It could take years to restore some kind of equilibrium. I think it’s kind of like banks being “too big to fail”. While it’s conceivable, it’s jut going to be bad. Debian could lose a host of developers slowing already slow releases. The new branch could be weak for years. I just don’t see the result being so much better that it’s worth all the wasted energy. Forking was good for LibreOffice. It could be good for NewDebian, but I doubt it.

    Debian has ~1K developers for a reason. That’s what it takes to release a huge distro every two years or so. What would happen if 80% stayed with Debian and 20% moved to NewDebian? I can’t see that being good for either and what would users do? It could kill the whole concept of a “universal OS”.

    No. I think the best way forward is for the children to grow up and learn to respect each other. Name-calling and innuendo don’t scale well. If we want to grow FLOSS/GNU/Linux, we have to work better together. Systemd could be the greatest thing since sliced bread but there hasn’t seemed to be much consideration of the resistance of humans to change, particularly revolutionary change. Poettering et al are not the greatest salesmen. If they believe systemd is wonderful they should invest in better PR. It’s one thing for developers to argue the technical merits. Users are too diverse to get much out of the discussion. While Debian “testing” is used to import packages to the distro, it’s not clear that systemd was even mature enough for that channel. It could have waited for a year or so for better documentation/demonstrations/development before inclusion. Certainly, all the breakages should have been sorted out rather than becoming release-critical to the distro.
    Systemd is of priority: optional – “This is all the software that you might reasonably want to install if you didn’t know what it was and don’t have specialized requirements. This is a much larger system and includes the X Window System, a full TeX distribution, and many applications. Note that optional packages should not conflict with each other.”

    So, sysvinit-core is labelled “extra”, a lower priority even though it is required to boot the old way and conflicts with lots of useful packages like lxsession which depends on systemd. The dependencies are many and layered. The whole idea of a distro like Debian GNU/Linux is that experts work out these details and the users don’t need to sweat the details but systemd is in our face until the dust settles. I have systemd installed on most of my systems and it’s running but not the init system on one of them. I’ve figured out why/how that happened but it’s definitely a cloud hanging over my IT-system. I want to use IT not have it use me. There was no hint of this kind of complication when I chose to migrate all my systems to Jessie, based on bug-count/performance. Then systemd happened and everything went sideways. They should have waited until next year when transition to systemd might have been smoother. Something this fundamental and complex and intrusive should have been debugged before inclusion. It’s not like a new version of grep or something like that. It’s like a whole new OS-layer.

  9. ram says:

    Looks like Debian is going to fork. Well, that always was a core strength of open source and Linux. If a group makes it too hard for developers, or if the users mostly prefer another direction, there is no way a project can force them to use their package.

  10. DrLoser says:

    How are my needs to have simple reliable IT being met by systemd?

    By, um, implementing a way of booting up a Linux environment that doesn’t involve a crap-ton of shell scripts that date back to the stone age? (Although you can write shell scripts if you want. Once again: Pid Eins. Clearly you didn’t read it the first time I cited it.

    Give it a read now.

    By providing a stable unified platform for booting up Linux services that can be built upon going forwards?

    By providing a solid basis to minimise the well-known bloated attack surface that is the Linux (SysV) system start-up, replete with silly little scripts written by people with no comprehension of security issues at all?

    Just a few ways off the top of my head, Robert.

    And if you can’t cope with the minimal effort to sort things out, then it’s just the XP fiasco all over again, isn’t it?

    Tens of millions of amateur XP sysadmins got the darned thing to boot up and work on a satisfactory level. You? No … too much effort.

    And hundreds of thousands of amateur Linux sysadmins will be able to get a systemd Linux box to boot up and work on a satisfactory level. You? No … too much effort.

    The evidence so far in front of us, Robert, suggests that the problem does not lie in the unfathomable intricacies of XP.

    Neither does it lie in the unfathomable intricacies of systemd.

    It lies … somewhere else, I think.

  11. DrLoser wrote, “Do you have a cite for that, Robert?”

    Item 4 in the Debian Social Contract:“We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments.”

    Now, if one believed systemd was the best way to do IT, that would be OK but lots of people have no need of it. For instance, if I leave Beast run 24×7 I don’t need faster booting, in any event I don’t need binary logs, systemctl won’t even run so I can’t control the thing, etc. How are my needs to have simple reliable IT being met by systemd? How is the power of APT working for me if I’m endlessly tangled in dependencies on systemd? e.g. at the moment, the following all depend on systemd: udev, lxsession, lighttpd, libvirt-daemon-system and a host of others that depend on those… so, by making systemd optional but the default, Debian developers have made systemd compulsory for me because I’m not running some minimal embedded system. I don’t want to run a crippled system. I want my hardware to be free to do all the things it can.
    DrLoser wrote, “”

    There’s actually a bug report about systemctl not working… Apparently, although systemd is running, it’s not PID1 here. Go figure.

  12. DrLoser says:

    Anyway, is Joey Hess the Bad Guy, a despicable type who supports systemd, or the Good Guy, a saint and saviour who supports SysV?

    I must admit, I dozed off half way through the discussion, and when I woke up it appeared that I’d subconsciously changed the channel to Nickelodeon. What will SpongeBob Square Pants get up to next?

    But, nevertheless, Inquiring Minds Wish To Know.

    Joey Hess — Black Hat or White Hat?

  13. DrLoser says:

    Oh wait, I’ve dug it out for you. (With a link. You didn’t provide the link.)

    We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments.

    And naturally you omitted the back half of that, which states:

    In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system.

    Sometimes you help your users by dragging them, willy-nilly, into the 21st century, Robert. Thus the “integrated system of high-quality materials.”

    Debian are under no compulsion, even given their rather fatuous and naturally legally unenforceable “charter,” to support wizened old types who can’t keep up with modern technology.

  14. DrLoser says:

    That might be true elsewhere but Debian developers are supposed to be committed to fulfilling the users’ needs.

    Do you have a cite for that, Robert?

  15. olderman wrote, “The fact that a group of users do not “like” systemd or do not “feel it is necessary” simply doesn’t cut it in terms of the real functional capabilities that systemd brings to linux.”

    That might be true elsewhere but Debian developers are supposed to be committed to fulfilling the users’ needs. I don’t know any users who demanded systemd be the default and drag everything with it. This is a hijacking amongst the flight-crew.

    Further, systemd is still beta software. It is running on my systems and hasn’t done anything except clog up the update-queue. The systemctl command doesn’t even run on Beast. It does on this machine. I have no idea why/how. I like to know how my system operates. That’s why I use GNU/Linux. Just like Wintel, if I go back to Wheezy, gradually my system will lose functionality as more new software grows dependent on systemd so that’s not a long term solution.

  16. DrLoser wrote, “Sounds like business as usual to me.”.

    No, it isn’t. There hasn’t been this much rancour in Debian since I’ve been on board. Folks discussed. Folks voted. Debian moved forward.

    Hess did seem to be in favour of systemd. He still left even though systemd was chosen as the default init. His departure is not about systemd but about the strife in Debian. I, too, don’t see anything particularly wrong with systemd. I mostly care if it works and there’s no proof of that. I see no effect on my system except that I have to learn to do everything differently and I may be forced to use this software instead of that just because of systemd. That’s not why I chose FLOSS, to be forced to do stuff. So, I and Hess are both upset with the situation despite being on opposite sides. It’s like a football game where fans of both sides are unhappy with the result. The game has changed.

  17. DrLoser says:

    I might be missing the point (I often do), Robert, and maybe I’m hopelessly confused, but the posts below make it sound like Joey Hess is actually in favour of moving forward with systemd and quit in disgust because Ian Jackson mandated a whole bunch of unnecessary work to support SysVInit, even though SysVInit is at this point dead in the water as far as Debian going forward is concerned?

    Does this mean that Joey Hess, after a brief period of being a Stakhanovite Hero of the Revolution, will now be cast into the Outer Darkness along with such fiends as Miguel de Icaza, or not?

    Yup, I really am confused here. Finalzone seems to have a good handle on what’s going on back there. Hopefully he can sort the details out for us.

    Meanwhile:

    It doesn’t seem as though anyone is happy and some are going out of their way to make others unhappy. It’s all so strange and un-FLOSS-like.

    Sounds like business as usual to me.

  18. Those links are very interesting. I even tried some of the commands…

    systemctl doesn’t work for me. “Failed to get D-Bus connection: Unknown error -1”

    I even have 3 dbus-daemon processes running…

    One thing I noticed in these readings… Since systemd is Linux-only and wonderful this means that the more things depend on systemd, the less portable FLOSS will be generally, like working on FreeBSD/Solaris/whatever.

  19. olderman says:

    “Why are they being forced to use systemd if they don’t value it enough to be a choice?”

    Because software needs to grow in function and features to meet the needs of the greater group of its users. The fact that a group of users do not “like” systemd or do not “feel it is necessary” simply doesn’t cut it in terms of the real functional capabilities that systemd brings to linux.

    besides, anyone who doesnt like it is free to take a snapshot of the code base with sysvinit in it and maintain it on their own, including all the backports that will be necessary to keep sysvinit linux going.

    so whats the problem. Robert Pogson?

  20. It’s from further along the thread of messages on debian-devel:
    https://lists.debian.org/debian-ctte/2014/11/msg00047.html

    It all caught fire after this bug-report

    It doesn’t seem as though anyone is happy and some are going out of their way to make others unhappy. It’s all so strange and un-FLOSS-like. No one seems to be laying out the pros/cons/merits or even ensuring the continued comfort of users/system-administrators/developers. What really irks me is that lock-in is developing so that a critical mass of applications will be “systemd-aware” and folks outside that warm circle will be shut out. People chose Linux. Why are they being forced to use systemd if they don’t value it enough to be a choice?

    That page on systemd in Fedora is the right way to do things. It’s not forcing, just selling the virtues. However, there’s still the matter of lock-in. Since systemd is all-singing, all-dancingly wonderful and with no end of dependencies in sight, it’s viral. My system was working perfectly well last year. Why the rush to move to an untried system still in development by folks who don’t seem to understand system administration? Perhaps we are spoiled by Debian. “Testing” used to work so well. Now it’s a war-zone. I can’t even flee back to Wheezy because it will sooner or later be unsupported and what becomes Jessie will be the new “stable”. It’s like being tied up as the steam-roller approaches. I just don’t understand why any other packages have to depend on systemd…

  21. Finalzone says:

    Robert Pogson,

    Do you have the source of that quote?
    Debian Jessie init default is systemd as voted and it is still in development stage.
    The idea about that quote has been done before notably on Fedora 14: https://fedoraproject.org/wiki/Fedora_14_talking_points#Systemd
    Other main distributions might do similar during their development stage. Look how entreprise distributions like Red Hat based and Suse achieve the switch from the old sysvinit to systemd.

  22. Eewwww! “For the moment, we invite concrete proposals for technical changes which would arrange that 1. new jessie installations using Linux would get systemd but 2. existing installations retain their existing init system so far as possible.”

    I can tell you that for a system administrator this would be toxic. One would have to clone systems instead of installing them with the installer. It looks as if the Technical Committee is going off the rails and taking Debian with it. I can see why Joey chose to quit. Life should not be this hard.

  23. Finalzone says:

    Actually, from my understanding Joey Hess left because of Ian Jackson’s actions by abusing the General Resolutions process to fit his view. It seems Ian Jackson tried to impose his will to Debian Developers by exploiting the loophole inside Debian own constitution.

    Taken from Phoronix post

    Sure, but it will create an unprecedented situation. Ian Jackson’s proposal isn’t just a decision, but a tool to enforce developers and maintainers to do work on SysVinit support, even though such a support doesn’t exist.

    Think a Debian package maintainer where his upstream project decides to remove daemon privilege dropping after the second security bug found in the code. They instead choose to rely on the init system handling this, so they remove the insecure code and refactor at the same time while upping the version number. systemd can handle privilege dropping, but SysVinit can’t.

    This means that the package will now be banned from Debian, unless the package maintainer add privilege dropping support for SysVinit himself. Or he risk that someone from Ian’s faction places a NMU patch turd in the maintainers repo; An invasive patch (because of the refactoring) with potential security holes. It will essentially be a fork of the program which will make life difficult for the maintainer since he no longer just can apply patches from upstream.

    In this case the developer is blameless for the lack of SysVinit support, but it is up to him to resolve all problems. This isn’t how Debian used to work and it probably won’t be much fun to be a volunteer developer in such a case.

    […]

    If you go back to the original decision, you will see that the CTTE exactly didn’t specify a lot of policies regarding implementation of the decision. They did that because historically it has always been up to Debian developers to do that, and only call upon e.g. the help of the CTTE in case of disputes that can’t be resolved.

    But Ian Jackson has found a committee weasel trick to circumvent Debian developer influence on their own work, by referring to the original decision as reason for further CTTE decisions. That way their will no longer be any developer dispute necessary for the CTTE to interfere. It effectively promotes the CTTE to a permanent top down steering committee regarding everything systemd and other init systems.

    Letting the CTTE make technical implementation decisions that overrules developer decisions after a short (3 day) vote/discussion, without anybody asking the CTTE for such a ruling is highly problematic.
    lists.debian.org/debian-ctte…/msg00045.html

  24. DrLoser says:

    Oh, and I missed a couple of important facts out.

    In order for this to work in the particular case of Debian, you have to define your function as a discrete one, not a continuous one. I think this condition can be safely assumed. (Thus my use of the Information Theory application of Jensen’s inequality.)

    One also has to assume that the population in question (in this case, individuals who are predisposed to “vote” via one or more Debian websites) are random yahoos.

    Also, I submit, a valid assumption.

    Because, without this, Mr Galton’s “Wisdom of the Crowds” is pretty worthless, isn’t it?

    Far better to ask a peer-reviewed, unimpeachable, fully qualified expert on the subject like Robert Pogson, isn’t it? The only thing that unqualified people (ie the crowds) can do is to disagree with the expert.

    Although, to be fair to Robert, the crowds in question seem to have spent at least the last ten years vehemently disagreeing with him.

  25. DrLoser says:

    The theory behind group consensus is that the averaging of a set of real-valued or integer-valued numbers, is an example of an ensemble method. The fact that the result is very close to the target is a consequence of Jensen’s inequality and thus, the proper ordered set of decisions would be the outcome.

    Pretty impressive for somebody who proudly lives without an HSE, Dougie. I must admit that even my worthless tertiary education has not fully equipped me to understand the implications of

    φ(𝔼[X]) ≤ 𝔼[φ(X)]

    However, I’ll give it a go.

    First of all, you’re going to have to define your probability distribution somehow. Let’s keep this simple and assume an inverse binomial distribution (although there’s no obvious reason why we should assume such a thing). It doesn’t even have to be a non-skewed inverse binomial distribution, as long as a single property holds: it must be convex (thus the stipulation of an inverse binomial). Because Jensen’s inequality only holds for a convex function …

    … which looks pretty important to your thesis, because (using the Information Theory application of Jensen’s inequality) you are trying to minimise the average “message length.”

    ‘Course, you could invert the inequality, in which case you’re looking at a standard binomial and, unfortunately, a concave function. Which implies (in Information Theory terms) that you are no longer minimising the average “message length.”

    I think what this boils down to is that “the theory of the crowd” is best applied when you have a small number of people with a viewpoint (represented on the x-axis) somewhere in the middle, and a large number of people at both extremes.

    Whether or not this applies to the Debian community in this case, I don’t know. Perhaps you could explain further, Dougie?

    Incidentally, there is no implied “ordering” of a set of decisions here at all. Difficult to “order” an “in or out” decision, isn’t it?

  26. dougman says:

    Good article: http://21stcenturywire.com/2014/02/25/snowden-training-guide-for-gchq-nsa-agents-infiltrating-and-disrupting-alternative-media-online/

    Obviously this tactic could extend to other venues and used by competiors in various markets.

  27. dougman says:

    No wonder Linux cusses as much as he does.

    Obviously, Debian needs a leader that can and will make decisions, even if unpopular with a few devs. However, on unpopular decisions, I think a vote drawn across the users online would be agreeable too.

    The theory behind group concensus is that the averaging of a set of real-valued or integer-valued numbers, is an example of an ensemble method. The fact that the result is very close to the target is a consequence of Jensen’s inequality and thus, the proper ordered set of decisions would be the outcome.

    http://www.amazon.com/The-Wisdom-Crowds-James-Surowiecki/dp/0385721706

Leave a Reply