LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Closed Thread
 
Search this Thread
Old 05-09-2013, 04:11 AM   #76
commandlinegamer
Member
 
Registered: Dec 2007
Posts: 80

Rep: Reputation: 12

Quote:
Originally Posted by kite View Post
I totally agree with you... This is a very bad situation for Linux. Developers need to make sure things work and work well instead of changing things so dramatically and frequently.
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.

Last edited by commandlinegamer; 05-09-2013 at 04:29 AM.
 
2 members found this post helpful.
Old 05-09-2013, 05:46 AM   #77
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 226Reputation: 226Reputation: 226
Quote:
Originally Posted by ReaperX7 View Post
Edit: BTW, nobody answered my question regarding what currently controls cgroups outside of systemd. Is cgroups currently controlled by the system shell?
libcgroup

Which you'll find in Slackware already.
 
1 members found this post helpful.
Old 05-09-2013, 01:19 PM   #78
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 793

Rep: Reputation: 245Reputation: 245Reputation: 245
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.
Old 05-09-2013, 01:40 PM   #79
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,476

Rep: Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531
Quote:
I still think that Slackware 12.2 was one of the best releases ever.
I agree! Everything around that time seemed to "just work."
 
Old 05-09-2013, 02:36 PM   #80
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: ElementaryOS, Ubuntu LTS, Slackware
Posts: 1,497

Rep: Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682
Quote:
Originally Posted by Erik_FL View Post
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.
4.1.24 works quite nice actually. Here's a link to the build scripts:

https://github.com/kikinovak/desktop...0/extra/source
 
Old 05-09-2013, 04:42 PM   #81
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,860
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
Quote:
Originally Posted by wildwizard View Post
libcgroup

Which you'll find in Slackware already.
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.

Last edited by ReaperX7; 05-09-2013 at 04:45 PM.
 
Old 05-09-2013, 05:01 PM   #82
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 793

Rep: Reputation: 245Reputation: 245Reputation: 245
Quote:
Originally Posted by kikinovak View Post
4.1.24 works quite nice actually.
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.
 
Old 05-09-2013, 06:12 PM   #83
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.1, 14.1, 64-14.1, -current, FreeBSD-10
Posts: 1,658

Rep: Reputation: 570Reputation: 570Reputation: 570Reputation: 570Reputation: 570Reputation: 570
Quote:
Originally Posted by Erik_FL View Post
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.
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]

Last edited by astrogeek; 05-09-2013 at 06:14 PM.
 
1 members found this post helpful.
Old 05-09-2013, 09:17 PM   #84
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,860
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
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.
 
Old 05-11-2013, 10:28 AM   #85
imitheos
Member
 
Registered: May 2005
Location: Greece
Posts: 374

Rep: Reputation: 55
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:

Quote:
Myth: systemd is bloated.
...
As mentioned above, systemd is also pretty modular. You can choose at build time which components you need, and which you don't need. People can hence specifically choose the level of "bloat" they want.
When you build systemd, it only requires three dependencies: glibc, libcap and dbus. That's it. It can make use of more dependencies, but these are entirely optional.
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.

Quote:
Myth: systemd being Linux-only is not nice to the BSDs.
Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it.
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.

Quote:
Myth: systemd makes changes for the changes' sake.
Very much untrue. We pretty much exclusively have technical reasons for the changes we make,
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.
Old 05-11-2013, 03:48 PM   #86
Martinus2u
Member
 
Registered: Apr 2010
Distribution: Slackware
Posts: 342

Rep: Reputation: 55
Quote:
Originally Posted by ReaperX7 View Post
code freezes ... GNU core OS and Kernel ... accept no new code or projects ... extreme scrutiny ... "Linux Consortium Board of Regulators" ... established leaders ... Linux Software Certification Committee
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.
Old 05-11-2013, 04:45 PM   #87
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: ElementaryOS, Ubuntu LTS, Slackware
Posts: 1,497

Rep: Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682
Quote:
Originally Posted by imitheos View Post
Myth: systemd being Linux-only is not nice to the BSDs.
Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it.
What's Systemd's bus factor? One? Anyone care to rent a bus?
 
Old 05-11-2013, 05:17 PM   #88
JWJones
Member
 
Registered: Jun 2009
Location: Cascadia
Distribution: Slackware, LinuxBBQ, OpenBSD, Mac OSX
Posts: 723

Original Poster
Rep: Reputation: 185Reputation: 185
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
 
Old 05-11-2013, 09:15 PM   #89
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 793

Rep: Reputation: 245Reputation: 245Reputation: 245
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.
Old 05-11-2013, 10:08 PM   #90
hitest
Senior Member
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 4,140

Rep: Reputation: 523Reputation: 523Reputation: 523Reputation: 523Reputation: 523Reputation: 523
Quote:
Originally Posted by Erik_FL View Post
I believe that strengthening support for at least one other DE besides KDE is important for Slackware.
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.
  


Closed Thread

Tags
cgroups


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Slackware: Is Systemd Inevitable? LXer Syndicated Linux News 5 07-22-2013 04:54 AM
[SOLVED] slackware and systemd fl0 Slackware 512 08-29-2012 11:07 AM
slackware and systemd (OT) eloi Slackware 44 08-24-2012 04:36 PM
[SOLVED] systemd and Slackware's future kikinovak Slackware 95 07-14-2012 11:40 AM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 09:02 AM


All times are GMT -5. The time now is 03:56 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration