0 users browsing Discussion. | 10 bots
| tomman |
Posted on 22-10-08, 02:37
|
|
Dinosaur
 Post: #1195 of 1318 Since: 10-30-18 Last post: 6 days Last view: 19 hours |
OK, so it's not software bloat that it's murdering performance here, it's good ol' aRts playing not nice with good ol' Pulseaudio. As soon as aRts daemon spawns, both it and Pulseaudio daemons go 100% CPU, and system performance goes to hell, things run toasty, etc. If I disable aRts and use non-TDE apps, those have perfectly working sound through Pulseaudio, so that rules out possible driver issues. Supposedly recent TDE versions should work better with Pulse, but not only there is no option to pick it on audio settings (only ALSA and OSS), it does some sicknastyness that makes Pulse go real mad. Welcome back to 2006! This is NOT the part of the Vintage Linux Experience™ I wanted to revive, folks... If I can't fix it on my T40, no way in hell I'm deploying TDE to my daily drivers. And of course, uninstalling Pulseaudio is NOT an option I'm willing to consider on any of my laptops, thanks. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-10-10, 01:14
|
|
Dinosaur
Post: #1197 of 1318 Since: 10-30-18 Last post: 6 days Last view: 19 hours |
EXTRA STAGE BOSS: moving the nx9010 to Modern Debian. I had neglected my ol' HP Compaq nx9010 since I rarely use it's Debian setup these days (it's also my rare mainly-Windows box here) because due to typical software bloat and the natural progress of tech, it's not a great Linux runner anymore. Leaving aside modern DEs wanting machines released since the last Apple hardware launch, and even sane DEs (like MATE) not being that lightweight anymore (hello GTK3!), I just left it there, rotting away. Oh, it also fails to properly work with any kernel past 3.16 because ACPI support on this thing breaks spectacularly on 4.x kernels and later (this is why most live distros won't even boot properly on it). Anyway, let's update it just for the sake of consistency, and because I'm masochist. So far I've done the Jessie->Stretch step, mainly for performing kernel testing: - Kernel 3.16 (Jessie's default): everything works more or less OK! - Kernel 4.9 (Stretch's default): ACPI causes weird hangs, but only sometimes. - Kernel 4.19 (stretch-backports, Buster's default): ACPI causes weird hangs ALWAYS. Kernel logs register errors like this: ACPI Error: Method parse/execution failed \_SB.PCI0.SOME.PATH, AE_AML_LOOP_TIMEOUT (some ACPI version string) or processes being hung then kernel complaining about 120 second timeouts with large stacktraces involving ACPI drivers, and the usual consequence being reboots become impossible (except sometimes via Magic SysRq key), being unable to monitor battery status, or CPU temperature. After doing more testing, the things more likely to cause the ACPI hangs are: - Trying to monitor battery status, if battery is installed (amazingly mine STILL holds some charge, despite being 18 years old!). Removing battery also removes this source of hangs. - Trying to monitor CPU temperature (which on those machines is done via ACPI thermal zone sensors) Messing with acpi_osi identifiers do not change anything, so it isn't just matter of laptop getting angry because it expects Windows. Everything works fine with kernel 3.16 or older, and of course WinXP works fine too, as expected. There are some very ugly regressions on the ACPI subsystem on the Linux kernel that impact this specific laptop very badly, but it's extremely unlikely any kernel dev will care because why would anyone want to run modern Linux on a 20 year old laptop? So much for "Linux brings back old hardware back to life"... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-10-16, 16:39
|
|
Dinosaur
Post: #1199 of 1318 Since: 10-30-18 Last post: 6 days Last view: 19 hours |
Just moved my firewall/router rules from old and crusty iptables to the new hotness, nftables. After some useful advice from the lurkers at #netfilter, and some Stack Overflow posts, the migration turned out to be painless and simple: - There are tools (included upstream) that will translate your rules. While you can one rule at a time, bear in mind that nftables do NOT create the default filter chains you would expect (INPUT, OUTPUT, PRE/POSTROUTING, etc) - you have to start from a completely blank "anything goes in" state! Instead, dump your iptables ruleset with iptables-save, then translate it with iptables-nft-restore which will take care of creating the required chains. - There is some minimal scripting support, including being able to define constants. But you can't pass constant values over commandline until nftables 1.0... which will ship with the next Debian stable (Bookworm) - Bullseye currently uses 0.9.8 which doesn't support the -D parameter. This became a showstopper for me because on my current iptables ruleset I expected to pass the currently active network interface name to the script! - However, forget about hacks, temporary files, and defining interface names on the fly. Just hardcode everything! For that we have one of the most wonderful additions to the syntax in nftables: SETS! Oh man, sets are THAT great: save lines of nearly duplicate rules by using sets of everything: IP addresses, subnets, port ranges, and even interface names. Since in my case I already know which names are going to have my interfaces ("wan0" being the NIC where my DSL modem lives, "usb0" being always my cellphone when tethering, and "ppp0" for the rare times I need to use my ol' 3G data stick), I just hardcoded those on a set. Turns out you don't need nftables which one to use - the kernel will just pick the one that is set as the default route at any moment, which works fine for me as I don't expect here to have more than one WAN device active at the same time. - I ended moving all of my rules to a external .nft (what an unfortunate name given the current affairs on the net) ruleset file, instead of having everything as commandlines in a Bash script. This keeps things tidy, separate, and easier to manage should I need to add a port forwarding rule for any of my laptops, or to move the SSH port again in the future. - Documentation is... not great, as you would expect from modern software projects. The nftables wiki is known for having syntax errors and deprecated samples! Apparently you're supposed to become a graybeard sysadmin just to define your own firewall rules on Linux, or buy a $35 unflashable TP-Link router these days :/ But hey, now my firewall rules are future-proof... for now. The final pending task for me is to switch DNS from BIND to something else, as I can't stand those ~2 minute delays on shutdown because BIND is trashing my HDD hard, and 128MB SDRAM sticks are not exactly easy to find here... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-11-12, 03:22
|
|
Dinosaur
Post: #1202 of 1318 Since: 10-30-18 Last post: 6 days Last view: 19 hours |
If you're using GDM as your logon manager on your To stop this madness for good: just purge nvidia-egl-common - this gets permanently rid of /usr/share/glvnd/egl_vendor.d/10_nvidia.json (which is useless on most Optimus systems, at least not without PRIME), instead of having to delete it each time the blob gets an update. This package is safe to remove and won't break anything else, except for GDM's nasty habit on trying to use a GPU it is not supposed to use! .... oh, and kernel 6.0 is now available via Backports, yay~! Except that us nvidia-legacy-390 users need the DKMS package from Testing because it brings the required build fixes for the noVideo kernel module. But watch out for the future: kernel 6.1 may break your laptop backlight controls! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-11-20, 18:23
|
|
Dinosaur
Post: #1204 of 1318 Since: 10-30-18 Last post: 6 days Last view: 19 hours |
https://endoflife.date/nvidia "What do you mean the end is near?!" Ah yeah, I'm still using a Fermi If you still run an old desktop PC with a noVideo GPU: you can find used Radeon cards for cheap, people! But if you're stuck on a laptop (like me)... well, I share your pain. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-12-12, 03:06 (revision 1)
|
|
Dinosaur
Post: #1209 of 1318 Since: 10-30-18 Last post: 6 days Last view: 19 hours |
Debian Setup Of The Day: bringing sanity to one of the most insane platforms ever. In a rare dumpster pickup (for this country standards!), a couple days ago I salvaged a entire unsuspecting machine from its date with the dump truck: our HOA decided it was time to dispose of its ancient PC, an HP Brio (TIL that line existed). But when I took it apart at home, I found that the internals were not exactly your typical "big brand supermarket special"... but worse: - PCChips motherboard, a classic of doom: a M756LMRT with swollen G-Luxon crapacitors and its unlovely SiS 630E chipset (where the E is for "especially BAD chipet!"). The memories of that M755 with Windows Mistake Edition are a open wound that will never fully heal... - The lamest Socket 1 Pentium III CPU ever made: a 450MHz first-gen Katmai from late '99. - 512MB PC133 SDRAM, on 2x256MB DIMMs. Probably the only GOOD part of this thing - someone actually spent good cash feeding a normally RAM-starved PoS! - 40GB WD PATA HDD with an unbootable XP setup and about ~90 reallocations (couldn't found any dirt from its previous operators - just a bunch of useless documents and spreadsheets, too bad) - 56X Benq CDROM, meh. - Sony FDD, died after killing some test floppies. - Delta 85W HP OEM PSU. The good shit - Tier 1 Taiwanese OEM, fine Nichicon caps where you want 'em, and only a lone toasty area near from a couple diodes (likely product of poor cooling and years of accumulated crud). PCChips. A name many that have been in this industry for long enough will never forget, no matter how much beer or weed you do. Running Linux on those have always been a crapshoot, especially on non-Intel chipset boards. ESPECIALLY SiS-based boards! My M755 had this horrible IGP with meh VESA BIOS and subpar X11 drivers that were only good for 2D, and maybe watching videos. Combine that with PCChips legendary manufacturing quality (thin PCBs, crapacitors, the inventors of Fake Cache®, and its signature yellow-ish PCBs), and you've got a recipe for doom. And this M756LMRT is one of those cases: no Linux distro I tried would boot without panicking or freezing very early at boot! Tried several versions of Debian installer disc, and even my trusty Parted Magic stick (via Plop Boot Manager bootdisk). Tried tweaking every single BIOS feature I could find (there are not many tunables on this thing). Tried switching between APM, ACPI, or nothing at all. Even tried with a different CPU (have another dumpster salvage, a Coppermine Celery 600MHz), but nope, they would either hang or panic. Debian installer would consistently halt at the same point: shortly after detecting the ATA/USB controllers, but before enumerating devices attached to them. A memtest came up clear always, and swapping RAM modules didn't helped anyway. Sometimes I would get a panic stackdump (more on this later), so tried also messing with kernel commandline params: acpi=off, noacpi, nosmp, biosirq... until I found a pattern on the few readable stackdumps and panic messages: all of them mentioned the following: 1) Fatal error inside a interrupt handler 2) The words "idle" and "<IRQ>" on many of the function names on the stacktraces. Turns out something really fucky was going on this BIOS/mobo: while the CPU "idles" for saving power, Linux usually does it in a way that would piss off this mobo and thus it hangs. The solution was idle=poll, which means the CPU will waste its "doing nothing" cycles... doing something that looks like it's doing nothing. This is bad for power saving and thermals, except that on a desktop Pentium III that turns to be quite irrelevant anyway. On to the setup! - Switched the lamest P3 ever for.. a slightly less lame Socket 1 Katmai of unknown origins, a 550MHz part. Really, I never had that much interest into Slot 1/Socket 370 platforms for retrocomputing purposes until this year, I guess, so my inventory of parts of that vintage is VERY limited. Despite the slow external cache, it's still faster than my 600MHz Celery solely due to the faster 100MHz FSB. - Ethernet jack (driven by the built-in SiS 900 NIC on the 630E die) was dead (link light came up, but blinked even without traffic), so I had to jam it in a random NIC on the scarce PCI slots of this thing. - I/O performance of the 630E PATA controller is sucky, despite claiming UDMA support. It's at the same level of the venerable PIIX3 (Triton) Intel Socket 7 southbridges. - Onboard audio (C-Media CMI8738) works fine. This chip was used by PCChips on many of its M7xx/8xx mobos, while others based on SiS chipsets resorted on its internal 7018 audio (plus an AC'97 codec chip). Will play your FLACs like a pro player! - No firmware blobs required! - For hi-rez framebuffer, you want sisfb. But since Lennart has a hateboner on old-skool framebuffer drivers, you'll have to remind Debian, systemd and udev who's the boss here. - There is a SiS 950 chip near to the bottom of the board. That's NOT an Ethernet chip - instead, it's a rebadged ITE SuperIO/sensors chip, fully supported by the it87 kernel module (but many of the voltage readings are bogus) ...and that's all? Really, once you figure how to boot up this thing, this turns out to be a rather unremarkable Linux board choice. Might make a fine routerbox, if you replace the fake caps first and get a multiport NIC and a CF-to-IDE adapter. I have no plans for this mobo yet (bad caps, ugh!), but it was still worth the test. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-01-16, 02:02 (revision 1)
|
|
Dinosaur
Post: #1211 of 1318 Since: 10-30-18 Last post: 6 days Last view: 19 hours |
It's that time of the year again, when emulators try to use the latest shinies and break on my Debian setups! Today's answer is NOT "update your distro, buddy~" thankfully, but it involves some annoyances anyway. No, I'm not trying to build Dolphin and dying in the way (Dolphin fortunately still builds OK on current Debian stable as of January 7, 2023), but a close friend: meet Duckstation, the hottest PSX emulator in the 'hood, and whose Qt-based UI formed the basis for many of Dolphin's GUI improvements. First things first: Duckstation requires Qt 6, which is only available on backports for Bullseye (qtbase6-dev, qtbase6-private-dev, qtbase6-dev-tools - ignore qttools6-dev). It also requires a relatively new version of SDL2 solely for SDL_HINT_JOYSTICK_HIDAPI_PS5_RUMBLE, despite the fact that 98% of the potential userbase for Duckstation won't have a PS5 gamepad. You won't find that one on backports (and I'm not even sure if that's coming for Bookworm either), but I was able to workaround that by abusing CMAKE_CXX_FLAGS: And then, once the thing was up and running (sans icons for whatever reason, and the "make install" target is BROKEN), I was in front of whatever default theme that Qt 6 ships. Ugh. Yes, it's the qt5ct saga all over again. There IS a qt6ct (and it will even ship with Bookworm!), but for now, you want this, and remember to set QPA_QTPLATFORMTHEME to gtk2 every time you need to run a Qt 6 app to have that sane Speaking of things that suck: LENNART!!!! Right now, I'm taking a trip to Nostalgia Planet with that PCShits mobo from the dumpster, with a install of good ole' Wintendo Mistake Edition (spoilers: I finally got it to not BSOD every 5 minutes!), but since I don't have a set of spare speakers, I need to pipe audio from this mobo into any of my other computers. How to listen to a input? - Windows: Plug cables, open Volume control, find the proper input and unmute it, adjust volumes, DONE. It has been this way since WINDOWS 95! (Dunno if MS fucked it post-W7?) - Linux/ALSA: Plug cables, run alsamixer, find the proper input and unmute it, adjust volumes, DONE. (Things could get messy with a Real Soundcard™ like Soundblasters, but that's more or less the way to do it) - Linux/PulseAudio: Plug cables, run pavucontrol, notice that on Input Devices audio volume is being monitored but there is no way to listen to it, dick around, find nothing, check everything twice, open web browser, google for the first Stack Overflow result, find that the magic enchantment is "pactl load-module module-loopback latency_msec=1", run that, dick around pavucontrol even more, adjust volumes, rant over IRC, get a "butbutbut someone would rant if that were setup as the default because BLOAT!!!" non-answer, lose all remaining faith in mankind, remember you have to redo all that on the next reboot. Hope Pipewire doesn't commit the same mistakes, but I'm not hopeful as all software is doomed to suck nowadays :/ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| CaptainJistuce |
Posted on 23-01-16, 03:15
|
|
Custom title here
 Post: #1116 of 1164 Since: 10-30-18 Last post: 73 days Last view: 23 hours |
It has been this way since WINDOWS 95! (Dunno if MS fucked it post-W7?) Sad to say, they did. Seemingly in the name of privacy, based on the options I had to toggle and the fact that they put a big microphone icon in the tool tray. Source: decided to use a 90s MIDI module with WinX. --- In UTF-16, where available. --- |
| Kawaoneechan |
Posted on 23-01-17, 00:31
|
|
Not a pony
 Post: #585 of 599 Since: 10-29-18 Last post: 205 days Last view: 16 hours |
I'm surprised Tom hasn't gone full cave hermit yet. |
| CaptainJistuce |
Posted on 23-01-17, 03:46
|
|
Custom title here
Post: #1117 of 1164 Since: 10-30-18 Last post: 73 days Last view: 23 hours |
Posted by KawaI'm surprised I haven't sometimes. --- In UTF-16, where available. --- |
| creaothceann |
Posted on 23-01-17, 07:12 (revision 1)
|
 Post: #427 of 456 Since: 10-29-18 Last post: 53 days Last view: 8 hours |
Posted by CaptainJistuce Don't let your dreams be dreams My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| CaptainJistuce |
Posted on 23-01-17, 21:47
|
|
Custom title here
Post: #1118 of 1164 Since: 10-30-18 Last post: 73 days Last view: 23 hours |
Posted by creaothceannI can't go homeless, where would I keep my stuff? --- In UTF-16, where available. --- |
| creaothceann |
Posted on 23-01-18, 06:11
|
|
Post: #428 of 456 Since: 10-29-18 Last post: 53 days Last view: 8 hours |
Posted by CaptainJistuce Right next to you :) My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| tomman |
Posted on 23-02-25, 04:56
|
|
Dinosaur
Post: #1219 of 1318 Since: 10-30-18 Last post: 6 days Last view: 19 hours |
Today's stupid bug of the day: ever tried to run a random executable from your favorite file manager (something Windows and Mac users do every day without blinking an eye, but a concept completely foreign to Unix users), just to be cockblocked by your own computer... but not always? If that's you, you might be a victim of this: https://forums.linuxmint.com/viewtopic.php?t=276003 https://stackoverflow.com/questions/45329372/ubuntu-recognizes-executable-as-shared-library-and-wont-run-it-by-clicking Long short story: most modern executables are compiled these days with -fPIE, which is good for security as it allows devs to use countermeasures like ASLR to keep exploits away, and suddenly this fools most file managers into thinking that suddenly every ELF file compiled that way has to be a DLL and not necessarily an executable, leading to a completely bogus (and unhelpful) error message, while leading former Windows users over IRC to rethink their decisions to migrate away from the sinking boat that is Windows, or the perfection that is Mac. Of course, some desktop environments whose names I am not going to mention here claim that running executables from a file manager is silly and why would you want to use your own computer in non-sanctioned ways? https://bugzilla.gnome.org/show_bug.cgi?id=737849 https://gitlab.gnome.org/GNOME/nautilus/-/issues/443 "Every executable should ship with a .desktop launcher, otherwise it's broken." - Official GNOME® Policy™ But the real culprit here is Freedesktop.org's MIME type database: https://bugs.freedesktop.org/show_bug.cgi?id=97226 https://gitlab.freedesktop.org/xdg/shared-mime-info/issues/11 Fixes! We want fixes! Fortunately we're not doomed. This time. - EASY MODO: convince your file manager that those "DLLs" are actually executables, and that they should run through bash or something, by applying the Windows-esque concept of creating a file association. Here is how to do it under Caja (MATE) - for other DEs the idea is similar. Of course only schoolkids play in EASY MODO, and we want a proper fix so the penguinistas don't laugh at us, right? (Spoilers: they will still laugh at us, but they will be *ehem* climaxing themselves hard at their pimped out xterms) - The Actual And Proper Fix: This bug was finally squashed upstream two years ago, so all you need is to update shared-mime-info in your distro to version 2.1 at least. And indeed Debian picked that update... on Bookworm(testing) only! And you can't just use the .DEB due to the presence of a binary (update-mime-database) that relies on a newer libc in Bookworm (really Debian? This should be split in TWO packages, the tools and the database itself, IMHO). But fear not - you only need the actual database file itself, /usr/share/mime/packages/freedesktop.org.xml - the format hasn't changed in years, so just take the one from the Bookworm .DEB, replace it, and run update-mime-database /usr/share/mime as root. There, you can now eat your PIE, like a Windows peasant! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-03-26, 17:10
|
|
Dinosaur
Post: #1221 of 1318 Since: 10-30-18 Last post: 6 days Last view: 19 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™ |
| wertigon |
Posted on 23-04-03, 09:46
|
|
Post: #194 of 205
Since: 11-24-18 Last post: 165 days Last view: 1 day |
Posted by tomman I assume a Radeon 550 is off the table? https://www.amazon.com/dp/B09V2GYKPJ |
| tomman |
Posted on 23-04-03, 23:17
|
|
Dinosaur
Post: #1222 of 1318 Since: 10-30-18 Last post: 6 days Last view: 19 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™ |
| wertigon |
Posted on 23-04-04, 07:41
|
|
Post: #195 of 205
Since: 11-24-18 Last post: 165 days Last view: 1 day |
Posted by tomman Ah. Then, unfortunately, it is soon time to start hunting for a more modern laptop. I assume it has a combined NvIntel and the Intel circuits are still working with 6.2+. I can recommend Lenovo AMD APU-based systems, those are more likely to have long Linux support though nothing is guaranteed. My wife has been running an AMD 4800U system for the past three years, we're pretty happy with that one. |
| CaptainJistuce |
Posted on 23-04-04, 11:38
|
|
Custom title here
Post: #1123 of 1164 Since: 10-30-18 Last post: 73 days Last view: 23 hours |
Posted by wertigonI think you've forgotten this is Tomman. The most recent technology available to him dates back to the Clinton administration. --- In UTF-16, where available. --- |
| creaothceann |
Posted on 23-04-04, 15:20 (revision 1)
|
|
Post: #432 of 456 Since: 10-29-18 Last post: 53 days Last view: 8 hours |
So surely he'd appreciate it if we ship him a 4090 Ti and a dock. (EDIT: and a PSU) My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
