Nonstarter, sorry.

2 members found this post helpful.

And glibc-2.28 still in /testing?

I think , 2.27 go to /pasture , and 2.28 as default in some moment.

SQLite 3.25
Release notes: https://www.sqlite.org/releaselog/3_25_0.html
Source: https://www.sqlite.org/2018/sqlite-a...3250000.tar.gz

Can confirm I'm using it without issues.

dmidecode-3.2
http://download.savannah.gnu.org/rel...ode-3.2.tar.xz

1 members found this post helpful.

Good!!

Everywhere I've worked, whenever they decided to start using SELinux, they regretted it. It does little to improve practical security, but regularly caused problems in production which were hard to troubleshoot (in part because it was seldom obvious that SELinux was the cause).

Two years ago my current boss announced that they we going to start using SELinux, and I pitched him my argument against it, citing problems at other companies. He and the senior sysadmin assured me that that was "old, bad SELinux" but the "new, good SELinux" didn't have any of those problems.

So now we use the "new, good SELinux" and sure enough, mysterious errors pop up in production which tie up multiple admins for hours or days. They skritch their heads and try different things until they find out that yes, again, it was SELinux preventing our software from doing what it needed to do (mostly permissions to write or create files).

I've avoided saying "I told you so" .. but might have snarked on company IRC once about how a problem couldn't possibly be caused by SELinux, because my boss assured me that such problems didn't happen anymore.

It gladdens my heart to hear SELinux in Slackware is a nonstarter. One fewer thing to worry about.

4 members found this post helpful.

For the record, I did not ask to implement either feature. I only asked "Are there any technical reasons not to enable apparmor/selinux in the kernel?"

I am aware that apparmor is provided at slackbuilds.org, although users must compile a new kernel to use the package.

While Pat politely answered he is not interested, the original question has not been answered. I'm fine if there are no technical reasons -- and the only reason is lack of interest or complexity with little return on investment for most users.

I'm not fanboy of either technology. Just curious if there were technical reasons both are not supported in Slackware. Probably should have been a new thread.

2 members found this post helpful.

Linux security definitely has some strange ideas. Instead of minimizing layers and layers of crap to improve things and thus security, they just keep on adding crap, that smaller and saner distributions have to fight back to stay manageable. It's becoming harder and harder, but we shall prevail.

1 members found this post helpful.

feature creep is real - set aside all complicated explanations - its likely a conspiracy.

xorriso-1.5.1:

https://www.gnu.org/software/xorriso...o-1.5.1.tar.gz

Everyone talks with serenity about the future "must" inclusion of Qt5, even in the light of current statements, the Plasma5 hog itself may or may not be included in Slackware.

BUT, the Qt5 itself is so fat that it chewed the Chromium as WebEngine.

So, if the perspective is to include anyways the Chromium as part of Qt5, I wonder why not to add the Chromium itself to Slackware?

After all, the Chromium is a fine web-browser and a shiny alternative to Firefox.

1 members found this post helpful.

I would be onboard with this. I'm not sure if Chromium fits well with Slackware's stable release model, though, since it appears Chromium puts out a new major "stable" release every 6 weeks.

Not everything on Slackware has LTS releases, you know...

Well sure, but browsers need security updates, and Chromium doesn't seem to have a mechanism for that outside of just releasing a brand new major version every six weeks.