Lady Goosepelt

St John Karp

Ramblings of an Ornamental Hermit

Tag: computers

Cobalt Qube 3: Part 2

The saga continues! I previously wrote about my laborious experiences compiling a 2.6 kernel for the Cobalt Qube 3 and getting a semi-modern Linux distro running on it. Those steps took me as far as Debian Wheezy, but official support has now ended for that release and the latest Debian won’t run on an i586 processor. So where are we supposed to go from there? Read on, dot dot dot.

Slackware and a 4.17.2 Kernel

Slackware is the only mainstream Linux distro (outside of Gentoo) that still supports the i586 architecture. I exclude Gentoo from that calculation because it’s a source-based distro and compiling all your software on a Qube will be ridiculously time-consuming, though you’re welcome to have at it if you’re that way inclined.

So a-slacking we must go, but will modern Slackware run a 2.6 kernel? Even if it does it would probably stop supporting it in the near future, and besides, there’s all those juicy kernel updates and security improvements that have been made since then. Are we going to miss out on all those? Are we buggery.

It took me a good weekend because I’m no C developer and know precious little about the kernel, but I eventually managed to port the old Cobalt kernel patches to a 4.17.2 kernel. I daresay there are even some improvements because the maintainers of the 2.6.36 patches had disabled the code that handled writing to the LCD panel and had misplaced some of the code for the Cobalt reboot routine. It wasn’t hard to uncomment that code and update it to work with the newer function calls. Again I want to state that I am not a C developer or a kernel expert, so these patches are unofficial, unsupported, and entirely at your own risk. That said they seem to be working pretty well for me and I’ve confirmed the Cobalt drivers do actually do their thing.

Here we go then, here’s how to get your Slackware up and running:

Update: When I wrote this originally it was for the 3.16.56 kernel source. I’ve since updated it for the newer 4.17.2 kernel, but I’m keeping the 3.16.56 patches online in case anyone needs them.

  1. Plug your hard drive into a separate desktop and install Slackware 14.2. You can do this by booting from the installation media, or just handling the whole process via VirtualBox as described in my previous post.

  2. Grab kernel 4.17.2 (the latest stable release at the time of writing):

    wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.17.2.tar.xz
    tar xvf linux-4.17.2.tar.xz
    mv linux-4.17.2 /usr/src/linux-4.17.2-cobalt
    cd /usr/src
    ln -s linux-4.17.2-cobalt linux
    cd linux
    
  3. Apply my 4.17.2 kernel patches:

    patch -p1 < ~/linux-4.17.2-cobalt.patch
    
  4. I figured out a working kernel config through trial and error. Originally the kernel compiled to something like 2.3 MB, which was evidently too big because it just refused to boot. After stripping out some stuff that wasn’t relevant on a Cobalt and compiling a bunch of other things as modules I got it down to 2 MB and that seems to boot just fine on my machine. If it doesn’t boot for you, you may need to slim it down further.

    cp arch/x86/configs/qube3_defconfig .config
    

    I only created a working config for the Qube 3. The previous patch also contained some configs for various Raq machines, but I didn’t port those because I can’t test them. You should be able to use them and run “make oldconfig” to bring them up to speed with this kernel, but you might have to do some work to remove stuff you don’t need.

    Don’t forget to make any edits you need for your own hardware. In my case I compiled CONFIG_SATA_SIL as a module because I use a particular SATA PCI card.

    Update: After porting the Cobalt patches to 4.17.2, the size of the compiled kernel ballooned back up to 2.3 MB. I reduced it again by getting rid of as much as I could, which unfortunately included the RAID drivers. Please review your requirements to figure out what you need and re-enable them in your config, but you may need to take something else out or compile them as modules to keep the size down.

  5. Compile and install:

    make
    make modules_install
    make install
    strip vmlinux
    bzip2 -c vmlinux > /boot/vmlinuz-4.17.2-cobalt.bz2
    cd /boot
    ln -s vmlinuz-4.17.2-cobalt.bz2 vmlinux.bz2
    

    When I did this the installation build step automatically put its System.map into the /boot folder, so no need to do it manually as we did in my last post. I also noticed it didn’t create an initrd.img, but then my machine booted fine without it so I won’t go dicking with it now.

  6. Prepare the OS to be booted on your Qube.

    1. I had my drive plugged in as a USB device so Slackware detected it as /dev/sda. If this was the case for you too, you’ll need to edit the /etc/fstab entries from /dev/sda1 etc. to /dev/hda1 etc.

    2. Edit /etc/inittab to comment out the normal tty1, tty2, etc. and uncomment the first serial line ttyS0. Edit the baud rate of that serial tty from 9600 to 115200. It should look something like this:

      s1:12345:respawn:/sbin/agetty -L ttyS0 115200 vt100
      

      This will enable you to connect to your Qube using the serial terminal.

    3. You might also want to uncomment ttyS0 in /etc/securetty. Otherwise this will prevent you logging in as root via the serial console.

    4. Remove the network hardware automatically detected on your current machine:

      rm /etc/udev/rules.d/70-persistent-net.rules
      

      This will get automatically regenerated when we boot off the Qube.

    5. Set the ethernet speed correctly by adding the following lines to the top of /etc/rc.d/rc.inet1.conf:

      ethtool -s eth0 speed 10 duplex full autoneg off
      ethtool -s eth1 speed 10 duplex full autoneg off
      

Now everything’s jake — you can take your drive, plug it into your Qube, and boot ’er up. Plug in via the serial console to continue setting it up the way you like it. How do I know what you want a Qube for. Get your own ideas. Go on. Shoo.

Make the LCD Do a Thing!

What was the point of all that fiddling around with kernel drivers if we’re not actually going to use them? First I wanted to confirm they actually worked, so I did a couple of these:

cat /proc/cobalt/raminfo
cat /proc/cobalt/sensors/thermal

This spits out a bunch of data about the current RAM and CPU temperature, so we’re looking good on that front.

You can also run this:

cat /proc/cobalt/lcd

Now you can read what’s currently printed to the LCD panel at the back. But how the hell do you write to it? Turns out some angel-eyed developer called Jeff Walter created some utilities for interacting with the LCD panel, so let’s fire those up and see what’s what. His original site is now offline, but he did submit the source to the Debian repos at some point. You can download the source and compile it, then write to the LCD panel by running:

lcd-write "Skaboopy"

Go check your LCD panel — go on, I’ll wait. Isn’t that nifty?

I haven’t got the original program that shipped with the Qube to manage all the buttons, but it looks like these utilities will help you if you want to write a new program to do what you like with it. Personally I can’t imagine using the panel often enough to bother with that, but I did set up a little cron job to run this every day to display the Discordian date:

lcd-write "$(ddate +"%A")" "$(ddate +"%e %B")"

Hardware Recommendations

I had to go through some bum hardware before I figured out the smart way to do things, so let me save you some time. Don’t bother with an IDE hard drive. They’re all getting old now, and even if you find one that works it’s not going to last forever. Then what are you going to do? Make one? No, what you want is a 120 GB SATA drive to act as your main drive and an IDE-to-SATA adapter to plug it into the Qube’s IDE controller. You’ll need an adapter that specifically supports ATA 33, like this one from StarTech.com. If your adapter doesn’t mention ATA 33, don’t buy it — it probably won’t work.

120 GB is about the largest drive you can plug into that IDE controller due to the Qube’s hardware limitations. That isn’t a stellar amount of storage these days, so you may want some extra. You can plug an external hard drive into the USB port at the back, but it is USB 1.1 so be prepared for some glacial speeds. I preferred to grab a SATA PCI card, whack it into the Qube’s free PCI slot, and plug a 1 TB drive into that. Bob’s your auntie. Don’t forget to pick up a Molex to SATA power adapter too. You won’t be able to boot off this drive, but it will give you some bonzer extra storage at a decent transfer rate.

If you’re anything like me you’ll have got this far and, feeling very satisfied with yourself, prepare to put the lid back on your machine — only to find that the damn thing won’t close because your drives stick up too high. It appears that the old IDE ribbons had a pretty low clearance and the lid of the Qube was built without much wiggle room. Both my IDE-to-SATA adapter and the SATA cables for my secondary drive stuck up too high to let me shut the lid. Even replacing the SATA cables with right-angle connectors didn’t make them low enough, so you’re going to have to get a bit ingenious here. First thing is, make sure you get 2.5” drives, not 3.5”. It turns out 2.5” drives are short enough that you can just mount them one screw lower on the Qube’s mounting brackets. Sure, they’ll only be secured by one screw on either side, but they’ll fit into the slot like a dream and let you close that lid.

Now aside from the CPU, which can’t be upgraded beyond 550 MHz, there’s two remaining bottlenecks with these machines. One is the USB port which is USB 1.1 and crawls like a dead whale. The other is the ethernet, which is 10BASE-T and chugs along like Steamboat Willie. So far I haven’t been able to upgrade either because I already used up the PCI slot with a SATA controller. Too bad. If you’re not using a secondary drive you might consider a USB 2.0 or an ethernet PCI card (remembering to recompile the kernel with support for any new drivers you need). A USB card could theoretically let you plug in a fast external drive and a USB-to-ethernet adapter, but I haven’t been down that road. Personally I hear tales of a SATA-and-ethernet combo card, but I haven’t been able to track one down yet and I’m starting to suspect that they’re nothing more than the lonely dreams of old sysadmins, hunched and heating their frozen bones around a heatless fire, grown grey and wizened with years of disappointment.


How I Installed Debian on a Cobalt Qube 3

(and so can you)

Cobalt Qube 3

If some gorgeous thing plagues your life for three whole weeks, depriving you of sleep and sanity, it’s either an ex-boyfriend or a Cobalt Qube. I’ve wanted one of these for years — I mean look at it, who wouldn’t want such a beautiful computer in their house? But the expense was always a sticking point for me, even long after the Qube computers were current, until recently I spotted old Qubes going for about $70 on eBay. Ka-ching. Pick me up a cheap Qube, whack Debian on a hard drive, and Bob’s your aunty — adorable home server. Or so I thought. Little did I know that I was getting myself into three long, hard weeks of boot hell, kernel compiling, and painstaking upgrades.

But first, a little background. The Qube 3 is a square-ish computer designed as an easily configurable server with a web admin interface. The earlier models ran MIPS processors, but the Qube 3 runs an i586 AMD K6-2 processor. I gather they shipped different configurations of the machine, but the highest speed they sold was 450 MHz. My home server has been happily chugging along on a Sheevaplug for ages, but I’ve been irked for a while by the fiddliness of having the OS on an SD card, the lack of grunt of the 1.2 GHz ARM processor, and the fact there’s no good place to stick a hard drive. I thought, if I’m going to have a shit home server, it may as well be a cute one. I’ve determined that about the most modern release of Debian this is ever going to run is Debian Wheezy (still technically supported, but not for much longer). The process of upgrading the Qube to run something semi-modern is not straightforward, and this guide is for all you (one? two?) intrepid archaeonauts who want to make the best of beautiful old hardware.

Hardware Upgrades

Cobalt Qube 3 innards

Yes, you heard it here first. Raise that RAM to the mother-lickin’ roof. Mine came with a 64 MB stick of RAM, but you can upgrade it to a max of 512 MB. Do it! Grab some off eBay, stick it in, and boot it up. Amazingly, this was the only straightforward part of the upgrade process.

The CPU was held down by a tall, silver heatsink that did not want to budge. The clamps holding it down were merciless, and the thermal paste had hardened so much I thought the heatsink might actually be glued on. After prying at the damn thing with screwdrivers, I finally managed to free both the heatsink and the CPU without damaging the motherboard. Turns out the CPU that came with it was an AMD K6-2+ (450 MHz). Well I thought we can do better than that, so I popped on eBay and nabbed a 500 MHz K6-2+. That’s a performance boost of like… a ninth? Bonanza. Only when I booted, the ROM kept telling me the thing was only running at 450 MHz, or thereabouts. Turns out the jumpers for selecting the CPU speed aren’t actually jumpers at all. They’re resistors soldered onto the damn motherboard, under the CPU if you please.1 Well I’m not taking a soldering iron to my motherboard for 50 MHz, so I guess I’ll stick with 450.

Now let’s talk hard drives. The Qube has room for two IDE hard drives, but the controller only permits a maximum size of 137 GB each. So far I haven’t had any luck replacing the 20 GB drive that came in the box. The first 120 GB drive I got off eBay was actually a mis-advertised 160 GB drive, and the second one I bought got delivered to Anchorage, Alaska. I live in California. I do, however, need something with at least a terabyte as a secondary drive so I can stream my music collection and run a small backup server. The Qube has one free PCI slot, so I bought a SATA controller card that has so far done nothing but throw “lost interrupt” errors and has prevented the machine from booting, so screw it. My 1 TB drive is currently connected with a SATA-to-USB adapter to the USB 1.1 port at the back of the machine. I’ve bought a USB 2.0 PCI card with an internal port, so hopefully that will give me slightly zippier storage. I’m thinking I can also get a USB-to-ethernet adapter and get some faster ethernet than the motherboard’s sluggish 10BASE-T.

The ROM

The Qube has a slightly bizarre boot process that’s going to inhibit everything we do from this point on. As far as I can tell it doesn’t load from the hard drive’s bootloader. It boots a minimal Linux kernel from its own internal ROM, which it then uses to load a secondary kernel from the hard drive. If it can’t load the secondary kernel, it will actually boot the OS using the ROM kernel. Being from 2002 the ROM kernel is version 2.2 (or something equally archaic) and won’t recognize an ext3 filesystem, but when Sun stopped supporting the Qube they open-sourced the ROM code and some enterprising developers made their own improvements.

You’ll want to grab the flashtool and latest ROM from the Cobalt ROM project. For the Qube 3 the appropriate ROM is cobalt-2.10.3-ext3-1M.rom.

  1. Get yourself a serial-to-USB null modem cable and plug it into the serial port at the back of the Qube.

  2. Boot the Qube while holding down the Reset Password button with a paperclip. This will enable the serial console.

  3. From a Linux machine on the other end of that null modem cable, run:

    sudo screen /dev/ttyUSB0 115200
    

    You now have console access to the machine, and you’re going to be using this a lot.

  4. We’re going to install a basic OS that will let us get started. The Qube supports netbooting, but fuck a lot of that, I’m going to use VirtualBox instead. Grab your hard drive and an IDE-to-USB adapter and plug it into your Linux machine.

  5. Create a virtual disk mapped to your hard drive:

    sudo VBoxManage internalcommands createrawvmdk -filename /home/user/woody.vmdk -rawdisk /dev/sdd
    

    (or whatever your device is called)

  6. Run VirtualBox (as root so you have access to that VMDK):

    sudo virtualbox
    
  7. Create a new virtual machine with your VMDK file as its drive.

  8. Grab an installer for Debian 3.0 (Woody) from Debian’s CD archive and set that ISO as the virtual machine’s CD drive.

  9. Install the hell out of Debian, being sure to use ext2 partitions. Don’t worry about package repos — not yet anyway. We just need a minimal machine to flash the ROM.

  10. Shut down the VM.

  11. Copy your flashtool and ROM onto the drive.

  12. Edit the /etc/inittab file to enable the serial console. I had to comment all the lines that enable tty1, tty2, etc., and uncomment the line that gives you a serial terminal:

    T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
    

    Make sure you’ve set the baud to 115200 as well, because by default it’s going to be 9600.

  13. Move the hard drive to the Qube and boot it.

  14. Back up your original ROM:

    ./flashtool -v -r > original.rom
    
  15. Flash your new ROM:

    ./flashtool -v -w cobalt-2.10.3-ext3-1M.rom
    
  16. Reboot and make sure your new ROM kernel boots successfully. You should be able to boot into Debian Woody at this point, but don’t worry, we’re not leaving it there.

Upgrade the OS Kicking and Screaming

Update: There’s a new post over at Cobalt Qube 3: Part 2 with more up-to-date instructions on compiling the kernel and installing the OS.

The Qube just does not want to run a modern OS. This is partly because the i586 processor architecture is all but unsupported these days. Debian dropped support for this with Stretch. Jessie will still run on an i586, but because of the fact we need a kernel patched specifically for the Qube and I haven’t been able to find a kernel patch for any version beyond 2.6.36, the latest Debian that we’ll be able to run is Wheezy. Getting us there is going to be a chore. You might think you could just install Wheezy on a hard drive, boot it from the ROM kernel, and compile your kernel right there. Nope. Nope. Big bag of nope. Wheezy won’t even boot with the ancient ROM’s kernel. So what we need to do is install the latest bootable Debian and start upgrading from there.2

  1. Install Debian Etch on the drive using your Linux machine and the same VirtualBox procedure as above. When asked to configure the package repo, you can specify the Debian archival repo at http://archive.debian.org/debian/.

  2. Boot Etch in VirtualBox and install the dependencies we’ll need to compile a kernel:

    apt-get install build-essential bzip2 kernel-package gcc libncurses5 libncurses5-dev bin86 gawk ncurses-dev initramfs-tools
    
  3. Shut it down and copy to the drive all the Cobalt files we’ll be using. These consist of:

  4. Move the hard drive to the Qube and boot into Etch. We need to install a 2.6.24 kernel (but not greater) in order to upgrade to Lenny. After that we can install our 2.6.36 kernel.

  5. Install the kernel source:

    dpkg -i linux-source-2.6.24_2.6.24-7_all.deb
    cd /usr/src
    tar -jxvf linux-source-2.6.24.tar.bz2
    mv linux-source-2.6.24 linux-source-2.6.24-cobalt3-tw
    ln -s linux-source-2.6.24-cobalt3-tw linux
    cd linux
    
  6. Apply the Cobalt kernel patches:

    patch -p1 < ~/linux-2.6.24.3-cobalt3-tw.patch
    
  7. Copy the kernel config:

    cp ~/linux-2.6.24.3-cobalt3-tw.config .config
    
  8. Edit .config and set CONFIG_LOCALVERSION to “-cobalt3-tw”.

  9. Prepare to compile:

    make oldconfig
    make-kpkg clean
    
  10. Compile that mother! This will take a wee while. I’ve used the date as the revision number.

    make-kpkg --initrd --revision='2018.05.15.1' kernel_image kernel_headers modules_image
    
  11. The previous step resulted in two beautiful new DEB files in /usr/src. Install them now:

    dpkg -i ../linux-headers-2.6.24-cobalt3-tw_2018.05.15.1_i386.deb ../linux-image-2.6.24-cobalt3-tw_2018.05.15.1_i386.deb
    
  12. Create the vmlinux:

    make vmlinux modules modules_install
    strip vmlinux
    bzip2 -c vmlinux > /boot/vmlinuz-2.6.24-cobalt3-tw.bz2
    
  13. Change into the /boot folder and configure the newly generated boot files for the Qube by setting up the appropriate symlinks:

    ln -s System.map-2.6.24-cobalt3-tw System.map
    ln -s initrd.img-2.6.24-cobalt3-tw initrd.img
    ln -s vmlinuz-2.6.24-cobalt3-tw.bz2 vmlinux.bz2
    
  14. Reboot and make sure you’re now booting successfully from your 2.6.24 kernel (i.e. not falling back to the ROM kernel).

  15. Move the drive to your Linux machine again and boot the VM. When GRUB comes up, you won’t be able to boot from your newly compiled kernel so just pick whatever came with Etch.

  16. Upgrade Etch to Lenny by updating the release version in /etc/apt/sources.list and running:

    apt-get update
    apt-get upgrade
    apt-get dist-upgrade
    
  17. Boot the Qube again. It’s time to compile a 2.6.36 kernel.

  18. For some reason it won’t compile without a newer version of kernel-package, so go ahead and install that from the files we transferred to the Qube earlier:

    dpkg -i kernel-package_12.036+nmu1_all.deb
    
  19. Unzip the source for the new kernel:

    tar -jxvf linux-2.6.36.2.tar.bz2
    
  20. Compile the kernel using the same steps we used for 2.6.24. I used the 2.6.36 patches I found on the Web. They came with a kernel config that didn’t entirely work with subsequent versions of udev that we’ll get to in a later upgrade, so I made some tweaks and you’ll want to use that. It’s going to take considerably longer to compile than the 2.6.24 kernel did, so leave it overnight.

  21. When it came to linking the new initrd.img, I found the compiler hadn’t generated one for me. No worries, we can do it ourselves:

    mkinitramfs -o /boot/initrd.img-2.6.36.2-cobalt.img 2.6.36.2-cobalt
    

    Remember to remove the symlinks we previously created in order to link to the newer kernel.

  22. Plug the hard drive into your Linux machine and boot the VM again.

  23. Upgrade Lenny to Squeeze.

  24. Upgrade Squeeze to Wheezy. Now you’re upgrading to a supported distro, so you can change your repo URL to a current one instead of the archive (e.g. http://ftp.us.debian.org/debian/). By the time you read this it may no longer be supported, in which case stick to the archival repo.

  25. Boot the Qube again. We’re now running Wheezy — huzzah! But there’s some additional steps we’ll need to get a few things working.

  26. I needed to run “depmod” to get the kernel to generate/load/whatever the appropriate modules. Without that everything was SNAFU’d.

  27. Remove the ethernet device definitions that will contain the virtual network card from VirtualBox because that virtual card buggerizes things a bit:

    rm /etc/udev/rules.d/70-persistent-net.rules
    

    Don’t worry, this file gets regenerated with the correct settings when you reboot.

  28. Install ethtool, which will help us get the network running properly:

    dpkg -i ethtool_3.4.2-1_i386.deb
    
  29. At this point I had a working OS, but no network! Turns out the OS tries to read the ethernet adapter as 100BASE-T when it’s only 10BASE-T, so we’re going to need to tell it what speed to use. Add this line to the end of the definition of eth0 in /etc/network/interfaces:

    up ethtool -s eth0 speed 10 duplex full autoneg off
    
  30. Reboot — and there you go! Your own working, (semi-)modern Cobalt Qube 3 in only seventy million easy steps.

You’re welcome to go dickering with these steps — I’m positive there’s a lot of room for improvement, but I spent a long three weeks working these out by trial and error, so when I got to a working set of steps I wasn’t inclined to go screwing with it.

Where to from Here?

At the moment I’m quite happy with Wheezy. As of writing it’s still supported, so it has all the backports and security updates necessary to run a secure server. In the future I’ll probably wind up compiling more of my own software to keep it up to date. In terms of speed it’s not the flashiest thing in the universe, but it sure is the sexiest. I’m even running Subsonic on it to stream my music, and although the UI is a tad sluggish the MP3s are streaming flawlessly. Provided Subsonic doesn’t have to transcode anything, software really isn’t involved — the bottleneck is probably going to be the hard drive and ethernet speeds.

IMHO this is about as far as you’ll be able to upgrade the Qube without a newer kernel. I see no good reason the Qube shouldn’t be able to run Debian Jessie (the last Debian release to support i586) or the latest version of Slackware (still supports i586) if someone were able to patch a newer kernel, but that is waaaay beyond my level of expertise. Any volunteers out there? Can it be done?

Notes

  1. A lot of source material on the Qubes is no longer online, so be prepared for a lot of links to the Wayback Machine. For the Qube’s processor hardware, see Martin Hoeffer’s blog

  2. For the kernel compile steps I’m highly indebted to Installing Debian on a Cobalt Qube 3. It’s an excellent article with probably even more detail than I have here, but it was written in 2009 and there have been a lot of changes in Debian since then. 


The Web is a Shot Bird

Mozilla caused a kerfuffle on the weekend by deliberately pushing an add-on to a lot of people’s Firefox installations. This add-on, called Looking Glass and accompanied by the ominous text “MY REALITY IS JUST DIFFERENT THAN YOURS”, turned out to be a promotional tie-in with the TV show Mr. Robot. Like a lot of Firefox users tired of Mozilla’s fuckery, I’ve been nosing around for alternative browsers — but the state of the browser ecosystem is shockingly poor. A large number of alternate browsers out there are forked or patched versions of Chromium and Firefox, and the ones that aren’t are painfully underpowered.

What’s the reason for such low genetic diversity in the browser world? It’s because creating a Web browser is hard. The Web isn’t the Web it used to be — you can’t just slap together something that renders basic HTML and CSS and call it a Web browser. You now need something that can handle CSS animations, form validation, HTML5 canvas elements, secure encryption, digital rights management, FIDO U2F, and enough audio and video support to replace your default media player. On top of all that let’s not forget a JavaScript engine that doesn’t chug along like Steamboat Willie. Google and Mozilla spend a lot of time and money making JavaScript fly in their browsers, so good luck with that. So when aspiring young Jane or Jimmy says that someday they want to build their own browser, they’ve set themselves a practically impossible task. Just fork Chromium or Firefox instead and have 90% of the work done for you out of the box.

Why don’t I just shut up and make do with a truly independent browser, one that’s not based on Chromium or Firefox? Aside from being chronically underpowered and lacking features (just you try watching Netflix using qutebrowser or Midori; go on, I’ll wait), those independent browsers won’t support Chrome or Firefox extensions. I would never browse the Web now without at least an ad-blocker. My minimum suite of add-ons consists of uBlock Origin (ad blocker), HTTPS Everywhere (security), and Privacy Badger (privacy). I would no longer consider browsing the Web without these or equivalent add-ons because the Web has become an ad-infested, unsecure, privacy-invading stew. It’s like acid rain in all those old sci-fi stories where kids have to go to school wearing armor-plated raincoats. We’re all wearing the armor-plated raincoats now, and anyone browsing the Web without one is asking for trouble.

So this is the state of affairs: we have a Web that no-one can browse and no-one can build a browser for. It’s a shot bird, in my opinion, and probably beyond saving. Which hurts to say — I grew up online and spent a lot of very happy days making friends there and discoving the enormous quantity of stuff that was available to me for the first time (obscure music, digitized books, census records). But when was the last time you visited someone’s website? You don’t any more — you visit their Tumblr or their Twitter or their Facebook. When was the last time you downloaded an MP3 and discovered a new band you liked? You don’t — you let Spotify or Pandora make recommendations and stream them to you. The Web has been turned into an app delivery service and your browser has been turned into an app execution platform, all for the sake of companies that are harvesting users as their product. The Web has strangled itself out of all diversity and innovation. I’m not saying there aren’t still great things on the Web or that we should go back to 1997, but things can’t and won’t continue like this indefinitely. Something has to change. Until then, I dunno… browse Gopherspace or read a book. Ned Beauman’s got a new one out called Madness Is Better Than Defeat. Seems apt.


Certainly never send me any email here: gerald@fuzzjunket.com.