0 users browsing Discussion. | 7 bots
| tomman |
Posted on 19-03-29, 16:43
|
|
Dinosaur
 Post: #232 of 1315 Since: 10-30-18 Last post: 57 days Last view: 13 hours |
Big updates mean big troubles! But that's the life of a non-Windows/non-Mac user (aside of OS upgrades, which are painful for everybody). So here is it, another of my "tomman hates computers" threads! RULES! (did you expected anything else from me?!) - No Poetteringware™ (systemd/PulseAudio/Red Hat) trashtalking: I know you guys have a secret Poettering dakimakura stashed under your bed, just next to your Stallman-authographed katana. No, seriously, I get his software is controversial and it has caused pain for several of you here (including myself in very specific situations, just like any other piece of software, and when it happens again you will hear me bitching loudly, after picking the pieces and hopefully gluing them again), but that's not the thread for bitching and moaning about how systemd is killing Linux (it isn't), or your conspiracy theories about Red Hat turning Linux into Windows (this is not Slashdot/Phoronix). Make your own threads for that, PLEASE. - No "why not BSD" suggestions: You guys have a weird taste about platforms where no commercial desktop software will ever run outside of very hacky ways (emulation, compatibility layers), or simply don't use your computers for anything beyond hacking your own code, posting on message boards and reading the news, but I'm too old for such experiments (I stopped being a college student a decade ago). Despite its downfalls, I'm very happy with Linux, and extremely dissapointed with the IT/computer software industry in general (especially since the dawn of the smartphone, where all platforms went onboard into the 737 MAX to Suckville, but crashed in the Atlantic Turd Latrine with no survivors), and no OS switch will fix that. BTW, this rule is not limited to *BSDs: I'm not interested about hearing how close to perfection are Macs, of why Windows 10 does not suck - threads are free so open your own! - No Mozilla products talk: that's why we have the "Mozilla, *sigh*" thread for. - You're encouraged to talk about other Linux distros here, but leave the PRO GEAR SPEC Gentoo Ricer at home! Anyway, on topic: it's release upgrade season! I'm now down to two Jessie boxes at home, which due to its low specs and very specific usage patterns are to stay there until the end of LTS and beyond. Everything else is now running Stretch, but this last migration (the Dell laptop) was a very bumpy ride. After downloading almost 3GB of packages (including a bunch of crud I don't want due to the default "install recommends" policy, like Firefox which managed to sneak in), and surviving another city-wide blackout during the final configure phase (this 10yo battery is still good for emergencies), this Dell got into Stretch... but without a login manager! My login manager of choice is GDM3. "BUT WHY?! Didn't you hate GNOME with a passion?! YOU HYPOCRITE!" Well, I don't mind using the few sane bits of GNOME, of which GDM is one: it provides me with a Windows-like logon experiency: click my name, enter password, done. kdm is dead, sddm is horrible, and while I use lightdm for prehistoric boxes, this 2006-vintage Dell has more than enough muscle on its T7200 CPU to actually give me the GDM experience instead of a '80s-styled "enter user and password" form. Too bad you still have to install a bunch of GNOME shit just to have a logon display that actually greets you with your full name! See, this is where I intentionally stepped into the mine field all by myself: prior to the upgrade I performed a GNOMEctomy, getting rid of the remnant GNOME bits I don't want to see ever again in my life (CSR window decorations must die in a fire!). "Does it have 'GNOME' on its package name/description? Doesn't break gdm3? Off you go!" I said... but now I was in front of a good ol' console with no logon display. A look at syslog didn't gave any clues, aside of a "Unable to init server: Could not connect: Connection refused" and a segfaulting "gnome-session-f" process. After wasting my time reading about countless people with the same problem, each with unresolved/open bug reports/StackOverflow questions, and others which came up with myriad of solutions (from reinstall your video driver to rebuild your font cache), none of them applicable to my situation, I turned on debugging on /etc/gdm3/daemon.conf. At a first look, nothing relevant was among the bunch of crap logged on syslog... but after reading the logs like 3 or 4 times, I noticed entries for a missing "gnome.session" file. And sure enough, after comparing with my other Stretch laptop, there indeed was a missing gnome.session which is part of the package gnome-session, one of the victims of my GNOMEctomy! (technically this is a direct dependency, except that any other desktop session providing x-session-manager should work... except that it doesn't!). Reinstalled gnome-session, and all is well again. (The segfault on "gnome-session-f" is not really related: that process is actually "gnome-session-failed", which does nothing but to display a "fuck you, GNOME crashed so go and reboot it yourself because we hate you!". Yes guys, the error message was crashing too! I guess that's part of Official GNOME Policy) After finishing with the Dell (getting rid of obsolete packages, reinstalling some missing stuff, undoing some minor annoying UI settings on recent MATE versions, and enabling software compositing because -believe it or not- on this old ATi hell, running with it off will result in poor performance, drawing artifacts while dragging windows, among other things!), it was time to update the Asus. Oh boy, :linusfinger.jpg: Yes, nVidia wants me to throw my (mostly) working 2012-vintage laptop into the dumpster, poisoning your fishes and waters. Turns out that Fermi GPUs are no longer supported by the mainstream driver; support has been moved to the legacy-390.xx branch. Stretch has 390.xx mainstream as the default driver, but the legacy branch is now available via Backports. Except that it isn't useable as-is if you have a Optimus laptop (I've lost count of how many times I've said that "hybrid graphics are a 32X-level mistake", and this is no exception). I don't know how the kool kids of Silly Valley cope nowadays with said setups of the Intel+nVidia+muxless variety, but I'll be sticking to the tried-and-true bumblebee solution. Long short story: I'll omit my 3-hour long horror story, so here is how to properly switch to the legacy branch so you're ready for when the time to switch to Buster comes: - Purge primus and bumblebee FIRST - otherwise you will be leaded straight to dependency hell and "would you like to uninstall Xorg too?". Leave bbswitch alone, as it doesn't conflict with anyone else in this mess. - Purge any nVidia package with the same version number of the currently-installed driver (if you're using the stock Stretch driver, that would be 390.87-8~deb9u1). Leave nvidia-kernel-common installed, as it doesn't get built from the main driver source package. - Reboot. This is because nouveau will get un-shitlisted and will try to meddle in the way. We already have a non-working GPU, which is preferable to a half-assed crash-prone GPU! - The version of bumblebee in Stretch is not compatible with the legacy-390.xx branch, so you will need the one from Buster... oh wait, that one depends on a newer version of init-system-helpers too, a package that you should NEVER EVER mess with as it is flagged as "essential" AKA "risk of fatal system breakage!". The only recourse is to backport it yourself to Stretch, but luckily that's very easy: after installing the Debian source package, open bumblebee-3.2.1/debian/control with your trusty editor, and drop the required version of debhelper-compat to 11 (it's set to 12, which introduces the dependency on the newer init-system-helpers, which we don't want to mess with!). The file header should now look like this: Save, and build your new DEBs (dpkg-source -b -us -uc -tc). You can install bumblebee now, but not bumblebee-nvidia yet! Leave that one for last. - Install your newfangled legacy drivers. Avoid the glvnd-flavored packages for libgl1 and friends, as those won't work with bumblebee! Remember, you want libgl1-nvidia-legacy-390xx-glx (if you missed it, install it now - let apt-get sort out the required library replacements so we can get rid of the GLVND mess which doesn't play nice with our hybrid graphics disease). Since you're on Fermi, you have no rights for Vulkan so avoid installing those packages too. - NOW you can reinstall bumblebee-nvidia from the DEB you've built earlier! Keep those files on a safe and handy place just in case. - Reinstall primus (and if you have Steam and/or Wine, primus-libs:i386) - Time to reboot again! But before, a final tweak must be made: delete /usr/share/glvnd/egl_vendor.d/10_nvidia.json now, otherwise as soon as Xorg/Wayland starts it will load both the Mesa and nVidia EGL drivers (because I DON'T KNOW!?), the latter triggering the loading of the nVidia kernel modules, completely breaking bumblebee/primus and therefore no hybrid graphics for you! - Test that everything works: primusrun glxgears is the quintessential test for this case, while you keep a syslog/dmesg -w open on a secondary terminal for taking a look at the kernel logs. Disregard any warnings/stackdumps if they begin with "pci 0000:01:00.0: disabling already-disabled device" - that looks like it is a bumblebee bug of some sort. - If you live in a 1st-world country, go and buy a laptop with a SINGLE GPU, preferably not made by nVidia or AMD! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-03-29, 20:00 (revision 1)
|
|
Dinosaur
Post: #233 of 1315 Since: 10-30-18 Last post: 57 days Last view: 13 hours |
More quick fixes for UI stuff: - Want to preserve the sanity of good ol' Cleanlooks on your GUI apps? While it's kinda late for GTK3, at least for Qt 5 there is a couple of solutions that can be combined to achieve the perfect look (and most of the feel). Build this, but don't set it up as your default platform theme as the README tells you to do so. Instead you want this for more control, the missing Qt 5 control panel. This one is on Debian, but sadly available for Buster/Sid only. Don't fret - with a trivial modification it's easy to backport to Stretch! Install the sources, modify debian/control to drop the Qt 5.9 minimum requirement (as Stretch ships with 5.7), and build it - despite what the changelog says, it works just fine with Qt 5.7. qt5ct comes with its own platform theme provider, so set it up (the ideal place is your .xprofile file, remember: export QT_QPA_PLATFORMTHEME=qt5ct), logoff, log on back, and run your fancy new Qt 5 control panel to specify qt5gtk2 as your Qt theme. - Continuing with fixes for your Qt apps, this one is now required if you want to run Qt applications with superuser privileges (hopefully using sudo!), due to increased SEKURITAH! thanks to rootless Xorg: just set a variable: sudo QT_X11_NO_MITSHM=1 yourQtProggyGoesHere Neglect to run that way and all you're going to get is a barrage of X errors, with the most obvious being a instance of "BadAccess (attempt to access private resource denied)" from the MIT Shared Memory extension. Apparently what this variable does is to turn off the use of said feature because shared memory is DANGER MINES YOUR CREDIT CARDS ARE IN DANGER!!!! X11 pls. - Remember: to build Qt 5 apps on a dual Qt4/5 setup, either figure out how to use qtchooser, or install qt5-default to tell Debian that you're indeed going to work mainly with Qt5 stuff, so the symlinks to qmake and friends are properly set up to the correct versions. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Duck Penis |
Posted on 19-03-29, 22:53
|
|
Stirrer of Shit
Post: #150 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Posted by tomman Tried LXDM? It looks nice by the screenshots, and should be lightweight. Otherwise you could just install another greeter for LightDM. Personally I use SLiM and have never had any trouble with it. It looks terrible but I use it for about five seconds so why care? But then again I'm not a ricer ;) There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| CaptainJistuce |
Posted on 19-03-29, 23:38
|
|
Custom title here
 Post: #378 of 1164 Since: 10-30-18 Last post: 63 days Last view: 4 hours |
"RULES!" Man, you just banned 95% of bboard posts. --- In UTF-16, where available. --- |
| Screwtape |
Posted on 19-03-30, 01:05
|
|
Full mod
 Post: #187 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
My problem with LightDM is that when you login, it launches a shell to run all the X11 startup scripts, but it doesn't launch it as a login shell, which means the shell doesn't read ~/.profile. That means any environment variables you set in ~/.profile specifically so that they would be available everywhere (like $PATH and $LD_LIBRARY_PATH so you can use programs you compiled yourself, or $PAGER and $EDITOR to configure your favourite helper tools) are missing. The LightDM maintainers have been informed of this deficiency, but apparently it's deliberate because they think ~/.profile is only for textual logins, like on the console or via SSH. I guess that makes sense if you start from the assumption that X11 logins break the whole Unix login model, so why bother trying to choose sensible behaviour. However, it makes sense (to me) to handle all logins in a similar fashion. Also, it's what GDM (probably the most widely-used DM) does and I think XDM (the original "official" DM) too, so they should do it even just for compatibility, if nothing else. The ending of the words is ALMSIVI. |
| Duck Penis |
Posted on 19-03-30, 01:41
|
|
Stirrer of Shit
Post: #151 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Man, I hate X. Tons of failure modes, a black box that sometimes sprays black goo all over everything, and designed around the non-existent use case of running software over the network. When will it die? Here's an idea for a Linux distro: each successive version of a package has to decrease its size/complexity, or else it won't be merged. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| tomman |
Posted on 19-03-30, 01:59
|
|
Dinosaur
Post: #234 of 1315 Since: 10-30-18 Last post: 57 days Last view: 13 hours |
Posted by Screwtape I've always used ~/.xprofile (although never verified if it works with LightDM as I don't have specific use cases for such setups yet), so exactly what's the difference between both files? Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| BearOso |
Posted on 19-03-30, 02:59
|
 Post: #65 of 175 Since: 10-30-18 Last post: 1450 days Last view: 1450 days |
systemd? Haven’t had any problems with it, to be honest. I like its core dump utility. Pulseaudio was a disaster at launch because it was clearly written by a novice audio programmer who had a narrow view of sound use-cases. It actually works ok with very little cpu now, and no longer keeps a hold on the sound device unless it’s playing audio. |
| Kakashi |
Posted on 19-03-30, 04:01
|
 Post: #109 of 210 Since: 10-29-18 Last post: 1876 days Last view: 1848 days |
I also have never had an issue with systemd. Arch Linux's wiki taught me how to use it straight away. Pulse Audio doesn't bother me after I tell it to kindly ask alsa to use a channel. (also Arch wiki) |
| CaptainJistuce |
Posted on 19-03-30, 04:02
|
|
Custom title here
Post: #379 of 1164 Since: 10-30-18 Last post: 63 days Last view: 4 hours |
Posted by sureanem I use software over the network. Not that it matters since everything's bitmapped these days no matter how little sense it makes to do so. X made a lot more sense when it was created than it does now, and part of that is due to software developers deciding to opt out of X at all levels and treat it as a very complex way to draw bitmaps. And suddenly every part of the distro was deleted. --- In UTF-16, where available. --- |
| BearOso |
Posted on 19-03-30, 19:47
|
|
Post: #66 of 175 Since: 10-30-18 Last post: 1450 days Last view: 1450 days |
Posted by sureanem GNOME 2 did that and people complained. GNOME 3 did it again and people complained. You can’t please everybody. |
| Kakashi |
Posted on 19-03-31, 05:54
|
|
Post: #110 of 210 Since: 10-29-18 Last post: 1876 days Last view: 1848 days |
Posted by BearOso Holy shit, it got simple. Caja for the win here, because Thunar is crash city. |
| Screwtape |
Posted on 19-03-31, 07:17
|
|
Full mod
Post: #188 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Posted by tomman There's a bunch of files that get involved at different parts of the process — .xinitrc, .xprofile, .xsession — and I'd have to read through all the X11 startup scripts to figure it out for sure. The main thing, though, is that .xprofile would only be read during graphical logins, while .profile is read for all logins. If I want an environment variable to *always* be set, no matter how I log into my computer, .profile is where I want to put it. See also: How to set your $PATH. The ending of the words is ALMSIVI. |
| Duck Penis |
Posted on 19-04-14, 01:09 (revision 1)
|
|
Stirrer of Shit
Post: #201 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
So I ran a sudo apt-get dist-upgrade. No big deal, I thought. Updates happen all the time, and I'm running stable. Something like ten packages, none of them sounded important. And so, two very important features break: 1) controlling backlight via the power manager (backlight keys had already been broken) - had to make a symlink and then use xbacklight 2) shutting down the bloody computer with the "log out" button in the start menu Maybe I should switch to systemd already, but I really don't trust that piece of software. God damn it, I just want things to work. Isn't this the whole point of stable, that things don't manually shit themselves whenever you update? What's even the point of having updates in a supposedly "frozen" distro? Man, I want a distro where everything is statically linked and the only updates are to fix immediate security issues (in which case they should make the SMALLEST POSSIBLE CHANGE NEEDED, not exploit it to force you to update) or voluntary, based on wanting some new feature. Presumably, this is just a pipe dream because of the obscure properties of some arcane layer deep down that mere mortals cannot even begin to comprehend, but it would be nice. Maybe I shouldn't update unless I need something, but if I want to install packages then I can end up in a broken state, so I have to update even if I don't want whatever the update drags in. I don't like Microsoft, but at least they underst This is the downside of open-source software: nobody wants to work on a boring project for free (unless they're insane/ideologically driven), so the parts nobody wants to touch with a ten-foot pole remain completely undisturbed (see: X) and the parts people do care about (see: all the small unix tools people use every day and have a vested interest in making work as well as possible) are absolutely state of the art. I suppose putting stuff in containers is a step forward, and it seems like people are finally starting to leave dynamic linking behind where it belongs (the 1980s). It's only good for loading in extensions via dlopen() and possibly system libraries which would be impractical to link in. For anything else it's rubbish, and should be replaced by static linking, or even better unity builds. > B-but my precious storage and RAM! What about the compile times? Compiling with static linking, proper compiler settings, and a good libc gives far smaller binaries than dynamically linking glibc with -Os, stripping, and calling it a day does. I haven't been able to test this, but I strongly suspect that integrating the libc would make for even smaller code since it could for instance inline syscalls better than LTO can. Compile times are negligible, and also a non-argument - you wouldn't compile in -O1 for release because it "compiles faster," now would you? Fuck dynamic libraries and fuck updates. Both cause lots of pain while bringing precious little of value to society. Windows Vista was a mistake. EDIT: Apparently, these issues solved themselves with a reboot. Updates are still annoying though, even if it's not as bad as Arch yet. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| tomman |
Posted on 19-04-14, 13:05
|
|
Dinosaur
Post: #256 of 1315 Since: 10-30-18 Last post: 57 days Last view: 13 hours |
Dude, your Troo UNIX® Way™ sysadmin graybeard is showing. Also, fuck static linking too. That only works if you're releasing proprietary blobs, or if you don't intend to update your software EVER. I grant you the "I want a stable API, god damn it!" part, but for the FOSS crowd, everything has been a moving target since forever. And it's now true for proprietary software too (hello, Windows). > Apparently, these issues solved themselves with a reboot. Updates are still annoying though, even if it's not as bad as Arch yet. Man, do you even reboot more frequently? Every time I do a dist-upgrade that touches delicate/fragile bits (kernel, systemd, libc), things will act weird until the next reboot. You may not be able to reboot initially, except via the Magic SysRq combo (it occasionally happens to me). But after a couple reboots, everything is kosher again. Same applies to Windows because Windows Update is a piece of complete rubbish Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| creaothceann |
Posted on 19-04-14, 14:27
|
 Post: #115 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
Posted by tomman You can just install new versions of the software. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| Duck Penis |
Posted on 19-04-14, 14:44
|
|
Stirrer of Shit
Post: #202 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
What's wrong with static linking? The whole "it makes it hard to update" thing is a non-issue. Because it has no external dependencies, you only need to update whenever you actually need to update. For instance, if there's a critical bug in the libc it's built against or if you actually need to update the program. And if you're only updating to replace the libc, it's not really an update proper - it can't (shouldn't) introduce any new bugs in the software, the user doesn't get any new features, etc. Of course, the libc's should follow this pattern too. So if there's a critical bug in v11.2 and below, and you have packages compiled against v5.9, your new packages should be built against v5.9.1 and not v11.2.1. It should be up to the developer what version of libc he wants to use, not LATEST ALWAYS BECAUSE LATEST IS BEST. And since we're doing unrealistic dreams anyway, all these packages should be reproducible and subarch compiled and distributed as delta patches via BitTorrent instead of mirrors. for the FOSS crowd, everything has been a moving target since forever. Static linking solves this, at least in theory. There might be issues with the GUI toolkits though, since they usually read global config files. But if they'd be modified (or alternatively, the system provide config files under namespaces of some kind), then you could have GTK2 applications that didn't depend on anything but X11, which isn't linked in but communicated with over the network. Oh yeah, fuck GUI toolkits as well. Nuklear is pretty cool though. it's now true for proprietary software too (hello, Windows). Microsoft realized there was no business in being sane anymore, so we ended up with Psycho-Pass instead of SEL. Windows 10 is just the beginning. Soon you'll miss it, being forced to switch to DaaS. You know the error Photoshop gives you when you try to open banknotes? Imagine it for every piece of copyrighted material in the world, as well as whatever someone (cough Chinese government cough) is willing to pay enough to have register as an "accidental" false positive. Maybe it's like Psycho-Pass, the third/second world countries get to keep their freedom for a little longer. Maybe you'll get to switch over to glorious Astra Linux. Can't get ME'd if your CPU was made back when Bush was still president. Man, do you even reboot more frequently? Every time I do a dist-upgrade that touches delicate/fragile bits (kernel, systemd, libc), things will act weird until the next reboot. You may not be able to reboot initially, except via the Magic SysRq combo (it occasionally happens to me). But after a couple reboots, everything is kosher again. Same applies to Windows because Windows Update is a piece of complete rubbish Agreed. I didn't connect it at first since it was just a teeny update (man, I hate the term "upgrade" used for things which aren't appreciably better) of like ten packages. If I'd have rebooted first, I probably wouldn't have written the post... Posted by creaothceann Or the same version with a fixed libc, much more reliable. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| funkyass |
Posted on 19-04-14, 18:39
|
|
Post: #34 of 202
Since: 11-01-18 Last post: 660 days Last view: 15 days |
wouldn't updating libc mean you are reinstalling the OS, essentially? Since AFAIK, modules haven't landed in the C standards. |
| Duck Penis |
Posted on 19-04-14, 19:29
|
|
Stirrer of Shit
Post: #205 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Posted by funkyass No, "updating the libc" would be a completely alien term. You would install a new version of an application that would include whatever version of libc it pleased, or none at all if they're writing freestanding code. It would be up to the application author (and to some extent the repo maintainers) which version of what libc to use. Presumably, newer versions would use newer libraries. If there would be some Heartbleed-esque bug in whatever version of libc a program uses, that program's executable (and executable only) should get replaced by a version which does the absolute minimum needed to fix it, provided that part of the libc is actually being used. And if this would affect all the applications, you would indeed need to do this once per application. However, since the ideal package manager would just apply a diff, the download size would be quite small, probably about as big as the corresponding diff for the shared library. The breakage would be minimal, limited to whatever regressions the fix manages to introduce. Most importantly, security updates wouldn't force updates of anything else. If it would have containerization, or the application has no non-library dependencies, you should be able to run software from $NOW forever and ever with such a system, assuming of course that architectures stay the same and/or the application doesn't have portability bugs. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| Screwtape |
Posted on 19-04-15, 03:45
|
|
Full mod
Post: #220 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Some context to consider: Currently, fixing a problem in a shared library means fixing the problem in that library's source-code, recompiling it, and publishing the new binary. Given those costs, an all-volunteer project like Debian provides (I think) two years' security support, big commercial organisations like Ubuntu and Red Hat provide about five years' support, and huge got-them-by-the-short-and-curlies organisations like Microsoft sometimes support software for as long as ten years. If I understand your proposal, instead of fixing a problem by changing source-code and recompiling, you want problems fixed by reverse-engineering the binary and hex-editing out the problem parts. And instead of fixing the problem once, you want the process repeated for every single binary that (directly or indirectly) uses the library in question, a process that probably can't be automated if the binaries were built with an optimising compiler of any complexity. I'm not sure what you expect to happen with second- or third-party binaries; would customers have to send them in to be patched? Would customers need to have a security engineer on-staff to do the patching? Also, if a binary had *two* problems, would the second patch require the first patch to be present, or would you expect every possible combination of patches to be available? There's no way to tell for certain, but I'm guessing that given *those* costs, there'd be a *lot* less security support available. I'm sure that, just like today, if you were to pay your OS vendor squillions in annual licensing fees, they'd be willing to provide patches for as long as you want, but security support would probably become entirely unavailable to anyone outside a multinational corporation. The ending of the words is ALMSIVI. |
[Your ad here? Why not!]