SoylentNews

Debian General Resolution to Prevent Init System Coupling Fails to Pass

posted by janrinok on Wednesday November 19 2014, @11:25AM   
from the I-hope-we-don't-regret-this dept.

novak writes:

Ian Jackson's general resolution to prevent init system coupling has failed to pass, the majority vote deciding that the resolution is unnecessary. This means that not only will Debian's default init be systemd, but packages will not be required to support other init systems. Presumably, this means that using other init systems on Debian (without using systemd as a base) will not be possible without major workarounds, or possibly at all. It also leaves the future of Debian projects such as kFreeBSD unclear, as systemd is linux specific.

The vote results can be found here

The winners are:

Option 4 "General Resolution is not required"

• Re:Dark Day Re:Dark Day (Score: 3, Interesting) by cockroach on Wednesday November 19 2014, @03:00PM

  by cockroach (2266) on Wednesday November 19 2014, @03:00PM (#117694)

  Same here. Hows it going? I've been keeping notes.

  Nice! I'll try to add some comments of my own:

  What do you think of their bootloader? Its only been 20 years of LILO later GRUB for me so its interesting to see something new. rc.ng or whatever its called is subjectively about twice as fast as systemd on the same hardware doing the same tasks which makes me laugh and laugh.

  To me it seems that FreeBSD takes quite a bit longer to boot than Debian (without systemd), could be related to disk encryption and/or a wrong impression though.

  Everything is intense deja vu very similar to Debian but different. Wasn't it a trip seeing the installer basically being the same and asking the same questions, almost but not quite?

  Haha yep, the installer could be the Debian installer from a parallel universe. I like it.

  So the docs are in subversion, and the core OS has one updater, and there's a binary package system, and the ports system, or you can install stuff by hand, sounds crazy but apparently they "work together" well enough. So far I have done Nothing with ports at all. All packages. On my to do list.

  I've had to build some Xorg stuff from ports to get a dual screen setup working with the Radeon driver on 10.0. I think this has since been fixed but I had to admit that I still have a bit of a mess where I'm not entirely sure how to keep track of binary packages and ports that have been manually compiled.

  I haven't gone ZFS yet.

  Last time I used ZFS on FreeBSD I had some rather unfortunate stability issues which were AFAICT related to my machine not having enough RAM. I won't be doing any further such experiments until I have way more than 4 GB available.

  I found installing X to be really weird. You have to enable hal and dbus then install xorg, then you get "Elf Binary type 3" errors which means you need to load up the linux shim in order to load the linux nvidia driver which unfortunately my peculiar card requires. Isn't the BSD equiv of linux's /etc/modules baroque? So there's entries in /boot/defaults/loader.conf but you override them in /boot/loader.conf, which is similar but different from /etc/rc.conf (isn't everything conceptually supposed to be in /etc/rc.conf... except for what isnt?)

  I haven't had any "Elf Binary type 3" issues but then I'm not using the nvidia drivers. The stuff with loader.conf takes some getting used to and I still haven't mastered it (i.e. I have no idea how to debug it).

  But windows style "you've installed a mouse, you need to reboot" type BS... Grrr.

  Haven't had that but it certainly sounds annoying. I did have to restart X at some point when messing with a mouse (on a different machine) though, seems a bit less smooth than on Linux.

  Speaking of XDM you manually edit /etc/ttys to turn it "on". Really, freebsd? Really?

  Hmm, I think I just installed "slim" which did all that for me.

  As far as apps go, chromium was kinda dull, some WTF-ness about the sysctl kern-ipc.shm_allow_removed=1.

  Indeed, I still feel dirty whenever I have to set that. One of these days I'll have to lookup what it actually does :)

  Parent

  Starting Score:	1		point
  Moderation		+1
  Interesting=1, Total=1
  Extra 'Interesting' Modifier		0
  Karma-Bonus Modifier		+1
  Total Score:		3

• Re:Dark Day Re:Dark Day (Score: 2) by fnj on Wednesday November 19 2014, @05:37PM

  by fnj (1654) on Wednesday November 19 2014, @05:37PM (#117755)

  I'm not entirely sure how to keep track of binary packages and ports that have been manually compiled

  Yes, this is a weakness. I had to compile postfix from ports because the binary package was compiled with stupid options. Then "pkg upgrade" will try to stomp on it if a newer binary package appears. What I did discover is that you can "pkg lock postfix" to prevent this. So now you can safely run "pkg upgrade" again. Until you "pkg unlock postfix", it will bypass any newer postfix packages.

  Hope this helps.

  Parent

  • Re:Dark Day (Score: 2) by cockroach on Wednesday November 19 2014, @05:43PM

    by cockroach (2266) on Wednesday November 19 2014, @05:43PM (#117758)

    Hope this helps.

    It does indeed, thank you!

    Parent

• Re:Dark Day (Score: 2) by cafebabe on Wednesday November 19 2014, @06:26PM

  by cafebabe (894) on Wednesday November 19 2014, @06:26PM (#117776) Journal

  I still feel dirty whenever I have to set that. One of these days I'll have to lookup what it actually does :)

  I assumed that it relaxed security in relation to shared memory segments but I was wrong. It seems to hold shared memory segments open until the last process terminates. Effectively, it ignores shmctl(shmkey, IPC_RMID, 0);

  --
  1702845791×2

  Parent