0 users browsing Discussion. | 2 guests | 13 bots
| tomman |
Posted on 22-05-14, 23:50
|
|
Dinosaur
 Post: #1100 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
...and I blew up the speakers on the T40 after doing my video testing. Now they sound heavily distorted under ANY OS! But if you plug headphones, those sound fine. Ah well, I guess I need new speakers too :/ I guess those fairy tales of "Linux damages hardware" might be real. Or I simply found another case of "old hardware often dies". Whatever... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| CaptainJistuce |
Posted on 22-05-15, 08:46
|
|
Custom title here
 Post: #1077 of 1164 Since: 10-30-18 Last post: 66 days Last view: 3 days |
Posted by tommanWhy not both? Linux damages old hardware! --- In UTF-16, where available. --- |
| tomman |
Posted on 22-05-26, 01:22
|
|
Dinosaur
Post: #1105 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
Since the T40 is now considered Vintage IBM™ by many out there, and people have been trying to install Linux on those things since IBM sold them new (with various degrees of success), and all the guides you will find online are 1) hopelessly outdated and 2) more patchy than Cyberbugged 2077, here is my take on how to install Linux on a T40 in 2022: - Distro chosen: Debian 11, what else? For maximum convenience use the unofficial "firmware" netinst ISOs, since it will save you some work by installing the nonfree blobs (and enabling the non-free/contrib repos for you) - You want at least 1GB RAM for modern Linux installs, even if you're planning to use a lightweight desktop. Don't bother with anything less than that. 1GB DDR1 sticks are still cheap (albeit difficult to find, but definitely NOT unobtanium!), and the T40/1/2 line will take two of 'em, so max it out! - 32-bit kernels these days usually require PAE, but Pentium Ms officially do NOT support PAE/NX. Except that they actually DO. ALL of them! But due to Intel being Intel, the PAE/NX flags are not exposed via CPUID, so many distros will either not boot at all, or will resort to a non-PAE kernel (which you do NOT want). Luckily "forcepae" is a thing on Linux, so you need to append that to the boot arguments on Debian installer (hit TAB at the installer bootmenu to edit the bootargs, just append "forcepae" at the end and hit ENTER to boot). Magic™ will happen and the "forcepae" flag will propagate to the installed system GRUB config. - I went with no swap partition (a complete waste of a MBR entry, and I hate extended partitions) - a swapfile is fine these days. - MATE works fine on these machines, so I went with that. - Video: My T40 has a Radeon 7500, and the X.org drivers for those have aged VERY BADLY. Performance went from "zippy" circa 2006 to "barely useable" in 2022. Anything involving video playback of any kind will suffer inmensely, like if there was no video acceleration at all! Remember: those vintage R100 Radeons greatly benefited from XAA accel, which was purged from X.org nearly a decade ago, and noone bothered making those GPUs working decently with EXA (and forget about GLAMOR and friends - those ain't no R600!). You get a basic 2D desktop and that's all. You may enable software compositing (it's even the default these days on MATE) if you wish, but don't expect performance at all for any kind of multimedia workloads, as the CPU isn't even the bottleneck here :( Welcome to ATi driver hell! At least X11 won't crash or hang... T41p/T42 users might have better luck, as those have the Radeon 9600 as an option, and drivers for those (R300) are less horrible. - Audio: Something something Analog Devices something AC'97. Just Works™. You may or may not want to use PulseAudio, depends on how weak is your CPU. Since the volume hotkeys on ThinkPads are special snowflakes, you want to install tpb to get a crude OSD for those (they're controlled by the EC, not by the audio codec). Alternatively, ALSA exposes a secondary audio device for that EC mixer. BE CAREFUL TO YOUR SPEAKERS - THEY'RE FRAGILE! - Networking: Back when those machines were hot, it was basically wired or nothing. WLAN was a pain due to shitty drivers (either primitive FOSS drivers or BUGGYBUGGYBUGGY proprietary blobs) and a crude 802.11 framework. Fast forward to 2022, and all 3 WLAN options for the T4x series (airo, ath5k, ipw2200) should Just Work™. Except that those cards are JUNK! (seriously: mine had a Intel 2200 which would constantly drop the connection... ON WINDOWS! Those cards are known to die fast). Do yourself and your ThinkPad a favor, go buy a TP-Link TL-WN861N (they're getting pricey!), and either get fresh underwear and flash a unlocked BIOS (look for T40-T41-T42-SLIC2.1_7U_no_1802.zip) or at least run any of those no-1802 bootdisks (safe, but you'll need to redo it if you ever change your CMOS battery) before swapping cards. Your wireless router will thank you~~~ Wired should Just Work™ (it's an e100 or e1000 depending on your config), but I didn't bothered this time. - PCMCIA: Just Works™. Tested with a ol' analog TV capture card (KWorld NB-TV 100, requires "card=81 tuner=54" params to saa7134 module, or the driver will rant at you about pennypinching bastard OEMs), although video performance is horrible due to the subpar Radeon drivers. - Laptop bits: suspend Just Works™. Haven't tested hibernation (I don't use that anyway). My battery is a brick, so can't test battery life tweaks. - ThinkPad bits: Mostly Just Works™. All EC sensors are properly detected. Haven't tried messing with fan control yet (but will definitely do once I manage to upgrade the CPU on this thing - already tracked down a nice Dothan part, hope it turns out to be another lucky find). Already mentioned the volume control stuff on the audio section. Nipple mouse works as expected. tpb will also take care of the other TP-specific OSD bits (LCD brightness/ThinkLight). "Access IBM" hotkey is mapped to XF86Launch1, so feel free to bind it to something. - Oh, I guess there is a DVD drive there. Yawn~ - USB ports Just Works™, as expected: Ports not tested: parport, S-Video out. - There is a winmodem - ALSA claims the device (snd_intel8x0m), but of course it's useless without a proprietary blob that doesn't really exist anymore. Maybe if I'm THAT bored, I could try making the Buster package working on Bullseye,,, - Amazingly I found some guy in MercadoLibre selling a Port Replicator II compatible with this thing. If I can find yet another $10 to spare on this thing, I would get an extra USB port, a DVI-I port, and a honest-to-God RS232 serial port. Worth a test, as finding information on Linux and docking stations is hard. Veredict: This T40 would be a worthy replacement for my nx9010, if it weren't for the failsauce ATi GPU drivers :/ Still, if you can stand the subpar video performance, and are willing to spend a few bucks on much-needed hardware upgrades, it makes a solid XP/Linux dualbooter for many of your modern vintage computing needs. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-05-26, 01:31
|
|
Dinosaur
Post: #1106 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
Oh wow, the modem blob WORKS! Not the kernel one (that's broken, forever), but sl-modem-daemon from Buster will install and use the ALSA driver instead. Chalk another one for the "doing pointless stuff for teh lulz" then. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-05-26, 18:32 (revision 1)
|
|
Dinosaur
Post: #1107 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
Part of the reason any 3D workload on Vintage ATi R100 hardware sucks on modern Linux: your modern DE may be enforcing software rendering on Mesa (which these days is llvmpipe), completely ignoring the prehistoric OpenGL 1.x bits on your metal. I didn't discovered this until I noticed that glxinfo was reporting llvmpipe/OGL 4.5 as my 3D device, which is obviously not right! Long short story: LIBGL_ALWAYS_SOFTWARE was being set on each MATE logon, without any way to override it (except manually from a xterm). After (once again) wasting my time in fruitless Google searches, a kindred soul at #debian pointed me to the correct track: 1) mate-session checks if there is working GL acceleration on logon... https://sources.debian.org/src/mate-session-manager/1.24.1-2/mate-session/main.c/#L667 2) ...which relies on a helper proggy, mate-session-check-accelerared, which among other things tries to match the renderer string against a blacklist... https://sources.debian.org/src/mate-session-manager/1.24.1-2/tools/mate-session-check-accelerated-gl-helper.c/#L312 3) ...which only contains a few entries, including any Radeon prior to R300! https://sources.debian.org/src/mate-session-manager/1.24.1-2/data/hardware-compatibility/ If those checks fail, you'll get llvmpipe software rasterizer. I don't know why MATE explicitly has blacklisted R100/R200 (maybe too buggy/old/slow?), but disabling HW GL for everybody is rude. If you absolutely want to use your GL silicon bits, all you need is to comment out the R100/R200 blacklist entry on the blacklist, which lives at /usr/share/mate-session-manager/hardware-compatibility, logoff, then logon again. Haven't noticed any breakage even with software compositing enabled, but then, that DID boosted my 3D performance: glxgears went from 13FPS to almost 60FPS at 1024x768! :D If only nerds crowdfunded other nerds writing high performance video drivers for vintage hardware, instead of wasting their time doing drivers for shiny new Apple appliances... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-05-30, 02:48 (revision 1)
|
|
Dinosaur
Post: #1108 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
Now that my SL7V3 (that's a top-of-the-line Dothan 2.1GHz for 400MHz FSBs) arrived, let's see if we can do something to alleviate the multimedia woes on this T40: - CAUTION: the 2.1GHz part is HOT. Literally - it easily reaches high-80s when the pedal gets pushed to the metal, and if it goes over 87ºC, it will downthrottle to 600MHz to prevent scorching itself. I've heard there are two fancoolers for T4x's, but unless you care about the GPU (well, you should - even the lowly 7500 gets a bit toasty when pushed to the max), don't bother with the "long" fan assembly as it won't really improve CPU cooling. A good thermal paste is a must in any case! - Windows: there is not much difference between latest VLC (which STILL runs on XP!) and some random old codec pack (I used the last XP-compatible release of CCCP). Do NOT use OpenGL (on VLC) or any of the fancy EVR modes (on MPC-HC). The limit is at 720p 30fps 8-bit H.264, which for most media the Dothan 2.1 will play mostly fluid. - Linux: GPU power saving mode is set to whatever mode the video BIOS sets at boot, crippling somewhat video playback performance (unthrottle it with "echo high | sudo tee /sys/class/drm/card0/device/power_profile", but careful with the cooling!). mpv is hopeless no matter the renderer as it is aimed to MODERN machines, so don't bother. VLC is MOSTLY OK as long as you switch the renderer to X11 (that is, X11 shared memory AKA "ancient junk that doesn't even use your videocard at all"), but performance is still horrible if you go beyond 360p. Surprisingly the best results are achieved with good ol' Xine with OpenGL (set renderer to "opengl", NOT "opengl2"!), but as expected, Xine has aged badly too: on whatever build Debian ships with Bullseye, I only managed to play a few videos - everything else went with garbled audio or no playback at all, despite Xine using FFmpeg at its core! Oh, and although I got decent framerates with some 720p material, image jumps A LOT with the few 360p videos I tried! X11/shm gives more stable playback, at the cost of lower performance. Speaking of cooling, the only fan control solution that works with modern distros on ThinkPads is the aptly-named thinkfan. It's even on Debian repos... except that for whatever reason it's NOT on Bullseye, so you'll need to build your own DEBs. If you choose to build from the source packages at testing/Sid, you'll notice that upstream have switched from whatever arcane config format they used to the hipster-friendly YAML. Here is my current test setup: Best of all, thinkfan is not limited to ThinkPads - if your system has proper hwmon drivers that allow fan control, you can use it on your laptop (or desktop) too! I guess I've found a good replacement for i8kmon (which also have a somewhat arcane config file syntax) on Dells then (will be testing on some Inspirons Real Soon™). Note that the "level auto" (IBMesque for "let the EC do its job and hope it does it well") and "level disengaged" (IBMesque for "uncontrolled jet blast" AKA "11") are ThinkPad-specific, and all other levels are hardware/model-specific (on Thinkpads you get levels 0-7 aside of the special levels, while on Dell laptops, it's 0-3, or even 0-2 as 3 is often an alias to level 2) ...wonder if the fan on my Asus is also controllable by thinkfan, as thermals on this laptop have always sucked since the day I bought it... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-05-30, 03:24
|
|
Dinosaur
Post: #1109 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
https://wiki.archlinux.org/title/fan_speed_control#ASUS_laptops So apparently I DO have some sort of control over the fan on my Asus... kinda, sorta: - Only 1 (manual mode) or 2 (automatic mode) work over pwm_enable (0 aka "full speed" won't work on my K53SD), but setting it to manual will break fan speed monitoring! - Setting pwm to 255 (max speed) works (it even works on automatic mode, and will switch back to manual), but again, you won't be able to monitor fan speed! - Fortunately fan speed monitoring can be regained by switching to automatic mode (pwm_enable = 2) So yeah: half-assed implementation as expected from Asus laptops under Linux. Not really worth the effort anyway :/ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-06-09, 20:23
|
|
Dinosaur
Post: #1120 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
KERNEL HAAAAAXXXX TIME!!!! Since I'll be confined to craptacular "3G"/"4G" mobile data for the next weeks/months/years, it means repurposing my (new) routerbox for that. I have my scripts for that - just plug any 3G stick, and let good ol' PPP do its miracle. Or since Android phones SUCK and can't give you a honest-to-God modem device anymore (unlike actual dumbphones), it simply involves plugging the phone, enable USB tethering, and enjoy 3 or 4 layers of NAT. Except that this won't fly for my fancy new Xinniephone, as the Redmi Note 11 is juuuuuuust too new for vintage Debian, and you can't really think about upgrading anything without a proper Internet connection. Cellphones these days get recognized as RNDIS (MS' bastardization of CDC Ethernet device class), and the kernel has been able to deal with those for years, but OEMs always find creative ways to bend the rules: while both my Alcatel and my KrapOS® Blu work fine with rndis_host, the Redmi won't unless you're using a new enough kernel (like the ones on current Debian stable). Since Saki's brains got permafrozen at Debian Jessie, but now on an actual i686 body, maybe I can afford upgrading the kernel over 4G? Well... yes but no: tried pulling the final kernel release from jessie-backports (4.9), but nope, that won't pick the Redmi either - too old! What the fuck is this Xinniephone doing under the hood? lsusb has some answers: Alcatel OT-5044R that works: KrapOS® Blu Zoey Smart, that one works too: Redmi Note 11, which gets completely ignored by old Debian: ...and now let's take a look at what's rndis_host expecting: Debian Jessie / kernel 4.9 (backports) Debian Buster / kernel 5.10 (backports) Aha! The lists of supported device aliases has increased on newer kernels! And if we map between kernel aliases and USB descriptors, we can get the following: - Both the Alcatel and the KrapOS' Blu have a interface for Wireless Communications class (E0), subclaas 1 (Radio Frequency), protocol 3 (RNDIS), so in other words, a cellphone sharing its Internets. - BUT! The Redmi instead believes it's a Miscellaneous Device (EF), subclass 4 (nobody knows), protocol 1 (wtf). Older kernels won't pick those, while newer ones will (usb:v*p*d*dc*dsc*dp*icEFisc04ip01in*). So you know where this is going down: fire up the hexeditors! In this case, the change seems to be simple: since I have no device using interface EF/01/01, it should be a simple edit to change that first "01" to a "04", right? And indeed it is: there is a single occurrence for EF0101 near the middle of the compiled module (in my case: offset 0x143D). Just in case, I edited the alias string too, which is quite close (offset 0x174B), saved my hax module, and tried to insmod it (remember to rmmod the distro-supplied one first!). Plug the phone, enable USB tethering, aaaaand... Well... at least nothing caught fire TODAY. But apparently there is another roadblock in the way, but who? The key lies on the module dependencies: usbnet,cdc_ether,usbcore. The "CDC" bit tells that I need to look at cdc_ether, which is the proper standard for USB network interface devices that aren't modems (remember: RNDIS is a bad hack of CDC Ethernet). Fortunately, no serious bandwidth is required to read the kernel sources: (4.9) https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/usb/rndis_host.c?h=v4.9.317 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/usb/cdc_ether.c?h=v4.9.317 (Latest stable) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/rndis_host.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/cdc_ether.c And the answer is right in front of our eyes! The "bad CDC descriptors" come from usbnet_generic_cdc_bind, after it fails to match a device with either CDC Ethernet or RNDIS drivers. Even when rndis_host can take the device, cdc_ether must clear it first as a proper RNDIS device, otherwise it will bail out. And here is what this Xinniephone is Doing It Wrong™: So yeah, our shitty Chinazi phone is pretending to be... a datacard. WHY WHY WHY WHY!?!??!?! Hacking this one out got more involved, as I had to bring bigger guns into this struggle: enter the dissasembler! Long short story: knowing just a bit of ugly x86 assembly language can be a lifesaver. Compiler optimizations on the other side will lead you to instadeath if you aren't careful. There is no magic "EF0101" number to patch out, instead we end at this: Punch in "80780601" on the hexeditor, we get two matches. But we want the one that goes with "80780701", so the magic one-byte patch (01->04) I had to do was exactly at offset 0x0683! Save, clean, insmod, try again: KERNALITY! All I have now to do is to enjoy my 1GB of "worse than GPRS" LTE data--- wait, wtf is DNS not working?! But I can ping IP addresses!? Ah, Digitel, hope you choke with that Big Red Commie schlong (for whatever reason, they block every single DNS server except for Google's 8.8.8.8 -and only .8.8, .4.4 is blocked-, maybe to not break Android), so after disabling all forwarders but 8.8.8.8 on BIND, I'm back to business... kinda. tl;dr: better dust off the CANTV Mafia™ phone numbers? Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-07-24, 20:50
|
|
Dinosaur
Post: #1160 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
Now that my DSL is alive (and I'm $200 poorer after footing the bill for the power surge carnage), it's time to move on and prepare the upgrade path for this Compaq box o' hell: here are my two paths: 1) Preserve the current install from Saki (RIP), and dist-upgrade all the way: Jessie->Stretch->Buster->Bullseye. SHOULD be safe, but messy given that many things have changed since 2015. 2) Start from scratch with latest Debian release. I have plenty of spare PATA HDDs, plus it would be a good refresher of my server setup skills. So 2 it is - a new machine, a new beginning. BUT! Since this is my routerbox, it means I'll be offline during the setup, without a way to research anything at all should shit hit the fan. Fortunately we're in 2022, and I have something I didn't had two decades ago: virtual machines! I created a machine with a setup as close as possible as my Compaq. Of course it means I can only match RAM, HDD, and input devices, so I went with a 184MB, 2GB HDD VM for testing. Insert the Debian netinst+firmware CD, aaaand... *BOOM*  Hellooooooo, software bloat~! Apparently having to support every wretched setup out there (from crypto paranoid nutters to weirdass server-class hardware to people wanting to install Debian into exotic filesystems), plus years of software "progress" has taken its toll on Debian Installer, but since they're so nice, I'm downgraded to "low memory mode". In this mode, the installer: - Can't guarantee setup success. - Will not load most setup modules, including ext3/4 support, or many drivers... but will give the user the option to manually load the required ones. - Will not load locales either, so installer will only run in English, and will deliver a "C"-locale setup, if it manages to finish. So... uh, these are my notes for such an special setup, for the moment I decide to fully commit and perform the bare metal setup on my Comcrap box: * The modules you will definitely want are: choose-mirror (to select a Debian mirror to download packages from), mbr-udeb (do I really need it?), nic-modules-KERNELVERSION-ARCH-di (you want your network card to work, right?), partman-ext3 (without that one, you'll only be able to install to ext2 partitions from 1998). * Setup may be a bit unstable, and fail without warning. But then, VirtualBox has been acting quite wonky today, so maybe either I need a RAM check or finally ditch Orrible® software... I had to attempt setup TWICE, but hopefully that won't be the case on bare metal! * When partitioning, don't forget to create a swap partition! Slow swap on vintage PATA drives is better than nothing, and the installer will activate it as soon as possible as it IS needed if you want your setup to not get aborted by the OOM-killer! * When tasksel starts, you only want the defaults, that is, base system utilities and SSH server. * Oh, setup finished successfully? OK, time to fix up stuff before we start installing packages! - Login as root, or use "su -" - the dash is important as otherwise you will have no access to /usr/sbin in your path! - dpkg-reconfigure locales. For now, your only locale is the useless "C", so go and enable glorious es_VE.UTF-8. - Reboot. But before, edit root's .profile and remove the lines enforcing C locale for root as Debian Installer ran in - Oh, we now have a Spanish locale-- WTF, my Ñ's are mojibake instead?! Suck! Well, the proper way to fix that is editing /etc/default/console-setup. No need to reboot, but won't harm either. - We're done. Proceed with the setup of remaining services (Samba, dhcpd, BIND, ...) as usual. You should still have some free RAM at the end of the day (as long as you don't do adblocking with BIND) Also: I suspect I won't be maxing out RAM on this supermarket special Compaq anytime soon: Posted by Intel ® 810E Chipset: 82810E Graphics and Memory Controller Hub (GMCH) datasheet So 128MB DIMMs should be fine as long as they're 16Mx64, and 256MB DIMMs are Russian Roulette? Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-07-27, 01:30
|
|
Dinosaur
Post: #1162 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
Old game decompilations are a godsend for both software preservation and UX improvement (native binaries trump emulators any day of the week), and it seems I have a sweet spot for N64 decompilation projects. But it seems that different projects have different ideas: Super Mario 64: - Go pick a suitable port - this one is as close as vanilla as possible, no improvements at all other than "it runs on computers". - Supply base ROM - any retail ROM will do! (support for the Shindou JP ROM may depend on whatever fork you've picked, as that one got fully decompiled quite late) - Make! - Enjoy. The built binary should run fine even on toasters and IKEA smart bulbs. - Want to remap keys? Try this fork instead. Zelda OoT: - There seems to be a single decompilation+port project, with an incredibly obtuse project name. - The README doesn't tell you anything about "we can't distrbute binaries due to copyrights, so here are the build instructions". Instead... you are supposed to join a fucking Discord (why?!?!?!?) to find precompiled binaries. - But in order to not piss off Nintendo, these guys found a clever way to be able to distribute binaries sans copyrighted assets: the latter get extracted and recompiled to a separate resource file (oot.otr) - that one is supposed to be generated by you, the user, by providing your totally legal OoT ROM. OK, that makes sense... - ...except that you can't simply go use - In any case, I'm grown up enough to not rely on binaries build by randos from a fucking Discord (WHY?!?!?!?), so instead I've got code, I should be able to build my own binaries! Fortunately, if you keep reading you'll eventually find the build instructions... and oh boy, it seems these kids are overengineering things to hell and back! The Linux build instructions specifically require fucking Docker because the project formally only supports 32-bit executables on Linux targets! WHYWHYWHY!??!?! But then that's actually a lie, thankfully 64-bit support was merged recently and noone has bothered updating the instructions. You only need to do the two Make lines after cloning the repo and placing the expected N64 ROM inside. - And here is where I hit yet another brick wall product of said overengineering: these kids want C++21 just because they can, so you need a new enough compiler. My trusty Debian Buster with GCC 8 and Clang 11 won't cut it, so I had to build on my ol' Dell which is running Bullseye with GCC 10. - Of course the thing built fine there... just to have the thing crash at start because they're using "Dear Imgui" which somehow wants OpenGL 3 and this Dell ancient ATi GPU only goes up to 2.0. Fortunately there is llvmpipe to save the day (albeit slowly due to the ancient Merom CPU), and finally, native Ocarinas of Time on Personal Computers! Why do you hate PC gaming so hard, Nintendo!? MS and even Sony have no fear on making some good cash from us pasocom peasants~~~ - There is no way to remap keys yet!? - Despite having a GitHub repo, the guys from "Ship of Harkinian" really do not want to use it for support/development. Instead... yeah, you know where this is going: FUCKING DISCORD!!! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| creaothceann |
Posted on 22-07-27, 05:55
|
 Post: #410 of 456 Since: 10-29-18 Last post: 47 days Last view: 4 days |
Posted by tomman I had a discussion with someone who thought that everyone uses discord. On reddit. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| tomman |
Posted on 22-07-28, 00:32
|
|
Dinosaur
Post: #1163 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
Posted by creaothceann Absolutely love those assholes that insult you because they can't imagine a world where people with different tastes and beliefs exist, instead everybody must use The One And Only Proprietary Chat Application OR ELSE! So basically it's down to WhatsFuckingCrapp vs. Fucking Discord. Computers were a BIG mistake. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| CaptainJistuce |
Posted on 22-07-28, 01:17
|
|
Custom title here
Post: #1102 of 1164 Since: 10-30-18 Last post: 66 days Last view: 3 days |
Posted by tomman Nah, computers were fine. It's networking that was a big mistake. --- In UTF-16, where available. --- |
| tomman |
Posted on 22-07-30, 01:23
|
|
Dinosaur
Post: #1164 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
This dude did the big Jessie->Bullseye leap... on a setup much older than mine! https://diziet.dreamwidth.org/11840.html And he even went further, by not only leaping between releases, but also switching architectures in the meanwhile! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 22-08-11, 02:17
|
|
Dinosaur
Post: #1169 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
Buster mainstream support has ended 10 days ago, so it's now under the umbrella of the LTS team for the next 2 years. I guess I'll be spending the next weekend updating my final Buster setup to Bullseye: my dailydriver Asus. Expect cursing, pissing, and heavy ranting about why I haven't quit computers yet. But first, the semi-monthly HDD image just in case things go south first! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 22-08-11, 14:21
|
|
Is gonna need more trope
 Post: #582 of 599 Since: 10-29-18 Last post: 198 days Last view: 12 hours |
Y'know, this is the fifth time in the past two months that I've considered upgrading my server. I fear fucking everything up. |
| creaothceann |
Posted on 22-08-11, 14:31
|
|
Post: #413 of 456 Since: 10-29-18 Last post: 47 days Last view: 4 days |
Posted by Kawa YOLO My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| tomman |
Posted on 22-08-11, 18:39
|
|
Dinosaur
Post: #1170 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
I still have two machines pending for the update to Bullseye: - The Asus laptop: HDD just imaged, now ongoing~ - The routerbox (new name TBA): that's the one I dread the most, but it need to be done - Jessie has been out of support for about TWO YEARS. NO EXCUSES. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 22-08-11, 22:53
|
|
Ask me about SCI
Post: #583 of 599 Since: 10-29-18 Last post: 198 days Last view: 12 hours |
Posted by creaothceannNo yolo! |
| tomman |
Posted on 22-08-12, 00:37
|
|
Dinosaur
Post: #1171 of 1317 Since: 10-30-18 Last post: 2 days Last view: 12 hours |
While this machine downloads ~4GB of packages, I'll need to take note for when I finally do the routerbox setup. Apparently iptables has been deprecated for years, and kids these days roll with nftables instead. The good news is that iptables rules syntax is still supported, although it's done over wrappers these days... wrappers that aren't guaranteed to stay forever. Luckily it seems the new syntax is quite similar, so migration should be relatively straightforward: https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables https://unix.stackexchange.com/questions/283275/how-to-do-masquerading-with-nftables ...but watch out for possible gotchas: You should use probably use oifname (slower string matching) rather than oif if the interface might disappear and then re-appear (like ppp0 and others may, upon disconnect, etc.) unless you'll make other arrangements to masquerade upon the interface coming up each time. So yeah, if you're using a cellphone for tethering and sharing that connection, it's something I need to be aware of. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
