Xseba360 has quit [Remote host closed the connection]
Xseba360 has joined #neo900
Xseba360 has quit [Client Quit]
Xseba360 has joined #neo900
Xseba360 has quit [Client Quit]
<DocScrutinizer05>
dbus is about the worst implementation of bus I have seen so far
Xseba360 has joined #neo900
lobito has joined #neo900
<Oksana>
;-)
* Oksana
will look up bus implementations...
<DocScrutinizer05>
just look up dbus-send syntax and you're done
<DocScrutinizer05>
btw Oksana, I hope you followed up on IPHH invoice payment which must have been due around this time
<DocScrutinizer05>
HiFo job, but...
<DocScrutinizer05>
... I don't see it mentioned in "fiscal report"
<DocScrutinizer05>
Oksana: ^^^ (for highlight)
<DocScrutinizer05>
(dbus) also see for example datatypes and hardcoded timeout
<DocScrutinizer05>
and I still suspect massive bugs in dbus implementation too
<DocScrutinizer05>
just too often everything dbus related acts too random on my machine
<DocScrutinizer05>
as if there were anouther 20 race conditions in it that are not yet known - I hope the known ones got fixed meanwhile
<DocScrutinizer05>
and then the thing has no concept of any load limiting/trottling, which results in fools actually streaming media over dbus (audio, even video) - for *sure* sth you MUST avoid to do
<DocScrutinizer05>
~2119
<infobot_>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
<DocScrutinizer05>
you may ask mickeyl (Lauer, Head of FSO) about his experience with dbus. He almost reached the point where he had written his own bus implementation or even used CORBA, instead of dbus, due to mere frustration and problems
<DocScrutinizer05>
a nice little sign about general state of dbus land: mickey wrote mdbus2 despite dbus-send and dbus-monitor being around at that time
<DocScrutinizer05>
btw iirc mdbus2 is python and "just works" even on maemo, I copied the "binary" (actually script) to my N900 ~5 years ago
sparetire has quit [Quit: sparetire]
kolp has joined #neo900
che11 has joined #neo900
Xseba360 has left #neo900 ["Leaving"]
<FIQ>
I never had issues with systemd myself in the little time I used it
<FIQ>
except for the BS log format
<FIQ>
and a system instability bug that caused a system wide crash if there was too many segfaults in quick succession
<FIQ>
(which, granted, is kinda critical, but I've had issues with other boot systems as well)
<Humpelst1lzchen>
rofl "never had issues"...except..
SylvieLorxu has joined #neo900
<DocScrutinizer05>
yeah, and the MAIN isuue ELEPHANT in the room is that you can't opt out of systemd, since the whole distro gets patched to satisfy dependencies to systemd that forbid using *any* other possibly better init system
<DocScrutinizer05>
Devuan started to fix this before it's definitely too late. It already is pretty difficult to build a distro without all those systemd dependencies
<DocScrutinizer05>
again, it's not even interesting how good or awful systemd works, it's about it hijacking the distro and taking away linux users' freedom of choice
<DocScrutinizer05>
and breaking stuff like e.g. maemo which *cannot* move to systemd and thus soonish will not be compatible to upstream recent debian anymore, since that upstream debian is full of packages that have hard dependencies to systemd
<Wizzup>
There are quite some distros that only have systemd as an option, not default
<DocScrutinizer05>
Poettering did it once when he pushed PolypAudio and tons of apps broke since the flimsy pathetic ALSA compatibility layer PA came with rendered those apps broken and urged them to move to genuine PA support. Now he's doing again, this time basically for ALL apps on the system, not only for audio apps, by introducing an init system that also has dependencies that apps need to satisfy
<Wizzup>
For maemo/debian based it may be more of a problem
<DocScrutinizer05>
seems there's already a systemd dependency in xinit resp startx (both?) that in effect makes systemd mandatory when you want to run unpatched X11 on your system
<DocScrutinizer05>
so THIS is the TRUE clusterf*ck of systemd
<DocScrutinizer05>
it introduces requirements other basically completely unrelated apps have to satisfy so systemd can work as supposed to, and those requirements introduce dependencies to systemd in all those unrelated packages
<DocScrutinizer05>
now some of them may come with a --without-systemd buildtime option. The question is how long that will be supported, and it's already obvious that many packages will never even provide such option
<DocScrutinizer05>
simplified picture it's like if systemd switched from little-endian to big-endian and now urges all other packages to do same when they want to stay compatible to future systems
<bencoh>
(tl;dr : "fight cancer, burn teh witch")
<bencoh>
;p
<DocScrutinizer05>
rather "fight for your freedom - take away the freedom from those who want to take away your freedom"
<bencoh>
:-)
<DocScrutinizer05>
I don't want golden cages. And this one doesn't even look golden to me, rather quite rusty
<DocScrutinizer05>
and broken by design
<Wizzup>
It probably won't last
<bencoh>
Wizzup: you forgot the "too much involved/invested" factor
<Wizzup>
like with HAL?
<bencoh>
hmm, dunno
<bencoh>
maybe more
<Wizzup>
in linux, nothing lasts ;)
<kerio>
DocScrutinizer05: i want openbsd on neo900 :c
* bencoh
inserts coin in kerio
<kerio>
wut
<DocScrutinizer05>
grease it ;-D
<kerio>
dear lord
<bencoh>
DocScrutinizer05: ohno! :]
<Wizzup>
kerio: but would you be able to do anything with it?
<DocScrutinizer05>
first: would you be able to do sth _about_ it
<DocScrutinizer05>
kerio: you're free to port bsd to Neo900 any time - or find others to join that effort
<DocScrutinizer05>
Neo900 is *open* in that we support porting *any* OS to the platform
<kerio>
well, the openbsd devs shunned the sheevaplug because it had shitty specs that relied on linux drivers and binary blobs
<kerio>
i don't think it's the case for the neo900
<DocScrutinizer05>
well, Neo900 is _not_ like that
<kerio>
hopefully a dev will buy one
<DocScrutinizer05>
we even might support such efforts by loaners
<Wizzup>
kerio: the sheevaplug specs were really quite good at the time
<DocScrutinizer05>
and for bsd we prolly would
<kerio>
were they
<Wizzup>
yes.
<kerio>
wait
<kerio>
which specs
<kerio>
i meant the kind of specs that describe what and how it works
<kerio>
not how fast
<DocScrutinizer05>
that's docs, not specs
<kerio>
k
<DocScrutinizer05>
specs are basically a table of numbers
<kerio>
sorry
<kerio>
well, the openbsd devs shunned the sheevaplug because it had shitty docs that relied on linux drivers and binary blobs
<kerio>
i don't think it's the case for the neo900
<kerio>
hopefully a dev will buy one
<bencoh>
:]
<kerio>
[:
jonsger has joined #neo900
<kerio>
ok to be fair
<kerio>
the openbsd vm i had was really underwhelming
<kerio>
it booted much slower than a matching linux vm
<DocScrutinizer05>
when there's one thing I don't care about then that's boot time
<DocScrutinizer05>
when I started professional career, booting of our minicomputer too well over 10 minutes
<DocScrutinizer05>
took*
<kerio>
one of the "topical" VMs (nginx+ruby webapp) takes like 8 seconds to boot
<kerio>
it's almost enough to only require a single refresh from the user
<DocScrutinizer05>
tbh it sounds illy to boot a VM at all, except once in it's whole lifespan
<DocScrutinizer05>
silly*
<kerio>
well
* DocScrutinizer05
needs a new kbd
<kerio>
it's debian stable
<kerio>
it only gets updated for really important stuff
<kerio>
the kind you should probably reboot for :)
<DocScrutinizer05>
a VM you boot up once, snapshot it, then resume from snapshot instead of booting it a second time
<kerio>
not when your purpose is to ensure that the old libssl isn't in use anymore
<DocScrutinizer05>
ok, possibly you then need to resort to boot, when you can't do e.g. zypper ps
<kerio>
but yeah, to not reboot the host system i just suspended and resumed
<kerio>
(restarting kvm in the... process)
<kerio>
(LOL!)
<DocScrutinizer05>
courtesy systemd ? ;-P
<kerio>
DocScrutinizer05: debian-goodies has checkrestart
<kerio>
it's neat
<kerio>
no systemd
<kerio>
i'm using the old version of libvirt for that reason
<DocScrutinizer05>
well RPM goodies have implicit restart of services whenever updating them
<kerio>
sure thing bro
<kerio>
restart literally everything at once when i update a library
<kerio>
that sounds like a good idea
<DocScrutinizer05>
hehe
<DocScrutinizer05>
for libs it's a tad tricky, yeah
<DocScrutinizer05>
but then, when you update a lib, you often want to update the service using the lib as well
<kerio>
sure thing bro
<DocScrutinizer05>
if not, there's still zypper ps
<kerio>
update literally everything at once when i update libssl for the 35th security update in a row
<DocScrutinizer05>
I thought that's "yoh dawg"
<kerio>
i thought you liked updates?
<DocScrutinizer05>
anyway they said apt << RPM, even tools like aptitude etc
<infobot_>
mooooooo! I am cow, hear me moo, I weigh twice as much as you. I'm a cow, eating grass, methane gas comes out my ass. I'm a cow, you are too; join us all! type apt-get moo.
<kerio>
libvirt is... eeh
<kerio>
kvm is also eeh
<DocScrutinizer05>
xen fscks up my network, changing NIC to bridge
<kerio>
ipv6 forwarding is fucking cheating
<kerio>
you set the correct addresses
<kerio>
and it just works
<kerio>
in my days, routing required effort!
<DocScrutinizer05>
no, bridge doesn't 'just workk'
<kerio>
it does if your bridge is only for the VMs
<DocScrutinizer05>
bridge is a pita, particularly when installed later on on a eth0 system
<kerio>
and you let linux do routing instead
<kerio>
hetzner sends the whole /64 to your eth0
<kerio>
you configure a /128 on eth0
<DocScrutinizer05>
and *particularly* when some stinking network manager blows chunks on bridge
<kerio>
and a /64 on br0
<kerio>
literally effortless
<DocScrutinizer05>
well, that may be true when installing xen manually bottom up. Not so when you get the whole xen package that swaps your kernel and whatnot else, and converts eth0 to bridge without further notice
<DocScrutinizer05>
I'm obviously talking about my normal desktop here
<DocScrutinizer05>
for VM on a dedicated server, xen or die
<DocScrutinizer05>
~factinfo moo
<infobot_>
moo -- created by mgeary <n=mgeary@166.70.44.49> at Fri Sep 28 15:18:07 2007 (2740 days); last modified at Thu Apr 18 20:21:06 2013 by cirdan!~chris@c-68-45-49-242.hsd1.nj.comcast.net; it has been requested 301 times, last by DocScrutinizer05, 8m 49s ago.
<DocScrutinizer05>
kerio: isn't libvirt also needed for xen?
<DocScrutinizer05>
xes: ^^^
freemangordon_ has joined #neo900
<kerio>
DocScrutinizer05: xen has plenty of "frontends"
<kerio>
kvm has very little of those
<drathir>
openvz rulez...
<kerio>
hahahahahahahahaha
<kerio>
ok to be fair
<drathir>
DocScrutinizer05: xen if good remember is standalone with own set of cli interface, the virt-manager is some kind of frontend and is need to be patched if good remember...
<kerio>
i'm basically taking full VMs and paravirtualizing them as much as possible
<kerio>
i even thought about using p9/virtfs
<drathir>
openvz for cheap solution, kvm for full solution in my opinion...
<kerio>
it definetely allows for simpler overbooking of your resources
<kerio>
that's not my style
<bencoh>
9p/virtfs isnt really a good option
<bencoh>
it looks like it, but ... meh
<Wizzup>
What's wrong with 9p? :)
<bencoh>
nothing wrong with 9p
<bencoh>
just the linux 9p virtfs driver
<bencoh>
and its slab management
che11 has quit [Ping timeout: 245 seconds]
freemangordon_ has quit [Ping timeout: 264 seconds]
freemangordon_ has joined #neo900
freemangordon_ has quit [Read error: Connection reset by peer]
<kerio>
bencoh: yeah, the problem was that i needed it for some fairly unixy stuff
<kerio>
relying on correct mtime and fcntl locking across hardlinks, and stuff like that
<bencoh>
I considered using 9p and eventually went back to nfs
<bencoh>
it sucks, but it doesnt eat all your ram
<bencoh>
neither does it go OOM on you
<bencoh>
(because 9p wont release memory it kept for "cache")
<DocScrutinizer05>
He's asking for telling him where on his 17 points of "unix philosophy" systemd resp he and his gang failed. I think it's simpler to state where they didn't: 3. Maybe 12, 14, 15, I CBA to check systemd for compliance
<kerio>
why the hell didn't they at least use level3's dns
<DocScrutinizer05>
anybody not seeing how systemd fails on point #6 is actually just... :-x
<DocScrutinizer05>
>> Systemd has been what ca 7 years in the making now with what 5 of those years being direct integration with wide variety of components and distribution so this is not a simple matter of writing an new init system, this is so much much more work which I dont think those new or existing init project and it's developers realize.<<
<DocScrutinizer05>
of course we realize that bloating, and that's exactly the problem
raccoon_ has quit [Quit: bye]
raccoon_ has joined #neo900
freemangordon_ has quit [Ping timeout: 264 seconds]
<jonsger>
all my systems are based on Ubuntu 14.04 LTS so I dont care about systemd ;)
<kerio>
sysv or bust
<pigeons>
i gave systemd a chance. dont put it on servers :(
<pigeons>
i dont like it being a lottery whats going to happen when i reboot them remotely
<DocScrutinizer05>
so what do you think about both RHEL and SLES already adopted systemd?
<pigeons>
i've been using debian but same issue there. very frustrating. probably will live with it some, explore gentoo some more, netbsd, etc
<kerio>
openbsd!
<kerio>
i would pay hundreds of millions of euros to have reallocarray on linux
trx has quit []
<DocScrutinizer05>
devuan
<kerio>
stop saying devuan
<bencoh>
:]
<kerio>
no seriously go install openbsd in a VM
<kerio>
it's like stupid easy
fling has quit [Quit: leaving]
fling has joined #neo900
Pali has quit [Ping timeout: 265 seconds]
Pali has joined #neo900
mvaenskae has joined #neo900
<DocScrutinizer05>
why the heck would I do that?
<kerio>
to try
ddark has joined #neo900
<kerio>
it's fun :c
Pali has quit [Remote host closed the connection]
arcean has joined #neo900
<DocScrutinizer05>
I'm not interested in fun, when it comes to my tools I need in a working state to make a living
<kerio>
...but it's fun :c
<P-G>
Productivity is fun too. :)
mvaenskae has quit [Ping timeout: 248 seconds]
arcean has quit [Read error: Connection reset by peer]
Kabouik_ has joined #neo900
Kabouik_ has quit [Remote host closed the connection]