Slackware is perfect the way it is. There is no need for adjustment from your BDFL. Slackware is a one man circus/army and doesn't need any outside input from those who don't follow protocol.
Leave well enough alone. Find another distro if you don't like it. Better yet, move to Windows, it might be a better fit. I'll wait for persecution from the cavalry. Here they come 3...2...1

says the person who recently is not able to make a post addressed to me without a totally wrong allegation.
As in this thread, where I start to give you info and you come with assumption about my motivations, false of course, and dogmas :-)
and who recently started a total off topic side blow on personal level against me for no reason.
Fanatics are able to prove them wrong withing some sentences, in this case posts, without even notice. The next prove you deliver four your mindset.


Since your obvious burn out syndrome is just superseded by your Stockholm syndrome (or why is it always you who plays the knight who defends the holy grale of Slackware), I think this is just a win.

Sad to see you became like this, kiki did obviously made a smarter move when he noticed that hist frustration level became to high. Seriously, if you burn away your life time for something that you self start to question, do not make others responsible for your your bad moode and stop putting discussions about things and ways of implementation on personal level.

1 members found this post helpful.

The logic is just broken by the wrong allegations that some, and their fan boys here, make constantly. And that you obviously following.
I talks about the philosophy that says, don't fix what is not broken, and that some say that non building packages are not broken. This is the example and prove why this is just a dogma that does not hold if you match it against reality outside of some believe system some create.

This is not Gentoo. You get pre-built binaries and the source, SlackBuild, and any patches used to create them. That's it. There's no guarantees beyond that.

Maybe it's time for you to move on from Slackware if you are so against its philosophy...

2 members found this post helpful.

people is starting to make fun of the ones freaking out about Spectre...

https://skyfallattack.com/

2 members found this post helpful.

The problem is Spectre is NOT meltdown. The reality is Spectre will if anything be used to escalate privileges by and attacker, likely by stealing credentials to than use with a higher integrity process or steal information from another process. In most cases that process Chances are pretty good successful Spectre based attacks will have to be against processes owned by the same user as well, because of interactions by other platform elements.

So we are talking about someone who has code execution already...Which means they can quite likely do things like say replace the binary they want to attack in the local directory with their own. If you have the local directory in your path that is the one your are going to get, the vulnerable one, so even re-comping the entire OS won't have helped you much.

If anything it probably makes the most sense to focus on places like browsers were we "allow" remote code execution sandboxed or otherwise. Those are going to be the jumping off points. If you fix the stuff like browsers, anything that handles documents with embedded scripts or macros, and anything that does RPC. You are probably pretty safe from Spectre as a practical matter. So its not necessary to recompile ever obscure binary. It won't matter if fsck.ext4 gets rebuilt with Spectre protections. It won't be part of the exploit in that way.

Sure in a perfect world everything would get rebuilt I suppose on a regular basis. I honestly can't dispute that. It also is true that the latest generation of top drawer CPUs paired with M2.e storage and 120 gigs of Ram probably can rebuild all of Slackware in just a couple days. I would suggest anyone who feels real strong about the necessity of doing that ponies up and buys Pat a rig like that. It might make him more receptive to your cause, or it might not. Who knows but you can always try.

3 members found this post helpful.

Forgive my off-topic rant. I do not have an opinion on the subject (i lean on a4z's side that it would be nice if slackware packages were compilable but i also understand that it will need much time from Patrick to chase patches for every time gcc changes its behavior).

I want to comment on this behavior that i see from some (unfortunately many) slackware users. Why is criticism so loathed ? With the slight bit of criticism, there is a barrage of replies "go use ubuntu", "go use windows", "we don't want slackware to change" and stuff like that.

Slackware is of course great and it has proven its worth again and again and has withstood the passing of time where other distributions were discontinued. That doesn't mean that it must stay still and can't be improved. I understand that "improvement" for some will be "downgrade" for others and i agree. Every idea that is being thrown on the table doesn't need to be incorporated by Patrick. Patrick can even discard 100% of the ideas, but why can we not discuss it ? Even if it is a stupid idea ? Why must there always be these hostile "go somewhere else" replies ? And we don't see this kind of behavior only for large controversial changes (like pam and systemd) but even for small changes.

Thank you for your time.

6 members found this post helpful.

I would prefer the term 'vulnerable' to 'broken'. The application functionality is still present, so not broken, but may be vulnerable to attack.
What is new in the landscape is the demonstration that speculative execution can be used to access privileged information. A previously hypothesised attack route has now been shown to be practically achievable. So we now see hardware manufacturers and operating system suppliers co-operating to address the issue.
An interim solution is software based, hardening the code base through compiler enhancements and operating system enforced privilege separation. The longer term solution is hardware based, removing a fundamental flaw through microcode updates and new hardware.
This thread is largely about what is the appropriate response for the Slackware community.
If you have a user base that you do not trust, then this is is an immediate threat that requires timely mitigation, as attacks in the wild are inevitable. For this case, an ability to recompile old packages is paramount, otherwise the vulnerability needs to be removed.
If you have a user base that can be trusted to not do silly things to expose a vulnerability, then you are more likely to want to retain existing functionality, rather than remove potentially vulnerable functionality.
Please people, this is a serious situation that requires sober consideration of what we have now, what is practically achievable and what is cloud cuckoo land.

3 members found this post helpful.

I think it is when an idea is presented to which Pat or Eric come in and say that whatever the idea is won't happen, but then people keep pestering. a4z knew what the answer was going to be before posting this thread, yet decided to post it anyway. We have had good discussions on potential changes to Slackware, but when there's thread after thread of discussion on the same topic and every single one has had someone in authority say that it isn't going to happen, people start to get annoyed.

Also, listing packages as broken when they indeed are not broken (building them might be, but this isn't Gentoo and the problem will be addressed the next time the program needs to be rebuilt) doesn't help the matter.

As for suggesting them to move onto a different distro, it seems that if your ideals clash with Slackware fundamentals so bad, that maybe Slackware isn't the best fit for you. I think many Slackware die-hard fans realize that Slackware isn't the perfect distro for everyone, even if it is for them. The beauty of Linux is there is probably a distro out there for everyone, and if they have so many issues with Slackware, maybe it's time to see if there's a better one out there for them. I suggested it might be time for a4z to move on because of this:

So, because it's used for nostalgia, Pat should increase his workload (probably exponentially) to ensure all packages can be compiled at any time, even if the already-compiled program works fine?

1 members found this post helpful.

I am afraid he will have to. Once we have a gcc version with spectre mitigation options everything not compiled with that version will be considered vulnerable. And most likely every new version will introduce more mitigation options making mandatory the ablility to easily recompile stuff.


Cheers

2 members found this post helpful.

There is a Weapon of Mass Building Slackware Packages: https://slackware.nl/alien-kde/source/5/

So, as I understand it:

• hardware mistakes where made that make it possible for software to be abused
• it is far easier to fix software than hardware
• although easier (and cheaper) to fix than replacing every CPU bought in the last 20 years, recompiling all software is not trivial

Nice...

Lets just put aside (for just a moment) the fact that not all Slackware packages compile cleanly from source on the newest version of the OS.
Does Slackware (I mean Pat) have an automated way of compiling bulk packages in one go, or does every slackbuild require personal attention?
It would help a lot in situations like a total rebuild if the former and suck if the latter...

I don't want to sidetrack the discussion or hijack the thread, so apologies in advance to the OP.
I'm just curious and interested in a build farm for Slackware.

2 members found this post helpful.

I agree with everything you posted. My comment was sarcasm for the ones who have their heads stuck so far up PVs [explicit], no one is able to have a unbiased/non-biased opinion whether it be polite or rude. I share your sentiment. I'm just riding the wave, don't pay me no mind. The cavalry has come to rescue their Savior.

Can you please not tell users with valid issues to go to other distros? Its lame and just casts a black mark on the quality of this thread and forum.

The bottom line is providing mitigations against security issues is not against the Slackware philosophy and you're getting bent out of shape over nothing.

5 members found this post helpful.

This would be a one time requirement (possibly more than one, depending on how gcc patches progress), not a permanent change in his workflow.

We don't know how things will progress, it might only require total recompilation sparingly, not every new version.

His complaint about programs that can't compile occurred long before Spectre or Meltdown was ever made public. Simply put, packages are not broken, even if the source used to compile them no longer results in a package.

And I don't think it is bad to suggest that Slackware isn't the best distro for everyone. That is a statement of fact. For some, it may be beneficial to find a different OS that better suits their requirements. That could be a different Linux disto, OSX, or even Windows. There is not one OS that is perfect for everyone. Pretending that Slackware is the perfect OS for everyone is stupid, and when someone feel so strongly against the way Slackware does things, maybe it's time for them to move on.

Pat will make the decision on how to handle recompiling the OS to mitigate security concerns. That doesn't require that he permanently change his workflow to allow for all packages to be able to be compiled at all times. That would mean for each package he adds to Slackware, he would have to recompile every single one that might be affected by it to ensure that the package didn't break compilation, even if the programs still function perfectly.

1 members found this post helpful.