LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
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 05-15-2013, 07:18 PM   #91
Poprocks
Member
 
Registered: Sep 2003
Location: Toronto, Canada
Distribution: Slackware
Posts: 199

Rep: Reputation: 30

I say go back to 3.2.x for the kernel and move up to 3.9.x for /testing.

That is because -- assuming 14.1 were released today, which you HAVE to do when maintaining a tree that could at any arbitrary time potentially be freezed for the next release -- it is STILL projected to be EOL'd later than any of the other Kernel trees at this juncture.

See https://www.kernel.org/category/releases.html for more information.

The other alternative is to delay the release for a further period of time (targetting a 15.0 rather than a 14.1 release, as many people have pointed out as a possibility) and wait for the next version of the kernel that is projected to be supported longer than 3.2 already is.

That's my opinion, anyway. The server always needs to be looked at as the lowest common denominator for a general purpose distro with an emphasis on stability such as Slackware.

Slackware stuck with 2.4.x for years because, among other reasons, it was stable, maintained, and a rock-solid choice for servers.

If Slackware goes with 3.4 or 3.9 or any other branch that is only going to be maintained through 2014, I'll be skipping 14.1 on my server but will be looking forward to the upgrade on my desktop machine.

On 2) and 3) I have no opinion. I'll defer to the BDFL on those.
 
Old 05-15-2013, 07:24 PM   #92
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 877

Original Poster
Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Going back to 3.2.x is not an option due to the severe bug between that kernel and udev that leads to long boot time delays. Plus, I think the people who would like to see a retreat back that far are a severe minority.

If someone wants to run 3.2 when the support for 3.4 or 3.8 runs out, nothing is stopping them. But, it makes no sense to ship a kernel that old when there are better options available. It wasn't that long ago that LTS kernels didn't exist at all, and somehow we all survived.
 
Old 05-15-2013, 07:31 PM   #93
ryanpcmcquen
Member
 
Registered: Apr 2013
Distribution: Slackware
Posts: 80

Rep: Reputation: Disabled
On the other side of the coin, wouldn't someone wanting support for that long just be able to stick with the 14.0 release?
 
1 members found this post helpful.
Old 05-15-2013, 07:39 PM   #94
Poprocks
Member
 
Registered: Sep 2003
Location: Toronto, Canada
Distribution: Slackware
Posts: 199

Rep: Reputation: 30
Quote:
Originally Posted by volkerdi View Post
Going back to 3.2.x is not an option due to the severe bug between that kernel and udev that leads to long boot time delays. Plus, I think the people who would like to see a retreat back that far are a severe minority.
I wasn't aware that was an issue, but yeah, that is probably a showstopper. :-(

Is that only an issue when newer versions of udev are combined with 3.2.x?

Knowing that information, I do agree that 3.4 is probably the best option (Lesson: never distrust the BDFL ever again). 3.9.x in testing/ would still be nice, but not a priority as folks can always compile a newer kernel for themselves.

Quote:
Originally Posted by volkerdi View Post
If someone wants to run 3.2 when the support for 3.4 or 3.8 runs out, nothing is stopping them. But, it makes no sense to ship a kernel that old when there are better options available. It wasn't that long ago that LTS kernels didn't exist at all, and somehow we all survived.
I suppose that's true, but I feel that in the 2.4 days, things weren't aggressively changed as much and if a newer 2.4.x needed to be put into /patches for security reasons, it was a relatively smooth upgrade. Maybe I'm just looking at the past through rose-coloured glasses, as is my wont.

If 3.4.x were EOL'd before Slackware 14.1 was intended to be, and a major security issue were detected with the 3.4.x kernel shipped with 14.1, would you try to backport the security patch from a newer kernel?

Last edited by Poprocks; 05-15-2013 at 07:39 PM. Reason: typo
 
Old 05-15-2013, 07:51 PM   #95
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 877

Original Poster
Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Quote:
Originally Posted by Poprocks View Post
Is that only an issue when newer versions of udev are combined with 3.2.x?
Nope. With some drivers it is a problem in 14.0, but there wasn't a fix (we looked), so we had to live with it there.

Quote:
I suppose that's true, but I feel that in the 2.4 days, things weren't aggressively changed as much and if a newer 2.4.x needed to be put into /patches for security reasons, it was a relatively smooth upgrade. Maybe I'm just looking at the past through rose-coloured glasses, as is my wont.
I'd have to agree that the way 2.4 evolved didn't place people on the bleeding edge as often, but due to the way Slackware's 2.4 kernels were compiled at the time, upgrades of 2.4 were pretty nightmarish on this end. There were a lot of kernels for various SCSI controllers then, not just a huge and generic kernel.

Quote:
If 3.4.x were EOL'd before Slackware 14.1 was intended to be, and a major security issue were detected with the 3.4.x kernel shipped with 14.1, would you try to backport the security patch from a newer kernel?
If it's major (like a remote root), certainly yes. It's been done in the past, sometimes even for local root issues like the mmap zero page.
 
Old 05-15-2013, 08:40 PM   #96
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,808

Rep: Reputation: 234Reputation: 234Reputation: 234
Quote:
Originally Posted by Poprocks View Post
I wasn't aware that was an issue, but yeah, that is probably a showstopper. :-(
3.2 was also the cause of hard lockups on my laptop [i5 with Ivy bridge]. I don't know what the problem was, but it has certainly been fixed in later versions.

I like 3.8, which is stabilizing nicely now. A reversion to 3.4 is also a step too far backwards, IMO.
 
Old 05-15-2013, 09:06 PM   #97
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,849
Blog Entries: 15

Rep: Reputation: 1189Reputation: 1189Reputation: 1189Reputation: 1189Reputation: 1189Reputation: 1189Reputation: 1189Reputation: 1189Reputation: 1189
Patrick what about inclusion of an alternative to udev like hotplug2 in /testing?

3.4.x as the default kernel is the best course of action, while 3.9.x should be moved into /testing. As with the previous sentence above regarding hotplug2, maybe udev can be worked around if it gets problematic, or even replaced with something more viable.
 
Old 05-15-2013, 09:15 PM   #98
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 877

Original Poster
Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Quote:
Originally Posted by ReaperX7 View Post
Patrick what about inclusion of an alternative to udev like hotplug2 in /testing?
Feel free to submit a package that includes a complete set of working rules.
 
2 members found this post helpful.
Old 05-15-2013, 10:48 PM   #99
TommyC7
Member
 
Registered: Mar 2012
Distribution: Slackware, CentOS, OpenBSD, FreeBSD
Posts: 439

Rep: Reputation: Disabled
Hopefully whichever kernel version you pick Pat, the kernel modules for the intel GPU's are better or at least on-par with the 3.2 series (tried 3.4, 3.6, 3.7, 3.8 and 3.9, for some reason they all result in about 33% less FPS than the 3.2.29 kernel).
 
Old 05-15-2013, 11:06 PM   #100
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,808

Rep: Reputation: 234Reputation: 234Reputation: 234
Quote:
Originally Posted by TommyC7 View Post
Hopefully whichever kernel version you pick Pat, the kernel modules for the intel GPU's are better or at least on-par with the 3.2 series (tried 3.4, 3.6, 3.7, 3.8 and 3.9, for some reason they all result in about 33% less FPS than the 3.2.29 kernel).
That's not same result I get!
 
Old 05-15-2013, 11:29 PM   #101
TommyC7
Member
 
Registered: Mar 2012
Distribution: Slackware, CentOS, OpenBSD, FreeBSD
Posts: 439

Rep: Reputation: Disabled
That's the result I get using many programs with the intel GPU part of my nvidia optimus laptop. Perhaps it may not apply to those who have only an intel GPU.
 
Old 05-18-2013, 08:28 PM   #102
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 908

Rep: Reputation: 447Reputation: 447Reputation: 447Reputation: 447Reputation: 447
What is the state of the USB 3.0 xHCI stack in 3.4 vs. 3.8? I heard of many improvements since 3.2, where it is only barely functional.
 
Old 05-21-2013, 01:01 AM   #103
Poprocks
Member
 
Registered: Sep 2003
Location: Toronto, Canada
Distribution: Slackware
Posts: 199

Rep: Reputation: 30
Quote:
Originally Posted by volkerdi View Post
If it's major (like a remote root), certainly yes. It's been done in the past, sometimes even for local root issues like the mmap zero page.
In that case, I now have no opinion on (1), (2) or (3). :-P

Initially my thinking was that we might be placed into the extraordinary possibility of Slackware 14.0 being in a position to be supported up to a later date than 14.1.
 
Old 05-21-2013, 06:18 PM   #104
torimus
Member
 
Registered: Apr 2013
Distribution: Slackware
Posts: 81

Rep: Reputation: Disabled
  1. Linux 3.4 as the well tested branch with planned long time support is currently an optimal choice. However I'd also vote to put more recent version (> 3.8.4) in testing/ as already suggested. Hope it won't be too tiresome and time consuming to keep it updated. As 3.4.x do work well, there are noticeable benefits mostly on some kind of (recent) hardware like broader chipsets support, fixed very annoying power-management regressions (although introduced in late 3.5/early 3.6 versions, some issues from 3.4 were also fixed), better support for dual graphics adapters (like nVidia's Optimus) etc.
  2. Keeping GCC branch of 4.7 also find a wise decision. I don't see any significant benefits to use 4.8 now. Not enough tested, introduces a few incompatibilities and some of upstream sources not yet adapted and won't compile without a home-brewed patch etc. Also most of major distributions do use 4.7 as their default currently.
  3. By similar reasons mentioned in the previous paragraph, I'm also giving nods to Your suggestion and would prefer to keep Xorg at 1.13 version. Although avoiding closed-source sw as possible, some of them (proprietary vga drivers, commercial games, etc.) are linked/tested with not the most recent X & OpenGL libraries so with 1.14 some may not run (properly). As a nice bonus backported drivers (bugged intel's especially) packaged in testing/ would be welcomed.

Keep the great job.

Take care
 
Old 05-21-2013, 06:42 PM   #105
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 147Reputation: 147
Quote:
Originally Posted by jtsn View Post
What is the state of the USB 3.0 xHCI stack in 3.4 vs. 3.8? I heard of many improvements since 3.2, where it is only barely functional.
In my case I can say any versions before 3.6 don't work. The inplug event can be detected, but the device can't connect to the xHCI.

And bacause versions >=3.8 crashes 100% of the times disconnecting from bluetooth modem, I am stuck to 3.7.10 currently.
 
  


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
modversions.h and my sanity! stcinifeic Mandriva 1 05-28-2004 06:12 PM
samba sanity skywaterhulk Linux - Software 0 04-22-2004 09:13 PM
Question of sanity ch4s3r Linux - Newbie 3 02-29-2004 08:22 PM
I guess a simple backtracking problem spank Programming 15 08-27-2003 12:21 PM
in the name of a musicians sanity! leprechaun Linux - Newbie 3 02-17-2002 02:34 PM


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