0 users browsing Discussion. | 1 guest | 7 bots
| CaptainJistuce |
Posted on 22-08-12, 07:50
|
|
Custom title here
 Post: #1104 of 1164 Since: 10-30-18 Last post: 66 days Last view: 3 days |
Posted by Kawa The Adventures of Yolo. --- In UTF-16, where available. --- |
| tomman |
Posted on 22-08-12, 18:41 (revision 4)
|
|
Dinosaur
 Post: #1172 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
3/4: the Asus is done! - Need to clean up a bunch of Python 2 remnants. The initial update marked on hold a metric fuckton of obsolete Python 2-related junk, so a post-update dist-upgrade seems to be required to take care of that, plus some manual cleanup later. - No extra unwanted tray icons/applets this time! - Yeah, Cleanlooks-Phenix has been victim of the UXtarded terrorists from GNOME. A minute of silence, please... - I lost VirtualBox, as expected (due to the reliance on Python 2 junk). I may or may not deal with this later, depending on how urgent I need to run VMs (if you still want to give Orrible® relevance, the recommended instructions is to add Debian Fastrack to your sources.list). Or maybe I'll bite the bullet this time and fully commit to QEMU/libvirt... - ntp conflicts with systemd-timesyncd - use one or the other. Apparently the systemd way™ is simpler to manage. But even good ol' ntp has evolved a bit too, as it's now a transitional package for ntpsec, whatever that is. Since I extinguished my Poetteringware hateboner (needed room for the cellphone/Javascript hateboner instead), I'll keep it this way and just get rid of the old ntp version. - Also have to reinstall: Clang, Inkscape. For the first time EVER since I'm using Debian, I ended with only ONE GCC version: the one shipped and supported by Debian Stable: GCC 10 - GCC8 got wiped too during the upgrade. Nice~ - Speaking of Inkscape... it's now forcing fucking Adwaita on me. WHAT THE FUCK. Fortunately you can tell Inkscape that nope, I do not want fucking Adwaita (or anything by the GNOME team), and instead Thou Shall Respect Mine System Theme (which shall be TraditionalOK as Cleanlooks-Phenix was savagely murdered by the GNOME design clowns), but what the fuck, since when software is supposed to override system themes?! Ah yeah, GTK... hope they choke on a iPhone cable. - Need to recompile every single of my off-repo emulators to take advantage of the new libs, or to have executables that can run here. On the flip side, I now have a GCC version able to compile current Dolphin, so for now I can delay the unavoidable build errors whose fix is to play Clang version games with Backports, or "update your distro, buddy~". - The noVideo blob is still there. I still need to get rid of 10-nvidia.json to not let GDM3 fuck up with my * For the blob, * bbswitch however is NOT on backports, but a fixed version for 5.18 is on Testing (bookworm). But you can't just take the .deb and rebuild it, as it requires updating dkms and some DEB build crap. BUT! All you need is a single patch (linux-5.18.patch) from Bookworm's source .deb, add it under debian/patches/, and don't forget to edit debian/patches/series to place it at the end so it applies. Rebuild and enjoy~ Oh, if you use GDM3 as your login manager, don't forget to zap /usr/share/glvnd/egl_vendor.d/10_nvidia.json - either delete it or chmod 000 it, otherwise the nVidia kernel blob will load at every boot, needlessly wasting power. - If your GPU only supports VDPAU for video decoding *cough*noVideo*cough*, vdpau-va-driver is now gone. Dunno what's its replacement these days, but all decent players support both leading APIs, and I can't imagine of any case requiring a VA-API wrapper for VDPAU (the inverse is also true these days: since the death of Flash, nobody really needs wrappers these days). - Surprisingly my PJ64_V1.x (read: not true N64 ROMs) ROMhacks still work on Debian's Mupen64plus builds?! Well, I tested one, and it booted fine. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-08-15, 00:34
|
|
Dinosaur
Post: #1173 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Sayonara VirtualBox, thanks for all the fish and sorry you have to rot in Orrible® hell. However, my entrance into the weird and wonderful world of QEMU/libvirt wasn't exactly seamless. Here are my notes on migrating one of my XP VMs from VBox to QEMU: - Packages you need to install: qemu-system, libvirt-daemon-system. This will bring a bunch of QEMU bits you may or may not need (hooray, I can now emulate ARM machines other than GBA/NDS). For a nice, user-friendly (mostly) GUI, I'm using virt-manager. - Add yourself to "libvirt" group, then logout and login again before doing anything else. - VirtualBox uses VDI disk images, while QEMU uses QCOW2 images - you can't attach VDIs directly so you need to convert them: (On older QEMU releases you needed to convert from VDI to VHD using VBoxManage first - today that's no longer necessary as qemu-img now understands VDI format too) - You need to start virtual networking first, or libvirt will not let you create a VM with networking at all! - Create a new XP VM with virt-manager, and don't forget to tell the wizard you're going to install XP on it (you need to tick the box to show unsupported OS for XP to appear in the list). This is mandatory and can't be changed once set it up (alongside other settings, like base chipset). You already have a VDI with a working XP setup, so attach that one instead of a XP setup ISO. - Boot! And... get stuck in a endless reboot loop with STOP 7B BSODs. 7B means Windows can't find the boot volume because we've changed storage controllers. There are two ways to address this, depending if you still have VBox installed or not. In my case I had to download an old version of Hiren's Boot CD, and use its fix_hdc.cmd patch (you need to tell it first where is your Windows folder). After that, Windows will now boot, and... - ...get confused because of all those new unknown devices, as expected! And here is where Internet failed miserably at me again: most "XP on QEMU" guides are hopelessly outdated, so let's feed this down Google's throat: if you stick to defaults, all you need is the SPICE Guest Tools installer for Windows - it will nicely take care of this. But wait, there is no ISO download, and you're likely to have selected an unsupported (by XP) Ethernet card! Either build an ISO, or shutdown the VM, and change Ethernet setup to good ol' Realsuck RTL8139, for which XP DOES ship drivers! I downloaded the guest tools on my host Debian and just copied it via Samba (don't forget to SMBv1 support first!). This will install all of the missing drivers (QXL video, QEMU-specific guest drivers, and VirtIO devices). After that you can even switch from RTL8139 to virtio for a nice performance boost on your virtual networking. - Life would be perfect if I could figure out how to export my new fancy VM to a .OVA container for future deployments... So yeah, I'm quite impressed with QEMU/libvirt, albeit not all is roses and caviar: * Documentation (particularly at migrating between virtualization products) is MISERABLE - Internet doesn't help as many of the guides you're going to find are aimed at virtualizing Linux distros, newer Windows versions, GPU/PCI passthrough, or are hopelessly outdated and no longer apply to recent versions! * Networking is a pain. VirtualBox handled transparently all the networking modes you could have wanted, including bridged mode. But on libvirt and friends, you now need to learn an extra bunch of external commands, plus tampering with /etc/network/interfaces and other arcane UNIXisms just to let your VM behave like another bare metal PC on your LAN (that is, bridged mode!). This NEEDS to improve if the plan is to get people off VirtualBox/VMWare! Some of us just want to run old software/games on its original environments, not to run webapps and server shit! * libvirt takes ownership of any ISO you ever mount on any VM. Rude, and completely unneeded noise. * virt-manager translates some special characters on filenames to XML escape sequences, which break things when you start the VM - this bite me when trying to mount Hiren's Boot Disc (as it has a hypen on the ISO filename). Guys, it's 2022, are we still falling into the same booby traps over and over?! * Haven't tested USB passthrough yet, but I expect pain. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| creaothceann |
Posted on 22-08-15, 07:17
|
 Post: #415 of 456 Since: 10-29-18 Last post: 47 days Last view: 4 days |
Posted by tomman Should at least be better than VBox, which only supports USB 1 speeds in the free version (afaik). [1] [2] My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| tomman |
Posted on 22-08-15, 15:41 (revision 1)
|
|
Dinosaur
Post: #1174 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Posted by creaothceann For VBox, the open source edition and the official binary releases only support USB1, indeed. But Orrible® offers a free but proprietary, binary-only extension pack that adds support for USB2/3 (among other things), which comes with a lot of legalese attached, so it's understandable that many people prefer to avoid it, considering how litigious are Larry's minions. The other big problem with VBox are its kernel modules: only the guest drivers have been mainlined on Linux, while no real attempts have been made for the host-side modules (required for nearly everything, including networking). Remember, Sun was bought to weaponize Java against the industry (and they have been quite successful at that, considering that the lawsuit against Google is not dead yet), everything else was expendable. At this stage, they should do the right thing and punt VBox to someone else who cares (preferably someone that isn't the Apache Foundation's Foster House For Unloved Oracle FOSS Products). But it seems that ship has sailed, and on top of Das Embargo™, I have no option but to make friends with the messy QEMU/libvirt/KVM ecosystem... UPDATE: Oh, I just read your links. Typical "One Raging Asshole Called Larry Ellison" tactics in action. Yeeeeah, this kind of extortion IS illegal, but Orrible® has more lawyers than many nation states together. So it's wise to avoid using VirtualBox anywhere. A shame, the product was fine, but once again, Larry bought Sun to weaponize it against the world, not for improving on it. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| creaothceann |
Posted on 22-08-15, 20:00
|
|
Post: #416 of 456 Since: 10-29-18 Last post: 47 days Last view: 4 days |
It seems that lawsuit was concluded last year. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| tomman |
Posted on 22-08-15, 22:30
|
|
Dinosaur
Post: #1175 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Posted by creaothceann Just like the SCO v. IBM lawsuit (the Emiya Shirou of frivolous IT lawsuits), Oracle will hit back. Mark my words, and promptly uninstall all Orrible® software from your system! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-08-18, 03:02
|
|
Dinosaur
Post: #1177 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Well, at least I now have a OpenGL 3.x-capable PC with "GCC 10 or newer", so let's try again building Now instead of running two make commands (and ignoring the need to setup Docker), they've switched to a more modern CMake+ninja contraption. At least the instructions are simpler this time: run four commands in order and you're done. Too bad they still insist in "join our Discord" for troubleshooting instead of foolproofing the build procedure (god forbid you've using the wrong ROM - all you're getting is a useless KeyError from a Python script which leads to useless issue reports where one of the contributors will call you a pirate). Hope that they at least manage to figure out how to use ROMs other than a very specific leaked debug ROM only found on GameCube discs made of solid unobtanium. Oh, and they made the keys remappable - hit F1 to enable a ImGui-based menubar/UI and you'll find the option there. Sanity, at last! Oh wait, I forgot that the older I get, the harder I SUCK at RPGs :/ Was OoT's camera always that bad? Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-08-28, 19:24
|
|
Dinosaur
Post: #1179 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Upgrading to Bullseye ended adding a bunch of extra xdg-whatever executables to each graphical session:Like, WTF is this shit? Apparently it's the extra distro/DE-specific integration bits required for sandboxed gamepaks™ in modern Linuxland (that is, Flatpak and Snap) to be able to access your files and other potentially dangerous operations. Since I do not intend to run any of those newfangled pieces of bloat (gimme sources I can compile, target the Steam Runtime, a statically linked executable if there is absolutely no other way, or GTFO), these xdg-desktop-portal bits are NOISE and BLOAT. Just purge xdg-desktop-portal, kill all those running executables (apt won't do it for you WHY?!), and call it a day. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-08-30, 01:37
|
|
Dinosaur
Post: #1180 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Now that I had updated, decided to recheck the Bluetooth audio situation between my cellphones and Debian. Oh, since I now have Yet Another Android Junk (the Xinniephone Note 11), I need to test it to see if there have been any improvement. Spoilers: Bluetooth audio is still a dumpsterfire. - A2DP still works fine. HSF/HFP still FAILS to work on Android phones, the Redmi Note 11 included. KrapOS® still aces this single task with flying colors - maybe whoever wrote this feature on B2G actually used it? I thought dogfooding was banned in modern software/hardware development! - Speaking of the Redmi, it can be somewhat picky if you plug headphones yet want to go back to BT audio: you can't. Instead you need to unplug headphones. But what if you want to keep your headphones plugged in (say, for FM radio) yet want to use BT audio? Simple: plug headphones FIRST, then open the BT connection to your speakers! - Oh, add the Redmi Note 11 to the ever growing list of "devices where the FM radio only exists on the analog realm", as there is no way to pipe FM radio to anything but wired headphones! But this phone goes further: if you have BT audio currently enabled, Xiaomi's radio app will disable the "switch to speakers" option! WHY. Also, the Xiaomi app allows to RECORD radio, so why there is no way to listen to it over Bluetooth?! So... uh, I'm not giving up my wired headphones ever, thanks. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-09-03, 15:36
|
|
Dinosaur
Post: #1181 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Some minor fallout from Bullseye update: mpv will no longer stream anything requiring youtube-dl because the latter won't run anymore in Bullseye because of Python crap:The bug-du-jour today is: the /usr/bin/python symlink is no more as of Bullseye due to Python 2 being deprecated, and the world expecting to be fully settled on python3. While youtube-dl will work with either major Python version, it tries to guess using a symlink you would expect to be there on any sane Linux distro, but Debian folks decided to remove it because they Know Better Than You™. Thaaaanks but no thanks. The solutions, in order: - youtube-dl is deprecated, dead upstream, and nobody should be using it anymore - the new hotness has been for months yt-dlp. Except that yt-dlp is not a drop-in replacement due to subtle commandline changes (so renaming/symlinking yt-dlp to youtube-dl won't work - it will die with some Lua-related vomit). Instead, you need to update to mpv 0.34, which brings proper yt-dlp support. Guess what version ships with Debian Stable? 0.32! And apparently mpv is one of those packages that never get backports (0.34 is on Testing right now!), so I'm fucked right there. - Compile mpv from source. Sorry, but I'm not doing that anymore. Since I retired from the anime encoding scene and the "running EOL'd distros for lulz" club, I have absolutely no desire to deal with FFmpeg and friends, so that's NOT happening. - Modding whatever Lua script mpv uses for invoking youtube-dl. Nope, can't really do that either, those things are extremely undocumented and upstream would not like you to do that but to bug your distro to update. - Fix the /usr/bin/python symlink. Easy, but there is a more elegant, Debian-style solution: install "python-is-python3" package. That will make youtube-dl work again... until Youtube and friends break it for good. - Call yt-dlp directly and pipe that to mpv - that has always been an option since the early days of youtube-dl: You miss proper integration, but at least it pleases the Troo UNIX® Way™ crowd, since that will ALWAYS work as long as yt-dlp manages to stream something. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-09-11, 19:03 (revision 1)
|
|
Dinosaur
Post: #1185 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Posted by tomman And here we are now: the new NTFS kernel driver (named "ntfs3") has been shipping since kernel 5.15! But you won't find it on Debian, not even on Sid! The reasons seem to be: - No userspace tools: This is a dumb excuse, as you can still use NTFS-3G tools just fine - it's not a new filesystem, just an implementation of an already supported one. The only tool we're lacking is a proper fsck.ntfs, which doesn't exist yet even on NTFS-3G. In any case, Paragon has promised to develop a mkfs.ntfs3 at the very least, but that's not a priority yet. - Buggy implementation not suitable for showtime: This one is actually a good reason, since it seems Paragon has been dragging its feet along. It seems Paragon has a sole developer assigned to ntfs3, a guy that went MIA for months, and in general there hasn't been good interaction between him and lead kernel devs. At some point, even Linus himself considered dropping ntfs3 from the kernel if a new maintainer couldn't be found. Since then, development has picked up... sloooowly. So yeah, the situation is still unclear. Many distros DO ship ntfs3, but Debian wants to play it safe with a "wait and see" attitude. Some believe that NTFS-3G is now "deprecated", but at this stage it seems to be a pretty mature project and Microsoft hasn't rained over this party with yet another radically different version of NTFS. I'm not jumping ship for now, as the last thing I want is massive data corruption, or recompiling patched kernels from scratch. Too bad, because ntfs3 does tick almost all the relevant checkboxes for me, feature-wise: Posted by tomman Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-09-12, 21:30
|
|
Dinosaur
Post: #1186 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
If you use LXDE (I don't, but had to help someone that does) and find yourself to suspend or hibernate without giving your root password (WTF), well, that's because LXDE has no native power management applets/services and instead you have to rely on a 3rd-party power manager. A popular choice is XFCE's power manager (xfce4-power-manager), but that one often causes pain when the time to suspend/hibernate comes. How predictable. Here are some possible fixes: 1) Follow these convoluted edits linked from a bug report that has been open since 2014 (!!!). Your changes will be reverted next time there is an update systemd or elogind. 2) Modify XFCE's power manager policy file instead, to remove the stupid "need to be admin to suspend your own PC". Your changes will be reverted next time there is an update for xfce4-power-manager. In the case of $SOMEONE, fix 1 didn't helped, but fix 2 did. YMMV, consider switching to another DE, or buy a iPhone. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-09-17, 23:15 (revision 1)
|
|
Dinosaur
Post: #1187 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
The final boss of my Debian upgrades at home, the routerbox formerly known as Saki is now facing its fate. Presenting... Saki Mark II?! Yeah, I decided to just update in place and keep the legacy going on. Better harder faster shittier, etc. Made a bunch of full HDD images on a spare drive of both its current Jessie setup and ol' Wheezy install, just in case. Archived the current Jessie HDD on my disk vault, like a replacement banknote. Popped a fresh Hitachi (well, an ExcelStor actually, different label, same Chinesium guts - Compaqs only deserve the finest shitty parts but I'm out of slimline Maxtors here) and wrote the Jessie image to it, rearranged partitions a bit, and got the party started~ Jessie -> Stretch: Easy as pie, just a few minor gotchas: - apt will complain about expired/missing keys. You may need to update debian-archive-keyring with the .deb from Stretch's repo to prevent further errors - that will take care of the missing keys but not the expired ones (which at this stage are irrelevant) - Had to redo my sshd config (really just add an extra port) to let it enable all those fancy new crypto algorithms. - Samba required "ntlm auth = yes" on smb.conf to let my Windows machines connect again. - Had to get rid of NUT (Network UPS Tools) due to a circular dependency between nut-server and nut-client: any failure configuring one of the two will cause dpkg to not configure this pair. Since I no longer own a PC-connected UPS (my current unit is dumber than Cirno), NUT is irrelevant now for my setup. - atyfb stopped getting loaded at boot, so I had no fancy hirez framebuffer for my ATi Rage (not using the onboard i810 GPU for that as it's even slower than the Rage!). Decided to defer fixing that until the next upgrade. In general this update was painless, and boot times even improved a bit! But... Stretch is unsupported right now even by LTS. To the next stage! Stretch -> Buster: Oh boy, the BLOAT strikes! - Early during upgrade, systemd starts vomiting endless "Refusing to reload, not enough space available on /run/systemd" every time there is the need to reload something because Debian by default reserves 10% of the system RAM for /run (which is a tmpfs filesystem in RAM). In my case that means ~18MB, but only ~15.6MB are available yet systemd enforces a "safety margin" of 16MB for whatever godforsaken reason. This WILL cause things to break during setup, so you must workaround, pronto! * Quick 'n dirty solution: add "none /run tmpfs defaults,size=32M 0 0" to /etc/fstab, then "mount -o remount /run". You may do this even during setup, this will stop systemd from bitching and will hopefully not break anything else. * The Proper Debian Way solution: edit /etc/initramfs-tools/initramfs.conf, set RUNSIZE to something sane (15% or 32M are OK), then rebuild your initramfs and reboot. Of course you need to do this BEFORE updating, and I'm not even sure if this parameter is even available on Stretch! - Locales broke due to the before mentioned issue (so most of the upgrade ran in English with constant "Cannot set LC_ALL to default locale: No such file or directory" errors), but self-healed near the end of the upgrade. Whew! - atyfb STILL refused to load at boot! Now THIS triggered me, so started checking. Yes, the module was getting into the initramfs. No, neither /etc/initramfs-tools/modules nor /etc/modules were having any effect. Yes, the module loads fine if manually modprobe'd! WTF. Long short story: "systemd-modules-load[173]: Module 'atyfb' is blacklisted" POETTERING!!! Turned out to be udev which now ships with a blacklist for vintage PCI video framebuffer drivers, and this one was on a rather unexpected place: /lib/modprobe.d/fbdev-blackist.conf. After stowing the freshly sharpened katana back, I removed atyfb from the blacklist and learned how to use dpkg-divert so the next udev update won't nuke my framebuffer again. OK, this one was painful, and yet it was matter of showing systemd who was the boss. None of my scripts and configs broke, and I still have RAM to spare, so BRING IT ON! ...but for now, I'm tired, so I'm saving the Final Boss for tomorrow: Buster->Bullseye. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-09-19, 03:08
|
|
Dinosaur
Post: #1188 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Final Boss conquered: Buster -> Bullseye Decided to engage into some optimizations prior to updating, to prevent a situation similar to Stretch->Buster: - Do the RUNSIZE mod to initramfs - ended going with 15% of physical RAM, which in my case means ~28MB. (This is also worth tuning on systems with loads of RAM - do you really want /run to grow up to 6GB on systems with 64GB?!) - Noticed the initramfs itself was getting bloaty, but that's because Debian puts every driver they believe it can be useful... including most Ethernet drivers and a bunch of other stuff that you may not end needing ever if your hardware setup remains static. On low RAM systems that can eventually lead to unbootable systems! (the Jessie one wouldn't boot on anything under 128MB RAM, and since this Compaq steals 4MB for its useless onboard video, well...), Again, on /etc/initramfs-tools/initramfs.conf, change MODULES from "most" to "dep", then rebuild your initramfs. Be aware that this now makes your boot highly hardware-specific and may not boot when moved to another, different setup! In my case, it was worth the tradeoff, since I managed to shrink down the initramfs considerably (~75%!) AND managed to shave a couple seconds down from boot time. Setup went pretty much without issue... until the initial reboot. Then my networking was broken. Desperately, I checked journalctl, pulled the cellphone and quickly found the why: the way network interfaces are named have been in constant state of change since forever, and systemd changed things yet again: in Ye Olde Times, Debian relied on autogenerated udev rules at /etc/udev/rules.d/70-persistent-net.rules. In Stretch, that was deemed "old because it's ooooold, ugly, beige, or whatever" but it will still honor your rules. Then Buster came and made no promises to respect your authoritah, but somehow my rules still got enforced. And of course, Bullseye finally made true to its promise to rain on my parade and completely ignored my udev rules because Poettering says it so, or whatever. Or something like that: my udev rules were being applied, but not how I wanted! LAN is supposed to be eth0, while WAN is supposed to be eth1, but udev inverted both because Lennart Poettering is actually the alterego of Seija Kijin. No, I'm not switching Ethernet wires or PCI slots on this thing! But if I zapped 70-persistent-net.rules, systemd would instead apply its silly persistent naming rules that I will never like (PCI bus/slot numbers, ewww!). So how in the hell am I supposed to apply sensible interface names in the Year of systemd/Linux? Well, your rules now live elsewhere, and have a new format, and the documentation fucking sucks like every modern piece of software these days (nowhere it says that if you have multiple interfaces, you need one rule file per interface!). Now I know how a Poetteringware hateboner feels... and damn, it's NOT a pleasant feeling! But to be fair, half of this shitfest was on me, by not bothering to check Debian release notes. But then, isn't that what apt-listchanges is for? I did read carefully the "important notices" presented on each apt-get dist-upgrade, but nowhere it said that I was supposed to migrate away from 70-persistent-net.rules (not for udev, or systemd, or anything!) So yeah, dear Debian package maintainers, you SUCK too! ... Anyway, live and learn. My netcards have sensible names again (this time "lan0" and "wan0", respectively for LAN and WAN), and after fixing the relevant places at /etc, my networking was restored and this house haz the Internetz again. Other stuff to watch out: - Avahi sneaked in. I guess it's handy for some network printers and Apple toys, but since I have none of those, purged it goes! - AppArmor is now enabled by default starting with Buster. Don't be tempted to disable it, otherwise systemd will get real angry and you'll end with an endless rebooting machine! If you do not want to use its services, too bad - it's for your safety, citizen. Userspace tools are safe to remove/purge. - This Compaq has useless onboard audio, but it's one of the rare soundchips to require firmware (ESS Maestro). Debian used to include it... until the DFSG Nedflanderists purged the impurity away in 2008, sending its unfortunate users back to 1995. Even with a non-free repo, the ESS Maestro firmware never came back to any Debian package, so you need to install it manually - download these two files and place them under /lib/firmware/ess. Why do I feel like channeling my inner JWZ!? So, that makes a grand total of 4 out of 4 major updates done. Despite the systemd-induced pains and this mania of devs hating to document their shit in human language, I'm still happy with Debian letting me using modern software on my computers until they rot, unlike Windows, Android or Fedora. For now, I'm not touching Saki Mark II until Bullseye leaves LTS, which won't happen until 2024 at the earliest :) (please Debian, let 32-bit live a bit longer at least in the CLI arena!) And for the next idiot that wants me to toss this machine in the trashcan (because "unfixable hardware vulnerabilities" and "beige is ugly") and instead have me buy an ARM toy board unobtanium in my country and whose only expansion ports are all USB through a hub, piss the fuck off! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| CaptainJistuce |
Posted on 22-09-19, 11:48
|
|
Custom title here
Post: #1105 of 1164 Since: 10-30-18 Last post: 66 days Last view: 3 days |
Congratulations on successfully navigating the treacherous waters. --- In UTF-16, where available. --- |
| Kawaoneechan |
Posted on 22-09-19, 13:55
|
|
Confound these ponies, they drive me to drink.
 Post: #584 of 599 Since: 10-29-18 Last post: 198 days Last view: 31 min. |
The more I read about this the less I dare to try and update this server. |
| tomman |
Posted on 22-09-19, 18:07
|
|
Dinosaur
Post: #1189 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Leaving aside Poetteringware shenanigans, me not reading the docs, and the docs sucking donkeys' ass, the whole ordeal was... not THAT traumatic after all. My scripts and config files remain pretty much unchanged from the last major reconfiguration circa But now, since I'm a masochist there is something I need to address: since I turned BIND into my adblocking solution of choice, its resource usage has shot straight to the moon. Right now, the largest RAM/disk hog is BIND: my 8MB adblock blacklist zone takes nearly 1 minute to load (with intense disk grinding), uses over half of physical RAM (and sometimes gets heavily pushed back to swap), and introduces annnoying ~1 minute delays on shutdown (again, with intense disk grinding) which is something I absolutely do not want, especially when I'm on a hurry powering down things during a blackout before the UPS battery runs out of juice! Also, configuring BIND is anything but pleasant, and I suspect there is room for improvements. The Internets suggest me to migrate to alternative DNS software like PowerDNS or NSD. Apparently both are performance-oriented, with lower RAM footprint, and in the case of PowerDNS it can even use Real Databases™, which is something I could get into (it can even import your BIND zones via SQL, or use them as-is via a BIND backend). Here is what I'm currently using BIND for: 1) Vanity domain names for my LAN hosts (this was its original purpose back in my years at the dorms as a bored college student). 2) Caching DNS server for my LAN, using third-party public DNS services as forwarders (Google, Clownflare, IBM, and as a last resort, the highly censored DNS from CANTV) 3) Adblocking, using blocklists compiled by this. 4) Extra blocking measures for unwanted parasites like Facebook or D'OH! Another favorite for 2), 3), and up to some extent 4) is PiHole, but it doesn't seem it can tackle 1), so I would prefer a real (but lightweight) DNS solution that I can configure myself and then forget it (plus PiHole is a self-contained solution that brings a lot of extra baggage I do not need). HALP! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-10-02, 14:00
|
|
Dinosaur
Post: #1193 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
It has been decided: Debian will include non-free firmware on the official install media! https://lists.debian.org/debian-vote/2022/10/msg00000.html https://www.phoronix.com/news/Debian-Non-Free-Firmware-Result https://news.ycombinator.com/item?id=33055100 About bloody time, people! So many new computers are unusable (some are literally unbootable) if your device drivers do not supply the required firmware blobs for the hardware! Ever tried to do a Linux setup over WiFi (remember: RJ-45 is dead on laptops because APPLE SAID SO), just to have your installer end abruptly there because it could not list any network? The Big Three PC GPU brands have required blobs for years for tasks other than textmode and unaccelerated desktops. Many audio, network, and even input devices DO require blobs to justify their existences! So yeah, Common Sense™ has finally prevailed (sorry Sanae but my laptop is not Gensokyo), and Debian will let you have a fully working desktop out of the box on the default installer. That's GOOD for the Linux ecosystem overall, even if Debian comes very late to the party... and will save me some time in the future by not having to dig into Debian's website for those hidden unofficial firmware images. You'll still have the option to disable that on the installer via some boot-time flag or something, should you not want a working PC, but of course the Nedflanderists, Stallmanites and other FOSS purists will go ballistic over this decision, and I can already envision the protests, Twatter/Matrix mobs, and possible Debian forks ("Purebian"?) stripping any kind of non-free impurities so these religious fanatic dudes can stick to doing nothing useful on their old Thinkpads, I guess? No, FSF/RMS, no OEM will ever go back to the era of soldering $1 flash ICs with old broken firmware and the risk of bricking it during updates! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-10-06, 02:58
|
|
Dinosaur
Post: #1194 of 1317 Since: 10-30-18 Last post: 2 days Last view: 14 min. |
Just like MATE preserves the look, feel and sanity of GNOME 2, there is the little known fork of KDE 3.5 (Peak KDE IMO), Trinity Desktop, or TDE. It's not new, but it finally seems to have mostly sane repositories for many distros, including Debian-based ones: https://wiki.trinitydesktop.org/Debian_Trinity_Repository_Installation_Instructions Since KDE 3.5 is now considered vintage, I chose my just-refurbished ThinkPad T40 for testdriving it, and here are my impressions: - Hello, good old friend~! I missed you! - Do not use the tde-desktop metapackage to install: for whatever reason it will try to replace desktop-base (a core Debian branding package) with its own. Instead review the dependencies of said metapackage and install only the parts you need (I skipped tde-accessibility, for example), plus some suggested packages (--no-install-recommends is your best companion here, or I would have ended installing of all things, XScreensaver. OH HELL NO!) - I know those old Dothans are not speedsters by any means, but man, TDE feels sloooooooooow. It isn't RAM - htop gladly reminds me that most of the 2GB RAM of my T40 are largely unused. Can't be HDD either - that ol' 80GB Sammy sits idle for most of the time. KDE 3 was powerful but not exactly lightweight, but it certainly felt zippier on lesser hardware back then, so I don't know where is the source of bloat here. Applications start slowly, even non-native ones! - Sound is a problem - it seems Pulseaudio gets upset by aRTs or something else (my initial session refused to fully logoff until I killed a 100% CPU-pegged Pulseaudio process at logout), and after the next logon, KNotify was complaining that it died when it tried to notify... itself? Sounds like I've got a conflict somewhere. Ugh. - I need to be root to change the display resolution? Except that nope, if you use the handy tray applet. WTF. - GTK3 apps stick like a sore thumb, due to theme mismatches. Fun. On the very same hardware, MATE performs MUCH better, but then MATE still receives love, unlike TDE. Veredict: TDE lets you live back the nostalgia of non-braindamaged power user desktops, but the internals have fallen prey to good ol' software bloat for unknown reasons. Oh, a little more manpower wouldn't hurt... Quote of the day: <frg_Away> tomman tde desktop is the SeaMonkey of desktops. Not enough devs and few people rooting for it. Even the latest kde release is funky. Wish too 3.5 would be back. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
