Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
| tomman |
Posted on 23-03-26, 17:10 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
|
|
Dinosaur
 Post: #1221 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
We're in Deep Freeze™ in Debian Pole! Target kernel is 6.1, as it is a LTS branch. The noVideo 390.xx legacy blob works fine with that, and it's not that likely Debian is gonna dump that branch from Bookworm (barring any late-minute security issue), so I guess I'll avoid Nouveau hell by release date... but I'm pretty much on my own for future backported kernels. If you're thinking on send your monies to Asahi Linux: why not send them instead to the Nouveau folks? Macs are shiny and cool, but we Linux users deserve to have decent noVideo drivers for when upstream leaves us in the deep cold! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-03, 23:17 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
|
|
Dinosaur
Post: #1222 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Posted by wertigon It's a laptop, so... yes, I'm afraid. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-09, 15:20 in I have yet to have never seen it all.
|
|
Dinosaur
Post: #1223 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Kiss your emulators goodbye on your Xboxes, as MS is now dropping the banhamme on emulators in Retail Mode, this time for real: https://gbatemp.net/threads/microsoft-preventing-emulators-from-running-on-xboxs-retail-mode.630524/ Why is the Nintendo's stinky anticonsumer stench everywhere? Ah right, because Nintendon't happened: https://nitter.it/AlyannaMcKenna/status/1644033000219332613 You can still pay $20 for the privilege of letting Microsoft give you permission to run code on the console you paid with your own money, under the walled garden of Dev Mode, but that means a lot of hassle for those just looking to play Sonic ROM hacks explicitly allowed by Sega, so for many users out there that means the golden era of self-published homebrew in the Xbox is approaching its end. Isn't DRM wonderful? Come to PC, we have FREEDOM. Oh, and you can run Nintendo games without their permission, but don't tell them~ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-13, 02:13 in Games You Played Today REVENGEANCE
|
|
Dinosaur
Post: #1224 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Junkbot Was checking through my almost 20 year old backup CD-Rs on my Win9x retrobox when I found this good ol' classic (I even found the standalone launcher I made in VB6 to not bother running it on a web browser!). The one Lego game where you literally have to play with Legos to get our cute orange mad trash-eater bot to safely eat all that yummy garbage. The ambience is industrial-style (it literally happens inside of a factory!), and the techno-ish soundtrack absolutely fits that setup. You guys know how much I love puzzle games, and my teen me had a lot of fun with this web game 20 years ago, so I highly recommend it... if you can get it to run, that is! Amazingly the game stood on the Lego website for close to 10 years, and even got a sequel in 2003 (Junkbot Underground, which I also had saved but had not played it as much as the original). Sadly Junkbot was not made in Java or Flash, but in its lesser known cousin, Shockwave... which (unlike Flash) was silently killed in 2019, never had anything but Windows and Mac browser plugins, and it can be a problem on modern operating systems. And of course, Lego let our poor orange robotic dude rusting in the attic (we never got a official Junkbot set despite demand for it - looks like the webgame was quite popular back then). These are your options right now: - Use period-accurate software: apparently this game may have compatibility problems with later Shockwave Player plugin versions, so I suggest using Windows 98/Me with Shockwave 8.5 (later versions have broken audio), or (I haven't tested this) XP with Shockwave 10 or 12. - There is BlueMaxima's Flashpoint, which is a (ridiculously comprehensive!) preservation project for webgames... and both Junkbot games are on their collection. But the initial download is HEFTY (~800MB, and close to 3GB when installed!), and the Linux version is "experimental", requires Docker (WTF!?) and relies on Wine anyway. But on the flip side, it restores the game ability to save your progress (apparently it talked home to Lego back then to do that), so there is that. And... this guy really loves that game! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-16, 20:38 in I have yet to have never seen it all. (revision 2)
|
|
Dinosaur
Post: #1225 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
My quest for - We now have awesome Director/Shockwave decompilers, and best of all, they're FOSS! 20 years ago, the best we had were Flash deocompilers that costed an arm and a leg, but nothing for Director. - Lingo is now becoming a lost programming language. But then, I didn't liked it in 2003, and still dislike it now, and Macromedia's environment and docs doesn't make it a palatable option for a guy like me used to full blown IDE. Ironically Adobe would try to get people to move to JavaScript by adding it to Director 11... with limited success :/ - If you're not dealing with the monstrosity that is Flashpoint, today I learned that ScummVM can run games other than old LucasArts games, as it now has some support for Director games! Even better, it's being actively worked on, and as a bonus it doesn't rely on webshit (unlike Ruffle). However support is mostly limited to early Director versions, so later Shockwave stuff is still off limits (Junkbot was made in Director 8) - You still need good ol' Director for messing with those decompilations, but fortunately it's a VM/retrobox-friendly environment. Even better, you don't even need to pay a dime to greedy Adobe (who shitcanned Director/Shockwave in 2017 with absolutely noone shedding a tear): if you do not want to track down a pirated serial, just get Director MX 2004 (Director/Shockwave 10), and follow these instructions to claim your free license key from Adobe since these versions relied on activation servers that are now defunct. If only they did the same for their Creative Clown jail... - Retail Director 8.x/MX installers won't let continue you without a valid license key. If yours does, it's because those are for the demo versions! - Shockwave Player installers are nicely preserved everywhere, including at the Archive. But... there is a catch: every single copy of the Shockwave 9 installer you're going to find online is "corrupted"... because those are actually ZIP files in disguise, whose contents is the Shockwave 8.5 installer instead! Yeah, Shockwave 9 DOES NOT EXIST, because its matching Director version (Director MX) didn't brought a new Shockwave version - instead it still ships with Shockwave 8.5. So much for curation, eh? (FWIW, Junkbot and its sequel doesn't work properly with Shockwave Player 10 and later, at least not for me) - Maybe I should lend a hand to the TCRF folks.... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-19, 03:43 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
|
|
Dinosaur
Post: #1226 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
If kernel 6.1 breaks backlight control on your jurassic laptop, send your death threats to this dude. Or not - he WARNED us and we chose to gleefully ignore him. My Inspiron 6400 now needs acpi_backlight=vendor to restore backlight to it's usually semi-broken (but still controllable) status, but your laptop might be Different™. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-19, 06:22 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs) (revision 1)
|
|
Dinosaur
Post: #1227 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
And now, for the Stupid Experiment Of The Day: crosscompile Super Mario 64 on a Debian box for Win9x retroboxes! Nintendo will unleash their dogs over anyone that dares distributing a binary built from the decompiled SM64 sources, so you're on your own. And the build instructions out there for Windows targets assume that you're 1) building ON Windows (yuck!), and 2) targeting "Windows 7 or later" (ha ha). Crosscompilation guides also suck because they assume (wrongly!) that you're using Arch (!!!), so they're of no use for this case. While there have been people reporting success on building Win9x-compatible binaries, noone will tell you exactly the full gory details to do it yourself at home. Since I'm - I'll pick the recommended fork for PCs these days, which is sm64ex. I'll also assume you can already build that for your Debian host - otherwise review the Linux build instructions first. Don't forget to place a vanilla SM64 .z64 ROM under baserom.us.z64 (or whatever region you want to use!) - Install the mingw-w64 package. It will require ~1GB of disk space and will net you Win32 and Win64 crosscompilers. You'll also need zstd because we need a few dependencies from MSYS2, and they're now using this hipster - Download these dependencies from MSYS2: mingw-w64-i686-SDL mingw-w64-i686-libiconv mingw-w64-i686-glew You'll end with some weird .zst files, which you will be able to extract with a straight tar -xvf if you've already installed zstd. Extract all three to a known place - you should end with a single /mingw32/ directory. Take note of that location! - Edit /PATH/TO/mingw32/bin/sdl-config to fix some things, otherwise our compile will bomb out: Change line 3 (prefix definition) to: ...and line 45 (--CFLAGS include path) to: - Build! Use this commandline (fix your paths accordingly): make TARGET_ARCH=pentium TARGET_BITS=32 RENDER_API=GL_LEGACY WINDOW_API=SDL1 AUDIO_API=SDL1 CONTROLLER_API=SDL1 WINDOWS_BUILD=1 CROSS=i686-w64-mingw32- CC=i686-w64-mingw32-gcc CXX=i686-w64-mingw32-g++ SDLCONFIG=/PATH/TO/mingw32/bin/sdl-config -j4 You want a Win32 binary using SDL1 and legacy OpenGL 1.x renderer, and this commandline will eventually generate one for you. - If you've followed these instructions correctly, you'll end with an executable under build/sm64.us.f3dex2e.exe. This will run... on Windows XP, but not 9x yet! The reason is that the libSDL static libraries from MSYS2 rely on a couple MSVCRT functions that do not exist on Win9x' msvcrt.dll (and no, you can't replace that lib or cheat by placing a newer one under the same directory as the executable! Fortunately the fix is simple - just bring your favorite hexeditor and do the following edits: * Replace _strtoi64 (hint 02B2) to strtol (hint 02C8) * Replace _strtoui64 (hint 02B5) to strtoul (hint 02C9) Be careful: the leading underscore is part of the original function name. Zero out the extra characters, and don't forget to fix the hint numbers too (they're BYTESWAPPED!). If you didn't screwed this, your binary will now run under Win9x! - Wait for the Nintendo Ninjas to knock at your door. I recommend a shotgun. And yes, those are the horrendous SiS 630 OpenGL drivers wrecking yet another fine game (poor Peach has some severe herpes there! Shadows are BROKEN!). Performance is barely better than the ancient emulators I used on that thing 20 years ago, but hopefully your retrobox doesn't suck as much as mine :P Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-24, 01:52 in I have yet to have never seen it all. (revision 1)
|
|
Dinosaur
Post: #1228 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Well, the impossible has happened, AGAIN: someone wrote a BREW emulator! And it even WORKS! (as in "runs games") Melange, a BREW emulator Android only, so far. Well, "emulator" is really stretching the meaning of the word: for those that never had the misfortune of owning a CDMA cellphone not made by Nokia prior to 2007, or sold by the now defunct Sprint PCS, BREW apps were NATIVE ARMv7 executables, not Java bytecode. This meant they were FAST, and often with nicer graphics than its J2ME equivalents. So in this case while the UI layer is emulated, the actual game code runs natively on your cellphone SoC, so this is more of a Wine-like approach. Absolutely impressive. However, sound seems to not work? (at least I got no sound on a couple games I tested on my Alcatel, and I'm not sure if this emulator would work on ARMv8 phones) What impress me is the fact that there are loads of game dumps out there, considering that BREW phones are usually locked out tighter than most modern iDevices! Software preservation FTW! (Oh, and FUCK YOU QUALCOMM! Fuck you forever, I'll never forgive you for the sins of your Binary Runtime Environment for Wireless jail!). Unfortunately my last BREW phone (my ol' trusty Motorola VE20) now rests in pieces in a box (its flex cable broke in 2019 after the cracked hinge couldn't hold the two halves together), and last time I tried to dump the dozen or so BREW games I had paid good money to Movilnet for, none of the tools I had back then could bypass the filesystem locks, or even do a full memory dump without having to resort to JTAG :/ A shame, as many of the games on that phone are still undumped and in risk of getting lost forever. However the bare PCB still powered up and could be plugged to a PC, so should a better way to dump those games appear in the future, hope it's not too late! Many games (like anything by AppAbove Games) never made the jump to the smartphone era, or even had J2ME versions! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-25, 19:43 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
|
|
Dinosaur
Post: #1229 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
PSA: Thanks to braindamage of both FFmpeg and VLC, the latter will ship with non-working VAAPI hardware acceleration on the next Debian stable release (Bookworm): https://code.videolan.org/videolan/vlc/-/issues/26772 https://code.videolan.org/videolan/vlc/-/merge_requests/1245 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021601 Here is the problem in detail: - VLC depends on FFmpeg, just like every other media player in FOSSland these days - VLC relies on FFmpeg for hardware decoding, including its VA-API interface. - FFmpeg will never learn the advantages of having a stable API/ABI (just like most FOSS) because those are for wimps, and did major changes for its 5.0 release sometime last year, including its handling of hwdec APIs. - Said API changes required major reworks on downstream projects with regards of VA-API support, which mean everybody had to update their players, AGAIN. - While most players eventually picked up the pieces and moved on, VLC devs chose a different path: their upcoming 4.0 release which has been delayed for at least 2 years, and which has no release date yet. - VLC also announced they're not fixing VA-API support on the current stable branch (3.0.x) since the required changes are far from trivial, leaving distro maintainers in a rather rough spot: either keep dragging multiple FFmpeg releases, figure out how to fix VA-API support on VLC, package and distribute a new major VLC version not fit for public consumption yet, or drop VLC completely. - While VLC devs assumed most distros would pick the easy way out (multiple libavcodec versions), the Debian maintainers aren't eating this bait after having been burned in the past, so they had no option but to adopt the VA-API-less patch and pray that noone notices. To be fair here, I can't blame Debian - they're distributors, not developers, they didn't got a word on this and we users get the short end of the stick, as usual. Now with the Bookworm release real close (we're now in Maybe fansubs were right all those years and either VLC was junk, or hardware decoding is for sissies :/ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-28, 01:23 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs) (revision 1)
|
|
Dinosaur
Post: #1230 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
https://lists.debian.org/debian-devel-announce/2023/04/msg00007.html Ladies, gentlemen, and FILE_NOT_FOUNDs of the boards, save the date: Bookworm is going Time to define the update strategy for the fleet: - T40: Already done! Picked my least used setup for a trial - went without a hitch, except for a minor catch which I'll detail later. - Thinkcentre: Next on the firing order, maybe I'll do that one before launch date too. - I6400: Will also get upgraded around release date. - Asus: Most likely by early 2024 for now, I'm not messing right now with my daily driver. - Saki Mark II: yeeeeeeeeesh, not yet. "2024" until further notice. Since I have to update many setups at home, I have two options to minimize the download impact on both Debian servers and especially my pathetically slow 3Mbit DSL which will go with me to the grave, it seems: either setup a local mirror (looks unfeasible since I can't find a ballpark feature for a SINGLE arch "all+i386+amd64" disk usage, and I'm not cloning 2TB for a entire Debian mirror!), or an "apt cache" (I've been suggested to use apt-cacher-ng, which is a on-demand cache setup) Ah, the first gotcha on the Bullseye->Bookworm upgrade: GRUB_DISABLE_OS_PROBER now defaults to true for "sekuritah" reasons, which means you'll lose the $OTHER_OS boot entries on your GRUB menu! Edit /etc/default/grub, add "GRUB_DISABLE_OS_PROBER=false" somewhere, save, rerun update-grub, done. Posted by Kawa Over 10 years ago, fansubs used to HATE VLC due to its subpar support for their ridiculously overengineered .ASS styled subtitles (mainly stupid overkill karaoke animations that would bring down a fast Pentium 4 playing SD video down to its knees). There was even one incident of a specifically crafted .ASS subtitle track that would crash VLC (which turned out to be a security flaw!). Instead large parts of the scene insisted in their carefully crafted codec packs for Windows (remember CCCP?), and those on other non-Windows platforms could go pound sand (mpv was in its infancy). They also derided anyone using mobile devices ("plastic toys"), and even when hardware decoding became commonplace on PCs, many actively avoided them (guess why you can't play most modern anime encodes on anything but software decoders AND some very niche devices? Look for the Hi10P drama, one of the many reasons I quit downloading anime) VLC support for styled subs would vastly improve since they switched to libass, and these days nobody cares, but I still remember when fansubs would kick your ass on IRC if you dared mentioning cursed words like VLC... or VirtualDubMod :P Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-29, 03:56 in Windows 11 (revision 1)
|
|
Dinosaur
Post: #1231 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
https://www.theregister.com/2023/04/28/no_more_updates_for_windows_10/ Win10 has been sentenced to death by MS - no more feature updates from now on, only security patches. Starting October 14th, 2025, it's Windows 11 or nothing. If you can afford the MS-sanctioned metal to run it, go nuts. If you can't or won't collaborate with the global pandemic of e-waste, then Win10 is the new Win7 is the new WinXP is the new Win98 is the new DOS. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-05-03, 16:04 in Windows 11
|
|
Dinosaur
Post: #1233 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Why not mix and match then? Keep the rust spinners for the legally acquired media, and use the solid storage for your OS, applications, and frequently accessed files. If you're at home, your rust spinners are just a cable away. And if you're away... plan ahead! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-05-04, 14:49 in I have yet to have never seen it all. (revision 1)
|
|
Dinosaur
Post: #1234 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Posted by creaothceann WebGPU is the new WebGL. That means it is the new way to draw 3D in web browsers. It is, in my opinion, very good actually. It is so good I think it will also replace Canvas and become the new way to draw 2D in web browsers. In fact it is so good I think it will replace Vulkan as well as normal OpenGL, and become just the standard way to draw, in any kind of software, from any programming language. (emphasis mine) ...I stopped reading right there. Good luck forcing AAA++++ gamedevs to build their flagships in webshit. Thanks but no thanks. Posted by creaothceann Now this is more down my alley: I thought only IBM bothered using Phoenix' BEER and PARTIES HPA bullfuckery! (everyone here that had to deal with old ThinkPads or ThinkCentres know what I'm talking about). Apparently not, because Samsung -in true Korean software fashion- had some really bizarre ideas there. On the brighter side, if it runs Linux it has to be jailbroken because YES~~~ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-05-05, 19:34 in I have yet to have never seen it all.
|
|
Dinosaur
Post: #1235 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Mischievous NPM Publications OK, now that's something absolutely evil shit, and yet another reason I'll not be adding NPM (or Javascript anything) to my resume anytime soon. Who in the hell let the Three Mischievous Fairies of Light have publishing rights to NPM!? Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-05-14, 14:15 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs) (revision 2)
|
|
Dinosaur
Post: #1236 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Asahi Linux (actually marcan) To Users: Please Stop Using X.Org Gotta love the smell of clickbait and flamebait in the morning~ But we can't expect better from a former console hacker/drama queen from Spain. I'll try to keep this polite, so I'm going to say this: MY computer, MY rules. No software developer decides what I should use and what I shouldn't, no matter the hardware. Please stop "pushing" my desktop "forward", THANKS. NOONE ASKED YOU FOR THAT. From now on, I hereby decree that Wayland is PERMABANNED in THIS house. If Debian ever caves to the Wayland "forward thinkers", that's the day I'm staying with the last Xorg-enabled version until it dies of bitrot, THEN I'm quitting computers for good. Hector Martin, welcome to my select list of Assholeware™ developers, just next to Moonchild, Tobin, and Jamie W. Zawinski. I'll be avoiding any project you're actively involved on from now onwards. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-05-21, 20:05 in Windows 11
|
|
Dinosaur
Post: #1237 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
As someone that has already installed a fair number of SATA SSDs on machines that are (sadly) not mine, getting rid of the random R/W performance bottleneck of rust spinners IS completely worth the price of admission. As a bonus you get to save power, which on a laptop means a few minutes of extra runtime, even on a worn battery. You're still limited by the SATA port speeds, and in sequential reads the difference between a HDD and SSD is minimal, but sequential reads are not the most usual operation your OS will do everyday. I now even want SSDs on my retroboxes, thanks~ Once you taste the forbidden fruit, there is no going back. For now I'm stalled for the most obvious r€a$on... but hopefully Soon™.... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-05-29, 20:48 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
|
|
Dinosaur
Post: #1238 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Look, I'm not against new tech - I'm NOT that much of a luddite (yet!) I'm against new halfassed tech designed by committee, where you're replacing a pile of hacks for a bunch new shiny code with many shortfalls that aren't a 1:1 replacement for most use cases, and where anyone presenting a sensible complaint gets promptly dismissed because You Don't Fit The Vision™. For me, Wayland IS my systemd moment. If I'm "going under" with Xorg, so be it. But then that day is far away, considering that Win32 is still a thing :P Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-06-10, 17:09 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs) (revision 1)
|
|
Dinosaur
Post: #1239 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Today is Bookworm's Release Day~! GO. --- Just upgraded Ye Olde IBM TV Box: another traumatic upgrade experience because the Radeon HD2600 is starting to show signs of the RoHS pox (or simply wants to die), as the machine hung early in the install phase, then after a reboot the display went corrupted... and hung again. After removing the case, poking it at the stupid AGP card, and trying a couple times ago, I'm gladly surprised of the battle-tested, highly resilient Debian package managers - here is how you recover from a botched upgrade (flaky hardware, blackouts, etc) without having to pull the nuclear option: - If the machine boots, that's good! Try booting to recovery mode (Advanced Options -> select any kernel that says "Recovery"), then give your root password and move on from there. - Try rerunning apt-get dist-upgrade. It will figure out that the last run was interrupted and will tell you what command to execute, which will be either dpkg --configure -a, or apt --fix-broken install - You may need to repeat that a few times until you're able to do a clean dist-upgrade, then reboot~! Some side effects: I lost all of my locales (except for en_US.ISO-8859-1), so I had to run dpkg-reconfigure locales before the first reboot to clean up that. Also had to do the GRUB_DISABLE_OS_PROBER=false so I don't lose the Windows boot entry (remember: dualbooters now have to do that because $RAISINS) As for the loss of VAAPI hwdec on VLC, there is a workaround: VLC still supports VDPAU, and there is a VDPAU-to-VAAPI bridge available on the repos: libvdpau-va-gl1. Install that, setup VLC to use "VDPAU output" as video output, done. Or use something else not made by braindamaged Frenchies, I guess... 2/5 done~ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-06-13, 03:24 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
|
|
Dinosaur
Post: #1240 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Bookworm launched... without the noVideo blob for some "legacy" GPUs, namely my Fermi 610M: https://tracker.debian.org/pkg/nvidia-graphics-drivers-legacy-390xx https://bugs.debian.org/1006719 https://bugs.debian.org/1033776 Remember, the 390-series blob went EOL last December, and that was reason more than enough to not ship it with the latest Debian stable. Even worse, a bunch of CVEs were disclosed recently affecting a large number of nVidia's blob... including already EOL'd versions, so it doesn't make any sense to ship obsolete, broken, and potentially insecure software with a stable distro. This also means for those of us stuck forever on Tesla/Fermi GPUs that we no longer have the right of having good, stable drivers with great performance for our metal. All that it's left is Nouveau and the big punch to the liver that comes to it with regards of its (lack of) performance because they never could get reclocking properly implemented for those GPUs, and I can't really blame them since, unlike Asahi Linux, noone is throwing money at them to support the ever-growing numbers of nVidia GPUs on Linux boxes (after all, "the blob works fine for the 99%"... until it no longer supports your card, but by then you're due for a new computer, right? RIGHT?!). The 390 branch is still available from Sid, and it should work for now (assuming you figure out which packages to install), but it won't work for much longer, so maybe it's time for me to just write off this useless extra GPU for which I paid good money 11 years ago :/ Or, if I'm masochist enough, risk frying this laptop for good with scripts like this: https://github.com/ventureoo/nouveau-reclocking (On the flip side, I would gain proper PRIME offload, something that noVideo refused to give us many years ago) Remember kids:  Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
