The Windows OS Thread - Formerly THE OS for gamers and normies, now sadly ruined by Pajeets

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
You probably can’t reveal too much, but if it wasn’t libraries breaking compatibility between versions, what was the ABI issue you were talking about?
It will be something like this.

RHEL 8 supplies libdl
RHEL 9 deleted libdl, merged the functionality into libc.so.6, and requires you to change your software to use LD_AUDIT.

Any software that links libdl is now broken.

Now, from a purely analytical point of view, just speaking in strictly technical terms, if your operating system supplies a library, and you delete it in an update, you will suck Satan's fat cock in hell eternity. Let's contrast this with how Windows does things. Windows still ships with pifmgr.dll, a linked library full of fun 16-bit icons that you just might need for your cool new Windows 95 apps. Wouldn't want your app to go icon-less.

1771644659390.png

THIRTY years later, Windows still keeps this lib around so old apps don't break. Yeah, I know, in 30 years, there are edge cases that don't work. But Linux can't natively run Linux apps from, uh, 2021, not without containerizing them first. Unless a kernel feature changed, and then they won't work at all. You learn in school that an API is a contract. You learn in Linux that an API is a Darth Vader contract. "I have altered the deal; pray I do not alter it any further."
 
It will be something like this.

RHEL 8 supplies libdl
RHEL 9 deleted libdl, merged the functionality into libc.so.6, and requires you to change your software to use LD_AUDIT.

Any software that links libdl is now broken.

Now, from a purely analytical point of view, just speaking in strictly technical terms, if your operating system supplies a library, and you delete it in an update, you will suck Satan's fat cock in hell eternity. Let's contrast this with how Windows does things. Windows still ships with pifmgr.dll, a linked library full of fun 16-bit icons that you just might need for your cool new Windows 95 apps. Wouldn't want your app to go icon-less.

View attachment 8589586

THIRTY years later, Windows still keeps this lib around so old apps don't break. Yeah, I know, in 30 years, there are edge cases that don't work. But Linux can't natively run Linux apps from, uh, 2021, not without containerizing them first. Unless a kernel feature changed, and then they won't work at all. You learn in school that an API is a contract. You learn in Linux that an API is a Darth Vader contract. "I have altered the deal; pray I do not alter it any further."
I can see how that would suck. But now we have to choose between jeetware and software that breaks. Could you not use RHEL 8 continually?
 
I can see how that would suck. But now we have to choose between jeetware and software that breaks. Could you not use RHEL 8 continually?

No. Because we're updating one of the applications in our stack to Fuckware 2024.3, which requires RHEL 9 or newer. Now, Fucksoft has told us we really need to use Fuckware 2026.1, but we have told them a thousand fucking times, updating to RHEL 9 only broke four applications, while RHEL 10 broke no fewer than twenty-three and raped our CISO's mom. UNIX didn't do this. At least not at the blinding rate Linux does.
 
It will be something like this.

RHEL 8 supplies libdl
RHEL 9 deleted libdl, merged the functionality into libc.so.6, and requires you to change your software to use LD_AUDIT.

Any software that links libdl is now broken.

Now, from a purely analytical point of view, just speaking in strictly technical terms, if your operating system supplies a library, and you delete it in an update, you will suck Satan's fat cock in hell eternity. Let's contrast this with how Windows does things. Windows still ships with pifmgr.dll, a linked library full of fun 16-bit icons that you just might need for your cool new Windows 95 apps. Wouldn't want your app to go icon-less.

View attachment 8589586

THIRTY years later, Windows still keeps this lib around so old apps don't break. Yeah, I know, in 30 years, there are edge cases that don't work. But Linux can't natively run Linux apps from, uh, 2021, not without containerizing them first. Unless a kernel feature changed, and then they won't work at all. You learn in school that an API is a contract. You learn in Linux that an API is a Darth Vader contract. "I have altered the deal; pray I do not alter it any further."
If the symbols you need are provided by another library, couldn’t you just make a symlink to that other library? In your example case, symlink libdl.so to libc.so. Linking against libc twice might cause… issues, but it might be worth a shot. As well, if there’s no name collision with newer libraries, and you can find a copy of that older .so (perhaps from a legacy package repo or something), couldn’t you just copy the old library into your /lib/ and call it a day?
Anyways, bringing the discussion back to Windows. Contrary to popular belief, Microsoft does delete libraries from time to time. For example, very old versions of DirectX contained a file called d3drm.dll which was removed in Vista. However, because of the handy “application-level-libraries before system-level-libraries” aspect of the Windows linker I was talking about, if you can find a copy of d3drm.dll you can just stick it under Program Files for the application that needs it and bam, problem solved.
People make fun of “DLL Hell,” but the Posix alternative is “Shit Don’t Work Ever,” and that’s really a lot worse.
 
If the symbols you need are provided by another library, couldn’t you just make a symlink to that other library? In your example case, symlink libdl.so to libc.so. Linking against libc twice might cause… issues, but it might be worth a shot. As well, if there’s no name collision with newer libraries, and you can find a copy of that older .so (perhaps from a legacy package repo or something), couldn’t you just copy the old library into your /lib/ and call it a day?
the entire point is to avoid all of that shit, hence using jeetindows, not to mention library deficiency being covered by people doing repacks and shieet like visual C++ AIO for example.
 
If the symbols you need are provided by another library, couldn’t you just make a symlink to that other library? In your example case, symlink libdl.so to libc.so.
The symbols aren't provided by libc.so.6. This is just one of many, many issues. Sometimes a lib gets deleted. Sometimes a lib's API changes. Sometimes function behavior is significantly changed. I had an issue a few years ago where some arcane font manager or something was ever so slightly changed in a way that made the UI of my application crash. These are all criminal acts, punishable by fiery torment for all eternity.

And let's not get into the insanity that is hardcoding the path of the C runtime into a compiled binary. The best way to understand Linux is as a wrapper around a point-in-time snapshot of Richard Stallman's personal fork of the C programming language.

People make fun of “DLL Hell,” but the Posix alternative is “Shit Don’t Work Ever,” and that’s really a lot worse.
This isn't a POSIX problem, because HP-UX (RIP), Solaris (RIP), and AIX don't have it . You can drop a .so anywhere in your LD_LIBRARY_PATH (LIBPATH for AIX because IBM needs to be different) and it will be found at run time. The problem Linux has is it's a coagulated mess of crap that is maintained by people who hate humanity and have no cruel corporate taskmaster enforcing binary compatibility on them. Back in the day, if you fucked up people's work the way Linux does, you would have lost your job. Linux isn't made by people who have jobs.
 
Win10 newb here again, anyone know how to get rid of the alphabet letter headings (red arrows) from start menu, or how to move apps (yellow arrow, others further on list) into a folder of their own? The latter do not appear in either ProgramData\Microsoft\Windows\Start Menu\Programs or in AppData\Roaming\Microsoft\Windows\Start Menu and they're activating my tism something fierce.
Untitled.png
 
(yellow arrow, others further on list) into a folder of their own
If it isn't a UWP app, than you can find the shortcut in either %appdata%\Microsoft\Windows\Start Menu or %programdata%\Microsoft\Windows\Start Menu. If it is a UWP app, then I think it is impossible to move into a folder. I sperged out about it earlier in this thread and eventually gave up and switched to openshell.
While Windows RT sucked, at least Microsoft remembered that people used folders in the start menu/screen (yay windows 8!). With Windows 10, 11, & UWP, Microsoft somehow managed to break a basic feature that has existed as long as the start menu has. It blows my mind that this major issue hasn't been addressed yet. Do the developers of Windows actually use Windows?
 
If it isn't a UWP app, than you can find the shortcut in either %appdata%\Microsoft\Windows\Start Menu or %programdata%\Microsoft\Windows\Start Menu. If it is a UWP app, then I think it is impossible to move into a folder. I sperged out about it earlier in this thread and eventually gave up and switched to openshell.
While Windows RT sucked, at least Microsoft remembered that people used folders in the start menu/screen (yay windows 8!). With Windows 10, 11, & UWP, Microsoft somehow managed to break a basic feature that has existed as long as the start menu has. It blows my mind that this major issue hasn't been addressed yet. Do the developers of Windows actually use Windows?
Glad isn't the right word for it, but I'm "glad" I'm not the only one annoyed by this nonsense. Just how many bloody Start Menu folders are there?! Suppose I'll have to give openshell a look then, thanks.
Tangent, but to your last point wasn't it revealed a bunch of Linux ""devs"" were using MacOS? Wouldn't be surprised if the same were true of MS.
 
THIRTY years later, Windows still keeps this lib around so old apps don't break. Yeah, I know, in 30 years, there are edge cases that don't work. But Linux can't natively run Linux apps from, uh, 2021, not without containerizing them first. Unless a kernel feature changed, and then they won't work at all. You learn in school that an API is a contract. You learn in Linux that an API is a Darth Vader contract. "I have altered the deal; pray I do not alter it any further."
Okay as a career SWE all enterprise APIs are Darth Vader contracts lol.

I can't even count how many times APIs changed, got dumpstered, or any other thing. My favorite is when you find out a company's enterprise, user facing API is actually a frankenstein monster they made out of various internal APIs that were all made because devs are lazy as fuck. Then you quickly realize that the API has tons of undocumented endpoints that can do all kinds of insanity like delete an entire instance of a SAAS service even if its a production one. A big reason why microservices became a big deal in the 10s.

API isn't much of a security risk if it does exactly 5 things and nothing else ever!
 
Okay as a career SWE all enterprise APIs are Darth Vader contracts lol.
It's one thing for a lib you ship with to change APIs. This is irritating, but it is your problem, and something that can be handled. The operating system changing APIs means programs start crashing all over the place. They should change rarely, optimally never. Linux changes a wide range of system APIs on a regular basis. It's why commercial software deployment on Linux is 10x more work than deploying on Windows or UNIX. It's why the only viable commercial Linuxes are the ones where they snapshot the whole mess and make only minor changes, like RHEL and SLES.
 
Secure boot certificates for Windows are expiring in June and sounds like it requires adding the new certificates to the computer's firmware.
Im not entirely sure if Microsoft will have a way of automatically installing the new certificates without direct intervention from the user, installing secure boot certificates for Ventoy and Linux Mint was fairly easy for me but I can see that being trickier for some users and I suspect the vast majority of users will be caught unprepared when the expiration happens. I wonder what happens if you were running Windows 10?

I feel like June 2026 might end up being a mini tech apocalypse if this isn't handled well where lots of people's computers just refuse to boot.
 
Secure boot certificates for Windows are expiring in June and sounds like it requires adding the new certificates to the computer's firmware.
Im not entirely sure if Microsoft will have a way of automatically installing the new certificates without direct intervention from the user, installing secure boot certificates for Ventoy and Linux Mint was fairly easy for me but I can see that being trickier for some users and I suspect the vast majority of users will be caught unprepared when the expiration happens. I wonder what happens if you were running Windows 10?

I feel like June 2026 might end up being a mini tech apocalypse if this isn't handled well where lots of people's computers just refuse to boot.
Secure boot certificate rollover is real but probably won't hurt you (A)
TL;DR: sane firmwares don't check whether certificates expired because date and time is an external thing to a computer so you should be fine (barring Pajeetsoft fucking up their updates around this)
 
Secure boot certificate rollover is real but probably won't hurt you (A)
TL;DR: sane firmwares don't check whether certificates expired because date and time is an external thing to a computer so you should be fine (barring Pajeetsoft fucking up their updates around this)
I suppose it's easy to check, just set your firmware clock to 2027 and reboot.

And how do you determine if a firmware is sane? I would expect that Microsoft would "encourage" it's hardware partners to fully support things their way which would include enforcing certificate expiry. But it sounds like all supported versions of Windows (such as 11 or 10 LTSC) should be fine, so only people who don't get updates won't get the new certificates.
 
Last edited:
I frequently use Copilot at work to make "digest" versions of technical sales decks for executive briefings and the like. Since a recent update, whenever I click "download," Copilot just crashes.
 
the way that Posix systems handle dynamic linking sucks massive dick and Windows does it way better. The simple reason as to why is that Windows makes it really easy for applications to have application specific libraries by just placing them in the same directory as the executable ... Arguably, application specific dynamic libraries defeat the entire purpose of dynamic libraries in the first place. The Unix solution to application specific libraries is to just statically link them instead of dynamically.
You can ship dynamically linked libraries with a software in Linux and just have them in the same working directory. It isn't about static vs dynamic linking at all.

The real underlying issue is that Windows provides a gigantic kitchen sink API that touches all its subsystems, that those dynamically-linked libraries can count on to exist and provide all the utilities they need. Meanwhile, Linux libraries have to have a N-deep dependency chain of other libraries to provide the same thing. Keeping all of these synced is where the problem comes from, not from where they're placed.

Statically-linked executables solve this problem because they shove that entire dependency chain into the executable, and the equivalent dynamically-linked solution is just as possible and exactly as (non)elegant: ship a copy of all the so libraries with the software. So rounding back, it isn't actually an issue with dynamic linking itself.
 
The problem Linux has is it's a coagulated mess of crap that is maintained by people who hate humanity and have no cruel corporate taskmaster enforcing binary compatibility on them. Back in the day, if you fucked up people's work the way Linux does, you would have lost your job. Linux isn't made by people who have jobs.
Linus does this for the KERNEL but nobody runs shit on a bare kernel. "Windows" usually means the Windows Kernel + the Windows API (of which there are a metric fuckton because Microsoft keeps changing what the damn hotness is for the current "native API"), and "Linux" almost always means (stallman mode get) GNU + Linux (or the distribution), which is a bunch of libraries that break ABI/API every fucking second along with a pretty darn stable kernel.

I'm still pretty damn sure the surge in containerization and virtualization is mainly driven by this linux fuckery.
 
Linus does this for the KERNEL but nobody runs shit on a bare kernel. "Windows" usually means the Windows Kernel + the Windows API (of which there are a metric fuckton because Microsoft keeps changing what the damn hotness is for the current "native API"), and "Linux" almost always means (stallman mode get) GNU + Linux (or the distribution), which is a bunch of libraries that break ABI/API every fucking second along with a pretty darn stable kernel.

I'm still pretty damn sure the surge in containerization and virtualization is mainly driven by this linux fuckery.
I swear that the distros which work best are the ones made for the lowest common denominator which are the gaming distros. The fact they are made for tech illiterate gamers is why they are so fucking stable and can work for normies even better than mint or base fedora. The three that have worked for me are Bazzite, Nobara, and Garuda Linux. Bazzite is troonix snd Garuda is made by a jeet so that leaves Nobara as just a weeb who named the distro after his waifu. My friend had Windian 11 break on his laptop and for whatever reason it would not let him install LTSC so we chose Nobara and it worked perfectly.
 
Back
Top Bottom