Main |
Artwork |
Books |
Donate |
Licenses |
Shorts |
Software |
Source |
|
|
|
Abiword 3.0.5 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) > requires: wv 1.2.9 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) Dillo 3.0.5 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) > requires: fltk 1.3.8 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) Elinks (snapshot 2017-07-23) (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) > requires: SpiderMonkey 1.0.0 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) GNUmeric 1.12.49 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) > requires: Goffice 0.10.49 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) hsetroot 1.0.2 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) > requires: IMlib2 1.7.4 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) Qemu 7.2.0 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) > requires: libslirp 4.6.1 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) AdvanceMAME 3.9 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) cc65 Compiler/Assembler (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) DGEN 1.33 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) DOSbox 0.74.3 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) dvdbackup 0.4.2 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) Gtypist 2.9.5 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) libaacs 0.11.0 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) libdvdcss 1.4.3 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) MinGW Cross Environment (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) Nestopia 1.40 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) p7zip 17.04 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) Qemu 6.2.0 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) sdcc 4.2.0 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) Snes9x 1.59 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) testdisk 7.0 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) TileWorld 1.3.2 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) Tor Browser 0.4.7.7 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) TSocks 1.8 (beta 5) (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) UnRAR 5.6.1 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) wol 0.7.1 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) x11vnc 0.9.16 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) xdotool (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) xf86-video-fbdev (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) xRDP 0.9.12 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) XVkbd 4.1 (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) youtube-dl (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) yt-dlp (youtube_dl fork) (compiled using Bonslack aarch64 15.0 on a Raspberry Pi) * I've read for a good, long while now that Raspbian's VC4 video driver would solve the Raspberry Pi's video woes. And, using a framebuffer would make the Pi's video system wayyy slower. Sure, VC4 will improve the color range of the Raspberry Pi (so that its video output resembles more typical video cards-- including more true black and helping to blur colors together). But, what I've found performance-wise is that-- the FPS for glxgears is about 92 using VC4 (which is ridiculously fast!) And, the FPS for xf86-video-fbdev is about 88. Any improvement for the Pi's video framerate is achieved thanks to additional Mesa optimizations (not the availability of VC4). When considering performance, there's basically no difference between using VC4 and fbdev. Mainly, I've chosen to use fbdev on systems where VC4 looks like shit (or-- I would like to control the video output using fbset). And, maybe I'll stick with VC4 when I want DVD video to look nice (like a couple of HDMI displays in my living room). ;) * Vanilla MAME did not compile for any of my ARM systems. So, I decided to continue development with the AdvanceMAME project. I'm not a huge fan of AdvanceMAME's non-existent windowed support and its disregard for aspect ratios. Also, it just seems to run like shit in general (none of my Rasberry Pi's can decode Mortal Kombat II at full speed using AdvanceMAME-- which is pitiful). On the other hand, the project tends to-- you know-- actually build for GNU/Linux systems. It also has an exciting new framebuffer feature (that works on framebuffer systems like the Raspberry Pi). Simply run AdvanceMAME from a full screen terminal. And-- it just writes the video directly to a framebuffer! :o * Slackware 15.0 includes dvdauthor and ffmpeg. So-- you won't find them in this list! * Yes-- I had to compile libdvdcss myself. Slackware finally got ffmpeg and dvdauthor. And-- Volkerding *still* isn't including libdvdcss. lol. * There is a SlackBuild for Nestopia Undead Edition. However, I found that it didn't perform very well on *any* of my systems (including a 64-bit x86 netbook I snatched from Ebay a while back). So instead, I decided to compile good ol' Nestopia 1.40 (the last official version of the Nestopia project). I had to "correct" a feature of the source code (which employs a C++ template using an undeclared enum value). I also added the ol' "-fpermissive" flag to make's CPPFLAGS (necessitating a "+=" for CPPFLAGS in Nestopia's 1.40 Makefile). Because-- the GCC maintainers have randomly decided that negative left hand operands should be a compiler error now (instead of prompting a developer with a completely reasonable warning). * I attempted compiling VirtualBox for x86 (clearly, that would not be possible for ARM based systems). And (oh, my Gawwwd)-- the worthless piece of shit doesn't even compile for 32-bit x86, anymore. Can you *believe* that?? Not only does VirtualBox only compile for 64-bit x86, now. It doesn't even provide a 32-bit virtualization mode. So, you can't run a 32-bit x86 system on top of it. Hell-- what good is it? I can safely declare that the VirtualBox project has become deprecated. And, I can no longer (in good conscience) condone its use. My recommendation would be to try out Qemu, instead. However, if a system does not have hardware virtualization-- a user is limited to software emulation when running x86 on top of x86 (which is totally stupid). Qemu has no paravirtualizer, yet. Why-- I have no idea. I'm attempting to compile Linux 2.4 for Slackware 15.0 (so I can improve Slackware 15.0's performance on top of Qemu tcg with udev disabled). But so far, I have been unsuccessful. The 2.4 kernel is designed to compile for GCC 2.4 - 4.2 (I think). And, GCC 3's SlackBuild (from Slackware 11.0) will not build for Slackware 15.0. I plan to continue researching this. Because, Slackware 11.0 (using Linux 2.4) runs pretty great on top of Qemu tcg (check out Insanely Witty Stupidity's Slackware 11.0 packages for some help with this). And, I'd love to see Slackware 15.0 (and possibly future versions) do the same. :D * Slackware 15.0's Snes9x SlackBuild builds some really great GTK optimizations. I couldn't believe the performance I got with the project on top of a Raspberry Pi (even 2x scaling with the ol' fbdev)! :ooo * Apparently, the Tor project's Firefox fork builds for ARM, now!! xD * I attempted building Wine for ARM. And yes, this would result in a project that can only run (and develop) Windows RT binaries. But, I still would've liked to see it build. Unfortunately, I was unsuccessful. The Wine developers insist their suite should build for ARM. But (as far as I can tell), it doesn't. And, I'm not quite sure what to do about that. So, I built Wine only for x86 (which is probably going to be the most useful type of Wine, anyway). Additionally, I built 64-bit Wine for 64-bit Windows binaries. So if you want to run a 32-bit Windows binary on top of a 64-bit x86, you'll need to chroot a 32-bit Slackware system. And, you can install the 32-bit Slackware Wine package in that there chroot. ;) * Slackware *still* does not include a VNC package (I cannot imagine why). *I* always build x11vnc (which only provides a VNC server). There's a SlackBuild for Slackware 15.0 that builds TigerVNC. But, the TigerVNC developers think their shitty VNC server should start its *own* X server (for some strange reason?) And-- there seems to be no way around this?? Since I only need a server, I compiled x11vnc like I usually do (I never feel like I *need* a client because I attach to xrdp using rdesktop). If you would like a VNC client for Slackware 15.0, you should try building the TigerVNC SlackBuild for your system. ;) * Yeah-- I went ahead and built fbdev for Slackware 15.0's X Window System. And yeah, I'm actually using it on some of my systems. VC4 looks like shit on one of my displays (it's a fuckin' joke). And, fbdev performs just as well. And, I'm not gonna use a shitty display just because the Raspbian developers think 92 FPS glxgears is better than 88. You gotta be shittin' me. * Update: I *did* manage to compile Slackware-15.0's kernel in a way that I like for Qemu. And by disabling most of Slackware-15.0's unneeded startup scripts (rc.S: rc.acpid, rc.modules, rc.udev; rc.M: rc.alsa, rc.bluetooth, rc.elogin.d, rc.messagebus, rc.pulseaudio, rc.wireless), I am able to launch a 32-bit x86 system in less than three minutes on top of tcg (running on a Raspberry Pi). :D I found that 64-bit x86 performs at nearly half the speed. I used Linux's "localmodconfig" make option with Udev disabled (meaning only modules that were loaded on top of Qemu without running Udev were compiled for the kernel). I also switched e1000, ext2/3/4, and psmouse to builtin modules (and EHCI-USB when building the kernel for 64-bit x86). Additionally, I've found that vanilla links (which has no JavaScript translator) can log in on Amazon and place orders and access my linuxquestions.org and StackOverflow accounts. I only compiled Linux 5.15.19 for x86 systems (because Qemu ARM vexpress and virt are pretty tough to support and-- I simply have no use for them, yet). Running Slackware on top of Qemu without a hypervisor is of utmost importance to me. Apparently, developers are so stupid and lazy nowadays that they are choosing to stop developing for 32-bit ARM and x86 targets. I have no idea what benefit uneducated maintainers rationalize they will achieve by doing this. But, the better design choice (obviously) would be to develop only for 32-bit (not build exclusively for 64-bit). This cuts the workload in half (just like developing only for 64-bit). But, compiling only 32-bit software retains the functionality of 32-bit systems. And, 32-bit software runs just fine on top of 64-bit hardware. However, the converse is not true. Furthermore, there is no performance boost when running 64-bit software on top of 64-bit hardware. There never was. And-- there never will be!! I fear that (pretty soon), the only solution for running 32-bit ARM and x86 hardware is going to be something like-- launching the latest suites (compiled only for 64-bit hardware, apparently) on top of Qemu built for a deprecated 32-bit operating system. That is-- if you wanna be able to browse the web on those systems. Almost every website nowadays requires the latest ssl certificates (because many inexperienced web developers are choosing to use https unnecessarily-- or (most likely) don't even know what https is or what makes it useful). Websites like Amazon are punishing customers for attempting to log in with ssl certificates that are only a few months old by forcing a user to change his/her password and blacklisting it. And (since Qemu offers no CPU paravirtualizer or solution for byte code bottlenecking), you're gonna need to compile a minimalist kernel in order to use a web browser that is permitted to log in on https websites. Ironically, developers could (very easily) continue allowing https logins with older ssl certificates. And, there is no security benefit to using new ones (sure, the new algorithms are more complex; but the old ones are UNBREAKABLE!!) Regardless, developers are consciously choosing to require recent certificates (many-- misinformed about ssl certificates and how they work). And, shadowy puppet-masters are enforcing obsolescence by crafting more complicated versions. As a result, the world wide web is (rapidly) becoming inaccessible to "less privileged" patrons. A user should not be treated this way. It's completely unethical! Unfortunately-- that's exactly what unknowledgable developers are doing!! It's a scary world we live in. D: |
| Random Fact: Insanely Witty Stupidity's icon (the "Oracle") is mysterious and perplexing. The more a person stares at it-- the more bizarre it appears. In reality, the logo is merely three letters inside of a yellow circle. Weird, huh? |
|
html revised 2024-04-18 by Michael Atkins. The maintainer of insanely |