I wish I knew the answer to the question of "when". My harddrive took a dump and now I'm wondering which version I should re-install. 14.1 or current? Or should I wait and keep using the temporary Archlinux I have installed? What if I install and then a week later after I have everything, pretty much, all configured, 14.2 (or whatever) comes out? What then? I can't stay with Arch, I've been a Slacker for 20 years, since 1995 and although they have a handy dandy package tool, I already am having problems with Arch, first of all it only sees the 3 gig 32 bit limit of memory, of which I have eight gigs. Hell after using Slack for 20 years I didn't even know there was a 32 bit limit on memory, evidently Slack always had it built into the kernel to recognize the extra memory using PAE mode. Duh on my part. Anyway I digress......

I guess I'll just do a re-install of 14.1 and if the new version comes out later I will just re-install again. In the meantime I just won't install a bunch of extra crap that'll create extra work on the temporary re-installation. (Did I just say re-install too many times?) And if I start to get bored I'll just add more crap to conky, that'll kill some time. Loooool...

Well, we haven't reached a beta yet, and if we hold to the timeline of announcement of the almost beta of 14.1 to the final stable release, we can expect the stable on 12 FEB. Unfortunately, we already surpassed the (jokingly) expected announcement of the beta (which would've been on 27 DEC.

But based on 14.1, from the time the beta was released, it was almost a month (26 days) until the first release candidate, and then another 3 weeks until the stable was released, so you likely still have some time to run 14.1 without it being immediately supplanted by a newer version. You do always have the option of running Slackware-current, which, while unofficially unstable, tends to be pretty stable (and even moreso, the closer we get to a release). I am running it on one machine (14.1 on the other), and it is running great.

If you want to see my math for the "expected" release dates, see this post. Keep in mind, I did that just as a fun exercise. You will not get your money back if those dates are not correct

1 members found this post helpful.

I think there's a reason for that, due to all these circumstances it also would be a quite controversial political statement. I think it won't be any good for Slackware, even discussion about it puts P.V. in quite difficult position, because no matter the outcome it could hurt Slackware image.

I can't see this discussion leading anywhere because, as I already said, I do not decide anything on Slackware, and ultimately I may rename my own Slackware installation version (or hostname) whatever I like. Slackware lets you do this, and more.

The circumstances leading to Murdock's death are cryptic and deeply disturbing, but I do not think that they are controversial and they do not explain how his death had little news value. Conspiracy theories will never go away anyway.

Slackware is comical, cynical, satirical and yet always welcoming and never intrusive, even if slightly elitist and definitely conservative and laid-back. The community is undemanding and never more than an LQo post away for help. That will not change with a version numbering honoring Murdock.

If, on the other there is a risk that some users (or PV) see distributions in an uncompromising competition for the spotlight, then my argument would be naive and should be discarded.

1 members found this post helpful.

Then you will read UPGRADE.TXT that comes with the DVD.

Mike

2 members found this post helpful.

I love the smell of freshly baked beta in the morning...

5 members found this post helpful.

So let it be written! So let it be done!

And the word came down from the wise and Benevolent DFL:

2 members found this post helpful.

Hasn't the DFL changed his stance on PAM?

I have found a bunch of packages for it on unofficial Slackware pages: http://www.slackware.com/~vbatts/pam/ , which say "pam for 14.2".

I mean, throwing away pam seemed reasonable a long time ago, but since we are having Pulse and various *Kits, I guess, it doesn't make much sense to avoid PAM.

Vincent Batts (vbatts), a Slackware developer, has had PAM packages available for Slackware for quite some time. However, Pat has not incorporated PAM into Slackware yet. We don't know if/when this will occur, but it is likely it won't occur before Slackware 14.2 is released.

Is it feasible to at least put packages that require PA into different disk(s) on the installation media? It would make life of many people much easier TIA

1 members found this post helpful.

How many exactly ? Three and some dirt ?

How should anyone know how many exactly? I found in quick search 13 persons saying here that they don't want to use PA. I'm sure there are others that are still silent about it. So which one of them are dirt? Sorry, but calling someone dirt just because you don't agree with their POV is childish (yes, even if they can be sometimes very annoying), you should have more respect for others.

3 members found this post helpful.

Anyway 3.14.15... your proposal is not realist. Just think what would happen if anyone not wanting to install an app would like to have it and its specific dependencies isolated. This would be simply not manageable by the Slackware team, especially with no automatic dependencies management.

As others have pointed out you can install PA and configure your system not to use it. Or you can not install it or make a full install then uninstall what you don't want. But you will have to do it yourself, possibly with the help of other users having already done that.

Debian doesn't have PulseAudio installed by default, but it is available in the main repository. I think that's a better solution because PulseAudio is so awful that I can't take the risk of having it installed on my production system. Every time I've had to use it I've had so much problems, all of which were instantly resolved by uninstalling PA. ALSA, on the other hand, has always just worked for me, right out of the box with no configuration and no problems whatsoever.

"PulseAudio seems to work fine" is not even funny. It's like famous last words. I get that you reluctantly need to have it for Bluetooth, but it does not work fine, at least it never has in my experience.

(Disclosure: I don't care about Bluetooth. Never used it, never will.)

1 members found this post helpful.

I thought that Slackware is all about being pragmatic, and doesn't deal with some abstract future, but only with here and now And even then, the situation now is quite unusual, it's not P.V.'s willful decision, but it's forced by circumstances, at least I understood it this way, so how many times this happens? And that's the point, we don't want to install that app PA is still not fully stable, sounds like c...p, it's poorly designed, and this brings security risks to the table. So I think it's quite reasonable to give those who need it some alternative, even if it's only possibility to ignore it more easily.
I guess you mean all possible requests? Because from what I've learned so far, it would need only some additional directories in 14.2, thanks to not having automatic dependency management? Once again, I think it's better to focus on here and now, and ask what's more reasonable thing to do. Leaving some users out in the cold is not, even if they can survive the chill on their own
Yes, I know. I'm not talking about it because I absolutely need it, but because I think (and I'm sure many others) it will make Slackware more cosy distro for everyone, and will be more faithful to its own philosophy (yes, I know, the ultimate Slackware philosophy is to do what P.V. wants it to do, I just have troubles imagining P.V. disappointing some of his users in this way, unless absolutely forced ).