> HP, Dell, Lenovo, VMware, Red Hat and others had paused the patches and now Microsoft has done the same.
Yes, I know that most people don't build new PCs or upgrade their processors that regularly. Yes, I know that many people don't have much of a choice because they have some requirement that currently ties them to Intel. However, those that do have that choice, should remember this debacle the next time they are buying a CPU/system (even if they are not doing it for awhile). Intel is hoping they can sweep this under the rug, we can't let them until they make amends. Do not buy an Intel chip until they've proven they will do better. I am not endorsing AMD either. You can still vote with your wallet by not buying anything at all. If enough people put off their upgrade, it would put a dent in Intel's bottom line. Things won't change until it hurts them financially.
They have already provided them:
https://github.com/GPUOpen-Drivers/AMDVLK
https://www.phoronix.com/scan.php?page=article&item=amdvlk-r...
I mean, I’m not putting Intel out of business, but I have a -choice-.
Time to go off the beaten path.
A few ARM SoCs -- including the entire line used in Raspberry Pi boards -- are safe, but the vast majority of recent ARM devices are affected by one or more of the attack vectors. This means virtually any flagship and most if not all midrange smartphones and tablets, even iPhones and iPads, are vulnerable.
This is the most complete list of affected CPUs and SoCs I've found, and they appear to be keeping it updated:
https://www.techarp.com/guides/complete-meltdown-spectre-cpu...
Had a friend do that... He bought 3 acres, spent a couple years building a cabin in his free time. Then one day just quit and went off to the woods.
Still visit him and he seems pretty happy with it. He doesn't need much income and makes enough money off odd jobs he seems to be doing pretty well.
2) http://americanbeejournal.com/insights-honey-pollination-pac...
This actually made the system boot but there are some leftovers being installed on first boot that I've been unable to disable that also causes the system to be unable to boot.
So now, the machine is running but as soon as it is restarted we have to re-image the disk, go through the process of manually removing patches, and then pray that we don't have a power shortage as we'd have to do everything yet again on next boot.
I'm not convinced that this patch will solve the issue either, because if this updates requires a reboot the fix won't be installed if we can't boot. I might try to install this update from the recovery console see if that works.
Quite frustrating.
That patch disables the use by the kernel of the new IBPB/IBRS features provided by the updated microcode, when it's of a "known bad" revision. Since Linux prefers the "retpoline" mitigation instead of IBRS, and AFAIK so far the upstream kernel (and most of the backports to stable kernels) doesn't use IBPB yet, that might explain why Linux seems to have been less affected by the microcode update instabilities than Windows.
Also interesting: that patch has a link to an official Intel list of broken microcode versions.
Linus probably won't pull it until it's truly known to be stable, because of his attitude towards having decent quality code and not causing needless system instability.
Without Linus... who knows what would have happened by now.
But yeah, upstream Linux kernel development is taking it slow. As far as I can see, variant 3 mitigations (PTI) are already in, variant 2 mitigations are partially in (retpoline) and partially not (the microcode dependent ones), and variant 1 mitigations are still under discussion.
There is an interesting paradox in our industry. If you pay enough attention (read: money) to security, you will be late to the market, your costs will be high and you lose profit. If you don't pay enough attention, you take the market, get your profits, but your product (be it hardware or software) and reputation will be screwed later. And worst of all: there's never enough attention to security.
So by simple logic, an optimal strategy is to forge your product quickly, take your profits within a [relatively] short period and vanish from the market. I guess we'll see this strategy executed from IoT vendors when market start to punish them for their bad sec.
For Intel, that "long period" just happened to be REALLY long.
All markets work like this. People bitch about the quality of products, but still buy the cheap stuff.
Interestingly, I think AMD has a lot of motive to create such a superflu, or at least encourage it's creation.
Intel may be too big for an abrupt failure, but they can absolutely fail in a decade-long slide into obscurity.
What's next? Repeat? Sounds like this could turn into a maintainance nightmare quickly. Also because I've introduced things like that myself in the past, and that was for normal applications and not a kernel or OS. Somewhere, someday, there's usually this one exception for which none of your rules hold true and the thing blows up in your face. Anyway, I'd love to see the actual code for this. Not a chance probably?
Intel's actions seem to shout that they have cared far more about releasing Kaby/Skylake X and Coffee Lake in short order, as a response to Ryzen/ThreadRipper, than actually really digging into fixing their major security flaws. Their actions speak of them preferring to keep their market and mindshare over actually fixing any security issues.
Intel is still so deeply entrenched that they likely believe that they can get away with their lazy approach. They make millions upon millions, if not billions of dollars ~ why should they give a shit, when their monopoly and half-hearted attempt at a solution will get them by? Intel is being strangled by their shitty management, seemingly...
Intel certainly isn't making any friends these days...
https://www.bleepingcomputer.com/news/microsoft/microsoft-is...
for server, Epyic is now finally available to purchase for desktop workstation Threadripper for desktop RyZen
for mobile... not many newer cpus out yet.. need to wait :(
* How promptly did they address the issue via official channels, i.e. did they leave users in the dark as they appealed to vendors in their forums (hint: most of them seem to have gone down this route) or did they share updates directly on their official sites, social media accounts, etc.
* Did they provide some estimates as to when users could expect patches?
* How much of their product catalogue were they willing to cover with security updates? Since this is a unique security issue with high impact I would have expected them to cover motherboards at least 4-5 years old.
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
https://www.wired.com/2002/01/bill-gates-trustworthy-computi...
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.
After probably 9 months of this, and with Windows doing ever more intrusive pop overs whenever I launched it for updates that don't take, I wiped all boot sectors everywhere and installed from scratch. That seemed to work, but it was incredibly frustrating that the boot process was so buggy as was error reporting. I've never encountered a situation like it in the past 15 years of heavy Linux use. Problems there are usually solvable with a couple web searches, even for extremely obscure kernel bugs with obscure packages. Windows refused to tell me anything as did the web.
Maybe I just got lucky with the right combination of hardware.
Remember to use backups!
https://www.techrepublic.com/article/03175c88-5c9b-4ccd-ac62...
I sure hope Intel will face a class action suit over this botched update. Many professionals have wasted countless hours dealing with this junk.
https://support.microsoft.com/en-us/help/4078130/update-to-d...
https://support.microsoft.com/en-us/help/4072699/january-3-2...
Customers without Antivirus
In cases where customers can’t install or run antivirus software, Microsoft recommends manually setting the registry key as described below in order to receive the January 2018 security updates.
I thought stopping updates was only for the case of unpatched AVs that did not set the registry key...
Why he gets a pass for being the 'nice guy' and DeRaadt gets the bad rep is still a mystery to me
A part of me feels this stories like this are going to keep getting worse until Spectre is finally used in the wild.
The day this blew up we rented our first physical server for the express purpose of running secure critical workloads in unpatched environments. Yes, I know that there is nothing secure, but not everything we do is running a chunk of logic uploaded by an attacker, so we will take our chances.
On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; Therefore, if you want to replace a DLL (or any other file) that is in use, you have to kill any program that uses it before you can do that; And if it's a fundamental library everything uses (USER32.DLL COMCTL.DLL etc), the only effectively reliable way to do that is reboot.
On Unix, once you have a handle=descriptor of the file, the name is irrelevant; You can delete or rename the file, The descriptor still refers to the file that was opened. Thus, you can just replace any system file; Existing programs will keep using the old one until they close/restart, new programs will get the new file.
What this means is, that even though you don't NEED to restart anything for most upgrades in Unix/Linux, you're still running the old version until you restart the program that uses it. Most upgrade procedures will restart relevant daemons or user programs, or notify that you should, (e.g. Debian and Ubuntu do).
You always need a reboot to upgrade a kernel (kernel-splice and friends not withstanding), but otherwise it is enough in Unixes to restart the affected programs.
Can't speak for everyone else, but Windows fully supports shared file-access which prevents the kind of file-locks which causes reboot requirements.
The problem is that the default file-share permissions in the common Windows APIs (unless you want to get verbose in your code) is that the opening process demands exclusive access and locking to the underlying file for the lifetime of that file-handle.
So unless the programmer takes the time to research that 1. these file-share permissions exists, 2. which permissions are appropriate for the use-cases they have in their code, and 3. how to apply these more lenient permissions in their code...
Unless all that, you get Windows programs which creates exclusive file-locks, which again causes reboot-requirements upon upgrades. Not surprising really.
In Linux/UNIX, the default seems to be the other way around: Full-sharing, unless locked down, and people seem prepared to write defensive code to lock-down only upon need, or have code prepare for worst-case scenarios.
There is a registry key which allows an update to schedule a set of rename operations on boot to drop in replacement file(s). https://blogs.technet.microsoft.com/brad_rutkowski/2007/06/2...
We are getting there on Linux too - with atomic or image based updates of the underlying system. On servers you will (or already) have A/B partitions (or ostrees), on mobiles and IoT too, some desktops (looking at Fedora) also prefer reboot-update-reboot cycle, to prevent things like killing X while doing your update and leaving your machine in inconsistent state.
macOS also does system updates with reboot, for the same reasons.
At least on *nix, even when you need a reboot, once is enough.
Historically (Windows 95 and earlier) reboots were required to reload DLLs and so on but that’s not really true anymore. Still a lot of installers and docs say to reboot when it’s not really necessary as a holdover from then
I'm running with Windows Update service disabled till this is fixed for good !
[1] https://answers.microsoft.com/en-us/windows/forum/windows_10...
I actually like Win 10, but it's shit like this that keeps me from becoming a true convert. Oh, for $X00 I can get enterprise update, but IMO that's just Win 10 home being used as ransomware. /rant
https://www.cnbc.com/2018/01/26/intc-intel-stock-jumps-to-hi...
I think it's our responsibility as technology literate folks and decision makers to explicitly highlight their failures so that mistakes and poor handling like this are not normalized.
I work in a bank and they are terrified of the possibility of user processes reading privileged memory. Not necessarily out of actual fear but out of the insane amount of paperwork this will require to satisfy the auditors that it is still safe.
Anecdotally, but you asked for "someone" and here is someone :)
- Theo de Raadt
[1] https://www.msi.com/news/detail/7yJ7XCklfBXt8mFhG8nkfSurJUz3...
This is not always correct; see: https://news.ycombinator.com/item?id=16256483
https://blogs.gnome.org/hughsie/2012/06/04/offline-os-update...
https://www.freedesktop.org/wiki/Software/systemd/SystemUpda...
https://fedoraproject.org/wiki/Features/OfflineSystemUpdates
It's still much faster than a Windows update (at least on my SSD system).
And speaking from experience, the recent macOS way of applying an update is absolutely insane - on my Macbook Pro (with the stock SSD with 3GB/sec read and 2GB/sec of write) a small system update can take 10+ minutes to install
MS doesn't provide an easy, GUI way of disabling built-in Defender by the way. If you 'disable' defender by using the control panel on windows 10, it only stops its activity temporarily and it can reactivate itself after 24 hours or something like that. You can permanently disable it through registry keys but it's not an officially supported, accepted method to edit the registry by yourself. There's a group policy for 10 Pro and other corp editions though.
For a normal home user, Defender is never fully disabled. It will deactivate itself if you install a third party antivirus, and reenable itself when you uninstall them. Bottom line, the average user is not supposed to be AV-less.
So get a patched AV. If you haven't installed another AV, then Defender is there and counts.
https://developer.arm.com/support/security-update
The Meltdown/Spectre class of attacks affect certain CPUs. Spectre is a microarchitectural attack on any CPU that does speculation and uses data caches, regardless of architecture.
Arguably, it has been handling Meltdown and Spectre in a much much more humble and transparent way. See https://developer.arm.com/support/security-update/compiler-s... for work they are doing with the compiler communities to address the Variant 1 both on current and future chips.
Also, CPU design changes take a long time. 6 months may seem a long time from the perspective of HackerNews node.js type hackers, but it's a bit harder to patch decades worth of CPU microcode than a website.
also look at the exploit numbering:
Variant 1: bounds check bypass (CVE-2017-5753) Variant 2: branch target injection (CVE-2017-5715) Variant 3: rogue data cache load (CVE-2017-5754)
according to https://cve.mitre.org/cve/identifiers/ this is sequence based so `Variant 2` was recorded to CVE before v1 and v3.
I get it may take a long time (that is fine even if the patches took a few more days), what I don't get is that they released it to production (server) envs seemingly without testing. Surely even rudimentary testing (deploying on a few 1000 different server platforms for a few hours at least should be something that Intel does for all microcode updates, after all they are rather more important than js Node packages as you point out)
No it is exactly the same principle: something has changed therefore invalidate all existing contexts. Far less error prone than trying to recompute them, what happens e.g. if a resource has already been accessed in a context that is now denied? Security 101.
As for logging other places out, that's a design choice. People change password either because they routinely change theirs (they either need to or choose to), or because of a (suspected) compromise. In the latter case you'll probably want to log everyone else out (though, who says you're logging out the attacker and not the legitimate user?) and in the former case you shouldn't (otherwise changing your password becomes annoying and avoided). The interface for changing the password could have a "log out all sessions" checkbox or it could just be a feature separate from changing your password.
No, it's not as simple as you put it. No need to condescendingly pass it off as "security 101".
Taking it slow seems very appropriate to me. This seems to me to have been a case of everybody grossly overestimating the short-term portion of the catastrophe, and underestimating the long term.
In the short term, the only people who were going to be plausibly affected in the next three to six months are people on shared hosting of some sort where you may share a server with somebody else's untrusted code, where an accelerated fix is in order, but also something that can be centrally handled. I'm not that worried in the next three to six months that my personal desktop is somehow going to be compromised by either Meltdown or Spectre, and personally, if I see a noticeable performance issue I may well revert the fixes (I'm on Linux), because first you have to penetrate my defenses to deliver anything anyhow, then you have to be in a situation where you're not going to just use a root exploit, which probably means you're in a sandbox or something which means it's that much more difficult to figure out how to exploit this. For most users, uses, and systems, spectre and meltdown aren't that immediately pressing.
Meanwhile, in the long term this may require basically redesigning CPUs to a very significant degree; there is no software patch that can fix the underlying issues. It is difficult to overstate the long term impact of this class of bugs. IMHO the real problem from the jousting match with Linus and Intel last week isn't that Intel's patches today aren't quality code, but that it makes me concerned that they're just going to sweep this fundamental problem under the rug. As I said in another post on HN, I fully understand that remediating this is going to be years, and I don't expect Intel to have an answer overnight, or a full solution in their next "tock". But if they're not taking this seriously, we have a very large long-term problem. We're only going to see more leaks in the long term.
Apart from browsers, it's fortunately pretty easy to avoid running code you don't trust on your devices.
Note I did not say there is no reason to be concerned about Meltdown and Spectre... just that for most users, uses, and systems, it's not that important. In the next three-to-six months, if you care about security at all, unless you are already running a tip-top tight operation, your money and effort is better spent defending against the many already-realistic threats, rather than worrying about the vector that may someday be converted into a realistic threat. Meltdown isn't what is going to drag your business to a halt next week; it's that ransomware that one of your less-savvy employees opened while mapped to the unbacked-up world-writable corporate share that has all the spreadsheets your business runs on. At the moment, the net risk of applying the Meltdown fix comfortably exceeds by several orders of magnitude the risk that Meltdown itself poses.
And my point is precisely that for most users and uses, that panic was not justified. Those for whom that is not true (VM hosting companies) already know they need to be more aggressive. There was no point in pushing out patches that nearly bricked some computers.
For something like this, I think best-effort bad-AV detection would have been best. Seems pretty insane to disable security patching because they can't be 100% certain that you have a compatibly AV.
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.
That's a very uncharitable interpretation of your parent comment, which was simply pointing out his connection and history with Intel.
Disabling security patches is not acceptable in current year without A LOT of nasty and annoying warnings.
I read the peanut gallery comment as an agreement that the guy knows what he’s talking about.
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. And then there's FILE_SHARE_DELETE which allows deletion, but then the handle starts returning errors when the file is deleted (as opposed to keeping the file "alive").
To make it even more confusing, you can pretty much always even create hardlinks to files that are "in use", but once you do that the new name cannot be deleted unless the old name can also be deleted (i.e. they follow the same rules). This should also make it clear that it's not the "name" that's in use, but the "actual file" (whatever that means... on NTFS I'd suppose it corresponds to the "file record" in the MFT).
The rule that Windows always abides by is that everything that takes up space on the disk must be reachable via some path. So you can't delete in-use files entirely because then they would be allocated disk space but unreachable via any path.
> What this means is, that even though you don't NEED to restart anything for most upgrades in Unix/Linux, you're still running the old version until you restart the program that uses it.
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. Is this correct? Because it seems to me that the Windows method might be less flexible but is likely to be more stable, since there's a single coherent global view of the file system at any given time.
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. two sub-routines inside the same running program) the cost savings had better be _enormous_ or what you're doing is just amplifying a problem and giving it to somebody else, like "solving" a city's waste problem by just dumping all the raw sewage into a neighbouring city's rivers.
Now, the "you can't delete things because then the disk space is unreachable" argument makes plenty of sense for, say, FAT, a filesystem from the 1980s.
But (present year argument) this is 2018. Everybody's main file systems are journalled. Sure enough, both systems _can_ write a record to the journal which will cause the blocks to be freed on replay and then remove that journal entry if the blocks actually get freed up before then. The difference is that Windows doesn't bother doing this.
Unix semantics were IIRC in place as far back as v7 (1979), possibly earlier - granted, a PDP disk from that time was bigger (~10-100MB) than the corresponding PC disk from a few years later (~1-10MB), but an appeal to technological progress in this particular example case is a moot point.
> 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.
Only if the libraries that use IPC have changed their wire format between versions, which would be a pretty bad practice, so I wouldn't expect that to happen often (if ever).
If something that's already running has its data files moved around or changed sufficiently, and it later tries to open (that is, the app was running but the data file wasn't open when the upgrade happened) what it thinks is an old data file, but is either new and different or just missing, that could cause problems.
> Because it seems to me that the Windows method might be less flexible but is likely to be more stable, since there's a single coherent global view of the file system at any given time.
In practice I've never had an issue with this (nearly 20 years using various Linux desktop and server distros). Upgrade-in-place is generally the norm, and most people will only reboot if there's a kernel update or an update to the init system.
kgraft for example swaps off each syscall for a process while it is not being used. This lets the OS slowly transfer to the new kernel as it is running.
kpatch does it all in one go but locks up the system for a few milliseconds.
The version that is currently merged into 4.0+ kernels is a hybrid of the two developed by the authors of both systems.
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 you get a mandatory kernel security update.
At the first glance this is true, but you can guard against this in several ways. If your process only forks children then it already inherits the loaded libraries from the parent as part of the forked address space. Alternatively you can pass open file descriptors between processes. Another option is to use file-system snapshots, at least if the filesystem supports them.
Yet another option is to not replace individual files but complete directories and swap them out via RENAME_EXCHANGE (an atomic swap, available since kernel 3.15). As long as the process keeps a handle on its original working directory it can keep working with the old version even if it has been replaced with a new one.
Some of those approaches are tricky, but if you want to guard against such inconsistencies at least it is possible. And if your IPC interfaces provide a stable API it shouldn't be necessary.
> And then there's FILE_SHARE_DELETE which allows deletion
That has some issues when the file is mmaped. If I recall correctly you can't replace it as long as a mapping is open.
While this is true, I've never seen this to be a problem. If two programs use IPC, they usually use either stable, or compatible protocol.
To make things even more complicated, you can have two programs, either each in it's own container, or statically linked, or with their private bundles of libraries, doing IPC and then they are free to have different versions of the underlying libraries, while the users still expect them to work fine.
Some versions are known to be incompatible and most Linux distributions do a very good job of recommending and doing a restart of affected services in a way transparent to users. I have been running Linux and home and at work for years, almost never restart those workstations and, as far as I can tell, never had problems from piecemeal upgrades. My 2c.
[1] Note that is not the same as your "must be reachable via some path". It is literally inaccessible by name after delete. Try to access by name and you get STATUS_DELETE_PENDING. This is unrelated to the other misfeature of being able to block deletes by not including FILE_SHARE_DELETE.
Ah. This must be why I can't permanently delete files in use by a program but can sometimes "delete" them and send them to the recycle bin.
Isn't there a $MFT\\{file entry number} virtual directory that gives an alternate access path to each file? Wouldn't that qualify as "a way to access the file?"
Also, you might say that in practice Linux abides by the same rule - the old file can be referenced through some /proc/$pid/fd/$fd entry.
That's why you should restart those programs that were using the library. You can find this out via `lsof`.
It's small details like these that make so much difference in daily convenience.
Renaming/Deleting files in use is one of those things that us nerds like to complain about, but it makes sense when you think of an accountant that has an open spreadsheet and accidentally deletes a folder with that file. For average non-technical people (on any OS) I would say it makes sense to block that file from being deleted.
I am not sure about deletion, but one of my programs has been using the ability to rename itself to do updates for the last 15 years.
Of course there is a theoretical possibility that this will happen; however, in practice, updates (especially security updates) on Linux happen with ABI compatible libraries. E.g. on debian/ubuntu
apt-get update && apt-get upgrade
Will generally only do ABI compatible updates, without installing additional packages (you need 'dist-upgrade' or 'full-upgrade' for that).
Some updates will go as far as to prevent a program restart while updating (by temporarily making the executable unavailable).
Firefox on Ubuntu is an outlier - an update will replace it with one that isn't ABI compatible. It detects this and encourages you to restart it.
All in all, it's not that a reboot is never required for linux theoretically - it is that practically, you MUST reboot only for a kernel update, and may occasionally need to restart other programs that have been updated (but are rarely forced too).
It's simple for any application to open a file in Windows such that it will allow a rename or delete while open - set the FILE_SHARE_DELETE bit on the dwShareMode arg of the win32 CreateFile() function. In .NET, the same behaviour is exposed by File.Open / FileShare.Delete.
You can rename a file when it's open. And once it's renamed, you can delete it.
I've had this happen in bash also, where I modify some script in an external editor then try to run it, only to realize that I'm running from the trash, even though the bash prompt naively tells me I'm in ~/SomethingNotTrashFolder.
Intuitive would be "Hey, this file you're working on was just moved to the trash. There's a 99.9999% chance you don't want to do this." rather than hoping the filepath is visible, and noticed by dumb chance, in the title bar, since not many people periodically glance at the file they have open to verify it's still the file they want open.
1. Do the upgrade, this changes the files.
2. You have a log of what packages got upgraded.
3. Run the package system's introspection commands to see what files belonged to that package before & after
4. Run the package system's introspection commands to see what reverse depends on those packages, or use the lsof trick mentioned upthread.
5. For each of those things restart any running instance of the application / daemon.
Even if something didn't implement this already (most mature systems to) this is at most a rather trivial 30 line shellscript.
There is also an API that retrieves a filename from a handle. I don't think it guarantees the name be usable though.
It's easy to imagine a system that works the way I would have it, because it exists: Unix. You can unlink and keep descriptors open. NT is very close to being there too, except for these goofy quirks which are kind of artificial.
I've primarily been using AwesomeWM for the last few years and occasionally XFCE (both on ArchLinux) and I cant recall ever experiencing what you describe.
I’m not sure what scenario you are envisioning. Usually upgrades are handled via the distribution and its package manager, and the maintainers take care of library issues. It’s not like windows where you go all over downloading packages from websites and installing them over each other.
>In a case where one could get some sort of inconsistency because of different library versions, you restart the applications.
I am envisioning the same scenario you replied to!
It's a really common engineering task to do this and I'm not at all surprised that someone trying to maintain uptime would do so. Honestly it's more mature than updating every time because each change also introduces more potential for regression. If your goal is to run a stable system you want to avoid this unless the risk is outweighed.
If my system is closed to the public world, has a tiny amount of external services, and I am aware of the specific bug delta since system release and what mitigations may or may not be required, I can leave it running as long as I choose to accept the risk. Cute phrases like 'pattern' and 'anti-pattern' are rules of thumb, not absolute truths.
While I find the situation different with systemd maintainers, whose communication style used to be questionable too often, and their software had some nasty bugs, I must admit that despite those problems they've also built software, which is nevertheless reliable, even though it took them a lot of time to come there.
This, honestly, is the most disappointing statement I read from you in the recent couple of years. And I'm saying this as a person who used to respect you a lot. I find your lack of respect together with the willingness to spread lies like this quite appalling.
In any case, my assumption here is we're trying to help the user and give them an easy way to know what to do, instead of leaving their software in an undefined state.
Ubuntu developer here. This doesn't happen to me in practice. Most updates don't cause system instability. I rarely reboot.
Firefox is the most noticeable thing. After updating Firefox (usually it's a security update), Firefox often starts misbehaving until restarted. But I am very rarely forced to restart the login session or the entire system. I should, to get updates to actually take effect, but as a developer I'm usually aware of the specifics, so I can afford to be more selective than the average user.
Are you sure you aren't comparing apples to oranges here, and are actually complaining about the stability of updates while running the development release, which involves ABIs changing and so forth?
For systemd updates, I can just reload it. For the likes of core components like bash, and major DE updates, I can just lazily use loginctl to terminate all of my sessions, and start fresh.
I'm not sure why Firefox would be causing instability until you restart (reboot?), though.
I get the impression that the UI loads files from disk dynamically, which start mismatching what was already loaded.
Ideally they'd just prefork a template process for children and open fds for everything they need, that way such a detection wouldn't be necessary.
http://neugierig.org/software/chromium/notes/2011/08/zygote....
Regarding the rest, if your code has incompatible API breaks between two patch or minor version changes, you’ll need to rethink your development model.
Lately, every time my co-worker has updated Ubuntu, it has broken his system. He's like my canary in the coalmine. I wait for his system to not fall over before I will update mine.
Which is almost true. In fact, you were unable to use programs that changed runtime dependencies or conflicted with current user sessions, init processes or kernel modules. You can often use other programs, but not ones that in any way touched the ones you upgraded, for one reason or another.
If you have to upgrade, say, a command line utility, that almost always doesn't require rebooting. If you have to upgrade a GUI app, or a tool that depends on some bastardized unholy subsystem designed to "secure desktop sessions", that may very well require relinquishing the session and restarting it. If you have to upgrade a tool used by your desktop (and if you have a complex desktop, that is literally thousands of programs), it's the same story, though you may even need to restart your desktop session manager or even your display server.
Then there's system init processes, kernel modules, firmware, system daemons and the like. You can reload those without rebooting, but it's certainly not easy - you will probably have to change to runlevel 1, which kills almost everything running. You can reload the kernel without rebooting, too - very handy for live patching - but really, why the hell would anyone want to do this unless they were afraid to power off their system?
So, technically, rebooting is not required to update in many cases in Linux, just like in Windows. But it is definitely the simplest and most reliable way.
This is less of an issue with Linux, per se, and more to do with proprietary video drivers.
I have multiple systems in my home with various GPUs. The systems running Intel and AMD GPUs with open source drivers don't have this problem. The two desktops with Nvidia GPUs have this problem whenever the Nvidia driver is updated.
I also had the same exact problem with my AMD system back when it was running the proprietary fglrx driver.
Actually, it IS a problem with Linux. I don't get this behavior on my Windows or OSX machines where NVIDIA has been reliably (modulo obvious caveats) shipping "evil proprietary" drivers for a decade.
Linux is great, but it doesn't need to be coddled.
No one is blaming you specifically, it is a common way of saying, “if you write operating systems, and you do $THING, you will get $RESULT.” Common, but wrong, which is why your high school English teacher will ding you for phrasing something that way.
Windows patches are a much bigger pain in the ass to deal with on a month-to-month basis, but Linux patches can really bite you.
Example 1:
Say I have an application 1 that uses shared library X, and a application 2 that spawns an external process every 5 minutes that uses library X and communicates in some way with application 1. Now let's say that library X v2.0 and v2.1 are incompatible, and I need to apply an update.
On Windows, if I update this program, it will keep running until the system is rebooted. Updates, although they take significant time due to restarts, are essentially atomic. The update either applies to the entire system or none of the system. The system will continue to function in the unpatched state until after it reboots.
On Linux, it's possible for application 1 to continue to run with v2.0 of the shared library, while application 2 will load v2.1, and suddenly your applications stop working. You have to know that your security update is going to cause this breaking change and you need to deal with it immediately after applying the update.
Example 2:
A patch is released which, unbeknownst to you, causes your system to be configured in a non-bootable state.
On Windows, you'll find out immediately that your patch broke the system. It's likely (but not certain) to reboot again, roll back the patch, and return to the pre-patched state. In any event, you will know that the breaking patch is one that was in the most recently applied batch.
On Linux, you may not reboot for months. There may be dozens or hundreds of updates applied before you reboot your system and find that it's not in a bootable state, and you'll have no idea which patch has caused your issue. If you want your system in a known-working state, you'll have to restore it prior to the last system reboot. And God help you if you made any configuration changes or updates to applications that are not in your distro's repository.
I just don't update nvidia or my kernel automatically and magically I only have to reboot less than once a month and always on my schedule.
Thanks, I'm glad at least one person agrees I'm not hallucinating. The vast majority of people here are telling me I'm basically the only one this happens to.
Monday's I merge last week's snapshot, take a new one, and run all my updates. Then I do my dev work in my VM. Before I head out on trips, I just ship the entire machine over the network to my MacBook Pro.
This is mostly because have you literally ever tried to install any Linux on laptops? It's always a Russian roulette with those $+#&ing Broadcom wireless chipsets. >.<
So you're not hallucinating. Linux as a desktop/laptop had a sweet spot from like...2012-ish till 2016. Then 802.11ac went mainstream so Broadcom released new chipsets and graphics cards had a whole thing with new drivers and Ubuntu's packagers (the people) lost their mind or something.
Nothing feels right, at least in Ubuntu/Arch land right now.
But we are the only 2 people in the world experiencing this, so never mind.
> You: All I can say is that, based on everything I know, that's not the current experience of the majority of users
>> Me: Yet from everyone's comments here I'm guessing I must be the only one who encounters this.
???
> You: It doesn't seem fair for you to generalize this to some architectural problem.
>> Me: 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.
???
I don't know of a single Linux distro that works out of the box with my laptops. Maybe if I bought a $2,000 laptop that shipped with Linux it would work. It would still be a pain in the ass to update, though.
I kind of hate Linux as a desktop now. I've been using it as such for 14 years, and it's only gotten worse.
Hardware support wise, newer kernels generally come to Debian sooner too, as the latest stable kernel generally gets into Sid a week or so after release, then added to backports for Debian Stable after a few weeks. Currently you can nab 4.14 from backports on Debian Stable, and 4.15 should be coming down the pike shortly (seeing as its just a few days old).
This is unfortunate. I've been using Linux and suffered, for the lack of a better word, with its warts since 2002.
There was a period between 2013-2016 where Linux was great as my main operating system. It was more stable than OS X and was much better for development.
Is hardware support your main issue with desktop Linux?
The software (especially Ubuntu's desktop) is lacking basic features from even 10 years ago. Maybe there's a way to get it to do what it used to do, but I can't figure it out, and I'm not going to research for two days to figure it out. I just live with a lack of functionality until I can replace this thing.
Not only that, but things are more complicated, with more subsystems applying more constraints (in the name of compatibility, or security, or whatever) that I never asked for and that constantly gets in my way. Just trying to control sound output and volume gives me headaches. Trying to get a new piece of software to work requires working out why some shitty subsystem is not letting the software work, even though it is installed correctly. Or whining about security problems. You installed the software, Ubuntu, don't fucking whine to me that there's a SELinux violation when I open my browser!
Hardware is a big problem because modern software requires more and more memory and compute cycles. All of my old, stable laptops can no longer perform the web browsing workloads they used to. Browsers just crash from lack of memory, or churn from too much processing. If you don't use modern browsers, pages just won't load.
Aside from the computing power issue, drivers are garbage. Ignoring the fact that some installers simply don't support the most modern hard disks, and UEFI stupidity, I can't get video to work half the time. When I can, there are artifacts everywhere, and I have to research for three days straight to decipher what mystical combination of graphics driver and firmware and display server and display configuration will give me working graphics. Virtually every new laptop for several years uses hybrid graphics, and you can't opt-out or you get artifacts or crashing. Even my wifi card causes corruption and system crashing, which I can barely control if I turn off all the features of the driver and set it to the lowest speed! Wifi!!! How do you screw that up, seriously?
Modern Linux is just a pain in the ass and I'm way too old to spend my life trying to make it work.