0 users browsing Discussion. | 1 guest | 18 bots
| tomman |
Posted on 19-06-24, 03:44
|
|
Dinosaur
 Post: #414 of 1317 Since: 10-30-18 Last post: 5 min. Last view: 5 min. |
Why Joe Vidya has to jump flaming hoops (virtual machines, containers, buying new overpowered hardware) just to play a videogame?! Not everything has to involve devops-y/Troo UNIX® graybeard sysadmin trickery just because they despise the Easy Modo life. Look, I get that Linux distros are often short on manpower so they're always looking for ways to reduce their maintenance workloads, and ejecting seldom used features is a easy way to achieve that, but who gets to take such decisions without consulting YOUR USERS FIRST? Stop distributing a 32-bit x86 installer? Fine. Kill multiarch userspace support? Not fine! This is not yet another "I want to play $ANCIENT_GAME on modern computers, so I need an emulation solution", this is breaking perfectly working setups for no good reason at all! We all get that x86 is long due for a replacement, but going 64-bit only that suddenly (while offering Rube-Goldberg-esque "solutions" to your -now possibly former- users) is a fine way to tell them "fuck you, and thanks for all the fish!". If you drive away all of your users, you will have plenty of available manpower... since there will be no distro to maintain after that! Yes, I'm aware that Wine is another hack that I would not like to have to use, but that's not the only use case to NOT kill 32-bit yet (curiously enough most of those use cases involve proprietary software, but I can think about a couple of FOSS apps that won't work at all under an all-64bit setup: that's the risk you run if you code your stuff in good ol' assembler unless you work twice and have separate sources for x86 and amd64). Also, for those that suggest that VMs are the solution, are you going to buy me the extra hardware and perform the required setup (which sometimes is far from trivial) so I can enjoy my old games that right now can just be executed in place with no performance loss and another layer of bugs on top? Sure, software developers often are at fault (you could have simply migrated your shit to 64-bit YEARS ago!), but as a software developer myself I understand that this is not always possible for a myriad of technical and non-technical reasons. Microsoft STILL supports Win16 (but only on 32-bit Windows builds) despite noone having made 16-bit apps in almost two decades (the excuse at this date is down the lines of "InstallShield and friends, you never know when you will need to install that old copy of Photoshop 6"). The reasons to kill 32-bit are not remotely clear, aside of the kool kidz' "IT'S OOOOOOOOLD and I hate dinosaurs!!!!" because the only processor arch they know is ARM. Maybe in 2025 virtualization/containers would have reached a seamless integration level with user desktop interfaces, and by them Steam and friends could just offer an one-click solution for that (even under Windows, as eventually MS will want to kill Win32 for good, no matter if they're in the right or wrong). But right now, we're not living in the future yet. Not even remotely. Don't be a rotten Apple (with a capital ASSHOLE), please. I hope this backfires spectacularly on Ubuntu's face, bleeding users just like Mozilla. But in the shorter term, this is no good for the Linux ecosystem at large because the kool kidz will end infecting other distros. At least I'm glad that "sanity" is the name of the game here at Debianland (for "good enough™" values of "sanity"). Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Screwtape |
Posted on 19-06-24, 04:24
|
|
Full mod
 Post: #288 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
> Kill multiarch userspace support? Not fine! What's the actual story here? Is Ubuntu actually trying to kill multiarch, or do they just not want to build and support specifically x86 userspace? At least in Debian, "multiarch" means the ability to install packages from incompatible architecures side-by-side on the same system (for example, ARM and MIPS), which is incredibly useful for cross-compiling. At least in theory, I think you can install ARM libraries and an ARM compiler, build ARM software and run it with QEMU's Linux-userspace emulation. Even without x86, Ubuntu still supports ARM, Power and s390x architectures, so multiarch would still be a useful thing for them. The ending of the words is ALMSIVI. |
| tomman |
Posted on 19-06-24, 04:34
|
|
Dinosaur
Post: #415 of 1317 Since: 10-30-18 Last post: 5 min. Last view: 5 min. |
From what I understand, Ubuntu will no longer build x86/32 packages of any kind, which also impacts the most typical scenario for multiarch users. If you absolutely must run your x86/32 software, you're now on your own. I don't know if you can build a x86/64 kernel that explicitly removes 32-bit support. For most users (including me), that's what "multiarch" usually means, and that's the bit that Ubuntu is trying to get rid of with this move. I might be pulling numbers out of thin air, but I can tell that there are far more people running x86/32 apps on x86/64 distros rather than people crosscompiling for ARM from x86. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Screwtape |
Posted on 19-06-24, 05:27
|
|
Full mod
Post: #289 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
On the one hand, multiarch is designed for all architectures to share. On the other hand, although multiarch would have been useful from the first day Linux was ported to a non-x86 architecture, nobody actually bothered to *implement* multiarch until a need arose to have x86 and amd64 binaries on the same system. RedHat's "multiarch" is even simpler and hackier - instead of putting libraries in a subdirectory named after the architecture name, it just has parallel "lib" and "lib64" directories... bad luck if you wanted two 64-bit architectures side-by-side, or if your original architecture was already 64-bit. The ending of the words is ALMSIVI. |
| BearOso |
Posted on 19-06-24, 17:23 (revision 1)
|
 Post: #95 of 175 Since: 10-30-18 Last post: 1451 days Last view: 1451 days |
Posted by Screwtape No, the need was there from day one. "Multiarch" is Debian's name for its most recent repository solution, but there were definitely 32-bit libraries packaged right from the start of 64-bit x86 support. Cross-compilation from my experience is different. The target libraries are stored in a cross-compiler-specific directory, not alongside system libraries. *edit* Forgive my misunderstanding. If I'm understanding you correctly now, you're saying the need for 32-bit on 64-bit drove multiarch support? Then yes, that's the only practical purpose. It's just an evolution of an earlier way of doing 32 on 64. They have a separate repository instead of bundled packs of 32-bit libraries in the 64-bit repository. |
| Screwtape |
Posted on 19-06-25, 01:58
|
|
Full mod
Post: #292 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Posted by Canonical Welp, problem solved, I guess. The ending of the words is ALMSIVI. |
| CaptainJistuce |
Posted on 19-06-25, 06:59 (revision 1)
|
|
Custom title here
 Post: #540 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
Posted by Screwtape Hooray, backwards-compatibility lives to fight another day! Also, from their post: You’ve heard about Spectre and Meltdown – many of the mitigations for those attacks are unavailable to 32-bit systems. What? Why not? --- In UTF-16, where available. --- |
| funkyass |
Posted on 19-06-25, 08:41
|
|
Post: #51 of 202
Since: 11-01-18 Last post: 660 days Last view: 16 days |
i doubt those protections would be enabled on 20+ y/o cpus, cause performance? |
| CaptainJistuce |
Posted on 19-06-25, 09:01
|
|
Custom title here
Post: #542 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
Posted by funkyassAre they as devastating to older processors as they are to newer ones? I mean, a Pentium 2 has fewer out-of-order optimizations than a Skylake Core, or whatever cute JRPG nickname Intel's given to their current processors. It stands to reason that it would lose less, assuming the vulnerabilities are implementable in the first place(it's become obvious that the recent Core processors have made some questionable decisions on their out-of-order and branch-prediction segments to gain speed, and it is the only reason the Intel-only exploits work). --- In UTF-16, where available. --- |
| tomman |
Posted on 19-06-25, 11:48
|
|
Dinosaur
Post: #416 of 1317 Since: 10-30-18 Last post: 5 min. Last view: 5 min. |
Cool, we've won this battle... but not the war.Software continues to grow in size at the high end, making it very difficult to even build new applications in 32-bit environments. Maybe it's time to... y'know, bring a notch or two down to the bloat? Nah, who am I kidding? BRING ON TEH JAVASCRIPTS!!! You’ve heard about Spectre and Meltdown – many of the mitigations for those attacks are unavailable to 32-bit systems. I'll keep those mitigations disabled across every single piece of hardware I'm directly responsible for (no matter the bitness), thanks. I'm an adult and can assume responsibility if some West Elbonian skript kiddo breaches into my junk for mining buttcoins or stealing my presidential assasination plans. Oh wait, noone cares! Neither do I. Intel (and everybody else) should still fix their broken junk. None of those discussions raised the passions we’ve seen here, so we felt we had sufficient consensus for the move in Ubuntu 20.04 LTS. It isn't "passion", it's "being able to actually use my computer with the software I've paid for/been using since forever". Anyway, you're still not guilty-free, Ubuntu. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Duck Penis |
Posted on 19-06-25, 13:05
|
|
Stirrer of Shit
Post: #439 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1762 days |
Posted by tomman https://en.wikipedia.org/wiki/Parkinson's_law 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. |
| creaothceann |
Posted on 19-06-25, 14:37
|
 Post: #158 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
Posted by sureanem Software is getting slower more rapidly than hardware is becoming faster. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| Nicholas Steel |
Posted on 19-06-27, 05:51 (revision 3)
|
|
Post: #225 of 426
Since: 10-30-18 Last post: 499 days Last view: 14 days |
Aren't most PC games 32bit? Like 70% or 80%? Pretty much every game released in 2009 and earler are 32bit or 16bit and that's a shit load of games... after 2009? We're still frequently getting 32bit games from indie devs and even some Triple AAA Publisher games are released as 32bit software. AMD Ryzen 3700X | MSI Gamer Geforce 1070Ti 8GB | 16GB 3600MHz DDR4 RAM | ASUS Crosshair VIII Hero (WiFi) Motherboard | Windows 10 x64 |
| tomman |
Posted on 19-06-27, 12:10 (revision 2)
|
|
Dinosaur
Post: #418 of 1317 Since: 10-30-18 Last post: 5 min. Last view: 5 min. |
Posted by Nicholas Steel Didn't you got the memo? You're supposed to stick to Windows forever, until MS says that it's time to throw your money in the trash because 32-bit is OOOOOOOOLD, unsafe as AIDS! Guys, please don't be like this guy: Posted by Some random at Moronix Or like this one: Posted by another pissed nerd at Moronix So basically us gamers have no rights, are holding "progress" hostage, and are actually HARMFUL for Linux. Got it. And people wonder why only nerds stick to Personal Computers these days :/ Also, fuck containers - not every Linux box is a cherished production server (where some hardcore nerds believe that it's the only place for Linux nowadays, according to such responses). Come up with a VirtualBox/QEMU fork specifically aimed at GAMING, and easy to use (none of this "container" hipster garbage), and then we'll talk. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Duck Penis |
Posted on 19-06-27, 15:24
|
|
Stirrer of Shit
Post: #445 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1762 days |
Happy that you're holding back the ONE Linux distro and really the ONLY distro that has and can bring Windows and Mac refugees into the Linux fold? You Geeks and Phreaks are Linux's BEST and WORST enemy! Or perhaps he's wondering how someone would bring into the fold a Windows user, by breaking the compatibility of his apps? Jokes aside, I am curious what compiler doesn't support 32-bit. GCC does, Clang does, and I would think MSVC and ICC does, but even if they didn't they're utterly irrelevant and a far greater edge case than i386 ever will be. Containers are pretty cool though. AppImages are almost exactly what I'd want in an application. No dependencies, just download and run. Could be made better, but so could everything. You might complain that they're bloated, but remember that every instance of productive bloat reduces the space available for non-productive bloat, and thus helps improve software quality. 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. |
| BearOso |
Posted on 19-06-27, 19:12
|
|
Post: #97 of 175 Since: 10-30-18 Last post: 1451 days Last view: 1451 days |
I looked into Snap packages and they’re a disaster. There’s so much Ubuntu-specific crap in the spec that unless you’re relying solely on Ubuntu’s packages it’s almost impossible to create one. Flatpak was much cleaner and easy to work with by comparison. |
| funkyass |
Posted on 19-06-27, 23:49
|
|
Post: #52 of 202
Since: 11-01-18 Last post: 660 days Last view: 16 days |
folders really should be the only package required to distribute stuff |
| Duck Penis |
Posted on 19-06-28, 21:35
|
|
Stirrer of Shit
Post: #447 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1762 days |
Well, sure, but then developers would have to build with static libraries. Because this is hard and also makes for big applications, they compile with dynamic libraries instead and then create one copy of the full library set for each application. They then assume that some other layer for which they conveniently are not responsible would handle that de-duplication, in accordance with a long-standing software developer tradition. ("don't worry man, the compiler will optimize it") Since dynamic libraries save space with more than one application using them, and dynamic libraries always have more than one application using them, or else they wouldn't be dynamic libraries, this means they always will save space, and thus must be used for AppImages. 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. |
| hunterk |
Posted on 19-06-28, 22:58
|
|
Post: #27 of 60
Since: 10-29-18 Last post: 1642 days Last view: 1564 days |
Posted by BearOsoIt's also really tough to get help with questions/issues/problems for snap packing. I've asked stuff on their forums and IRC and get little or no response. |
| tomman |
Posted on 19-07-26, 19:07
|
|
Dinosaur
Post: #452 of 1317 Since: 10-30-18 Last post: 5 min. Last view: 5 min. |
And now, the folks at Fedora also hopped on the failbus after losing their collective minds: First, the death of 32-bit x86 is now set: 32-bit kernels are no more, and they're considering to kill some 32-bit repos too: https://www.phoronix.com/scan.php?page=news_item&px=Fedora-i686-Drop-Kernel-Plus And today, we got the kicker: not only x86-32 is too stale for them, they're also trying to raise the bar on x86-64: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U/ https://www.phoronix.com/scan.php?page=news_item&px=Fedora-31-Possible-AVX2-Require Yup, someone is trying to convince the world that any 64-bit CPU made before 2014 should be thrown in a dumpster (yay, All of this because the Silly Valley "a new Mac a year" hipsters have finally infected FOSS down to the bone. There goes "Linux is friendly for the environment" and "Linux is helpful for 3rd-world shitholes with limited access to technology". Luckily I stopped being a RH/Fedora user almost a decade ago (and even then I stopped updating at Fedora Core 6, 12 years ago), but this is only matter of time before this anti-consumeritis spreads to the rest of Linux distros. Oh, Intel still sells 32-bit and AVX(2)-less systems right now, in 2019 (the Celeron and Atom lines do still exist, and still are somewhat-decent sellers, y'know). But you won't be running new Fedora releaes (or an hypothetical future RHEL release) on those anymore. All of this because those new-for-the-sake-of-oooh-shiny kids haven't learned how to use compiler switches (there is no need to bring separate amd64 and amd64-avx2 repos unless you want to drive your users crazy!). And if you absolutely need to squeeze performance of your state-of-the-art Ryzen rig down to the transistor level, you should be using Gentoo, not forcing others to pollute the environment and chase your users away! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
