81–90 of 329 posts
Earlier quoted context omitted.
Those were not delivered fixes, that was work in progress that is still work in progress. And the dude who was "called out" works for Amazon.
FYI - The “dude” from Amazon worked for Intel for 8 years before joining Amazon UK just over a year ago.
Earlier quoted context omitted.
> On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; This is wrong... there's no clear-cut thing like the "file name" or "file stream" that you can specify as "in-use". It depends on the specifics of how the file is opened; often you can rename but not delete files that are open. Some (but AFAIK not all) in-use DLLs are like this. They can be renamed but not deleted. A…
Yes, in principle what you've said about the Unix approach here is correct, if you upgrade one half of a system and not the other half and now they're talking different protocols, that might not work. But keep in mind that if your system can't cope with this what you've done there is engineer in unreliability, you've made a system that's deliberately not very robust, unless it's very, very tightly integrated (e.g. tw…
> But keep in mind that if your system can't cope with this what you've done there is engineer in unreliability
It's weird that you're blaming my operating system's problems on me. "My system" is something a ton of other people wrote, and this is the case for pretty much every user of every OS. I'm not engineering anything into (or out of) my system so I don't get the "you've made a system that [basically, sucks]" comments.
> [other arguments]
I wasn't trying to go down this rabbit hole of Linux-bashing (I was just trying to present it as as objective of a flexibility-vs.-reliability trade-off as I could), but given the barrage of comments I've been receiving: I don't know about you, but it happens more often than I would like that I update Linux (Ubuntu) and, lo and behold, I can't really use any programs until I reboot. Sometimes the window rendering gets messed up, sometimes I get random error pop-ups, sometimes stuff just doesn't run. I don't get why it happens in every instance, and there might be lots of different reasons in different instances. IPC mismatch is my best guess for a significant fraction of the incidents. All I know is it happens and it's less stable than what you (or I) would hope or expect. Yet from everyone's comments here I'm guessing I must be the only one who encounters this. Sad for me, but I'm happy for you guys I guess.
I never got them. The last update in my windows is from Dec 2017. My antivirus is compliant, the registry key correctly set up and yet it refuses to update. I still haven't had the time to debug it, but I wonder how many people are out there with their OS silently refusing to update.
I had huge problems with Win 10. Updates wold fail and install again and again without actually getting installed. Sometimes I would get an opaque error number but web searches revealed nothing for that number, and it was rare that I would be able to find even an error number. I don't do Windows, and just installed it for VR, and didn't spend that much time in Windows, so I would spend 15-30 minutes looking a month,…
Maybe I just got lucky with the right combination of hardware.
Earlier quoted context omitted.
Oh, this is the same issue?
It's the same bug, same company pushing patches, but we don't know if it's the same reason.
It's also not the same reason. Linus doesn't like the mitigation in the kernel, disagreeing on how Intel intends to implement it. This article is about unstable microcode patches that Intel retracted, and that retraction has been discussed on here a few times. The article is just exceedingly bad at describing the actual issue. It also doesn't help that the kernel mitigation depends on new flags introduced by the faulty microcode update, but the update being faulty is orthogonal to Linus' opinion.
A more accurate title would be that Microsoft disabled the specter mitigation’s due to a flawed Intel update, right? I thought this was all Microsoft’s fault until getting half way through the article.
Earlier quoted context omitted.
> On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; This is wrong... there's no clear-cut thing like the "file name" or "file stream" that you can specify as "in-use". It depends on the specifics of how the file is opened; often you can rename but not delete files that are open. Some (but AFAIK not all) in-use DLLs are like this. They can be renamed but not deleted. A…
> What I expect it also means is that you'll get inconsistencies when doing inter-process communication, since they'll be using different libraries with potential mismatches. In theory, but Linux systems tend to do very little IPC other than X11, pipelines, and IP-based communication, where the protocols tend to support running with different versions. In practice you can achieve multi-year uptimes with systems until…
A more accurate title would be that Microsoft disabled the specter mitigation’s due to a flawed Intel update, right? I thought this was all Microsoft’s fault until getting half way through the article.
It's really telling that even Linus Torvalds was not happy with their "fixes" and now Microsoft. Intel needs to start taking the situation completely seriously cause their actions don't imply they are.
Earlier quoted context omitted.
FYI - The “dude” from Amazon worked for Intel for 8 years before joining Amazon UK just over a year ago.
The “dude” is also probably working under an insane amount of pressure and being made to feel like he is somehow responsible or at fault for the whole situation. Best not to make it personal from the peanut gallery.
Earlier quoted context omitted.
It's really telling that even Linus Torvalds was not happy with their "fixes" and now Microsoft. Intel needs to start taking the situation completely seriously cause their actions don't imply they are.
Intel doesn't care. What choice do we have?