<Pali>
"kdbus support is no longer compile-time optional. It is now always built-in."
<Pali>
"We encourage all downstream distributions to ... leaving kdbus support in systemd enabled"
<Pali>
so now when Linus still did not merged that kdbus crap, Lennart is trying to force distributons to patch their kernels with kdbus and ignore upstream development...
<DocScrutinizer05>
what an idiot
<DocScrutinizer05>
move to devuan!
<MonkeyofDoom>
fucking serious?
<MonkeyofDoom>
generally I give loads of benefit of the doubt
<MonkeyofDoom>
but depending on kernel features that aren't in the upstream kernel is just not fucking acceptable by any stretch
<ccnnjj>
And the mailinglist, where you can talk about forking the kernel.
<DocScrutinizer05>
Neo900 supports and recommends devuan
<ccnnjj>
Is it coming with Devuan instead now, rather than Debian?
<DocScrutinizer05>
Neo900 explicitly discourages the use of systemd on embedded
<DocScrutinizer05>
(or anywhere)
<ccnnjj>
It seems like the Neo900, and similar devices are the place where systemd would make more sense; as opposed to servers where init failing and being non-deubggable is much worse.
<DocScrutinizer05>
no, systemd resp poettering explicitly showed the stinky finger to embedded
<ccnnjj>
Huh. I'll look for that. Doesn't surprise me though.
<DocScrutinizer05>
and in fact systemd cannot work on quite a number of embedded devices, due to too small rootfs
<ccnnjj>
His response to other things (like spinning disks) is "we don't have it, we don't support it, you should switch"
<R0b0t1>
phones have a lot in similar with servers based on how most people use them... single boot long uptime, resource management
<ccnnjj>
Ah, but as the maemo bug tracker states, the N900 is *not* a phone (and by that logic, the Neo900), it's a mini (mini) computer. And users shut down their PCs regularly.
<ccnnjj>
I for one don't miss dealing with Nokia's dual-bug trackers, and the "it's fixed, but not for you" results.
<DocScrutinizer05>
duh! who shuts down their (linux) PC regularly?
<DocScrutinizer05>
cmd: 19:12 47 Tage 19:21 an, 19 Benutzer, Durchschnittslast: 0,52, 0,75, 0,86
<DocScrutinizer05>
and that's pathetically short uptime
<MonkeyofDoom>
ccnnjj: ugh, maemo bug tracker is an awful place
<ccnnjj>
I've taken to shutting down my laptop rather than suspending it. Something in the wirless (or something?) craps out if I suspend to disk sometimes.
<MonkeyofDoom>
"you don't need MMS, or support for certain wifi networks"
<ccnnjj>
I treat the N900 similarly. Besides, why leave it unlocked/unecrypted when I'm not around?
<DocScrutinizer05>
I do neither (shutdown / suspend)
<ccnnjj>
around/awake
<DocScrutinizer05>
anyway, how's that related to systemd madness?
<DocScrutinizer05>
just for systemd's idiotic claim to speed up boot process? who the heck cares??
<ccnnjj>
I'm looking forward to when Lennart starts submitting patches to the FreeBSD kernel because he wants to make systemd a hard dependancy for e.g. Gnome.
<ccnnjj>
That'll be some fun times.
<DocScrutinizer05>
err, afaik systemd already *is* a hard dependency in gnome
<DocScrutinizer05>
(( <ccnnjj> Is it coming with Devuan instead now, rather than Debian?)) yes, I definitely won't base the BSP on a systemd-infested debian
<bencoh>
debian isnt that infected by the way
<ccnnjj>
It's a weird mix of not-really-hard dependancies AFAI understand which is why Devuan can recompile things. Basically their thoughts are "as long as it still works on !Linux, we can recompile it"
<DocScrutinizer05>
and since we don't provide a full fledged OS and leave that to community, I dare to assume that FPTF also won't inbtroduce systemd
<bencoh>
oh, btw
<bencoh>
fun fact : # aptitude why libsystemd0
<bencoh>
i bsdutils PreDepends libsystemd0
<ccnnjj>
huh. interesting.
<bencoh>
isn't it ? :))
<DocScrutinizer05>
no, please see what devuan is doing, those guys are struggling hard to get systemd out of debian to build a devuan with freedom of choice on init system
<bencoh>
that's because of a (hardcoded) symbol reference to journal in /usr/bin/logger
<R0b0t1>
ccnnjj: If it looks like a phone and quacks like a phone, it's a duck
<R0b0t1>
I mean phone
<bencoh>
DocScrutinizer05: well I guess some parts can give headaches, especially in a desktop env
<bencoh>
but the core is mostly clean and you can run a server without it
<bencoh>
Unable to find a reason to install libsystemd-login0.
<bencoh>
that's the other funny part :)
modem has quit [Ping timeout: 264 seconds]
<bencoh>
(I guess that's because of a silly recommend)
<DocScrutinizer05>
systemd cabal tries hard to conquer all linux
<bencoh>
DocScrutinizer05: no need to try and convince me, I'm already on your side, you know ;)
<R0b0t1>
also, sysvinit or whatever the other is can have bootups close to a second or under it. I'd actually suspect boot time would be limited by the storage on the neo900
<DocScrutinizer05>
if you don't opt out _now_, then in 12 months you don't have the slightest chance anymore
<bencoh>
just saying that jessie on a server isnt that bad thus far
<bencoh>
(which means that devuan has ~2 years to find a way :)
<DocScrutinizer05>
yes, jessie is not completely lost yet, that's why devuan tries hard to fork on jessie and not later
<bencoh>
yeah
<DocScrutinizer05>
for a fork it's already almost too late, for sure it's too late for an easy low effort fork already
<DocScrutinizer05>
now go try asking Lennart Poettering how to keep maemo5 alive ;-P
<DocScrutinizer05>
he'll tell you it should have died a 3 years ago the latest
<DocScrutinizer05>
Oksana: did you ever put this topic on the minutes for a meeting? I'd think that's exactly what council is about: a clear word that maemo needs to move away from basing on debian and _must_ use devuan as base distro ASAP
<DocScrutinizer05>
you still could become one of (or even THE) major downstream distros basing on devuan, with all the support upstream (the devuan maintainers/devels) clearly announced they want to give to those distros
<DocScrutinizer05>
systemd (and thus new poetterized debian) is 100% incompatible to maemo, if only for cgroups which are already used in maemo in a way totally incompatible to systemd
<DocScrutinizer05>
so you can't get systemd on maemo -> you can't get any of the "new" debian packages that depend on systemd
<DocScrutinizer05>
according to Pali this even applies to lsusb and similar stuff
<DocScrutinizer05>
soon maemo will be more compatible to errr gentoo than to debian
<jonsger>
linux mint 17 and ubuntu 14.04 <-- both without systemd ;)
<Zero_Chaos>
yeah, just give up and switch to gentoo ;-)
<R0b0t1>
I was going to ask if there was a reason not to. It's possible to select older versions of most packages if you want stability.
cybiko123 has quit [Quit: Leaving.]
<R0b0t1>
ChromeOS is gentoo based, iirc
<jonsger>
minix or gnu/hurd ^^
<DocScrutinizer05>
I dunno how's your epertise with build environments etc
<DocScrutinizer05>
when you can tweak scratchbox/maemo-SDK so it uses gentoo or ubuntu14 or whatever and still produces binaries compatible to stock maemo, then prolly all fine
<DocScrutinizer05>
or you import systemd-debian or whatever based source to standard maemo-SDK and then have a lot of fun patching out all the systemd dependencies to make it even compile
<R0b0t1>
heh
jonsger has quit [Ping timeout: 252 seconds]
<DocScrutinizer05>
what you definitely cannot do: implement systemd into maemo so packages depending on systemd would compile for maemo without a lot of hassle to patch them
<MonkeyofDoom>
why not? how does maemo use cgroups?
<DocScrutinizer05>
it uses them, in a very relevant way. So they are not available for systemd which doesn't work without cgroups under systemd's exclusive control
<MonkeyofDoom>
yeah, I was curious what that way was (any links?)
<DocScrutinizer05>
OHM
<DocScrutinizer05>
maemo uses cgroups to priorize processes etc
<DocScrutinizer05>
and OHM has some closed-blobs by Nokia
<DocScrutinizer05>
so not even a simple re-implementation is in sight
<DocScrutinizer05>
afaik
<DocScrutinizer05>
no expert here
<Pali>
ohm is fully open source
<Pali>
some maemo5 sources are hard to find, but are available in meego git repos (in history)
<DocScrutinizer05>
then at least in *theory* somebody could rewrite all this crap to make it cooperate with systemd
<Pali>
there are links to commits
<Pali>
nobody understand that nokia code...
<Pali>
there is nokia(c) stack orientaed VM names dres
<DocScrutinizer05>
if anybody would be mad enough to do this. And it still would need a maemo update on all N900 to make them compatible with those new packages in extras-repo which would base on systemd
<Pali>
and in this VM is executed special code which also handle cgroups
<Pali>
and this code in that special VM is not open source
<MonkeyofDoom>
hm
<MonkeyofDoom>
that's crazy
<Pali>
also prolog code handles cgroups too
<Pali>
prolog code is closed, but I was able to decompile it back into predicates
vakkov has joined #neo900
<MonkeyofDoom>
oh you <3
<MonkeyofDoom>
I really don't understand why Nokia would build so much machinery
<Pali>
yes, on Nokia N900 is running prolog VM, dres VM and nobody else know whatever
<DocScrutinizer05>
MonkeyofDoom: so I hope it's clear now why maemo is incompatible re cgroups to systemd
<MonkeyofDoom>
what isn't clear is why people are so interested in running all this (hopefully unnecessary?) complex stuff
<DocScrutinizer05>
hmm?
<DocScrutinizer05>
it's what makes maemo work, unlike many other OS not finetuned to work on a phone
Guest67746 has quit []
<Pali>
it is easier to define actions and policies in logic orientated language as some imperative one
<MonkeyofDoom>
true
trx has joined #neo900
<Pali>
and I bet this is reason why that stuff was written in prolog
<DocScrutinizer05>
prolly, yes
<MonkeyofDoom>
personally I think I would have tried a state-machine approach
<MonkeyofDoom>
but that still leaves a lot of questions unanswered, obviously
<MonkeyofDoom>
Pali: thanks for the repo link, that's really interesting stuff to know
<Pali>
btw, I decompiled that prolog stuff only becase I wanted to use n900 headset button in media player
<Pali>
default rules was to enable it only in voice call
<MonkeyofDoom>
interesting
modem has joined #neo900
fling has quit [Ping timeout: 244 seconds]
<R0b0t1>
MonkeyofDoom: You can prove properties of a state machine. Not sure if it's better or worse than logic.
<MonkeyofDoom>
you can prove things about predicate logic too, of course
<R0b0t1>
well yeah that's what I meant
<MonkeyofDoom>
I think it might be easier for users to reason about what their device will do based on it being in a certain state as a more monolithic thing
<MonkeyofDoom>
e.g. "airplane mode"
<DocScrutinizer05>
Pali: which is one of the most insane policies in Nokia's maemo engagement: the user must not touch audio since it's too important for the device to let user mess with it
<Pali>
maybe... if you know puppet software (for system configuration; written in ruby)... my idea was to rewrite that into prolog :D
<Pali>
funny part could be once prolog just answer "false"
<Pali>
:D
<DocScrutinizer05>
I failed to grok prolog and lisp
<Pali>
probably you do not have enough brackets...
<DocScrutinizer05>
it gives me headache since not compatible with my brain architecture
<DocScrutinizer05>
I can do OO
<DocScrutinizer05>
but for sure not prolog and lisp
norly has joined #neo900
<Pali>
until somebody for fun write object system for prolog
<DocScrutinizer05>
the concept evades me
<Pali>
prolog is inverse how you write code in other languges
<DocScrutinizer05>
yeah, it feels like that ;-)
<Pali>
if C, C++ and others you need to describe how to solve your problem (but program does not know whats is your problem)
<Pali>
in prolog you describe your problem and it will solve it (if possible)
<Pali>
you do not describe *how* to do it
<DocScrutinizer05>
insane. Ho do I describe the "sub-sub-sub-problem" of e.g. >>give decent feedback aka error message and try catching up when file XY is not readable"
<MonkeyofDoom>
you can kind of guide it along "don't waste your time trying something that won't work" with cuts
<MonkeyofDoom>
but it's a clumsy language for many programming tasks outside of constraint satisfaction
<DocScrutinizer05>
:nod: exactly what I thought
<DocScrutinizer05>
Real programmers don't need all these abstract concepts to get their jobs done -- they are perfectly happy with a keypunch, a FORTRAN IV compiler, and a beer.
<DocScrutinizer05>
o Real Programmers do List Processing in FORTRAN.
<DocScrutinizer05>
o Real Programmers do String Manipulation in FORTRAN.
<DocScrutinizer05>
o Real Programmers do Accounting (if they do it at all) in FORTRAN.
<DocScrutinizer05>
o Real Programmers do Artificial Intelligence programs in FORTRAN.
<DocScrutinizer05>
If you can't do it in FORTRAN, do it in assembly language. If you can't do it in assembly language, it isn't worth doing
<R0b0t1>
DocScrutinizer05: In a functional program you specify relationships that hold between values. It is up to you to assign meaning to these values. The computer will then do what it must to prove what you wrote.
<DocScrutinizer05>
I doubt that works for e.g. writing sed or grep, invl --help and error messages
<DocScrutinizer05>
incl*
<R0b0t1>
5 = lists:foldl(List) -> true/false
<R0b0t1>
Well, there's more than one (I think) package for generating error messages in haskell
<R0b0t1>
I know the messages for the parser were terrible, programs it was compiling not so much
<R0b0t1>
it's like in any language, you just have a lot of print statements...
<DocScrutinizer05>
have mercy! I don't even want to touch that stuff
deafboy has quit [Remote host closed the connection]