Debian Jessie 8.0.0 out, with systemd - consequences?

[Capricorny]

The output of the command lsb_release -da on Knoppix 7.6.1 contains "8.3" and "jessie". But /etc/debian_version says "stretch/sid". So I guess it is (still) kind of stable/unstable hybrid.
On the outside, it is not very similar to my live Debian 8.3 with persistence, (the output of lsb_release -d is identical) even if I use LXDE on both.

And it seems both are based on systemd? I know standard Jessie is, but thought Knoppix had kept sysVinit. The output of ps ax | grep systemd is the same

 2611 ?        S      0:00 /sbin/cgmanager --daemon -m name=systemd
 3658 ?        S      0:03 /lib/systemd/systemd-logind

Debian live now can be used with persistence, quite similar to Knoppix, and I have been able to adapt it very well to my use. Debian kernels are still quite old, now it is 3.16 - but that means I was able to patch the VMware Workstation 10 vmnet module source and get it compile and run. Which I was not able to on Knoppix. Doing upgrades mostly goes fine in Knoppix, it is possible to work a lot without bumping into the complications caused by the Jessie/Strech duality.

Setting up persistent store manually or via own scripts is about the same, but Knoppix offers more service in that area. Both use aufs-mount, but with squashfs, Debian 8.3 has better OS support out of the box. The main step in remastering, creating a new compressed image, is even easier on Debian, it is simply aufs-mount, copy and compress.
Here is a current version of the script. With SSD and a 2011 version of mobile i7-processor, the whole process with a ca 4GB result took < 10 minutes, using ca 15GB for the copied file system. So time/space not really a reason for not doing it. Furthermore, having all customizations in a compressed read-only image makes it possible, even efficient, to run without persistence much of the time. (The directory name deb830_4(p) denotes the 4th remastering of 8.3...)

#!/bin/bash
#
# Usage: cp_mksquashfs <live_image> <persistent_image> <compressed_image>
#sudo  ./cp_mksquashfs.sh /media/sda6/deb830_1/live/filesystem.squashfs /store/local/deb830_1/persistence /store/local/deb_remaster/fs_rem.squashfs
# Work in progress.. updated from 20141127 version 20160312-21
[ -d sqfs ] || mkdir sqfs ;
[ -d persfs ] || mkdir persfs
[ -d aufs ] || mkdir aufs
[ -d copyfs ] || mkdir copyfs
#
# To make this more portable, the live system is copied to local dir
sudo mount -o ro,loop $1 sqfs 
# The placement of live-rw should be parametrized ..Done
sudo mount -o loop $2 persfs
sudo mount -t aufs -o br:persfs:sqfs none aufs
# Might check file system here?
#
#
sudo rm -rf copyfs/*
sync
sudo rsync -axu aufs/* copyfs 
sync
# Small detail
[ -f copyfs/persistence.conf ] && rm copyfs/persistence.conf  ;
#
sudo mksquashfs copyfs $3 -b 262144 -noappend 2>make_squashfs.log;
# 
sudo umount aufs
sudo umount persfs
sudo umount sqfs
sudo rm -rf copyfs/*

Here are the legacy grub entries for booting Debian 8.3 on one of my machines. The same image is used both with and without persistence:

title Debian 8.3.0 64 bits live sda6+7 1
root(hd0,8) 
kernel  (hd0,5)/boot/deb830/vmlinuz boot=live config quiet splash  initrd=(hd0,5)/boot/deb830/initrd.img persistence bootfrom=/dev/sda6 live-media-path=deb830_4 persistence-path=deb830_4p  keyboard-layouts=no
initrd (hd0,5)/boot/deb830/initrd.img

title Debian 8.3.0 64 bits live sda6 No persistence
root(hd0,8) 
kernel  (hd0,5)/boot/deb830/vmlinuz boot=live config quiet splash  initrd=(hd0,5)/boot/deb830/initrd.img bootfrom=/dev/sda6 live-media-path=deb830_4  keyboard-layouts=no
initrd (hd0,5)/boot/deb830/initrd.img

For anyone wondering about the upgrade from Wheezy, I can only say that for me, staying with Wheezy implies a lot more work over time. Many packages/programs are much easier handled with Jessie, and so far I have hardly encountered one case being the other way round. But with Poor Man's Installs , I can keep older versions around for years, it's a question of about 8 GB/version, and they are all booted with good old grub. Over time, some of them will not be able to handle the actual hardware, but then I can run then from where they are with kvm.