freenode/#devuan/ Monday, 2019-12-09

onefangOn ASCII AMD64 I don't have that directory.00:11
onefangSo it'll be some software that you have running on your x86, that isn't on your ARM and on my desktop.00:11
onefangNor on my server.00:12
ErRandir_maybe I still have something left over from Devuan Jessie on the x86 machine, it seems systemd created that directory. My arm machine is a fresh install.00:31
fsmithredI've got /run/user/1000 on my ascii (I think this one was upgraded from devuan jessie)00:36
onefangMine where both debootstrapped to ASCII, so there wont be any Jessie cruft left over.00:37
fsmithredthe date on that user dir is Dec 2, last time I rebooted.00:37
onefangOr could be some software you two have that I don't.00:38
fsmithredapt-file doesn't know it00:38
onefang/run is often a tmp device.00:38
fsmithredyeah, everything is Dec 2 except for utmp which has today's date00:39
fsmithredoh, and udev00:39
rrqdon't those /run/user/* belong to some "login manager", eg elogind ?00:43
ErRandir_timestamp on mine is also from the last reboot. Indeed it looks like elogind creates it via Thanks!00:57
DocScrutinizer05gosh, debian has another vote about init system policy?14:10
DocScrutinizer05what should devuan users vote for?14:11
masonDocScrutinizer05: Only Debian developers and maintainers can vote.14:17
masonDocScrutinizer05: And the overlap of Devuan users who can vote are probably fairly clear on what they want. :)14:18
yeti   MINT14:24
DocScrutinizer05mason: thanks15:01
* GyrosGeier voted already15:06
GyrosGeierand most of the options are so bad that "focus on systemd" made it into the first half15:09
GyrosGeierfor me15:09
GyrosGeierbecause that is still a better outcome than "we leave it up to individual maintainers"15:09
fsmithredIt would be really helpful (understatement) if maintainers who don't want to support other inits would accept patches that do provide the support.15:46
DocScrutinizer05yes, a cursory read across the proposal (headlines) already made me cringe, seems they are poorly chosen and don't really cover a reasonable spectrum of choices/options15:48
nemolink to the vote? and would it help to canvas debian package maintainers I know?15:50
DocScrutinizer05sombeody provide
nemoI guess 3A is the best option for devuan at present?15:51
DocScrutinizer05e.g. >>Choice 2: B: Systemd but we support exploring alternatives<<  WTH "we support exploring"??15:51
nemohm or 6E15:51
nemough. that's a lot of similar choices15:52
nemohow is the vote counted. will all the "support multiple inits" get diluted?15:52
GyrosGeierDebian has a sensible voting system15:52
nemoGyrosGeier: need 51% in multiple rounds?15:52
DocScrutinizer05>><nemo> ugh. that's a lot of similar choices<< that's why I also cringed15:54
GyrosGeierthe general agreement is that systemd remains default init, so the differences are in the level of support for people who don't want that15:55
nemoGyrosGeier: yeah, wouldn't expect that to change unfortunately.  the backlash against systemd is still a minority15:56
GyrosGeieri.e. is lack of sysvinit support release-critical or not; is it allowed to create NMUs if maintainers don't apply patches, etc15:56
GyrosGeiersystemd is also the most sensible choice for a desktop operating system on single-user computers who do not want to look into the innards15:56
DocScrutinizer05and I see the whole focus is on init system aka PID1, not targeting the massive dependency hell that got introduced by systemd-related takeover15:57
nemoGyrosGeier: hm. dunno... I have devuan on a 6 machines where no one seems to look at the innards15:57
nemoGyrosGeier: I mean, it's not like properly configured packages really *need* you to play with the init system15:57
nemoin theory the systemd is faster I guess, even with the clever simultaneous launch of multiple scripts, but it's not by an amount that really matters that much to most15:58
nemoGyrosGeier: the living room devuan machine the kids use boots in a few seconds15:58
nemothat one gets the most reboot 'cause they keep unplugging it15:58
nemoI've never touched the init system15:58
GyrosGeiernemo, problems like "if I connect my bluetooth headphone to it, what communications channel does the bluetooth widget on my desktop use to tell the bluetooth daemon, running as root, to pair with a device, and to save the link key in my user-local keyring so when I log in again I can access my headphones, but no one else can"15:59
GyrosGeierthese are what systemd solves15:59
GyrosGeierboot speed is largely irrelevant16:00
GyrosGeierbut being able to pair headphones without knowing the admin password, that is useful16:00
DocScrutinizer05clearly middleware considerations16:01
nemodon't know nearly enough about that problem space to comment.  I do know that typically home user is a member of sudoers...  I guess it'd be nice to have more limited accounts.  you'd think there'd be a way to design that that doesn't require the ground up rework of systemd16:01
GyrosGeierthis could be done without systemd, but it was kind of shit16:01
DocScrutinizer05that's systemd's problem, it started as "init system" but actually always targeted at middleware16:01
nemoDocScrutinizer05: is it possible to separate those considerations?16:02
GyrosGeierI'd think it was the other way round: middleware that needs to be pid 1 because that is where orphaned processes exiting are reported to16:02
nemoDocScrutinizer05: or are the modules too integrated?16:02
GyrosGeierthey are pretty much integrated16:03
nemoGyrosGeier: and the binary logs and removal of init scripts just grew out of the need for this reporting how?16:03
GyrosGeierbinary logs are because service instances now have IDs -- so if a service is restarted, it gets a new ID16:04
DocScrutinizer05there should be a resolution that generally mandates generic backwards compatible APIs for each package (at very least implemented by compatibility wrappers) that reduce inter-package dependencies to a minimum. Applicable to all packages, not only systemd16:04
GyrosGeierthere is a lot more data attached to log messages now16:04
GyrosGeierso these would be unreadable as text16:04
GyrosGeierremoval of init scripts is because the dependency system is more elaborate, and specifically supports dependency injection (i.e. I can make a unit that says "this unit becomes a dependency of another, even though they don't know me")16:05
nemoGyrosGeier: you could always have a sidecar log if it was really necessary, which I guess depends on the data logged.  As for unreadability.  Eh, you can, and many apps do, fit a hell of a lot of data on a single separated line16:05
nemoGyrosGeier: being able to process with text processing tools is not really about 80 chars per line16:06
GyrosGeierbut my expectation is that the complexity of the dependency tree is the limiting factor in the future16:06
nemoGyrosGeier: hm. I thought the existing init system in debian allowed exactly that kind of injection16:06
GyrosGeierbasically, service init works because the services are Unix daemons that handle failures well16:06
nemobut perhaps I'm misunderstanding a subtle point16:06
DocScrutinizer05if a log gets unreadable as text, it's gibberish per definition, as all logs need to be read by huumans in the end. Actually I don't see a single datatype (well maybe except multimedia rypes like pics, audio, video tjhat don't belong into logs) that can't be represented in ASCII plaintext as well16:06
GyrosGeiernemo, that worked to a certain extent, yes16:07
nemoDocScrutinizer05: another nice thing about text logs is they are much more corruption resistent.16:07
nemoDocScrutinizer05: binary formats are more sensitive to location of magic bytes16:07
DocScrutinizer05which is the foundation idea in the end16:07
nemoand I've certainly encountered log corruption before16:07
GyrosGeierbut expressing things like "start this before the network" didn't work16:07
nemoGyprocps:# X-Start-Before:    $network16:08
nemoGyrosGeier: procps:# X-Start-Before:    $network16:08
GyrosGeierI mean, I run sysvinit everywhere, and I agree on text logs16:08
nemoquick grep of my devuan16:08
GyrosGeierthat is insserv16:08
GyrosGeierwhich is optional16:09
nemowell yes16:09
nemobut that's your problem16:09
GyrosGeierwithout it, you need priorities in update-rc.d, but these have been removed16:09
nemoI mean the fact that it's optional sounds like a good thing to me, not a bad thing.16:09
nemoand if you want that capability, add it?16:09
DocScrutinizer05I consider logs I can't print realtime to a lineprinter as absolutely worthless and missing their purpose16:10
nemoDocScrutinizer05: heh. we did that on our sun systems for critical logs.  It made it a lot harder to hide an attack16:10
DocScrutinizer05(modulo printspeed that needs to get handled by the serial baudrate and buffer size or whatever)16:10
GyrosGeierI used to use BSD securelevels16:11
GyrosGeierbut support for that in Linux is spotty, and I'm not sure modern sysvinit still supports that16:11
GyrosGeier(that needs to be an actual thing in pid 1)16:11
nemoDocScrutinizer05: I imagine that even systemd is capable of outputting text logs as *well* but it bothers me text is a second class citizen16:11
nemoDocScrutinizer05: I don't see a good reason for *all* logging to be in text files with varying levels of detail16:11
GyrosGeierwe had logging to postgres years ago16:12
nemoDocScrutinizer05: if you want binary size savings, gzip rotation. better indexing? well add an index file16:12
GyrosGeierit wasn't popular16:12
nemoGyrosGeier: good16:12
nemoeven sqlite would piss me off16:12
GyrosGeierit absolutely makes sense in a datacenter context16:12
nemoand I actually am decentish at using it as a commandline tool16:12
nemoGyrosGeier: fine. then have the *binary* files as second class citizens in the data centre16:13
GyrosGeierno, postgres makes sense16:13
nemothat is the accumulation16:13
GyrosGeierwriting to postgres is still through text16:13
nemook. I guess accumulation is variable and the postgres can be local or cluster whatever16:13
nemojust so long as it's stage two16:13
GyrosGeierseparation of concerns16:14
DocScrutinizer05by system design, adding complexity to the common case (writing log events to a database) to optimize (redce complexity) for the rare infrequent and not time critical case (readout of logs) is a "test failed" in CS-exam16:14
nemoGyrosGeier: anyway of all the stuff above, your bluetooth one sounded most sensible.  perhaps 'cause I understand that portion of userspace devices the very least, and have no familiarity with how it might be shimmed into an existing init system16:15
nemoGyrosGeier: so that would be the one I'd have to learn more about if I wanted to defend my personal traditional init preferences16:15
nemowhich are for bias for simple modular systems, lightweight init, and text everywhere16:15
nemoand it sounds like I might have to defend my preferences if I start contacting debian maintainers I know16:15
GyrosGeiermy reason for preferring sysvinit is that it is simple16:17
DocScrutinizer05^^^ THAT16:17
GyrosGeierit will allow people to learn slowly, and have successes16:17
GyrosGeierI have been working with Debian since 1998, so >20 years now16:17
nemohm. ahead of me. I stayed on redhat and variants until about 200016:18
nemothen gentoo and debian16:18
GyrosGeierI find systemd to be incomprehensible because it expects me to grasp all these concepts at the same time16:18
GyrosGeiersame for Docker16:18
nemoGyrosGeier: interesting. yeah. that's my opposition to a ton of modern tool16:18
DocScrutinizer05GyrosGeier: full ack16:18
nemoGyrosGeier: I'm currently maintaining about 3 dozen web apps for the company I'm working for that I banged out with help of a couple of others over the past decade to automate paper processes and such16:19
GyrosGeierand a lot of people just learn magic incantations instead of the underlying concepts16:19
nemoGyrosGeier: we know every single piece of those apps and have trivially moved them to different infrastructures.  mostly 'cause they had few dependencies16:19
GyrosGeierthe Ubuntu forums were a step in the wrong direction already16:19
GyrosGeier"doesn't work? add sudo."16:19
nemoGyrosGeier: no external libs, no massive APIs.  injection opportunities closed down at lowest level possible..16:20
nemoprogressive enhancement...16:20
nemook. not *no* external libs. pragmatism. sometimes they are needed. but at least you know when you pull 'em in. and what they are for ☺16:20
GyrosGeiermy expectation is that there will be a new class of users, I usually call them Linux Consultant and Systemd Expert, that know the names of services and how they are connected, but not what they do16:21
nemoGyrosGeier: do you have more info on how the bluetooth device situation you mentioned would work for a home user who was not in sudoers in a non-systemd situation? if that came up.  what are the existing options?16:21
nemoGyrosGeier:  this was on HN today (again)  it seemed apropos to above16:22
GyrosGeiernemo, separate daemon running as root that knows that it is acting on behalf of users16:22
DocScrutinizer05this all fails with Mr P explicitly despising "portability", by statements like "who cares about BSD, Linux is mature enough to go its own unique way" OWTTE16:22
nemoGyrosGeier: what about the reporting to process 1? was there a spec for init to relay to the separate dæmon?16:22
GyrosGeierthat can be avoided for services you have under control16:23
GyrosGeierbasically, reporting to pid 1 happens when a process forks itself into the background, then terminates16:23
GyrosGeierwhich is default for daemons16:23
DocScrutinizer05is linux a unix that tries to stay as universally unix compatible as possible, or is linux outside the unix family16:23
GyrosGeierif a process terminates while it has child processes, all the children get reparented to pid 116:24
GyrosGeierDocScrutinizer05, both16:24
nemoGyrosGeier: yeah. that part I'm familiar with. it's the whole unprivileged device systems I'm not familiar with ☺16:24
nemoGyrosGeier: is the problem if the master dæmon dies unexpectedly?16:24
GyrosGeiernemo, the kernel doesn't provide access control methods that are fine-grained enough16:24
GyrosGeierso what people do is write a service that runs as root, implements the access control, and provides an interface that the user process can access16:25
nemoGyrosGeier: ok... but why can't that access control be implemented in the master... yeah. that's what I still don't get. why does this need to be in init16:25
nemoGyrosGeier: the whole why are these problems systemd is supposedly solving not modular16:25
GyrosGeierthe access control isn't inside init16:25
nemowhy can't you choose if you want to ditch init scripts or use binary logs or have a master dæmon for access control to devices16:26
GyrosGeierit's basically a reimplementation of the Windows95 service manager16:26
nemoI really don't understand the need for it to be completely intermeshed *and* in pid 116:26
GyrosGeierbecause it's a lot more work to implement it in a modular way16:26
nemook. well that would be understandable if it was a project being banged out by 1 guy16:27
GyrosGeierand they aren't getting paid for that, nor is there enough time16:27
nemohm. they aren't being paid for that? I really thought this was one area where corp money was being thrown at the problem16:27
nemobut I guess there's no incentive to split it up16:27
nemoyou'd think there'd be security wins to separation of concerns though16:27
nemoand that might matter to corp money. but maybe not16:27
GyrosGeierthey want to build a platform, where you can ship software that knows it can expect certain services16:28
GyrosGeiermaking that modular makes the platform weaker16:28
nemoI mean, windows famously put XML/XHTML parsing, rendering of window widgets, and TTF parsing in the "kernel" sooo16:28
nemoguess we're headed down that road16:28
GyrosGeierno, Linus used a few choice expletives when that was suggested16:29
nemoLinus is being sidelined16:29
nemohe won't be the gatekeeper forever16:29
GyrosGeierbut in general the kernel interfaces are "make things work", missing access control and revocation of interfaces16:30
GyrosGeierthe access control mechanisms that exist are historic16:30
GyrosGeiere.g. there is no way for the kernel to force a process to give up an ALSA device handle16:31
GyrosGeierso a user could leave an audio player running and log out16:31
GyrosGeierX11 implements access control and revocation for graphics hardware16:31
GyrosGeierwhen you log out, clients are told to go away16:31
GyrosGeierbut that's not a kernel interface16:31
GyrosGeiera process that has a framebuffer handle open cannot be told to go away16:32
GyrosGeierwhich is why only root can open the framebuffer16:32
nemoyeah. I get that part.  what I didn't get was the desire to cram everything and the kitchen sink in proc 1, but seems answer to that is simply "'cause it's easier that way and we don't care about alternatives/modularity"16:32
nemoeven if it might have security implications16:32
GyrosGeierpid 1 needs to understand the dependency structure16:33
nemoGyrosGeier: so... maintaining alternate inits might be for Debian's own good if this whole thing ends up biting linux16:33
GyrosGeieras said, it's a shite reimplementation of Windows 95/98 services16:33
GyrosGeierthe bluetooth widget in Windows works exactly the same as in GNOME16:34
GyrosGeierprogram running in session context with user permissions asks the OS to activate a "bluetooth configuration" component for them16:34
GyrosGeierreceives an IPC interface16:34
GyrosGeierthen uses that to set up things16:34
GyrosGeierthe policy layer for that lives on the other side of the interface, and most likely consists of multiple layers as well16:35
GyrosGeierif one of these layers fails, anything on top needs to be torn down16:35
nemois this similarity due to similar constraints, or are you implying the old "embrace extend..." due to MS loss of the server market?16:35
GyrosGeierthat is what systemd does as pid 116:35
GyrosGeierit's a sensible implementation16:36
nemohm  "shite reimplementation" and "sensible implementation" do not sound the same16:36
GyrosGeieryou can either define a network interface, or use an existing IPC standard and wrap the network interface within it16:36
nemobut I guess Ⓑ is the windows one ?16:36
GyrosGeiersystemd doesn't go far enough in many cases16:36
GyrosGeierthey just make it work somehow, but they don't incorporate the things we've learned from 25 years of Windows history16:37
GyrosGeiersystems like these have very specific failure modes16:37
GyrosGeiere.g. all dependencies are now runtime only, so you can't scan an executable to find out what packages need to be installed as well16:38
nemomy knowledge of bluetooth is limited to friend cursing the code quality of BlueZ to the point where he implemented his own driver for the device he was working on16:39
GyrosGeierMS solved that with embedded manifests16:39
nemobut I get the general principles above16:39
mcrGyrosGeier, what I hear you saying is that the systemd people are not re-inventing new init thinking, but rather are just replicating the failures of 25 years of Windows monolithic kernel errors.16:39
nemostill don't see the need for touching my precious pid 1  but I guess I understand enough to argue for saving alternate inits in a vote16:39
GyrosGeierpretty much16:39
GyrosGeierI mean, there is lots of cross-pollination between Windows and Linux16:40
GyrosGeiere.g. Windows basically boots with an initrd16:40
GyrosGeierand they have a mechanism for enumerating which drivers are included on the initrd16:40
mcrGyrosGeier, on the topic of forcing processes to give up access. We solved this for ttys back in the SRV3 / BSD4.2 days with revoke(2).  I wish we could do the same thing for NFS file opens, and it seems like the same thing ought to work for X11, ALSA device handles, etc.16:41
GyrosGeierttys are special16:41
GyrosGeierthere has always been an interface for revocation16:41
mcr(well, I'm old enough to remember before revoke(2))16:42
mcrSIGHUP wasn't enough, because processes could ignore it.16:42
GyrosGeiertrue, but their file handles went unusable as well16:42
GyrosGeierif you ignore SIGHUP, you need to really know what you're doing16:43
mcrno, they didn't. That took a call to revoke().  UUCP modem dialers needed to survive SIGHUP, when DCD actually did change :-)16:43
mcrThe GNOME file dialog still fails when NFS mounts are slow, and I'm still surprised given a wide variety of fuse-fs that we haven't invented better ways for the file dialogue to scan things without locking up.16:45
mcrOr to make df not hang on slow mounts.16:45
GyrosGeierthere is a better way16:46
GyrosGeierbut it's complex16:46
GyrosGeierand will mean more systemd integration :P16:46
mcrI have a few ubuntu VMs with systemd (because... docker and crap) and I continue to be amazed how hard it is to get a static /etc/resolv.conf configuration.  Yet, the systemd resolver stuff doesn't really help for captive portals on a laptop.16:47
GyrosGeierit also turns off return path filtering16:53
DocScrutinizer05>>GyrosGeier> and they aren't getting paid for that, nor is there enough time<< not an excuse for delivering shit - while I actually doubt that claim is correct to start with18:40
GyrosGeierDocScrutinizer05, RH is not paying the systemd developers to build a modular system, because they are not interested in shipping a modular system18:42
GyrosGeierthey are interested in shipping, as someone on Twitter called it so aptly, "a monolith with a string-based calling convention"18:42
GyrosGeiermonoliths are manageable18:42
GyrosGeieras long as you have full-time programmers, that is18:43
DocScrutinizer05that sounds more like it, yesa18:44
DocScrutinizer05I thought "paid for that" was systemd at alrge, sorry18:44
WonkaGyrosGeier: well, I work in a company paying over a hundred full-time programmers to improve the monolith they're selling. one of the longer-term goals is to make that monolith more modular.18:45
GyrosGeiersystemd is also "modular", but you can't easily exchange parts18:46
GyrosGeierbecause the API pretty much defines the implementation18:47
GyrosGeierprotocol design is a forgotten art form :/18:47
DocScrutinizer05actually I think a monolith is preferable for RH as it allows more easily to be poorly documented, intricate, obscure and without alternatives so RH (and Suse) may offer more expert service by those few who actually master that shit18:48
DocScrutinizer05and don't get me started about (the recent lack of) protocol design and system design skills in groups like systemd cabal and freedesktop.org18:50
BureksystemDesktop enviroment18:51
errandir1Talking about RH, today the OOM killer decided to kill systemd PID 1 on one of our RH systems. I just thought: good job OOM :)18:52
WonkaI would have thought there'd be protections against OOM-killing PID 118:56
errandir1OOM kills all bloat-ware18:56
DocScrutinizer05errandir1: LOL19:17
DocScrutinizer05errandir1: please provide syslog except ;-D19:18
DocScrutinizer05excerpt  even19:19
overflyerHi guys just a general question for openrc based systems. Is it possible that chrooting into an aarch64 rootfs from an x86 based openrc linux is somehow different than from a x86 systemd based system?20:17
overflyerI am on artix linux but no one over there answers at the moment. I am just asking because I read tens of tutorials know and I actually know what packages I need and what to do to chroot into an arm rootfs, but I always get /bin/bash: FIle or directory not found.20:19
overflyerMy kernel has binfmt support and I have all binfmt and qemu packages installed and I always copy /usr/bin/qemu-aarch64-static into usr/bin of the mounted arm rootfs image as every tutorial tells me to, but chrooting never works.20:20
specingoverflyer: did you enable the aarch handler in binfmtmisc?20:22
overflyerI can only tell you that my kernel has binfmt support enabled and a u"pdate-binfmts --enable qemu-aarch64.  " gives me "update-binfmts: warning: qemu-aarch64 already enabled in kernel." I do not exactly know what you mean by your question. Could you explain?20:25
specingoverflyer: maybe the qemu executable should be called 'qemu-aarch64'?20:30
overflyerspecing: I have a /usr/lib/binfmt.d directory where I have qemu.conf and a qemu-static.conf that both have a line starting like this (and many others): :qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x ............ so that is the elf magic I guess20:32
overflyerwhat did you mean by aarch handler and binfmtmisc then I will check that and you explain to me what to look for and what to add?!20:32
specingyes, it is20:32
specingwhat is the path to qemu in that magic line?20:33
overflyer /usr/bin/qemu-aarch64-static and /usr/bin/qemu-aarch64 in qemu-static.conf and qemu.conf respectively20:34
specingBut what gets passed to the kernel?20:34
overflyerif you tell me which file shows me that I will check20:35
specingI don't know which file does that on your system20:36
DocScrutinizer05no fist hand knowledge here but I seem to recall systemd with its mandatory cgroups-hogging interferes with at least VMs20:37
DocScrutinizer05a chroot won'T ahndle cgroups afaik20:38
overflyeris it possible that you want the content of /proc/sys/fs/binfmt_misc/qemu-aarch64  ?20:38
specingoverflyer: not me, you want it20:39
specingDocScrutinizer05: I remember it was quite a pain to run systemd containers in LXC on gentoo, precisely because of it hogging everything20:39
overflyerWhenever you think you learned Linux pretty well you just hit a category which requires new knowledge and you feel like you are at right at the beginning. Frustrating. :D20:41
onefangThat goes for any complex systems.  Some of us enjoy learning new stuff all the time.  B-)20:43
overflyerspecing: the file   /proc/sys/fs/binfmt_misc/qemu-aarch64vhas this content right here. enabled20:43
overflyerinterpreter /usr/bin/qemu-aarch6420:43
overflyerflags: OCF20:43
overflyeroffset 020:43
overflyermagic 7f454c460201010000000000000000000200b720:43
overflyermask ffffffffffffff00fffffffffffffffffeffff20:43
specingoverflyer: yes, see20:43
overflyeranyways I kindof assume that it is not good that there is no qemu-aarch64-static version of this20:44
overflyerjust the non-static one20:44
overflyerbut I am very certain for chrooting I need the static one20:44
overflyerSo how would I add this to the binfmt configuration so that next time I restart binfmt service it gets mount to /proc/sys/fs/binfmt_misc ?20:45
overflyerI basically want a /proc/sys/fs/binfmt_misc/qemu-aarch64-static file20:46
specingI think you need to go a few steps back and solve the initial PEBKAC caused by mindless copying of code from multiple incompatible tutorials20:47
overflyerIt was not like full-retard zombie mode mindless like maybe a BIT mindless, but since I think I understood what the tutorials told me about qemu and binfmt I understood enough to make sure not to spam my system with unneccessary packages or configurations or such. Anyways ... I will purge all the packages and configs and so on and try to start anew20:50
overflyerAnd all because I wanted to start öearning kernel module programming with my new espressobin v5 by a book from Rodolfo Giometti... sigh20:50
specingoverflyer: you'd have a nicer time doing that in Xen/KVM on x8620:53
overflyerthat was one of my next thoughts yes. I just really anted to work through the book step by step because it is brand new from 2019 and well written (well until the part he just chroots into the image and explains nothing although before that he explained everything in detail :D)20:55
overflyerand those books are hard to come by20:55
overflyerbut I guess I need to follow your advice20:55
onefangSee?  Some of us love learning new complex things, like kernel module programming.  B-)21:02
overflyerI just hope all this is not because I am to stubborn to use systemd based systems21:08
overflyerbecause over the last few years I encounter more and more problems ue to that fact21:08

Generated by 2.17.0 by Marius Gedminas - find it at!