LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 04-06-2021, 03:44 AM   #16
igadoter
Senior Member
 
Registered: Sep 2006
Location: wroclaw, poland
Distribution: many, primary Slackware
Posts: 1,962
Blog Entries: 1

Rep: Reputation: Disabled

Quote:
Originally Posted by gerogerigegege View Post
Dependency checking doesn't have to be some sort of over-complicated hell, just do it like how the BSDs do it.
Ok, just do it. Then we will see. Or who is supposed to do it?
 
Old 04-06-2021, 03:49 AM   #17
gerogerigegege
LQ Newbie
 
Registered: Apr 2021
Posts: 14

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by igadoter View Post
Ok, just do it. Then we will see. Or who is supposed to do it?
Okay.
 
1 members found this post helpful.
Old 04-06-2021, 04:34 AM   #18
Lysander666
Senior Member
 
Registered: Apr 2017
Location: The Underearth
Distribution: Ubuntu, Debian, Slackware
Posts: 2,142
Blog Entries: 6

Rep: Reputation: 2412Reputation: 2412Reputation: 2412Reputation: 2412Reputation: 2412Reputation: 2412Reputation: 2412Reputation: 2412Reputation: 2412Reputation: 2412Reputation: 2412
I think the more pertinent question is - how small would the core team allow the userbase to get before revising Slackware's ethos? I agree with the OP, largely. One can only resist change for so long and I think Slackware will need to move on at some point if it wants to usher the next generation of users in. It will have to do something because all it has at the moment are nostalgic ex-Unix users, curious hobbyists [of which I self-define] and some 4chan and Reddit users who use it to look cool. Those numbers will dwindle more and more as the older generation dies out [sorry, but it's true], and it can't have escaped the notice of the forum that the gap between Slackware releases is ever-widening most likely due to the difficulties of retaining Slackware's model in the 2020s.

That said, Slackware has had, up till now, a cast-iron ethos of not automating dependencies. It's part of its identity and its raison d'etre. However, it is horribly inefficient. As I said in another thread recently, it took me two hours - me, as a relatively experienced Slackware user - to recently update an old system's kernel and all its packages. I found it frustrating. In Debian this would have taken about five minutes. The other thing that I was surprised at, which I had forgotten about, was the length of time Slackware took to boot up and shutdown.

Remember when Debian switched over its init? Who can forget the fights, the arguments, the recriminations; it was brutal. But I think they did the right thing, they just did it sooner than a lot of people were expecting.

The arguments for not automating dependencies are "it is just not needed", "it gives you more control", "it's more Unix-centred" and "it's more stable". These are all totally valid arguments, though, in the case of stability, OSs like Debian are perfectly stable these days. Slackware currently exists as a relic of a mostly bygone computing era and to say that "Slackware is Linux" is no longer as accurate as saying, "Slackware is the traditional form of Linux". As time goes on, Slackware will have to make a choice, of either sticking to its guns and facing a smaller and smaller userbase as it antiquates and risks irrelevance and deprecation, or changing something about its identity in order to remain relevant to new users. Maybe 16.0 is a good time to think about this... or maybe not. For me, Slackware is just an enjoyable experiment which I play around with on older machines, but I cannot use it as my main system anymore.

"They can live in my new world or they can die in their old one." - Daenerys Targaryen

Last edited by Lysander666; 04-06-2021 at 04:37 AM.
 
1 members found this post helpful.
Old 04-06-2021, 04:35 AM   #19
walecha
Member
 
Registered: Jan 2010
Location: Malang, +62
Distribution: slackware
Posts: 86

Rep: Reputation: 16
No dependency checking? That's fine. I'll do it my self. It's not like I'm superbusy. I have the time with me.
 
2 members found this post helpful.
Old 04-06-2021, 04:56 AM   #20
igadoter
Senior Member
 
Registered: Sep 2006
Location: wroclaw, poland
Distribution: many, primary Slackware
Posts: 1,962
Blog Entries: 1

Rep: Reputation: Disabled
Quote:
Originally Posted by ChrisAbela View Post
I confess that your "long-titled" post has brought a smile to my face.
I can imagine that.
 
Old 04-06-2021, 04:59 AM   #21
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.2 & current
Posts: 7,914
Blog Entries: 59

Rep: Reputation: Disabled
Quote:
Originally Posted by gerogerigegege View Post
horrifically archaic...horribly archaic...horrifically large (8GBs)
Easily horrified? Nervous wreck? Take slow, deep breaths...calm down.
 
2 members found this post helpful.
Old 04-06-2021, 05:02 AM   #22
igadoter
Senior Member
 
Registered: Sep 2006
Location: wroclaw, poland
Distribution: many, primary Slackware
Posts: 1,962
Blog Entries: 1

Rep: Reputation: Disabled
Quote:
Originally Posted by Lysander666 View Post
I think the more pertinent question is - how small would the core team allow the userbase to get before revising Slackware's ethos?
You're missing point. Say OP will establish such system I will test it. It can be useful for custom installation. It is not easy to establish kind of minimal Slackware installation. It is not to go pro- or anti- Slackware ethos. Just some people can find this useful. So no need to kill this at the beginning. If OP is capable to do such thing, we'll see. Myself I can promise I will test it.

Edit: We are not Faith Purity Guardians here. Let allow people to do something. We'll see.

Last edited by igadoter; 04-06-2021 at 05:04 AM.
 
Old 04-06-2021, 05:46 AM   #23
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys
Posts: 3,501

Rep: Reputation: 3392Reputation: 3392Reputation: 3392Reputation: 3392Reputation: 3392Reputation: 3392Reputation: 3392Reputation: 3392Reputation: 3392Reputation: 3392Reputation: 3392
Lysander666, I am puzzled by your comment about boot times. I do agree that systemd does shutdown quicker but why would anyone care about that? Just hit Power Down and leave since you are apparently not using your PC any longer. However I have tried numerous systemd distros, Debian (both Stable and Testing), Arch, Manjaro, PopOS, Ubuntu, CentOS, OpenSuSe and a few other oddballs. None of them always boots faster than Slackware in my experience and if anything hangs at all on systemd's parallel arrangement it can take agonizingly long to boot and even longer to suss why.

If you are experiencing slow boots with Slackware I'd like to suggest building a custom kernel with "make localmodconfig" and turning off any services you don't actively use. Surely one can theoretically do that in any distro, even those using systemd, but it is a vastly more complicated process and still, once accomplished, boot time will sometimes hang on some device that doesn't respond in what systemd considers a timely fashion.

In fact, I'll be right back with an actual timed comparison... BRB

###
EDIT
###

OK. Back. I just booted consecutively this Slackware Current to compare with OpenSuSe, which incidentally I rather like at least compared to other systemd distros. Slackware booted in 12 seconds to runlevel3. One of the reasons I "rather like" OpeSuSe is that it isn't impossible or a royal PITA to boot to multi-user terminal... but then maybe that too is evidence that I'm some sort of "throwback, nostalgia ridden" dude Anyway, OpenSuSe took 25 seconds, a little more than twice the time. Granted it shutdown in half the time of Slackware but (and this may be just an odd artifact of my machine or BIOS/UEFI settings) rebooting from Slackware was flawless and rEFInd came up perfectly as it is supposed to but rebooting from OpenSuSe, while it did launch rEFInd, it came up with no USB active, no keyboard or mouse. I had to push the power button to be certain BIOS/UEFI would properly recover and it did and bingo! 16 seconds later I was at my Slackware Desktop.

Similarly while fixing a severely damaged Win10 hard drive belonging to my Brother ( I'm working on him as well as his install ) I installed that drive on my system to verify it would succeed in booting. It did boot successfully (and I sent him the new drive with the repaired system on it) but shades of days past, while it got to Desktop quite quickly, I could do nothing for about a minute while it continued to load stuff.

My Son wasn't so lucky as BitLocker encrypted his entire disk and being a corporate laptop the key from several years ago was no longer available. He had to plunk down almost 140 bux for a new iso while losing everything he had amassed over 5 years.

I only mention the Windows items not actually mentioned in this thread to point out that

CONVENIENCE COMES AT A PRICE! Unfortunately we most often don't get to see the cost until we are forced to pay for it. No thanks. I'll stick with "ancient" Slackware's horrific old ways.

Last edited by enorbet; 04-06-2021 at 06:12 AM.
 
1 members found this post helpful.
Old 04-06-2021, 06:44 AM   #24
Ilgar
Senior Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware64 14.2, Slackwarearm-current
Posts: 1,033

Rep: Reputation: 149Reputation: 149
I think Pat is not totally closed to fundamental changes, think of PAM, for example. Systemd and dependency checking (DC) are two other "controversial" changes I can think of but I feel that there isn't sufficient amount of push in their favor. DC would be the more benign of the two but although many of us would admit that it is a convenience, almost none of us suffers enough inconvenience to want to take risk by making a change.

I sometimes install this and that popular distro on a spare partition to see how they work, or sometimes because I need some Qt5 software which I can't run on Slackware 14.2. Their installation and management tools are a lot better than what you would find 10-15 years ago and the experience is much smoother, but to my surprise, so far none of them provided the stability I have in Slackware. It really gets on my nerves when some "automated" thing fails and then you have to do all sorts of weird workarounds to get it fixed because the system was not designed to be managed manually in the first place. Slackware is so solid and it matters so much to me that I would rather have that little bit of inconvenience than seeking adventures.

Last edited by Ilgar; 04-06-2021 at 06:45 AM.
 
2 members found this post helpful.
Old 04-06-2021, 06:47 AM   #25
keithpeter
Member
 
Registered: Nov 2015
Location: 52:30N 1:55W
Distribution: Slackware 14.2 and Current
Posts: 172

Rep: Reputation: Disabled
Quote:
Originally Posted by ChrisAbela View Post
[...] In retrospect, very few distributions allow such intrusive interventions, and that is why we love Slackware.
The absence of a tightly coupled dependency graph in Slackware allows experimentation. One experiment could be to write a package manager that provides dependency resolution. In fact Salix Linux has added just that (along with other things).

Quote:
Originally Posted by gerogerigegege View Post
[...]Dependency checking really shouldn't be viewed as taboo anymore; all of the (major) BSDs have it, and basically all */Linux distros have it. Even CRUX has it; even CRUX!
"Linux is a space of freedom", and perhaps we should preserve the 'biodiversity' a little?

Quote:
Originally Posted by Lysander666 View Post
[...] As time goes on, Slackware will have to make a choice, of either sticking to its guns and facing a smaller and smaller userbase as it antiquates and risks irrelevance and deprecation, or changing something about its identity in order to remain relevant to new users.
Recuperation has an odd logic of its own. Perhaps Slackware will become popular with a certain segment of younger people, in the same way that lava lamps, radiograms and bright primary coloured oven-ware have. Or perhaps not - things do have a life cycle after all.

Last edited by keithpeter; 04-06-2021 at 06:49 AM. Reason: Clarification
 
2 members found this post helpful.
Old 04-06-2021, 07:28 AM   #26
solarfields
Senior Member
 
Registered: Feb 2006
Location: slackalaxy
Distribution: Slackware
Posts: 1,138

Rep: Reputation: 685Reputation: 685Reputation: 685Reputation: 685Reputation: 685Reputation: 685
I am fine with the way things are at the moment: my Slackware installation provides a relatively broad base of software, which I manage with slackpkg. On top of that I install whatever I need from SlackBuilds.org via sbotools, which provides an automated dependencies resolution. For me that's a nice compromise.
 
Old 04-06-2021, 07:30 AM   #27
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 2,804

Rep: Reputation: 988Reputation: 988Reputation: 988Reputation: 988Reputation: 988Reputation: 988Reputation: 988Reputation: 988
Quote:
Originally Posted by gerogerigegege View Post
Slackware's pkgtools is, to be quite frank, horribly archaic; it doesn't have any sort of dependency checking, despite the fact that the core system is horrifically large (8GBs).
Yeah. How long do you cut a piece of string? Answer: Long enough to be useful.

8GBs is nothing these days. Stop acting otherwise. Anyway, you have it wrong. It's 16Gb and 1,560 packages.
Quote:
Originally Posted by gerogerigegege View Post
Due to it not having dependency checking, you're not able to deselect any packages without risking breaking your entire system, so you'll just have lots and lots of packages that just waste space doing nothing.
Go back to Debian and you can deselect to your heart's content.
Quote:
Originally Posted by gerogerigegege View Post
Dependency checking really shouldn't be viewed as taboo anymore; all of the (major) BSDs have it, and basically all */Linux distros have it. Even CRUX has it; even CRUX!
Yeah, the fact that Slackware is unique is a positive thing, isn't it? Otherwise, itd be just like all of the others. Where's the fun in that? You want Crux, go use Crux.
Quote:
Originally Posted by gerogerigegege View Post
Bleh, why are you all assuming I'm trolling?
Gee, I wonder.
 
1 members found this post helpful.
Old 04-06-2021, 07:39 AM   #28
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,435

Rep: Reputation: 7629Reputation: 7629Reputation: 7629Reputation: 7629Reputation: 7629Reputation: 7629Reputation: 7629Reputation: 7629Reputation: 7629Reputation: 7629Reputation: 7629
For some people it is a horribly frightening concept that Slackware allows you to break your own system where you then have to confess "it was I who broke it" instead of pointing to the distro's management tools and sighing horrifically relieved "it was not me, it was the stupid software".
Think this: what is the appeal of Slackware Linux? I think: it allows you full control.
What will remain of that appeal if you make it more like Debian, SuSe, RHEL, Manjaro? Nothing.
 
20 members found this post helpful.
Old 04-06-2021, 08:01 AM   #29
hazel
LQ Guru
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 5,310
Blog Entries: 15

Rep: Reputation: 3104Reputation: 3104Reputation: 3104Reputation: 3104Reputation: 3104Reputation: 3104Reputation: 3104Reputation: 3104Reputation: 3104Reputation: 3104Reputation: 3104
There's more than one kind of dependency checking. The OP mentioned Crux. I used Crux for many years and liked it a lot. It does have a form of dependency check but one that is quite different from the Debian/Red Hat model which most people here are familiar with. There is no central dependency database. Instead the pkgmk script (the Crux equivalent of a slackbuild) has a section at the end where the writer of the script lists those dependencies that he/she has used for the build. The package manager uses this section to identify any extra packages that need to be downloaded.

Now Crux is source-based but in principle a similar kind of thing could be used in some kind of Slackware derivative. This would avoid the Achilles' heel of Debian-style dependency, the database, which is always in danger of becoming corrupted due to a bad or interrupted update. Believe me, when apt goes bad, it really is a pig to put right again.

It would also preserve the great advantage of the present Slackware system, the fact that you don't need to install a load of bumf to make a package work. If you don't like Patrick's build, you can download the source and the slackbuild and redo it with your own parameters. This wouldn't be possible if a dependency database was introduced. But it would be consistent with a distributed dependency system in which it was up to the builders what to put down as the dependencies of their packages.
 
7 members found this post helpful.
Old 04-06-2021, 08:14 AM   #30
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 2,804

Rep: Reputation: 988Reputation: 988Reputation: 988Reputation: 988Reputation: 988Reputation: 988Reputation: 988Reputation: 988
Quote:
Originally Posted by Lysander666 View Post
It will have to do something because all it has at the moment are nostalgic ex-Unix users, curious hobbyists [of which I self-define] and some 4chan and Reddit users who use it to look cool.
You could not be more wrong there pal.
Quote:
Originally Posted by Lysander666 View Post
As I said in another thread recently, it took me two hours - me, as a relatively experienced Slackware user - to recently update an old system's kernel and all its packages.
How old are we talking? I just updated to kernel 5.11.11 in about 2.5 minutes flat.
Quote:
Originally Posted by Lysander666 View Post
I found it frustrating.
Because you're a Debian user at heart. You don't get Slackware and you never will. That has always been the case with Debian users. Slackware vs Debian is an age old fight. But it's OK. I flounder using Debian.
Quote:
Originally Posted by Lysander666 View Post
The arguments for not automating dependencies are "it is just not needed", "it gives you more control", "it's more Unix-centred" and "it's more stable".
How about: The whole system is on the iso. You don't need dependency resolution if you follow the recommendation and run a full install, because there is nothing to resolve. It has all been done for you. If you want to add stuff, by all means do it. The tools are provided.
Quote:
Originally Posted by Lysander666 View Post
As time goes on, Slackware will have to make a choice, of either sticking to its guns and facing a smaller and smaller userbase as it antiquates and risks irrelevance and deprecation, or changing something about its identity in order to remain relevant to new users.
Does every Linux distribution have to be the same? Gawd, what a dystopian future you're aiming for.
Quote:
Originally Posted by Lysander666 View Post
For me, Slackware is just an enjoyable experiment which I play around with on older machines, but I cannot use it as my main system anymore.
Great. Good for you. I not only use it as my main system, but I also use it on practically every computer in my life. It powers my NAS & media centre, it powers my OpenVPN server, it powers my off-site backup machine, it powers my laptop and work computer. There are not enough Slackware boxes in my life.
Quote:
Originally Posted by Lysander666 View Post
"They can live in my new world or they can die in their old one." - Daenerys Targaryen
"Here's a nickel, kid. Get yourself a better computer." - Condescending Unix user
 
6 members found this post helpful.
  


Reply


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: Microsoft and OIN: Legal Commitments vs. the Power of the Taboo LXer Syndicated Linux News 0 10-11-2018 04:21 PM
Curious: pkgtools Directories and SymlLnks with pkgtools-15.0-noarch-20.txz on Thu Jun 21 22:58:42 UTC 2018 kjhambrick Slackware 4 06-23-2018 01:16 AM
LXer: Why Copyright Shouldn't Be Considered Property... And Why A Return To 1790 Copyright May Be De LXer Syndicated Linux News 1 12-06-2012 04:01 PM
Dependency checking this, dependency checking that. Jeebizz General 11 09-29-2009 06:51 PM
glibc 2.3.2 and red hat 6.1 on archaic pc--will it work? gdiv Red Hat 0 06-21-2004 12:55 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

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

Main Menu
Advertisement
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
Open Source Consulting | Domain Registration