The State of Debian

security-tracker.debian.org/tracker/status/release/stable
>2018
>37 matches
We are 5 months into 2019, this feels like Slackware. I don't get it.
Is this how slow debian development really is today? They let packages with security vulnerabilities which are more than 6 months old (which got fixed almost immediately in upstream) just sit there?
I don't think all 37 matches are true.
And it won't matter if they are packages nobody uses anyway, 389 directory server is a server software for example which doesn't seem that commonly used.
I read sometime a rant about a debian developer who left, saying debian is not what it used to be. He committed backports for packages (and at that security ones which have higher priority) and the person in charge to accept those commits just accepted it when he felt like, usually past the point where this developer in question remembered making the commit. I don't have the bookmark to that link, is this still the case?

Attached: gay porn tabs.png (1000x811, 122K)

Other urls found in this thread:

michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
people.canonical.com/~ubuntu-security/cve/main.html
michael.stapelberg.ch/posts/2019-02-15-debian-debugging-devex/
twitter.com/NSFWRedditVideo

here it's the rant, he used to maintain a bunch of packages.
michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

Attached: debianwallpaper.png (1920x1080, 2.79M)

Attached: debian.png (300x500, 41K)

>Culturally, reviews and reactions are slow. There are no deadlines. I literally sometimes get emails notifying me that a patch I sent out a few years ago (!!) is now merged. This turns projects from a small number of weeks into many years, which is a huge demotivator for me.
>Interestingly enough, you can see artifacts of the slow online activity manifest itself in the offline culture as well: I don’t want to be discussing systemd’s merits 10 years after I first heard about it.
>Lastly, changes can easily be slowed down significantly by holdouts who refuse to collaborate. My canonical example for this is rsync, whose maintainer refused my patches to make the package use debhelper purely out of personal preference.

Attached: debian_in_a_nutshell.png (6969x6969, 993K)

Debian is too busy removing packages with the word "boob" in it to care about security.

Ebin xD

I used to meme about this but unfortunately is true, they give zero fucks about meritocracy now.
So I made this OP wondering if there is a better successor or a better stable general purpose distribution.
I know Fedora and Red Hat write most of the upstream code now in open source projectes so I use Fedora on my desktop, but I liked debian a lot since it maintained way more packages. Now they just ship them and let them get orphaned without any bugfix.

Maybe Devuan can get their shit together. I don't know what the current state of their project is.

>devuan
kek, made me chuckle.
they just take packages from debian and desystemd them.
Huge philosphy there, just making a fork because of le fedora nsa boogieman.
So they inherently have the same problems as debian.
If anything, Ubuntu is something that commit bugs faster than Debian. They are mostly based on debian unstable but if you take proper attention on how they work you will see thay actually do shit instead of depending on debian sometimes, at least with their official repository

people.canonical.com/~ubuntu-security/cve/main.html

For reference, the Ubuntu CVE tracker.

michael.stapelberg.ch/posts/2019-02-15-debian-debugging-devex/

just compare, debian would work if it was smaller but they do stuff very inefficiently for a way big number of packages

I just realized this is the i3 guy.

perfectly clean if you check with filters, but that is just the main repository, using the universe and all that shit often goes unmaintained since it's the community.

>getting debugging symbols
This does suck. On Arch (inb4 memes), I just copy the package build and rebuild the package without stripping the debugging symbols. It takes longer in some cases (compile time), but it's less of a headache.

>just making a fork because of le fedora nsa boogieman.
Strawman. See recent systemd exploits and anti-unix things

>anti unix things
opinion discarded, that means nothing
>"exploits"
security bugs that get patched instantly because there are a shit ton of people involved in systemd development.
Suckless retard

How many CVEs does runit have? systemd adds a massive amount of complexity for no discernible reason or benefit. At best, there's some super niche features that systemd can do, but no one ever uses them in practice and most machines would never need it.

>hurr durr I read suckless so I'm smart
I've read those stupid script kiddie arguments already, there is nothing substantial. See:
>runit
that's only an init. A lot of old methods and programa used before are now sub projects of systemd just like a lot of shit in a linux system is written by gnu. Nobody bats an eye because a lot of code is GNU, that's as retarded as saying "wahh systemd big".
Using bash for everything is hell of retarded for something so close to the system, it's fucking slow and everyone can do whatever they want creating a lot of systems that add complexity to writting packages and distributing software in different distributions. Debian, Arch, Ubuntu, Fedora, Red Hat all switched to systemd because of technical reasons. You think you know better just because you think you are smart reading and writting bash scripts. Those people actually are developers.
>wahh is too complex
brainlet, maintaining services alive when they crash and waking services based on the system state is very useful, plus it's easy to write and use.
It unifies better what the core of the linux system is to distribute software. Upstream projects can now expect writting to the same system so less work is left to packagers in distributions.
Now, let's review your anti systemd "arguments":
>muh unix
>too big
>I don't know how much value it adds to sysadmins and developers because I only watch anime, so it shouldn't have those features

>that's only an init
Runit can supervise processes so you're already wrong.

>Nobody bats an eye because a lot of code is GNU
Because GNU stuff is actually useful and serves a purpose.

>maintaining services alive when they crash and waking services based on the system state is very useful
Other init systems can do this too. Absolutely nothing about systemd is special.

>It unifies better what the core of the linux system is to distribute software. Upstream projects can now expect writting to the same system so less work is left to packagers in distributions.
This is largely disinfo and not true. A daemon is a daemon. It doesn't care what starts it or supervises it.

Most pro-systemd advocates tout a bunch of features that tons of other init systems already have as "new" or "innovative" when in fact none of it was. systemd does nothing for me that I can't do with runit or s6 and both of those programs are much easier to use and have way less baggage. I'll stick with them.

bro, no.

and I forgot to add, its modular enough to fit embedded systems and is very fast compared to your retarded bash scripts, you have to recompile it the same way your retarded suckless software, except this time for an actual reason.
Distro maintainers are the culprits of giving you a ""bloated"" systemd

systemd is slower than runit and s6 and sometimes even openrc. You can stop embarrassing yourself though.

>boot times of my anime desktop are performance benchmarks
>i don't know what it is or does so it should not be included in my anime desktop
>heh, that sure embarrassed him

Is this the best systemd shills can do? Sad. Most of you pretend like sysvinit is the only other init system in existence and that systemd invented all of these fancy new things even though most of its ideas are just copied from Apple's launchd.

success speaks for itself, all critical systems use systemd anywhere

how much does canonical contributes back to debian? is the outlook really that bad for the project's future?