LinuxQuestions.org
Review your favorite Linux distribution.
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 06-13-2018, 09:16 AM   #16
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys for decades while testing others to keep up
Posts: 1,947

Rep: Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843

Quote:
Originally Posted by solarfields View Post
So, what do we do? We just admit to ourselves that Linux lags behind when it comes to support of the most modern hardware? Just try to relax while waiting for things to settle down a bit and become stable? Which will coincide with the next release of Slackware.
Ho-o-o-o-ld on thar Baba Looey Hardware support is the domain of the kernel only. There is nothing preventing you from either trying or adopting the Current kernel OR rolling your own. For reference I still use a dedicated DAW box from time to time that is running Slackware 13.37 but with a 4.15.0 kernel for a few peripherals and improved scheduling and timing support. Until recently this newer Main box dual booted this 14.2 Multilib and a 14.0 32 bit system. Doing that allowed me a much smoother transition so I am frankly glad the release cycle isn't faster. Slackware in no way limits me to what I can do and I'm not saying that from isolation. Currently this box has 14.2 Multilib, 14.2 32 bit, Current, Debian, and Arch on it. Since Arch is a rolling release I am quite aware of what Upgrade Fever offers and I'm not impressed. I don't think I am a conceited Slacker but I am convinced!
 
Old 06-13-2018, 09:23 AM   #17
basharx
LQ Newbie
 
Registered: Nov 2013
Posts: 12

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by RadicalDreamer View Post
Maybe not change the release cycle but add the latest LTS Kernel to extra for the most recent stable release after a period in Current. The 4.14.XX series is stable enough to do that.
Yes, and I could also imagine a minor 14.2.1 release with updated kernels/bootloaders, if that is the simplest.
 
2 members found this post helpful.
Old 06-13-2018, 09:24 AM   #18
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 824

Rep: Reputation: 300Reputation: 300Reputation: 300Reputation: 300
Quote:
Originally Posted by basharx View Post
I greatly appreciate focus on stability and relatively
conservative view on adding new features, but having release
cycles over 2 years as a norm
Release cycles are not a set event in Slackware, your probably know that. To state that release cycles over two years as a norm is just plain wrong. From it beginning in 1993, there have been at least one or more release per year up until 2013. Then there was the record time between release 14.1 and 14.2 three months short of three years. We are not yet at the two year mark, very close but not there yet. I just do see a norm here of two years.
 
Old 06-13-2018, 09:52 AM   #19
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226
Quote:
Originally Posted by enorbet View Post
Hardware support is the domain of the kernel only.
Permit me to disagree!

For proper installation on a NVME device, you need also a proper support within installer and bootloaders, or as another example: to support some AMDGPU devices you need particular graphics stacks, i.e. more modern X.org, libDRM and Mesa.

The 2-3 years release cycle is a real issue because in 3 years the Linux computing evolves much.

And I think those long release cycles are not the fault of our BDFL, but our own fault, who ask so many things to be included in Slackware by default, when they can stay in their own repositories, having even different release cycles.

For example, imagine that in 3 years the KDE Project will release around 36 stable releases of Plasma5. Yep, is just about 36 freaking releases later. Yet, we insist the Plasma5 to be included in Slackware.

Permit me to ask you a bit rhetorically: what sense makes that, when the shipped Plasma5 will become quickly obsolete and it will eat a major part of the precious development time for managing its hundreds of packages?

I will respond myself to this question: because our laziness to use a separate official KTown repository, and because our stubbornness to not accept that Plasma5 shipped in another repository, with the advantage of being released even often, is still Plasma5 included in Slackware.

Last edited by Darth Vader; 06-13-2018 at 11:03 AM.
 
3 members found this post helpful.
Old 06-13-2018, 11:06 AM   #20
hitest
Guru
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 5,556

Rep: Reputation: 1605Reputation: 1605Reputation: 1605Reputation: 1605Reputation: 1605Reputation: 1605Reputation: 1605Reputation: 1605Reputation: 1605Reputation: 1605Reputation: 1605
Quote:
Originally Posted by basharx View Post
I'm sticking with Slackware since 1995, I like the philosphy,
but wonder about the last dilated release cycles.
So what? Debian has a longer release cycle. There were 2 years between Debian 8 and 9. It's not about having a speedy release cycle, it is about quality. I am very thankful that Mr. Volkerding does not feel pressured to release 15.0 early. He is taking the time to thoroughly audit 15.0 to ensure that it meets his standard for excellence. I am happy to wait.
 
3 members found this post helpful.
Old 06-13-2018, 11:54 AM   #21
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 738Reputation: 738Reputation: 738Reputation: 738Reputation: 738Reputation: 738Reputation: 738
Quote:
Originally Posted by Darth Vader View Post
For example, imagine that in 3 years the KDE Project will release around 36 stable releases of Plasma5. Yep, is just about 36 freaking releases later. Yet, we insist the Plasma5 to be included in Slackware.
We? I do not. Even as a KDE user I would prefer a 3rd party repo, with the current that KDE says is stable.
And therefor say a true multilib compiler with a small set of base libs in 32, not the converted ones.
But this is just because it fits my needs better. Others might disagree (where for the 32 bit topic, there is noting to disagree ;-) )
 
Old 06-13-2018, 12:31 PM   #22
allend
LQ Guru
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 5,007

Rep: Reputation: 1754Reputation: 1754Reputation: 1754Reputation: 1754Reputation: 1754Reputation: 1754Reputation: 1754Reputation: 1754Reputation: 1754Reputation: 1754Reputation: 1754
Jesus wept. This is the year of Meltdown and Spectre. Your latest and greatest hardware is probably junk. How can anybody release a stable OS until mitigations have been resolved?
 
2 members found this post helpful.
Old 06-13-2018, 12:56 PM   #23
nobodino
Member
 
Registered: Jul 2010
Location: in France
Distribution: slackware, slackware from scratch, LFS, linux Mint, Niresh (MacOS)...
Posts: 451

Rep: Reputation: 291Reputation: 291Reputation: 291
Nobody will be able! Meltdown and Spectre opened the "pandora's box". They are the new kind of vulnerabilities, due to the lack of security at the hardware level, unless you have new kind of processors you'll never get rid of. Don't count on stable kernel before months/years.
 
1 members found this post helpful.
Old 06-13-2018, 02:01 PM   #24
upnort
Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu MATE
Posts: 708

Rep: Reputation: Disabled
Want support for bleeding edge hardware? Use Arch. Or a non LTS Ubuntu.

If somebody wants a "stale" collection of packages then use Debian Stable. The Debian developers freeze packages about 9 months before release and are strict about updating packages with only major bug fixes and security patching.

Want really stale packages? Use CentOS.

Forget about using newer hardware with those distros. Slackware is almost bleeding edge compared to those two distros.

The Ubuntu rapid release model is buggy although the developers at least kick out an LTS release every two years. Yet the proverbial wisdom says wait until the .1 release to start moving into production. Ubuntu LTS point releases do include newer versions of packages, but they have many developers and millions of users who are happy to be beta testers.

A big challenge with free/libre software is the breakneck speed of upstream development. Changes in one upstream package almost always breaks some other package. Proprietary software does not escape this either. Browse any Windows forum to see the continual breakage caused by updates.

Basically, computer users these days are unpaid beta testers. Seems more often than not that software quality assurance has gone the way of the Dodo bird.

At work I use Debian (Proxmox), CentOS, and Ubuntu. Debian and CentOS have long release cycles but they are not immune to package update commotion. Just today I experienced breakage while updating a CentOS system.

When Slackware releases averaged about 9 months there were always a few bumps with updating, but the longer cycle now introduces more changes because of the exhausting upstream rapid release model. That means more testing. I don't envy anybody maintaining a distro. If Pat and the team need two years these days to produce a stable release then that is what we get.

I use four different distros. I never look forward to updating a distro. Updating distro releases takes a lot of time because of the breakage. Last year I needed a couple of months to update Slackware 14.1 to 14.2 because each system I use has different hardware and the breakage was different on each system. Shell scripts have to be tested too because often upstream package changes include syntax differences. Similarly, last year I updated six systems from Proxmox 4.4 to 5.1. That took about 2 months because each system had to be tested and then allowed to run for a few weeks to note possible breakage before updating the next system. Then monitor virtual systems for breakage.

Exhausting.

I am not offering solutions. Just noting that upstream rapid release models are hurting everybody. That software quality assurance is a sh-tfest these days.

Embrace rapid release and enjoy bugginess. Embrace a slower release cycle and forego the latest hardware. C'est la vie. I choose slow release cycles.
 
2 members found this post helpful.
Old 06-13-2018, 06:43 PM   #25
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys for decades while testing others to keep up
Posts: 1,947

Rep: Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843
Quote:
Originally Posted by Darth Vader View Post
Permit me to disagree!

For proper installation on a NVME device, you need also a proper support within installer and bootloaders, or as another example: to support some AMDGPU devices you need particular graphics stacks, i.e. more modern X.org, libDRM and Mesa.
NVME? Sorry but that's just cheapened junk having a lot in common with Winmodems and MOS drives... IMHO of course. Some AMD/ATi devices? Not new ones. Just old crap. The 4.15.x and beyond kernels have superb new AMD/ATi support AFAIK. New Xorg is not needed by any graphics chipset of which I am aware. How is Mesa version and libDRM the responsibility of a distro? I guess we just disagree.

Quote:
Originally Posted by Darth Vader View Post
The 2-3 years release cycle is a real issue because in 3 years the Linux computing evolves much.
From the posts I see here it doesn't seem to be an issue for the majority.

Quote:
Originally Posted by Darth Vader View Post
And I think those long release cycles are not the fault of our BDFL, but our own fault, who ask so many things to be included in Slackware by default, when they can stay in their own repositories, having even different release cycles.

For example, imagine that in 3 years the KDE Project will release around 36 stable releases of Plasma5. Yep, is just about 36 freaking releases later. Yet, we insist the Plasma5 to be included in Slackware.

Permit me to ask you a bit rhetorically: what sense makes that, when the shipped Plasma5 will become quickly obsolete and it will eat a major part of the precious development time for managing its hundreds of packages?

I will respond myself to this question: because our laziness to use a separate official KTown repository, and because our stubbornness to not accept that Plasma5 shipped in another repository, with the advantage of being released even often, is still Plasma5 included in Slackware.
With all due respect I am aware of your concerns over KDE and while I really don't see it as an important obstacle for many, because it seems you think so for yourself I do feel compassion for you on this but I truly don't see how any distro can be held responsible for what is important to so few. I assume you are able to manage else why would you stick with Slackware?
 
Old 06-13-2018, 07:40 PM   #26
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226Reputation: 1226
Quote:
Originally Posted by enorbet View Post
NVME? Sorry but that's just cheapened junk having a lot in common with Winmodems and MOS drives...
IF these NVME devices, which these amazing American Companies sell them in Europe even for more than $1000, are just some cheap junk having a lot in common with Winmodems...

For example, I think about this one: https://www.pcgarage.ro/ssd/intel/op...l-add-in-card/

This junk is as cheap as $1,443.13 on a country where $500 monthly is a good earning. And that's good news, because it was only $1,618.20 some time ago.

Then please delight me, you are kind to fully disclose what considers "decent" as storage devices, our brave Americans?

Something similar to the Quantum Storage Devices, like the ones used by Klingons in StarTrek?

Last edited by Darth Vader; 06-13-2018 at 08:05 PM.
 
2 members found this post helpful.
Old 06-14-2018, 02:07 AM   #27
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys for decades while testing others to keep up
Posts: 1,947

Rep: Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843Reputation: 1843
Quote:
Originally Posted by Darth Vader View Post
IF these NVME devices, which these amazing American Companies sell them in Europe even for more than $1000, are just some cheap junk having a lot in common with Winmodems...

For example, I think about this one: https://www.pcgarage.ro/ssd/intel/op...l-add-in-card/

This junk is as cheap as $1,443.13 on a country where $500 monthly is a good earning. And that's good news, because it was only $1,618.20 some time ago.

Then please delight me, you are kind to fully disclose what considers "decent" as storage devices, our brave Americans?

Something similar to the Quantum Storage Devices, like the ones used by Klingons in StarTrek?
You have my sincere, and red-faced apology. The only ones I'd seen to date were IMHO junk but thanks to your link I used that to look deeper and I'm actually shocked at the performance possibilities and of course the huge price tag as well.

Yes it is true that I live within the borders of the USA so I am an American but that doesn't define me. It's only a hint, the tip of an iceberg, as i suppose it is for any citizen of any country but as you can see i am not too proud to admit when I am wrong.

Oh and watch out for those Klingon drives, they may make snarly choppers but they don't have a clue about Entanglement
 
Old 06-14-2018, 03:14 AM   #28
pchristy
Member
 
Registered: Oct 2012
Location: UK
Distribution: Slackware
Posts: 332

Rep: Reputation: Disabled
For those worried about the slow release cycle this time around, have you tried -current? In my experience, its perfectly stable and bang up-to-date. Yes, there are updates appearing every few days, but there are on my wife's Mageia based machine as well (a supposedly stable release!).

Don't be put off by -current being labelled a "development" release! Its probably more stable than most others final releases!

--
Pete
 
Old 06-14-2018, 04:37 AM   #29
RadicalDreamer
Member
 
Registered: Jul 2016
Location: USA
Distribution: Slackware64-Current
Posts: 851

Rep: Reputation: 393Reputation: 393Reputation: 393Reputation: 393
Quote:
Originally Posted by basharx View Post
Yes, and I could also imagine a minor 14.2.1 release with updated kernels/bootloaders, if that is the simplest.
Yeah, I don't see what the big deal is if a minor addition from current is occasionally added to the Stable installer as an experimental alternative for newer hardware. The 4.14.XX series has had more revisions by now than 4.4.XX when Slackware 14.2 was released. The installer could mention if you have hardware produced after X date you might want to install this newer LTS Kernel in extra if your install fails. I don't see a reason not to do this. There are people out there who buy new hardware. Also it would create more noise for Slackware.
 
1 members found this post helpful.
Old 06-14-2018, 05:42 AM   #30
basharx
LQ Newbie
 
Registered: Nov 2013
Posts: 12

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by RadicalDreamer View Post
Yeah, I don't see what the big deal is if a minor addition from current is occasionally added to the Stable installer as an experimental alternative for newer hardware. The 4.14.XX series has had more revisions by now than 4.4.XX when Slackware 14.2 was released. The installer could mention if you have hardware produced after X date you might want to install this newer LTS Kernel in extra if your install fails. I don't see a reason not to do this. There are people out there who buy new hardware. Also it would create more noise for Slackware.
Thanks for the sane input. I totally agree, could be part of the installer,
there are more ways to do it, neither seem overly complicated. Folks didn't
get I was mostly describing the booting/hw problems of the "last stable version"
as a "consequence" of the long cycle, which I wasn't really criticising as such.

For what I know, it's a showstopper for potential new users and they will hardly
ever think Slackware again in their lives. And btw in my case, this was W10 machine
that got wiped. In a way, I couldn't care less, I know nothing about economy behind
Slackware, just thought it's pity for everyone.
 
  


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: Kernel release cycle LXer Syndicated Linux News 0 12-11-2015 12:24 AM
kernel release cycle vkmgeek Linux - General 1 07-30-2008 07:31 AM
Debain release cycle? plesaleza Debian 20 09-01-2007 08:10 PM
Is the Debian release cycle too slow? Pcghost General 15 03-27-2005 09:01 PM
Release Cycle? ubuntu-addict SUSE / openSUSE 12 11-17-2004 02:55 PM

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

All times are GMT -5. The time now is 12:37 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
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration