Wow... nice first post... but whatever dude. Try harder next time with trolling.

Also, please do not impersonate real people in attempts of defamation of their reputation. I don't like Lennart's policies and idealisms, but I'd never stoop to impersonating him to make him look bad and foolish, and respect him enough on some level to acknowledge he is a human being and deserves that much respect in the least.

I'd like to point out and get back on topic, our work over at LFS with Runit is getting close to being completed, and with some extra effort, a port could be made for Slackware. This would give an alternative to Slackware's bsd/sysvinit that's complete and viable. Because fairly much everything in Slackware is booted using /etc/rc.d/rc.S, Slackware probably wouldn't require as extensive a script conversion, except for /etc/rc.d/rc.M which would be replaced by the run scripts. If anyone would be interested in this effort the work is freely available.

1 members found this post helpful.

//Not trolling

ReaperX7,
I respect you for being an active and senior(than me) member of Slackware community but this is some hypocrisy of yours here, unless you had some kind of memory loss recently. If my memory serves me correctly, you announced LP as a narcissistic megalomaniac and a sociopath not really long back.
(No offense but this is the first time I'm quoting you.)

Regards.

2 members found this post helpful.

It's called point of view towards his policies and a look into the reasoning behind it. Plus it's no secret Lennart has his human flaws. We all do, but the problem is too many people tend to blindly agree with those policies and get sucked into the notion there is a major problem when no problem exists, or the problem is minor.

The facts are there are too many ill informed fan-boys out on a propaganda campaign that don't understand the basic principles of UNIX and proper implementations of software across a spread-spectrum of platforms within platform independent standards of implementation and only are worried about one factor of systemd that isn't even it's defining feature, the boot time. Systemd isn't the only parallel boot init system out there. OpenRC, s6, Runit, and Upstart all can perform parallel booting of services, and even with some script modifications, sysvinit can also. In fact just about every parallel boot init system out there has about the same speed of boot. The real defining feature of systemd is it's service management, but it's not the only init with service management features.

I question a lot about systemd such as why it requires being a dependency to many services, and why we have to have binary logs that are not only system proprietary, but software proprietary. To me, even whittled down to the bare minimums systemd still has too much invasiveness for my tastes.

The only other thing I question is why such the big push to have to have it? What overall long term problems does it solve? How does package XYZ that was modular and unrelated to systemd, differ from the equivalent package now part of systemd? Why can't more things be modular? Is feature ABC really necessary to having a working system?

These are questions that, honestly, have not been answered clearly and concisely by anyone either pro or con systemd.

This is why I got involved with porting Runit, to seek out a sane solution that adheres to UNIX principles, isn't mainstream, is simple, and doesn't overshoot it's purpose of being an init system, and only an init system.

5 members found this post helpful.

In case someone still wonder, our BDFL knows the web page mentioned in the first post of this thread.

Amazingly, Pat's tweet date back 26 Apr 2014, but initial post from Moisespedro is dated 28-05-14

New features supporting "factory-reset", including automatic creation of system users/groups and the population of empty /var and /etc:
http://0pointer.de/blog/projects/stateless.html


This is the bit that jumped out at me:
mtime of /usr can change for any number of reasons, and not all of them may warrant triggering the update services. I would have thought checking mtime on something explicit like a /usr/.NeedsUpdate would be far more reliable.

1 members found this post helpful.

GNU/Linux has never been about forcing one particular piece of software on everyone else. There are alternatives, forks, etc and that's how it's supposed to be.

Slackware won't "die out" because it has a very strong following who use it precisely because of the decisions taken by PV.
If you don't know about other init systems, that means you're not really qualified to troll on the subject.
Anything else? Weather predictions perhaps, could use some sun here...

2 members found this post helpful.

The UNIX principle over and over again. The only thing that I can see that may be against the UNIX principle that I can see is that DBUS is used for communication, not text streams. Which other "violations" of that principle do other people see?

2 members found this post helpful.

Arrogance lifted to the next level:
A systemd developer should not make assumptions about what the packaging software should do. These guys do not care for anything but their own agenda. What happened to the words "optional", "compatible" and "interoperable"...

Eric

10 members found this post helpful.

Yup. FOSS is all about having the choice to run software that meets your needs, not having it shoved down your throat. I'm happy that Mr. Volkerding is taking a wait and see attitude with regard to systemd.

On factory reset in systemd:
I truly do not understand the need for this on consumer systems (it may be useful in commercial settings, but I will address the above specifically). Why wouldn't you just reinstall like a sane person? Why are they trying to turn a full computer into an appliance? How often does your system break solely because you messed up /etc or /var? It seems as though they have a need for this stuff in massive container systems, and they are trying to justify it (and make it look sexy) on consumer systems too as a selling point (and induction to get upstream to change everything that they desire, since this requires changes on many levels from basically all upstream software ever). They could just be honest and admit this has little utility for a consumer system, but I guess then upstream projects may not be as eager to adapt...

Slackware "died out" numerous times already for not adopting RPM, not adopting APT, not adopting PAM, not adopting GNOME, not adopting udev>182, not adopting whatever. You know, you're talking about the oldest still surviving Linux distribution? You're on CoreOS, what is your concern with Slackware anyway?

5 members found this post helpful.

Expect systemd-packaged (a disguised RPM) to be introduced along the way and become the only packaging system allowed for CoreOS. "Unifiying" everything and still letting distro people play around with apt/dpkg and stuff doesn't seem logical to me. I have my popcorn reserves ready, when that hits. And they thought, they just imported an init replacement...

I strongly recommend reading this section in its entirety:

http://en.wikipedia.org/wiki/Slackwa...ign_philosophy

This philosophy has kept people coming back to Slackware for more than two decades, and there is every reason to believe it will remain a source of strength for decades to come.

1 members found this post helpful.

Hello,

From here. Not really (or entirely) on topic, but I can't resist :

--
SeB

4 members found this post helpful.

so long skype, and thanks for all the fish

6 members found this post helpful.