I don't have a big problem with people trying something different, if older versions are maintained (security patches, that sort of thing), until it's established the new way is a step forward.

With regards to systemd, if it does turn out in the end to be a big mess then having distros which haven't adopted it may be beneficial.

But I'm not convinced by the level of argument in this thread so far. More systematic studies, less of the anecdote and rhetoric would be helpful.

2 members found this post helpful.

libcgroup

Which you'll find in Slackware already.

1 members found this post helpful.

A lot of the problem with software today is the willingness to release software that is not finished or not sufficiently tested. Also, distros include that software far too soon. It does help when releases are clearly identified as "stable" or "unstable" but often "stable" releases are not that well tested and include much experimental software.

Two programs that I use frequently come to mind. VirtualBox and Paragon Hard Disk Manager.

VirtualBox is an excellent virtual machine program except that there is no single release version where everything actually works. I always use older versions that are only being changed to include bug fixes. Even so I have to live with some bugs that are never going to be fixed. Using the current versions is a gamble, because each release has different bugs. I will give Oracle credit for listening to their users and continuing to do bug fix releases on the previous major version of the software. For example, 4.2 is the current version, but bug fixes are still being done for 4.1 in parallel. Essentially the previous version is the "stable" version.

Paragon Hard Disk Manager has some great features including the ability to do image backup and partitioning for both Linux and Windows. Unfortunately it suffers from adding "features" frequently to justify customers buying new releases. The biggest problem is the rescue disk, that started out being Linux based and is now based on Windows PE. If one wants to build their own rescue disk, with drivers for their hardware it is difficult. Part of that is because Microsoft no longer allows Paragon to distribute pre-built rescue disks based on Windows PE. Paragon also did not document the build process well, nor make any provision for customization. The software requires a lot of special settings to work on Windows PE (all undocumented). Because the rescue disk is just one bullet on a feature list, improving it does nothing for the marketing buzz and it is not a priority. After implementing all the obvious features, what is left are esoteric and complicated features that tend to break the software at every release. I'm still using the 2010 version any trying to get around enough of the problems in the 2012 release to use it.

A friend and I used to joke about letting software, like wine, age, and then picking the old but good software. I still think that Slackware 12.2 was one of the best releases ever.

2 members found this post helpful.

I agree! Everything around that time seemed to "just work."

4.1.24 works quite nice actually. Here's a link to the build scripts:

https://github.com/kikinovak/desktop...0/extra/source

And is libcgroup broken to where it needs replacing?

I think realistically Linux needs break this cycle of Sisyphean-syndrome, and do code freezes every 3rd quarter across the whole spectrum of the GNU core OS and Kernel. Stop for 3 months, do only maintenance and bug patches for the 4th quarter, and accept no new code or projects until after the 2nd quarter of the following year giving them 1 whole quarter to work on their project, and 1 quarter to present their project, but under extreme scrutiny from a "Linux Consortium Board of Regulators" consisting of well established leaders in the Linux world at least a panel of 12 with an elected chairman, and have a rule that unless a unanimous vote to include a software project into Linux is acceptable for world-wide usage, no distribution or project can force it's wills or goals upon another.

This could lead to establishing a realistic Linux Software Certification Committee in which core and key projects to Linux could have some level of stability across the spread-spectrum, while keeping free software and open source principles in mind, and well as leaving enough room open for change and flexibility, yet enough control to ensure nothing gets out of hand.

The only software affected by this Committee and Board only would be key core software like INIT systems, the GNU tools and software, and the core libraries of the underlying system itself, and the kernel of course.

Isn't this what FreeBSD does, and look how stable FreeBSD is thanks to this.

That's what I'm using at the moment. The only thing that doesn't work for me is the seamless mode for a Linux guest (Slackware 14 + KDE 4.9) running on a Windows 7 64-bit host. I also get occasional hangs of my Windows XP guest OS though they are infrequent.

I tried 4.1.26 but the hangs on the Windows XP guest are much more frequent.

I agree, but for me it was Slackware 12.1, with selected updates from later releases, and a few rebuilt packages.

It was not just good, for my uses it was exactly perfect! I created my own local archive of 12.1 plus everything I added or changed (including sources and patches) and fairly complete notes from the first install to all subsequent installs and additions. From that I have managed all my own machines and quite a few others without incident until now.

I call that my "beachhead" distibution - I could rebuild everything from that if the world burned tomorrow...

A few months ago I added my first 64 bit system and have settled on Slackware 14.x as my next beachhead target. With it I have been following -current closely for the first time and have come to use - and like - slackpkg!

I hope that 14++ proves to be as long term sustainable as 12.1 was for me!

There is a lot to be said for carefully selected vintage software!

[EDIT]
Posted from my perfect 12.1 personal system!
[/EDIT]

1 members found this post helpful.

14.0 has been a good system for me. It took me some time to get used to the whole 64-bit software notion and the multi-lib aspect, but honestly, after a few weeks, I noticed I didn't need 32-bit software that much anymore, Slackware was stable enough for my needs, and the direction Slackware goes is always one that it seems spills over into other back-to-basics Linux distributions like Gentoo, LFS, and others. Keep it simple, smart, and keep the learning curve high enough to that much more beneficial to the normal end-user and system administrator alike.

If you permit my humble opinion, while i am not against change, i think systemd doesn't offer much and unfortunately it is forced on everyone's throat like much other software.

The thing i dislike about the devs' promotion is that they give misleading info and present the facts as it suits them. For example:

In the Why page, we read that systemd supports a gazillion things and in the above quote we read that it only requires three libs. We can of course compile it with only these three dependencies but then it will not be able to support all those things. So it either supports only a few things or it is indeed feature complete but it requires a lot of libs.

Also, i guess that the majority of distros will enable many dependencies in order to be feature complete and cater for every user's needs. Any user can of course rebuild systemd but the majority will use the package provided by their distro so the "anyone can choose the level of bloat" argument doesn't stand.

Is this an argument ? First I make someone's life difficult and then i blame him. If systemd was portable, maybe the BSD folks would adopt it. Or maybe not but as it is now they don't have a choice.

I genuinely believe that this is not a myth This is another complaint of mine. Someone makes some arbitrary change and then blames others for "engaging in bad practice" using the old behavior.

Let's consider for example the "separate /usr" thing. It worked for years and now we are forced to abandon it (or mount /usr through initramfs). In a forum discussion i got the response "having a separate /usr is bad practice and you shouldn't do it. why do you need a separate /usr ?". Perhaps wrongly, it is my belief that when somebody wants to make a change, HE is the one that should have arguments in favor of the change and not everyone else against it.

Ok i admit that udev hasn't worked fully since some time but it works in many scenarios (on my box i only get an error when udev tries to run alsactl to restore the volume but i don't mind). Even when the functionality is necessary (a wireless card or something), the 2-3 binaries needed could be moved to /sbin instead of robbing users of a choice they had for years.

The same thing goes about binary logs. With a simple text log you can do many tasks (like view or search or anything) quickly and without needing any special tool. You can even setup an old dot-matrix line printer you had lying on your basement to print the entries as they show. But no, everyone engages a bad practice with text logs and they should be binary.

Excuse my rant and thank you for your time.

7 members found this post helpful.

only that this model is borrowed from the world of corporate software and it goes against the ideas of open source, like "release early, release often". A good read on this is "The Cathedral and the Bazaar" by Eric S. Raymond.

1 members found this post helpful.

What's Systemd's bus factor? One? Anyone care to rent a bus?

Sorry, you lost me at "Regulators."

But seriously, this isn't necessarily a bad idea on its face, as far as the core system components go, but I think what we have now works pretty well, if we can keep the Red Hats and people like LP from trying to force their "solutions" down everyone's throat. I mean, we are free to use something like Slackware, it is very clean and stable, and others are free to use their perpetual beta software such as Fedora and Ubuntu. To each their own. But there does seem to be a creeping tendency in Linux towards sometimes questionable consolidation and standardization, with the Unix philosophy often being the casualty.

Commercial applications need standardization. This is always going to be at odds with the open source philosophy that allows everyone to make changes to the software they use. Inevitably some of those changes will make the software incompatible with some other software.

There is one commercial application on which Linux depends heavily, and that is personal computer hardware. This problem is addressed partly by Linux including drivers for the most crucial hardware such as the processors, chip-sets and mass storage. However, it is desirable for manufacturers of other PC hardware to provide Linux drivers. Having some standards for binary driver compatibility would be an advantage for Linux. Without the Linux community establishing some organization to create standards, there will always be commercial interests trying to assume that role. Many manufacturers chose the de facto standards of SUSE and Red Hat. Some may have recently chosen Ubuntu. One can argue that a lack of binary standards encourages companies to release the source code, but it also may discourage companies from releasing any Linux compatible software.

The idea of systemd is not a bad one. Promoting it is a bad idea. Good software does not need to be promoted, especially if it is open source. If it's good and useful, people will start using it. Thus, I believe if we simply resist the promotion, the rest will take care of itself. Each distro will evaluate systemd and decide if and when it is time to use it. The more conservative distros such as Slackware will wait longer and watch how well systemd works for the "bleeding edge" distros.

Some may fear that systemd will be adopted by most distros and leave other distros with no choice. Isn't that really the same situation as Desktop Environments? We have two major DEs, KDE and GNOME that dominate, and applications often depend on one of those. One can argue that UBUNTU has the third major DE. Yet, there are still people choosing to use other DEs. Some people don't care about boot times, and some people don't even care about dynamically creating device nodes. So, there will certainly be people who are happy without systemd.

Where does Slackware fit into all this? Slackware has often chosen to go in a different direction than other distros in order to provide an alternative. Until recently Slackware was unusual in not having GNOME and including KDE. I don't think that systemd has to become a part of Slackware for it to succeed. In fact, I would argue that Desktop Environments are the key to Slackware's future success or failure. Does KDE still meet the goals of Slackware? Could GNOME, XFCE, or some other DE better meet those goals? If KDE does not succeed in the long run, where does that leave Slackware? I believe that strengthening support for at least one other DE besides KDE is important for Slackware. The obvious ways to do that are by providing compatible applications, a well thought out default configuration and documentation to help users configure and use the other DE. KDE help is pretty good, but seems to have lagged behind the software. By that I mean what is there is usually correct, but it lacks breadth and depth. Other DEs may have less help, and probably need less. Still, it may take extra effort to make another DE be a viable alternative to KDE in Slackware.

One of the dangers of systemd is that it may become a distraction from the real issues driving the success or failure of distros. If and when KDE requires systemd, then I think the issue becomes important, and the same is true of the other DEs that Slackware may consider important to its success.

The server world may have totally different issues. There, the DE is less important and systemd could become a requirement for some services. If software developers are smart, they will avoid making services depend on systemd. Slackware could actually distinguish itself by being a reliable distro that does not use systemd. Not only would that provide system administrators an alternative to systemd, it would provide developers of services a way to test their software on an OS without systemd.

5 members found this post helpful.

Agreed. I'm a huge fan of the DE/WMs included with Slackware, but I think another DE would be a welcome addition to Slackware. I really like the work that chess and willysr are doing with MATE. Just a thought.

1 members found this post helpful.