You are pretty sure? BOB said that?

WHAT IF this July they discover another Breakdown and Phantasm, which will leave our operating systems, well... pants down? And in September again the crap will hit the fan?

I am afraid, dear Frenemy, that the Heroic Age of (manually) building operating systems just ended in a... Meltdown and the Spectre of hardware vulnerabilities will haunt us for loooong time since today.

Because their Age just started, after all.

That's why I believe too, that now arrived the time of hundred (re-)checks on full rebuilds; read: mass building of packages, to adjust them against those present and future hardware vulnerabilities.

I agree that Slackware (or any other distro) is not for everyone. However, i believe (of course i may be wrong) that the phrase "slackware is not for you" is pretty dismissing and, especially in a discussion forum, should be the last that comes to our mind, not the first. Isn't it possible that slackware is indeed best for a user except for a certain "shortcoming" ? I hate to mention pam (i am not trying to secretly ask for pam ) but it is the first example that comes to my mind. There are people that like everything about Slackware but they need pam for their enterprise integration or some reason.

Why is it so annoying to some users if they politely discuss about it (even if, as you said, it has been discussed in the past) ? Even if we agreed that it is annoying / unnecessary, isn't a "this has been discussed in X thread and we have reached the Y conclusion" reply better than the "slackware doesn't need pam. use ubuntu / windows" reply that we usually read by certain users ?

Some times we look like some grumpy old guys in movies that don't want to even hear about even the smallest change.

2 members found this post helpful.

I never suggested otherwise, I expect Pat to be fully capable of making his own informed, reasonable and practical solution to this issue when the time is right. My complaint is not with Pat or any of the other Slackware maintainers, but this unproductive bickering about some likely misinterpreted Slackware philosophy which certainly does not mitigate or resolve any real security issues.

4 members found this post helpful.

Slackware is a special snowflake. The reason it works as well as it does is *exactly* because of its style of development.

2 members found this post helpful.

This story has nothing about the development style, it is directly about (re-)compiling the software with special anti-Spectre flags, in whatever way.

It is entirely about its development style. And my vote goes to locking this thread.

4 members found this post helpful.

So another one pops up in a week or so? Until you and others face reality, these type of discussions will forever remain. Regardless of what you feel.

Fortunately for us, here is not the Soviet Union.

In Soviet Russia, thread locks you.

2 members found this post helpful.

Don't you think Pat and the rest of the Slackware dev team is well aware of the situation and implications? As it always has been in the past, practical and pragmatical measures will be taken. But I guess it's easier to shout ZOMG we're vulnerable!!1 Majority of problems has already been taken care of with kernel updates and microcode. The rest will take some time, sit back and relax. It is very hard to exploit anyway. Is your porn so important anyway? Hurtmuch, butthurt? How about giving thanks and support to the Slackware team instead?

3 members found this post helpful.

Addressing the OP's point:

I'm not sure I understand the logic in asking all users of -current to update all their packages just to see if they compile and run ok with the current versions of gcc/glibc etc knowing that they'll all have to update them all again once the mitigations start feeding their way in.

Mitigations that will themselves possibly dribble in, requiring cascading updates - for a non-mitigation example look at current and notice how mpfr-4 is progressing up through the packages requiring many to be rebuilt.

This extra step you are asking for sounds like a lot of extra work for the Slackware team for limited gain.

If you are simply looking for tips on what needs changed, you might instead look at Slackwarearm-current which started life much more recently and has fewer 'old' packages or Worsels and Nobodino's work on 'Slackware from Scratch and X11' or Ivandi's Spamware.

Or even look at how other distros do it, LFS, BLFS, Gentoo etc.

The clues for a lot of it are already out there.

1 members found this post helpful.

OMG, the usual, 'Pat should increase his workload' arguemnt,
no, if he does not want, I give a s..., if I can not use it, I donate to things I use before, OK?
but I am allowed to have an opinion, yes, or inform here about some realities. Or is the religious like behavior already so strong that not even this is allowed anymore?

Btw, if you have nothing else to do than developing an distribution than this is not too much to do, if you have other tasks you need either help, or say I can not do it, but not come with a 'do not fix because not broken' blabla.

and for you, since you seem to be a nice guy, I recently posted what the last use case I have for Slackware is, and what I would need that I can keep the use case in future. A very visible use case btw. Guess what happened? Read it, and if you have any questions a repacked 32bit package is not the same than a real multilib package, just ask ;-)

To the situation at Slackware, of course I would be happy to see some development in Slackware, fix the obvious broken things, PAM, multilib, build scripts, not recompile everything, usual stuff in 2018, all topics we had in last time and before, since longer time
Than I could use it as a tool for more tasks.
Like years ago, where you could do with Slackware everything that you could do with other distros, than things divided, and today you would need to replace too many parts of Slackware, and some are not even to replace, that is practically impossible. So I use other tools for the job, the right tool for a job, you know this philosophy maybe.
But your 'Pat should because of me'... assumption, sorry, don't follow other on rhetoric paths, this is just embarrassing to read

My porn is not so important, but honestly I will feel really, but really butthurt if my bank account will be emptied by some "genius", you know...

That's is at stake: my bank accounts, not my porn, dear comrade Sramov.

No distribution or CPU will save you from this Common sense prevails.

The process of discussion for solution must be built on facts, which are not speculations.
FACT: there are no compilation issues in stable which aren't caused by user mis-actions or flag misuse.
FACT: many hundreds of applications have already been processed by the new GCC in -current and completed without issues or corrected to compile successfully.
FACT: there are some applications which are still in process of review to compile under the newest Slackware GCC for -current, which is by FACT a development branch and not for the normal user or to be used in a production environment, which the Slackware and development team have documented on the Slackware website and repeat many times.
FACT: Other distro's haven't issued new code compilers that mitigate the newest threats, even though they have even larger development teams than Slackware.
FACT: Slackware has issued a new Kernel that implements the software side of mitigation for one of the Spectre threats already, although new microcode is also necessary and Intel has not issued that code for CPU's older than five years.
Speculation: All these posts are because the OP and some others like to poke at Slackware simply to have long threads of hysteria and illogical debate, which has already been discussed, rejected, and never helped the Slackware development team.
Speculation: The OP is trying to discourage the Slackware team. The old saying of "If you can't say something positive, then don't say anything at all" can be applied here. If the OP wanted to help the team they would not have posted a premature question. They would have looked at FACTS and using -current development branch tried to patched, from some unknown developer, the newest available GCC and then tested that patch on an application, under newest Slackware Kernel. Which would have been a contribution instead of deterring argument.

Cheers

1 members found this post helpful.