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.
Let's move on to something non-controversial, like gun control or abortion.
Continuity of a well defined system model being necessary to the continuing use of a free Unix-like operating system, the right of the users to keep and use SysV-init shall not be infringed.
Let's move on to something non-controversial, like gun control or abortion.
I'm a newcomer to Slackware; in my opinion Mr. Volkerding makes sane decisions with regard to changes to our OS. I honestly do not worry about the development pathway of Slackware.
I think an argument could be made that replacing the core foundation of an operating system with something completely foreign changes the very nature of the operating system itself. That's the problem. I think I'd rather have Linux remain Linux.
I think an argument could be made that replacing the core foundation of an operating system with something completely foreign changes the very nature of the operating system itself. That's the problem. I think I'd rather have Linux remain Linux.
The nature of Linux does not change at all. Linux is a kernel based on the concepts of the Unix kernel, like being monolithic (kernel address space is part of current-process address space and vice versa), "everyting is a file" (within reason) etc.
What does change is the nature of those distributions changing their user space to systemd. I see it as an experiment at this stage and i am open to the outcome.
I'm not exactly a fan of the gentleman in question, his ideas or his software, but this kind of excessively personal, if not defamatory, rhetoric reflects badly on us as Slackware users.
Thank you for the voice of reason. I appreciate feedback like this because it enables a user community to get things under control without calling upon the moderators.
Thank you for the voice of reason. I appreciate feedback like this because it enables a user community to get things under control without calling upon the moderators.
Claiming that the comments of a given Slackware user reflects badly on other Slackware users is hogwash.
The only common denominator among Slackware users is that they use Slackware. I would be honestly surprised if I had many other common characteristics with other Slackware users. (Other than being a human being of sorts.)
The nature of Linux does not change at all. Linux is a kernel based on the concepts of the Unix kernel, like being monolithic (kernel address space is part of current-process address space and vice versa), "everyting is a file" (within reason) etc.
What does change is the nature of those distributions changing their user space to systemd. I see it as an experiment at this stage and i am open to the outcome.
Yes, of course Linux is defined by the kernel and the kernel does not change. That is why I referenced elvis4526's original statement and used the word "since." He stated that the goal was to have systemd be "the core foundation of an OS." I made no analysis as to the accuracy of that statement; I only expressed something that would logically follow from it.
It was basically an if > then statement.
Even so, I think the idea is not too far off, even if it is not technically accurate.
Continuing to bicker about the ultimate conclusion to a slippery slope argument is rather pointless, don't you think? I don't think there has ever been any evidence anywhere in the universe to suggest that systemd will start adopting gnome components...but of course, you 'read it in passing' and have forgotten the link (which, if it actually was said, was by another person taking the slippery slope argument to its most extreme conclusions). There is no way systemd will suddenly become dependent on gnome, and as for the reverse, it won't happen immediately (as previously indicated) but no one really knows what the future holds (and thus debating the point is moot until some sort of action or serious discussion by gnome devs actually takes place). I don't think anything has changed since the last big systemd thread, so I think threads like these are a wasted effort until udev is officially integrated into systemd without the option of compiling it on its own. When that happens (and Slackware is no longer able to keep using an older version of udev), then a discussion would perhaps be warranted.
Just my opinion, of course, but if you enjoy arguing over unicorns you can keep at it.
So the thread is pointless and the discussion is wasted effort, but a long post detailing why this is so is not?
Get real. RedHat as the only remarkable corporation profiting from Linux (not counting much weaker SUSE) whole time of its existence just tries again and again to push their plans to fortify its dominant role on this market. Nothing surprising. It does not matter if there are working, proven, reliable solutions already. Add the widespread NIH syndrome and you get an idea.
Systemd not only replaces working initd & scripts, it also replaces working syslog (you can still use for now), working acpid (you can still use for now), working cron (you can still use for now), working xinetd (you can still use for now) and lot of system settings they just do reliably work called from SysV/BSD init scripts. Become aware Gentoo and Slackware are the only distributions not adopting systemd or intend to. Even relatively conservative Debian is going to use it. It does mean it becomes de-facto a standard upstream will rely on. It would be very hard to avoid it in the future and keep up with other init system - just not enough programmer forces. Even Free/Net/OpenBSD systems will be affected by 3rd party applications primarily developed on linux systems like some desktop apps. RH finances or contributes to so many projects including GNOME, Xorg, Glib, Gtk, D-bus, coreutils, util-linux-ng, kernel fundamental changes are to be expected to reflect above mentioned situation.
Although not agree what direction takes Linux and opensource projects around it I'm accepting it just as a fact. On the other hand I'm sad how much people lose to manipulation or are short-sighted. It does not apply only to software, of course.
There are no plans for Debian to adopt systemd as default init system.
They do a lot of work to adopt it, see FOSDEM 2013 conference record and Debian's wiki. Core Debian devs are well disposed to systemd. See their mailing lists. I did not write it is or will be in the next release their default init system. So far. It's just a matter of time and pressure of related/surrounding projects.
Systemd not only replaces working initd & scripts, it also replaces working syslog (you can still use for now), working acpid (you can still use for now), working cron (you can still use for now), working xinetd (you can still use for now)
Are you sure about this ? This seems to run counter to the Unix approach of having small programs that do only one thing but cooperate with each other. Using a configuration file for what to start at boot time instead of
running shell scripts already introduces some inflexibility, but having a single daemon to replace init, control logging, networking, power management and scheduled jobs looks like a recipe for disaster. Just imagine that
the daemon crashes because of a network problem. You don't have an init process on your system, you have no power management, and you have no log to tell you what caused the crash. There must be some modular structure in systemd
so that if one component crashes, it won't take all the others down.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
