Apparently he's going to do a fifth film as Bond...

https://www.theguardian.com/film/201...mes-bond-again

unless you have the 3 magic gcc/glibc/kernel pieces to build the distribution, you'll have to wait.

1 members found this post helpful.

I agree that this is premature, but it does seem worth considering once the relevant patches land. I know this is generally not how Slackware is developed, but it seems this time there is a good reason to make an exception.

Your text was "Short summary: Some time ago we had discussion if packages that do not build anymore are broken or not. Of course they are, but some see it different." and I responded to that. You never mentioned recompiling packages for the CPU vulnerabilities in that post of yours.
Also, even in that case the packages you'd want to recompile to harden them against these vulnerabilities are still not broken. It's the hardware that is broken, the packages are just fine.

Yes, that is why Slackware is still around as the oldest actively maintained distro - because its developer sticks to his master plan and does not run around in an air of chaos and panic like those other distros.

6 members found this post helpful.

Of course that is not a good reason! The worst thing to do is let yourself be driven crazy by people yelling that they need protection NOW. Almost all released patches have already been refactored and re-released, Red Hat refuses to ship the new Intel CPU microcode, instead pointing its customers to Intel 's customer support and Microsoft's initial patches left bewildered early adopters with irrepairable blue screen of death.

Just sit this out. And realize that the Spectre hole will never be fully closed. It's an architecture fault which can not be shuffled under the rug by software.

7 members found this post helpful.

The problem with this reasoning is that its far less practical to fix the hardware than it is to "fix" the packages.

What part of "can't be fixed by software, must be corrected by hardware architecture" as reported by Intel did you not understand? Eric's whole point is that even the software patches are not going to mitigate this possible if you have LOCAL access to the computer attacks. Additionally software patches are still "early" adoptions ( in other parlance it would be called development, IE unstable, IE may break your system) and the fallout of what breaks isn't yet understood by Intel or the kernel dev's. This whole thread is premature and actually being continued by hysterics and not real information from Intel or the kernel devs.

Eric and others have answered the question, "pls fix all non building packages". There are no non building packages which aren't being addressed and/or fixed in the the thread "packages not building on current". There are no packages for stable which don't build with the gcc/kernel/sources that are supplied under the 4.4.111 kernel Pat has provided. If there are then start a thread "packages not building on stable after latest kernel release" or something similiar so that the helpful posters here on LQ can look and address the issue. Pat cannot deliver something which is not yet developed or not broken. If you are taking proper security precautions then this preoccupation with Meltdown and Spectre is truly a waste of time while our very supportive Slackware guru's could be giving real support to others who need it.

2 members found this post helpful.

I see what you did there

1 members found this post helpful.

@barmunds You should actually read the thread before jumping off on a tangent. If you read the thread you would see that I certainly do agree that this thread is premature. However when the relevant patches land I do think it is worth considering taking time to rebuild packages and fix the builds as necessary.

At the risk of sounding like a broken record, fixing the hardware is not practical here and whether this is a hardware bug or not doesn't really change anything for hardware that has already been purchased and is currently in use.

wow, just, wow. upcoming religious fanatics should go into a rhetoric course at you to learn how to explain reality for that it makes sense for your needs, my respect!

maintained, hm, archived, hm, developed, no. well chosen word, maintained.

and don't get me wrong, also all others here that say I want something from Slackware to be...,
of course I would be happy if there would be some development in Slackware, but
I don't need it, its on one computer I use from time to time, just for nostalgically reasons, but for everything else there are other distros, and to build a distro there is yocto.

I think this is the point where we part ways respectfully (or not... I don't care - I respect your contribution 'sbbdep' but I do not respect you as a person). You - not I - are on a high horse all the time. You being the one that constantly nags about the defects in Slackware while not even using Slackware. Me feeding the community with packages, documentation and scripts and as a thank-you getting shat all over by cases like you.
Bye bye.

9 members found this post helpful.

I haven't been here long but I've noticed that a4z has a bee in his bonnet with you, Eric. It seems personal, for some reason. I really appreciate your efforts, as a new Slack user. They helped me get off the ground.

3 members found this post helpful.

https://spectreattack.com/spectre.pdf:

And in addition, the utter mess that Slackware build scripts are, will present major practical challenges for those trying to rebuild the distribution.


Cheers

2 members found this post helpful.

First I did read the entire thread and second I'm glad you agree this thread is premature.
When is the right time to ask that a software which isn't broken be fixed? That seems like not only premature but actually not in sync with reality. Reality is the software is working as designed, even with the latest stable release parts of Slackware. Even the hardware is working as designed. The problem is that hardware design had a technique which can be exploited, and software is now sophisticated enough to take advantage of the flaw. Both hardware and software therefore must be "replaced" to mitigate the threat.

Actually it does change everything. The OP first states that broadly that software is broken, which it isn't, because it can only use the hardware microcode and designs to execute, then ask that software mitigate a threat which will always be present due to the design of the hardware. Additionally both the hardware manufacturer and Linux developer have stated the microcode and hardware components must also be "replaced" to fully mitigate the "usecase". These experts don't say anything about software being broken or not functioning as designed. Further OP says in post #1 Which is blatantly not true. The OP does not identify ANY packages that are broken and don't compile under Slackware stable/current or the two compilers that stable/current use. The OP's statement is bad logic at best.

I understand that you feel it is impractical to fix the hardware, for cost or lack of funding. I share that concern, I have a 2005 Intel CPU, which might never get an updated microcode. BUT I also accept that Intel and the Linux Kernel developer have both said it requires both to fully mitigate these threats. So one has to accept the full answer and stop pushing for a software only fix which will never fully mitigate the threat. Or if you are unwilling to fix the hardware I suppose you simply stay away from the Internet, bluetooth, wifi, and all other ways that an attacker could get access to your system. But how practical and financially impacting that would be to you, well only you can decide on the risk. Just remember when it comes to Slackware you decide how to spend your money and time to maintain your Slackware Linux system. Cheers.

1 members found this post helpful.

@bamunds

You are kidding, right? Everyone should buy new CPUs, right?

How about instead everyone to sue those filthy companies which sell crap since the last 20 years?

At least you guys, living in the First World, you should sue them from orbit! All of yours!