Systemd-Free Debian "Devuan" Planning Their First Developer Gathering This Spring

[aht0]

problem is your biased view and the loud cry of some fools, on every other software updates are installed and people move on
https://resources.whitesourcesoftwar...lities-in-2018

* Mon Feb 25 2019
- Linux v4.20.12
- Fix CVE-2019-8980 (rhbz 1679972 1679974)

* Wed Feb 20 2019
- Linux v4.20.11
- Fix CVE-2019-8912 (rhbz 1678685 1678686)

* Fri Feb 15 2019
- Linux v4.20.10

* Tue Feb 12 2019
- Linux v4.20.8
- Fixes CVE-2019-7221 (rhbz 1671904 1673676)
- Fixes CVE-2019-6974 (rhbz 1671913 1673681)
- Fixes CVE-2019-7222 (rhbz 1671930 1673686)

* Mon Jan 28 2019
- Linux v4.20.5
- Fix CVE-2018-16880 (rhbz 1656472 1669545)

* Mon Jan 14 2019
- Linux v4.19.15
- Fix CVE-2019-3459 and CVE-2019-3460 (rbhz 1663176 1663179 1665925)

* Wed Jan 09 2019
- Fix CVE-2019-3701 (rhbz 1663729 1663730)

Bias? Indeed? Compare apples and oranges.
Linux kernel is project far larger than systemd. It should be somewhere around 30MLOC. It's guaranteed to have more bugs purely due to it's larger total size.

You haven't pointed out a single technical problem with systemd (not one!), only misconceptions and personal opinion. And sorry, your basic code snippets does not give you any authority in claims like "Wrong approach to development." regarding a major open source system and service manager.

Actually, I gave you even a list. If you chose to ignore it, it's your problem. Systemd's project size in itself is a problem, to start with. Smaller projects (like individual components systemd has replaced) are much easier to manage than single monster project. Statistical tendency is such that as the projects increase, amount of bugs does as well. I've seen multiple theories about it, some claim 3-4bugs per 1kLOC is good quality code, some claim 10-20 are "normal". So, how many hundreds of thousands of lines of code systemd is at, currently? I see close to 1000 unresolved bugs in github as of now. Following the optimistic idea of 3-4bugs per 1kLOC, there's good bunch still being not found.

At the end of the day, you simply have no clue about open source and how the players within work. Systemd has been chosen because it's technically superior. It's simply more effective than the projects it's "annexed". Every distribution could choose to not use systemd or just use parts of it. This notion that Redhat is somehow forcing it on people is completely absurd.

Do you have a clue? Lot's of words, accusations and insults. Haven't seen bit of solid knowledge yet TBH.

50k LOC..... Do you even github? Do you have a single line of public code? Have you participated in any open source projects?

Yes, I actually do have github, though until recently I found very little use for it, except for sending in patches, because unpaid account did not allow for private repos. Shit I wrote for money's been always closed source.

About the latter question, that forum post should provide sufficient answer.
https://forums.freebsd.org/threads/f...0/#post-368909

Oh and btw, I'm not raging I am writing this with a perfect 40 beats per minute pulse and a smile on my face sipping my coffee.

Either you are trying to brag or you have heart condition called bradycardia. In the latter case, go see cardiologist. Considering the amount of time you seem to spend behind computer, I suspect former.

[aht0]

you need to understand that that systemd is not driven by two people and that every component has it's primary maintainers to begin with

Overwhelming amount of commits are by bare handful of people. For example, yesterday Poettering alone commited 19 changes, which makes 62.3% of total yesterday's commits. When you look at total history of commits, it's dominated by just about five people, with huge scissors between first and fifth place.

the opposite is true when they interact and have dependencies given that refactoring and share code via private API's in a big repo is much easier

at the end of teh day the code for the same functionality is way smaller than in your small projects and you biased view forgets that the replaced ones didn't have the same functionality in many cases

In many cases, replaced ones had properly working functionalities, instead of oddball errors cropping up at random places.

again: biased view!

i don't run networkd, timesyncd and a lot of other components at all so a bug there won't affect me and on the other hand the heavily shared private library is fro sure one of the m,ost maintained peices of software out there and even bugs in context of components only a small part of users are actively using leads to another review

Just one question: if you find it necessary to exclude one or more modules, what's the point of the thing overall? Necessity of disabling parts of it, negates it's efficiency because you have to spend extra time getting it re-worked to your particular needs. So, you are spending time in any case. Might as well go the way of simpler OS design, which logically would give less issues long-term.

how many of them are discussed if it's even a bug at all and even if in which component and context
how many of them are even bugreports because "issue" can be a lot
how many of them are simply not true and nobody wasted it's time to close them?
imagine people like you are reporting bugs there while PEBCAK

This project is infamous for not admitting it's bugs as bugs nor caring about fixes. Thus I just took "open issues" and settled with it. It's more or less stable number near one thousand. Yesterday it deviated between 996 and 982, today it shows me 991.

Cherry on the cake for you: What the hell should one think about developer who would reply something like this to bug report:

Poettering:To make this work we'd need a patch, as nobody of us tests this

[aht0]

did you ever hear about external patches reviewed and commited by a few people instead have the world randomly commit waht ever it thinks?

External patches are relatively far and few between compared what main devs write. Since I took up yesterday's stats, out of thirtish commits, 4 were external merges.

frankly your lacking knoweldge about the project and sofwtare development at all is annoying

Me thinks, you are running out of excuses and arguments.

the point is that you are not willing or able to cope with changes and when someone si not willing to begin with it won't work well

When it gets on my way, sure, I dislike any change. When it fixes something broken for me, I am fine with it.

networkd: i run my own oneshot-systemd unit with iptables-restore, ip.commands, route commands, bridiging/bonding
timesyncd: my machines either get their time from the host or are ntp servers for a whole network

if disable something you don't need is worth any words for you just quit the IT!

you likely refuse the beauty of the unit below and what "systemctl status" gives you for each of the commands in case something goes wrong which makes it superiour to a shellscrpt or the old netwerok-service or networkmanager/networkd in case of *static* configured machines, but anyways, here you go

Frankly, I cant really see any beauty in this unit file. It's a bunch of cryptic strings without consulting documentation first. For reading.

OpenRC init script for your perusal ('PF' firewall). THAT I'd be able to write from beginning to an end without considering suicide first.

#!/sbin/openrc-run
# Copyright (c) 2007-2015 The OpenRC Authors.
# See the Authors file at the top-level directory of this distribution and
# https://github.com/OpenRC/openrc/blob/master/AUTHORS
#
# This file is part of OpenRC. It is subject to the license terms in
# the LICENSE file found in the top-level directory of this
# distribution and at https://github.com/OpenRC/openrc/blob/master/LICENSE
# This file may not be copied, modified, propagated, or distributed
# except according to the terms contained in the LICENSE file.

name="Packet Filter"
: ${pf_conf:=${pf_rules:-/etc/pf.conf}}
required_files=$pf_conf

extra_commands="checkconfig showstatus"
extra_started_commands="reload"

depend() {
need localmount
keyword -jail -prefix -stop -shutdown
}

start()
{
ebegin "Starting $name"
load_kld pf 2>/dev/null
pfctl -q -F all
pfctl -q -f "$pf_conf" $pf_args
pfctl -q -e
eend $?
}

stop()
{
ebegin "Stopping $name"
pfctl -q -d
eend $?
}

checkconfig()
{
ebegin "Checking $name configuration"
pfctl -n -f "$pf_conf"
eend $?
}

that he is at least honest and that you are completly wrong when you think that it's much different in other projects, no matter opensource or closed source - pretty sure some functionality which was a feature request with a patch which was reviewed and accepted and now someone comes up with different needs

nobody says all is perfect, it's not and it's also not in many other projects

at least it works and it works the last 7 years way better than anything before which likely is here the case because other than you instead of fighting against i look at it's capabilities/opportunities and make heavy use of them

and until you come up with a *relieable* initscript starting a service like below which i do for years for every service (yes adopted for it#s needs) leave me fuck in peace

Honest or not, such attitude is unacceptable when project in question is a service manager for an operating system. It's bugs and problems affect the whole system.

At the moment, I am getting a feeling, you have until now seen only SysV init (I admit it's cross-linking of files was pretty horrendous) and systemd. Nothing else. And mainly like systemd-init because it's indeed flat out superior to old SysV init. I agree here with you - anything is better than this mess was.
At the same time, there were bunch of other alternatives, which worked all better than SysV init and could have been used without fucking adding fifty-binary-kitchensink to 9 out of 10 Linuxes with it's inherent problems and bugs.

So, one German dude invented experimental rocketship for going into milk store and everybody + their dogs are singing hosianna.. when traditional alternative solutions already existed but were not considered because NIH syndrome, which is the curse of Linux.

[aht0]

which cryptig strings?
ExecStart?
really?

and when you mean things like "PrivateDevices" you have nothing similar in your crap, surely you need to consult documentation for hardening options not available anywhere else which are *optional* to use - what else? it's laughable how you argue all the time and think you have a single point while everybody which had really worked with systemd sees that you have no idea what you are talking about

the /usr/sbin/ip calls and the other ExecStart stuff are just plain commands and you don't realize it
practically as they would be in a shellscript without the "ExecStart="

the difference is that you get error handling for free in systemctl status, you see which command failed and you have the journalctl output of recent events on bottom containing stdout/stderr of the processes and so get the fucking reason without any additional line of code, for everything

It is said "Beauty is in the eyes of beholder". Shorter and more concise it is, more beautiful it becomes. Mine is shorter, both line-wise and by character count. Precise network details I would specify differently. Systemd replaced legacy network configuration utilities like "ifconfig", I'd use these. As a result, init itself has less possible points of failure. Because init's main task is to initialize the boot, not trying to do hundred other things simultaneously on background at the same time. Most reliablie tools, both in software and hardware, always follow the KISS principle. Keep It Simple, Stupid.

Privatedevices analogue would be "jails". Notice "keyword -jail -prefix -stop -shutdown". This file was taken from FreeBSD box with an OpenRC init. The fact that something might carry different name, does not mean your "hardening" is not present. About possible error messages, I'd get these from syslog - a non-issue.

You won't see shit like "Timeout for 1min 30sec" in OpenRC, which is so common with systemd when it has hit some rocks and shoals and tries to figure out how to proceed.
OpenRC just boots. I've gotten FreeBSD to below 10 seconds boot with it-which is awesome considering it's normally like 30 seconds with traditional RC init. Alpine Linux does it even much faster (also OpenRC). When I have to install OpenSUSE (systemd distro) I am waiting 1-5min pretty much on first boot after install and then have to start figuring out what the hell is causing disruption. Efficient ? No, because it almost always would require manual modifications.
And it always requires modifications when I changed something about local file systems or drives. I have wife and mother-in-law doing their nagging, I don't need some system manager adding to it.

[Weasel]

It is said "Beauty is in the eyes of beholder". Shorter and more concise it is, more beautiful it becomes. Mine is shorter, both line-wise and by character count. Precise network details I would specify differently. Systemd replaced legacy network configuration utilities like "ifconfig", I'd use these. As a result, init itself has less possible points of failure. Because init's main task is to initialize the boot, not trying to do hundred other things simultaneously on background at the same time. Most reliablie tools, both in software and hardware, always follow the KISS principle. Keep It Simple, Stupid.

Amen.

[Weasel]

bla

That's how all of your posts appear to me.

Can't argue with blindfolded ignorant who refuses to acknowledge facts.

[aht0]

that as answer to "the point is that you are not willing or able to cope with changes and when someone is not willing to begin with it won't work well" explains it all - you dislike any change and so you disklike that you get washed away because you decided to work in an industry which is all about change

now you have found systemd to reflect your selfhate about a job you dislike at all because it's about change and nobody will stop the world for you just to keep you safe and warm with that little stuff you know not willing to open your mind and so you get washed away sooner or later and believe systemd is doing that, no it's only making your anyways happening washing away caused by your attitude faster

RTFM or retire

given that you fucking don't read or even try to understand what you reply to just shut up, everone knows that you are dumb in the meantime

If you want me to actually read lots of what you type, dial down with personal attacks. I've already said once I see those, I'll just be skipping your posts

Do much extrapolation without actually knowing personally? Go into hate-speex much, because you simply lack proper arguments? LOL

I might as well claim that you are so stuck on systemd because SysV init was for you exceedingly bad experience, leaving you psychologically scarred, you were reaching the first straw (as systemd came to exist) and now are utterly terrified of letting go and looking at alternatives - no matter how unreliable the systemd is - you are rather ready to disable it's multitude problematic functionalities than look elsewhere.

Do I really HAVE TO cope with "changes" (as you see systemd) when alternative options offer much more solid experience? You can feel free to trail each progressive change like a faithful dog if you like. I know what I require and I use software accordingly.

[aht0]

Amen to bullshit like "Systemd replaced legacy network configuration utilities like ifconfig" which is nothing than a outright lie

* ifconfig is part of net-tools
* net-tools is deprecated for a decade (https://lwn.net/Articles/710533/)
* /etc/init.d/network is a completly different beast
* both, net-tools and /etc/init.d/network are still there in Fedora 28
* how can systemd which is in Fedora for 8 years now have replaced something which is still there
* yes, it's now about to disappear, in F29 you get deprectaion warning for /etc/init.d/network
* but again: it is there and so none of both was replaced by systemd

when something is about to replace /etc/init.d/network it's NetworkManager which has nothing to do with systemd at all because it's independent and exists way longer and so both of you have a head full of shit with the imagination systemd is guilty for every decision independent developers, maintainers and os-suppliers are making

and then you idiots talk about "facts"? seriously?

Check your own "facts". Some distros still use ifconfig, some distros deprecated it less than 5 years a go - not every distro is a instant copy-cat of Fedora. FYI: NetworkManager is purely Linux software. It does not work ouside Linux desktops. Came out of your 'Linux-cave', it's the reason of your tunnel vision.

Ifconfig is ONLY deprecated on GNU/Linux. It's still standard network configuration utility across BSD's, Solaris variants, OSX and commercial Unices (like AIX). So, tell me one good reason to start using another utilities (iproute2 package) when these are not used anywhere besides Linux AND offer less verbose and machine-readable/parsable output to top it off.

[aht0]

when you don't read anything why answer at all?
when you don't read what do you expect?
the only one psychologically scarred is you when it comes to systemd
well, when it works for 8 years in production on vservers, hosts, network storages, routers, firewalls, desktop-machines for me like a charme you can't tell me about unreliable
with your closed mindest you are not in the position to talk about "more solid experience"
nosense, i likely fight harder then you against "change for the sake of change" all the years but i am not stubborn
so do i and migration to systemd was no big deal and given how late you users of other distributions got to face it when it was much more mature as when i started i simply don't get that stubborn attitude "i have done this always exactly that way and so i continue, i don't make real expierience but talk a lot with no deep knowledge what i am talking about"

LOL. At one point claiming it "works like a charm" for you then talking about how he disabled bunch of functionalities from the thing that was supposedly "working like a charm".

[aht0]

nobody cares what some distros do - fact is that the manpages of net-tools binaries (ifconfig, route, arp...) are coming since 10 years with "this program is obsolete! For replacement check ip addr and ip link." notes and just because whatever distribution is using old versions don't change that fact
and?

Well, each distribution tends to have it's own set of man-pages. Of course, when it has any at all. Except for few distros, manpages on Linux just plain suck. So. the depreciation of net-tools might be written in man pages or it might not.

If you would try to understand what i post you would know that i don't give a shit about NetworkManager

Kinda hard to lower myself to that level. You pointed it out, so it had some meaning.

fact is for static server configs ou need just a few "ip" commands and you are done, would you really read what i post you would know

And it's same with ifconfig

i don't give a shit about BSD, Solaris and commercial Unices and especially not about OSX where people can't handel a terminal anyways and so does the rest of the world
tell me one good reason why to care about obsolete operating systems?

Well, I don't give a shit about systemd-using Linuces either, so we are on equal ground. I kinda like picking on you, you dont have good arguments but instantly start foaming around your fingers/mouth.

I do hope you are single because one thing I've learned over the years of my work - most common excuse for bullies and wife-beaters is "I did it because you forced me with you 'wrong' behaviour" - drawing parallels with your personal attacks here, attacks you have here justified with exact same reasoning.

I've noticed over the past few years quite a lot of new BSD users stating that they are migrating to BSD because of systemd. FreeBSD is said to be much like "pre-systemd Linux". Solaris derivatives (like SmartOS) still have features not available in Linux. AIX and other commercial Unices are used on vendor's hardware.