LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Backtracking to sanity (https://www.linuxquestions.org/questions/slackware-14/backtracking-to-sanity-4175457954/)

mlslk31 04-12-2013 09:18 PM

Do what you need to do to compete, Pat! Here's my opinion on it...

1) Good decision! Besides, it's easy to install a later kernel on Slackware. I'm stuck on 3.8 now, will probably be forced to 3.9 by the EOL tag, and hoping that the "follow the money" angle will kick in to "encourage" sane release management.

2) OK decision. I disagree on the kernel bugs part because I haven't hit a new one yet that I wouldn't have hit with 4.7.2. However, in my lame attempts to program in C, it seems like the new GCC libbacktrace feature needs more work, seeming to point to parts of a bad function that lead me away from the answer, not to it. The Clang Error Caret ^ it is not...but those GCC guys are pretty smart...they'll catch up...

Maybe a timetable for GCC 4.8.1/2/3 versus the timetable for Slackware 14.1/15 would be helpful.

3) My need for a newer X is driven solely by the work of Chris Wilson and the Intel Open Source Technology Center. Otherwise, I don't need a new xorg-server. The first really good editions (for me) of xf86-video-intel were tested against 1.13, so that's OK. No earlier, though.

This year of trying to follow the latest changes--pretending like it was 1999 and a two-week old kernel and six-month-old GCC wasn't new enough to compile the latest KDE--that has taken a slight toll on my sanity as a sysadmin. If you take your foot off the gas a little bit, I'll be the first to understand.

frankbell 04-12-2013 09:24 PM

I'm just going to agree with Erik_FL. He put into words what I was thinking.

cwizardone 04-12-2013 09:49 PM

Quote:

Originally Posted by GazL (Post 4930588)
For me, the 1.14.0 XServer, 3.8 kernel and nvidia 310.44 blob have been working together better than they have in a good while. Do what you feel you have to, but I'll be keeping a copy of the current versions for my own use as I'm loath to go back when it's all working this well...

+1
Currently everything is working better with the "current" -current :) than it has in quite a while.

AceofSpades19 04-12-2013 09:54 PM

I found that everything works much better in kernel 3.8 than any previous release so I would be very disappointed if Pat decided to move down to 3.4.

tuxrules 04-12-2013 10:29 PM

I am okay with moving to 3.4 provided we have a config for 3.8 and/or 3.9. I must add I haven't seen any issues with 3.8 though.

For gcc, I am no programmer but I am running -current right now and compiled quite a bit of SBo packages and I don't see any issues. I don't see why we should move back to 4.7.x.

No opinion on the Xorg-server.

Thanks,

chess 04-12-2013 10:47 PM

My x86_64 Slackware 14.0 system was freezing on my Ivy Bridge laptop with kernel 3.2.29 so I upgraded it to 3.8.4 and the freezing went away. So as long as Ivy Bridge graphics are working on a 3.4 kernel, then I'm okay with going back to that. As for the other bits, I say whatever Pat decides is fine with me. Stability over bleeding edge any day.

hitest 04-12-2013 11:31 PM

Quote:

Originally Posted by chess (Post 4930686)
My x86_64 Slackware 14.0 system was freezing on my Ivy Bridge laptop with kernel 3.2.29 so I upgraded it to 3.8.4 and the freezing went away. So as long as Ivy Bridge graphics are working on a 3.4 kernel, then I'm okay with going back to that. As for the other bits, I say whatever Pat decides is fine with me. Stability over bleeding edge any day.

Well-said. As long as my Acer netbook successfully down-grades to 3.4 I am fine with the move. Slackware = stability. :)

ponce 04-12-2013 11:34 PM

1) I've asked Greg about what will be the next LTS kernel when 3.8 came out, because I was interested in the user namespaces additions (BTW, things still has to go in with 3.10.x), and he told me that he's already got a lot of work maintaining two stable branches (3.0.x and 3.4.x) so unless someone else step in (like Ben has done for 3.2.x) for what he knew at the time there was no plan for another LTS kernel yet;

2) I was starting to like the 4.8.0 errors spam :) , but I also read about Stuart's problems in the arm changelog, so I suppose consistence comes first;

3) 1.14.0 is still giving me some problems with nx and virt-manager with qemu hosts using spice, two things that I use a lot: I was planning to try x2go and I'm using a workaround for the spice thingie (spicec works), but I suppose upstream still needs some time to fix this.

So, no prob at all for the downgrades here, but as GazL said, should be nice to have the stuff in testing/ to keep playing with them (besides the problems above, the rest here seems to work pretty fine) :)

allend 04-12-2013 11:37 PM

I share the experience reported by GazL and cwizardone.
On:
1) A stable release can remain on a server setup for a long time (heck, my server at work is still running 13.37), so it makes sense to have a LTS kernel as the base for a stable release. The option for a later kernel to support recent release hardware is highly desirable.
2) No informed opinion. My only comment is that a trusted compiler is preferred.
3) Upgrades of third party software packages may expect the new ABI.

kooru 04-13-2013 01:48 AM

Quote:

Originally Posted by frankbell (Post 4930667)
I'm just going to agree with Erik_FL. He put into words what I was thinking.

I agree with him too.

solarfields 04-13-2013 02:29 AM

Quote:

My x86_64 Slackware 14.0 system was freezing on my Ivy Bridge laptop with kernel 3.2.29 so I upgraded it to 3.8.4 and the freezing went away. So as long as Ivy Bridge graphics are working on a 3.4 kernel, then I'm okay with going back to that. As for the other bits, I say whatever Pat decides is fine with me. Stability over bleeding edge any day.
This! I have a ThinkPad S430 and experienced a lot of freezing with the 3.2.29 kernel. I later upgraded to kernel 3.7.7 and it has been working really well so far. Even if I need to upgrade the kernel again with the next release it is not such a big deal. :)

Actually, disabling compositing almost fixed the problem in KDE (almost), but it was absolutely horrible in XFCE. I really don't know why...

chrisretusn 04-13-2013 05:17 AM

I'm running three (two laptops and a desktop) machines on -current with no problems I'd rather not go back. If that is what happens, then so be it. I'll survive. Since it was mentioned (post 15), I would definitely not want to backtrack on KDE. Version 4.10.2 is working just fine on all three of my machines.

cynwulf 04-13-2013 05:32 AM

I don't see any issues - if someone needs a newer kernel than 3.4 they can build one.

tuxbg 04-13-2013 05:45 AM

I really like -current.Don't have any problems compiling kernel or any other package.My system feel more responsive under -current.

Martinus2u 04-13-2013 07:23 AM

Hiya. Generally my observation is that -current works well with the machines I administer, which is not to say that they wouldn't with an older set of releases. Another general statement is that I do not necessarily see the correlation between "old" and "stable", and those who think there is are welcome to use Debian stable. It is, however, true that the existing experience with older releases makes it easier to choose the "highlights" if there are any.

Detailed response:

(1) I don't care about the shipped kernel as I always compile my own. I usually run pretty recent kernels, with improved cpu and i/o schedulers patched in.

Having said that I don't care, I don't want kernel headers that are too old.

(2) I'm undecided on GCC. Does 4.8.0 produce better code? If not, I see no reason for not going back.

(3) Particularly the intel drivers (from i915 kernel driver to xf86 modules and mesa) are a moving target that are continually fixed, even for older chipsets. The quarterly recommendation by intel usually contains the latest releases. Before I kicked out intel graphics on my main workstation I event went to the crazyness of building new xorg version just to get a grip on the rare crashes that always came at the wrong time. In closing I would advise to go with the latest releases for the graphics subsystem.


All times are GMT -5. The time now is 08:57 PM.