Poor Soul, you do not know what you are talking about!

Now that the intel video bug seems to have settled down I am hopeful that we're closer to a release candidate; -current is running well for me. I have no clue as to how many bugs Mr. Volkerding needs to check off on his to do list before the code is ready. I appreciate the fact that the man is getting it right.

Then care to point out where in any regards discussion like this is going to weigh any merit on Patrick Volkerding's decision making process?

Care to point out where if any exists, the topic has any relevancy towards how Slackware will be going?

Care to discuss how many topics of this nature have been raised in the past and never go anywhere?

If you'd like to get a moderator in here to close this thread, then keep up the act by all means and you'll see how fast, brutally efficient, and heavy handed the moderators work here. I'm only warning you to end the attacks on others because after a while the moderators will catch on and will end the bashing and trolling, and the flame baiting. The moderators will tolerate anyone to a point, but even if you think you, or anyone, aren't crossing any lines, remember who is in charge, and it's not you. Just because you want to try and bait someone into an argument isn't going to go unnoticed. After a while, people catch on, and trying to say things, or act in manners that are trying to make the moderators look stupid, foolish, blind, or uncaring is going to land you in a place you, or anyone for that matter, might not wish to be.

There is nothing wrong with maintaining a stable release, if that's what your aim to kill is. Stable releases provide a baseline of stability because various people use Slackware in various functions and running a rolling release distribution that could get broken packages in need of rebuilding, is not wise, it's reckless and careless. If you want this style of operating system, go run Arch and play with their matches and dynamite in a room full of gunpowder. If you want a solid foundation of packages that only updates as measures are needed or provides you the system and network admin to patch on your terms for your needs, run Slackware, and go from there.

There is no "what if..." here. It's called (un)common sense in practice of methodology. What if? No... There is no what if because you're implying Slackware will abandon a founding principle to provide a stable system and foundation. Slackware hasn't adopted a new methodology since it was founded. -Current has always been a public repository of packages that are in the cycle of public testing for stability, bug fixes, backporting when necessary to stable releases if needed, and providing a work-in-progress platform for those willing to be sacrificial lambs. Are you supposed to run -Current as an everyday system? Go read the documentation and the answer is "no, unless you're fairly certain you don't have anything to lose". That's why stable releases exist, to give stability. You're free to say and think, but it doesn't mean you're right or wrong or that Patrick is going to see you as right or wrong on any level.

I never said or made any assumption I was, had, or was poised at the right hand of Mr. Volkerding. Are you implying something, again? I've never seen Eric or even Robby make such a bold statement. Last I heard, the person who was closest to Patrick's right and/or left hand possibly was his wife, the legendary Mrs. Volkerding.

In terms of "simplification", it's a paltry and weak argument. How is running -Current constantly and dropping stable releases going to simplify or solve anything? You end the problem of extra work on stable releases, but introduce a new problem of creating more structures for testing packages and ensuring new packages are stable, and dependencies need to be continually checked and rebuilt as new packages are imported. In the end the workload you've tried to reduce, creates more work on the opposite side of the table. Stable releases, like any system (UNIX, DOS, or NT based), are maintained as long as the core code stays viable and pliable with security standards, hardware support vectors, and is able to be supported financially.

Slackware could theoretically run any kernel it chose to, but I highly doubt it would venture off the path of GNU/Linux in favor of any but with such foundations as it has. You can ask, but don't expect replies that will be on your favor-ability list.

Hey, I'd love to join you on that horse of yours, but all the aerial ladders at my disposal are being used for real fires.

However, if you'd search your pockets for the compact mirror you're carrying, you may want to have a look into it.

cheers,

I find that -current has been remarkably stable at the times that I have snapshotted it. I wait until any breakage reported on LQ has been fixed before taking a snapshot.

The biggest problem for me has been buggy X Windows drivers for my Radeon R7 265 graphics card. That may not get fixed ever.
Ed

To be blunt, no, I would not like this style I use Slackware because of what it already is, I like the slow-paced, stable builds, and I would prefer that the devs continue to focus on that. I personally have new hardware on my desktop machine, and I picked the parts fairly carefully, although I did need to compile my own kernel to support a few things.

I'd go so far to say that Slackware actually taught me something about computing (beyond learning a bit extra about GNU/Linux). I have a strong tendency to play around with computers, even when I don't need to. I like updating software, upgrading things; for some reason it's a satisfying method of procrastination. My current work needs the computer, but it's not about computers. Slackware gives me a stable base to work from, and although I could have newer software, the latest version of this or that, rolling updates, I now have to wonder what for? For me the important thing is to have a system that I can work from, and stop messing around with updates just for the sake of it (with the exception of security patches).

Regarding hardware, well, we are dealing with Linux here. It requires a bit of forethought and consideration. Although the good news is, if someone prefers a rolling-release style with lots of new things happening all the time, they can already get that. It is good thing though that if such a development and maintenance philosophy is not to someone's taste, there are many options and possibilities in the Linux world. Anyway, I'm happy with Slackware stable, that goes for my old ThinkPad as well as my new desktop (NVIDIA Maxwell video card, Haswell-E CPU).

3 members found this post helpful.

The Radeon R series is still fairly new compared to the older stuff. Even at best, most drivers, regardless of hardware, don't really get a good enough shake-down for at least a 9~12 months after initial release when enough bugs have been worked out to see where further issues lie.

This is why a lot of old time GNU/Linux users and contributors always suggest getting hardware that is at least 1 year old as the newest possible hardware. By then drivers have stabilized, and hardware works as it should within at least 95-100 of acceptability.

The kernel, in the case of your R7, can provide drivers for getting consoles up and running on the framebuffer and basic handling of power and other PCIe/AGP usages, but in the end, X will still require it's own driver for display handling purposes to use DRI. However, even X is at the mercy of the kernel. Drivers in the kernel have to be stable for X to have stable drivers.

My suggestion, keep logs and direct them to the xf86-video-ati driver developers, and the Mesa developers, and use the xf86-video-ati and mesa gits often to check on progress.

ReaperX7 - thanks for the inputs. I bought my Haswell-E the week it was announced (I work for Intel, so I get our latest). The CPU and chipset work fine.

The Radeon R7 265 is a "Pitcairn" which first came out in 2012. One would think that it should work by 2015.

When I get amibitous, I will snapshot -current to see if X Windows 1.17.2 works better. I should clarify that the bugs are in the GPU hardware acceleration. I disable GPU hardware acceleration and the CPU draws correctly (and acceptably fast for 2D work even on a 4K monitor).
Ed

There are always people who go somewhere new, like it, decide to stay, then try to change it for the better, instead of going down the hallway, across the street or across town to a place just like the one they visualise. Why use a rolling release system when one can use a stable system and believe it would be better if it stopped being stable and became rolling?

From post #7:
These statements answer these questions:

• Is Slackware a rolling release?
• Will Slackware ever get to rolling release?

but actually the question was:

• What if Slackware will become a forever rolling release distro, in future?

We may take it seriously or not, provided that we stay on topic. As we see, doing otherwise just triggered an uselessly heated discussion (and rather boring, IMO).

PS and don't burst our bubbles, please. Everybody is entitled to build castles in the sky.

2 members found this post helpful.

What if... as a scenario still implies something is in place to make a change, but currently there is no way to begin to turn Slackware into a rolling release.

Rolling release works best against a source built package system. SBo might work, but we only have a limited set of tools to perform this, such as sbotools, but sbotools is still limited on it's dependency resolution abilities.

Binary packages produce a lot of problems because when a dependency is updated, everything using it, unless able to distinguish the dependency correctly, will break things.

So far, nothing of the sort is in place on any level in Slackware or even in SBo.

The question is not "Is there a way?"

I disagree. I can ask "What if gravity disappears for a minute", "What if Arch Linux starts to release a non-rolling-release version", "What if the Chinese start a war with the US" just fine without having something in place to actually turn off gravity, make Arch viable as non-rolling-release or having the Chinese start a war. In my opinion it is even exactly that, that we can ask these questions without having a base for them, that makes the human mind so fascinating and successful: that we can imagine something that hasn't happened yet and/or will never happen and discuss how it would be.

4 members found this post helpful.

Of course there's a way. 'slackware-current' already operates in a rolling fashion. All it would take is for Pat to announce that there will be no further stable releases and current is all there will be from now on ("Slackware as a service", just like Win 10 ). However, business considerations are far more significant than any technical issues involved with going 'rolling'; how do you sell boxsets when you don't have releases? Plus, the releases increase visibility and generate new interest when they occur, which would be lost in a 'rolling' scheme. Pat would probably have to take slackware subscription only, and then he'd have the problem of attracting new users.

I don't think 'rolling' would be a viable business model for Slackware, but it would be trivial to implement from a purely technical standpoint.

2 members found this post helpful.

Okay, so here's the question...

How do you accurately supply packages that can supply stability and ensure dependencies are resolved, runtimes are met, and nothing is broken for no longer than possibly a 24 hour period within given reason of course, packages are tested, and the ultimate challenge... only one person does all the work?

To me, being realistic, it can not be done with the resources and personnel limitations Slackware has. Remember, for all we know, Slackware is still ran only by Patrick. Not only that, but Patrick has to make a living off selling Media Installations, Books, and other Slackware goodies.

I'm not trying to say it can't be done with a dedicated team, but currently Slackware doesn't really have the resources to make the effort as such.

Only one person can do so much... Didn't anyone consider this?