SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Slackware hasn't changed and it doesn't look like it will change, certainly not any time soon.
Why? If such an intrusive, and I mean by that only that it touches many things, change was to be brought in it would be very early in any release cycle.
It hasn't, so we can probably say that it isn't going to happen for the next release.
But what if it happens for the next release after that?
Well, let's look back a bit, actually quite a bit. 15 years. Look at Slackware 3.9 and 4.0. Two releases at the same time, one a point release on the old and proven the other a step into the then unknown. So even then there could be a 'traditional' Slackware to keep the last of us going a bit longer while we see how things develop.
OK, so what if the release after the next release uses systemd?
Again, what's the panic?
A change in Slackware tomorrow won't suddenly invalidate the Slackware we have on our computers today. Slackware provides security updates going back several years, a quick glance shows that Slackware 13.0, a release from 5 years ago, getting security updates.
There is no rush, there need be no panic.
But what if I want to run foobar-3.1.5 ?
Well, look outside Slackware, no I don't mean away, outside.
Just as a few examples, V.Batts maintains PAM packages, Ivandi maintains PAM and NFS4, Alien Bob maintains packages for just about everything. All that and there are all the SlackBuilds, both those in the Slackware source and those on slackbuilds.org to use as examples.
So even if the package you want or need to stay shiny and new isn't in the next Slackware release, someone, somewhere has probably had a crack at it and a package or slackbuild script is available.
There is no rush, there need be no panic, we don't need the lifeboats anytime soon.
Last edited by OldHolborn; 11-27-2014 at 02:41 PM.
Reason: typos & grammar
Some change was unavoidable such as udev versus devfs, but udev wasn't intrusive and actually tried to help make GNU/Linux less painful to operate. Devfs had a number of problems that never were solved. One of which was device mounting allocations. Yes, devfs had rules, but most stuff even with hald, required some manual setup. Udev stayed out of the way, kept itself to it's own process tree, didn't try to go beyond it's design and intention, and even though it sometimes became a royal pain in the ass, it worked for the majority of the time, and does work.
However, some change isn't good. I think too many people have fallen into the aspect of "If you give a mouse a cookie..." mentality, to where they have one level of automation, but want more and more, because they want GNU/Linux to be more like Windows.
Of course cgroups is an interesting trade-off, whereas one gets effective tracking at the cost of portablity.
Thankfully there is now an independent implementation of the "one cgroup daemon to rule them all".
I don't understand what you mean. Or let me put it this way: as much as I understand what you are saying, so far you are completely in line with how I described this thread.
Quote:
Quote:
And sure, the binary logs are largely a non-issue, since "the system administrator may choose whether to log system events with systemd-journald, syslog-ng or rsyslog" [wikipedia]
That's absolutely not true. This is the peril of quoting Wikipedia as an authoritative source You cannot run systemd without systemd-journald, and you cannot run systemd-journald without systemd. This is because systemd is not modular. It is the opposite of modular [2]. systemd-journald will pass events to syslog-ng or rsyslog downstream, but systemd-journald has to be in charge, with all its overheads (its maintainers admit it's slow; they're working on it).
OK, so we get binary logs AND text logs at the price of some overhead? Can I describe it as not a big deal? How about not the end of Slackware? How about not the end of the world?
Quote:
Quote:
and even beyond that, systemd can always be patched if enough people desired it.
Again, I don't have a good idea what you are saying. May be it's my ignorance. I do, however, understand one or two things about free software. And as long as systemd is free software, and as long as there is enough outrage and popular desire to make it better, there will be a clear path to patch it or fork it to do whatever the heck we want. In particular, making it produce text logs does not seem like an unsolvable riddle.
Don't count me as systemd defender. I don't know enough to have an educated opinion about it. I think Lennart & CO are notoriously bad at communicating, or even documenting, so they shouldn't be surprised at the push-back. However, I am squarely in the camp that doesn't see systemd as a big deal. I would most likely continue to use Slackware, systemd or not, and my further decisions would be based on how it performs: not systemd, but Slackware.
I preferred ipfwadm over ipchains, so much simpler
Quote:
Originally Posted by ReaperX7
I think too many people have fallen into the aspect of "If you give a mouse a cookie..." mentality, to where they have one level of automation, but want more and more, because they want GNU/Linux to be more like Windows.
Agreed, it's the popularity problem. Like a startup commercial radio station that initially concentrates on Country and Western music, it does and is popular but to expand and spread the good tunes it needs money, money provided by adverts. To get more adverts you need more listeners and so the temptation is to go more mainstream. Before you know it, that sometimes idiosyncratic little radio station that played some really great and sometimes obscure tunes is now a clone station pumping out the exact same playlist every hour as every other station.
I think though we can quite happily say, without a doubt, Slackware has avoided this trap.
I think though we can quite happily say, without a doubt, Slackware has avoided this trap.
Agreed. Slackware 14.2 will not have systemd. That is my prediction. I am happy and proud that our distro continues to be exceptionally well-designed and maintained.
Agreed. Slackware 14.2 will not have systemd. That is my prediction. I am happy and proud that our distro continues to be exceptionally well-designed and maintained.
Are 'agreed', 'proud', 'designed' and 'maintained' new systemd facilities I have not heard of yet?
I'm afraid (oops) that all words ending in 'd' may soon become trademarked (oops) by some well known Linux company...
But what if I want to run foobar-3.1.5 ?
Well, look outside Slackware, no I don't mean away, outside.
Just as a few examples, V.Batts maintains PAM packages, Ivandi maintains PAM and NFS4, Alien Bob maintains packages for just about everything.
It's not that simple. Especially for PAM. It's too intrusive. Even more than systemd. Maintaining a parallel PAMified core system doesn't worth it. It will only help to further marginalize Slackware to the point where it's only suitable for setting up a "network" in the City Hall of Saint-Profond d'Arrière. Users who really need PAM have abandoned Slackware long ago anyway.
Maintaining a parallel PAMified core system doesn't worth it. It will only help to further marginalize Slackware to the point where it's only suitable for setting up a "network" in the City Hall of Saint-Profond d'Arrière.
How does forcefully pushing out viable projects for systemd only software help GNU/Linux and non-Linux systems? Change for the sake of change isn't beneficial Tobi. You're basically saying that "It's not broken, but we'll fix it anyway, and say that it's broken, but only to our design."
Why should projects like Gentoo even be on a six month notice to come up with an alternative? The alternative is distribution after distribution standing up to Lennart and crew, saying a big public "no".
Didn't we already discuss that change, coding, and doing things for the sake of doing them when nothing is wrong, broken, or in need of repairs, bad on all levels and should never be done by anyone sensible or sane, and trying to force those issues only gets you a gigantic pushback that hurts you worse in the end?
It is simple as that: upstream makes a change, downstream has to adapt or search for a different solution. This happens all the time in open source software, udev is nothing special. The nice thing that upstream can do is to make downstream aware of this and give downstream enough time to adapt or search for a different solution. Just saying "but we, a tiny part of downstream, don't want that change" will make no difference. You don't want it? So what, stop discussing the change and go to work, fork and do it how you think it should be done, or help alternatives to actually be a viable alternative.
I've often wondered what "political correctness" would mean for software, and now I see how truly bad being politically correct with software is and what is has done to Linux.
Forcing GNU/Linux to remold itself into another Windows-wannabe to try and compete for a desktop marketshare it will never have, is futile. I honestly remember Windows users talking about trying out Ubuntu because it was the most Windows-like GNU/Linux distribution back when Vista was being put through the grinders, and yet does GNU/Linux still have a marketshare on par with Windows or OS-X? Not even close.
All I know is, I do not want to use CoreOS on any level, nor do I want to use any Red Hat operating systems. I've been there, done that, and would like to avoid going back to it at all costs. My experience with Red Hat was one most foul.
Just because Windows has the highest desktop operating system marketshare doesn't mean anything. It only means Bill Gates was that much more clever a salesman than Steve Jobs, Linus Torvalds, and Richard Stallman were, or maybe ever could be. It also doesn't mean GNU/Linux has to dethrone Window or try. GNU/Linux users have been plenty happy over the years to use an alternative system for free, the same as BSD users.
The biggest flaw GNU/Linux faced or faces, is not an init problem, a service management problem, or any other issue claimed by Red Hat, Sievers, Poeterring, or any one else. The biggest flaw of GNU/Linux is the lack of willingness by commercial companies to develop software applications, games, utilities, etc. for GNU/Linux and BSD systems. Only one company sought to end that flaw by redeveloping commercial ports of software, namely Loki, and they didn't last long at all because nobody helped, funded, or contributed to them to further their efforts.
Even if we did get CoreOS or GnomeOS, or whatever systemd-esque-OS out there, it's not going to be able to compete if it has no software for it if companies turn their nose up at it.
Windows has a huge marketshare because of Gates marketing it, but also because companies wrote software for it, the same with Apple, Steve Jobs, and OS-X with their smaller marketshare, but if GNU/Linux gets no ports, it's not going to even get looked at. Free Software is nice, looks good on paper, and is budget friendly, but companies who write software, are going to want to make money, and while the GPL does grant the right to profit, it exposes trade secrets, and no company out there with a monopolized market is going to reveal trade secrets by using a GNU software based for development, so if systemd is going to solve any "problems", why can't solve that problem, the biggest, longest running issue of GNU/Linux?
Seriously, if you think that the goal of systemd is to make Linux on the desktop more succesfull how do you explain that most of its features revolve around server stuff, virtualization and containers?
And what has a lack of marketing for Linux as a desktop OS to do at all with systemd?
I have a question about systemd's use of binary log files.
C finds the end of the file and appends the data - no difference between binary or text except for the extra char conversions for a text file. So I don't see the big advantage of binary over text "logs".
Text "config" files on the other hand, if binary, could be pulled directly into a struct but a text config file has to be parsed.
But LP defends binary logs yet has no issue with text config files. So why does systemd do it this way?
The systemd journal does not just translate logs into binary, it adds signing and indexing to the mix.
Seriously, if you think that the goal of systemd is to make Linux on the desktop more succesfull how do you explain that most of its features revolve around server stuff, virtualization and containers?
And what has a lack of marketing for Linux as a desktop OS to do at all with systemd?
first it was marketed as "we make desktop not suck"
then it was "it was all for teh servers"
now its "we are making the core of modern linux"
At what point does GNU/Linux cease to exist and become something else?
Simple question, simple answer: GNU/Linux is not GNU/Linux anymore when you remove either the Linux kernel or the GNU userland. Example for that are Debian GNU/kfreebsd (GNU userland on non-Linux kernel) or Android (Linux kernel without GNU userland).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
You cannot run systemd without systemd-journald, and you cannot run systemd-journald without systemd. This is because systemd is not modular. It is the opposite of modular [2]. systemd-journald will pass events to syslog-ng or rsyslog downstream, but systemd-journald has to be in charge, with all its overheads (its maintainers admit it's slow; they're working on it).
