openSUSE Tumbleweed Part 4 / openSUSE Leap 42.1 Milestone 1 / Manjaro Part 2.75

I'll apologise ahead of time for bouncing between Tumblweed, Leap, and Manjaro; I'll try to make it evident which I am talking about.

So far I've installed and updated Tumbleweed and at the moment I'm waiting for the other packages to install (VLC, K3B, etc).

It does seem like I would have gone with Tumbleweed had I thought about it, but since I haven't been able to preform any real testing, I can't say anything for sure right now.

Also, while I was browsing around yesterday, I saw the upcoming release of openSUSE is called "Leap" which will have the SUSE Linux Enterprises (SEL) at its core and allow security updates directly from them. In other words, I have another version of openSUSE to test out once it's downloaded and I've finished my testing for Tumbleweed.

Oh, one thing I forgot to mention with the first Manjaro Linux post is that I figured out what the weird "fourth" button (the one second from the left) on the volume/user/etc menu is. It's meant for devices with accelerometers, in other words, it's to allow/lock screen orientation. I figured this out when I updated from GNOME 3.14.x to 3.16.2, as the circular arrow was replaced with a tilted rectangle with a curved arrow, and when I clicked on it, the arrow became a padlock. Mystery solved.

Back to Tumbleweed, I just tried a video file in VLC and it gave me the error message that it could not decode h264; I looked in zypper and found there weren't any h264 codecs at all. Looks like I'm going to have to add the repository from Packman and test again.

When I booted into Manjaro, I saw that I had GNOME 3.16.2 and not 3.16.3 that I updated to on Melty, which gave me problems. As much as I wanted to update it and test to see if it broke on Triela, the Tumbleweed testing came first (kinda hard to update GRUB if the target system isn't usable. Sure I could use mhwd-chroot and do it, but that requires booting into a live version of Manjaro to do - so why take the risk if it will just complicate things?

Tried VLC again in Tumbleweed with the same message, but this time, h264enc was in the repository. Oh how long it's been since I've had to do this sort of thing... I should pull up caf's guide, but at the same time, I don't really want to. Luckily, it worked without any problems.

Decided to try an mp3 and I'm glad I did, as supposedly the plugin wasn't installed, though zypper tells me something different, I decided to install gstreamer-0_10-plugins-fluendo_mp3, but it didn't seem to help, so I tried removing pullin-fluendo-mp3 which also didn't work. I then noticed that gstreamer-0_10-plugins-fluendo_mp3 replaced gstreamer-0_1-fluendo_mp3, so i reinstalled gstreamer-0_1-fluendo_mp3, but that also didn't work.

I decided to used caf4926's guide (from 12.3, but it's not like the packages are any different), and after getting it all installed, I was able to get mp3 playback.

So yes, Tumbleweed is quite viable, but as I mentioned twice before now, I'd rather yaourt than have to go through the trouble doing it "manually" (plus, I'd probably have to put some extra effort into FreeFileSync, since it's meant for 13.2 atm). So with this, I conclude Tumbleweed's test, and now I move onto updating Manjaro.

---

It took a bit longer than I wanted for Manjaro to update, but I was able to reboot back into it without any problems. What's weird is that the screen orientation button has reverted to the circular arrow... Since I know what it is, it won't bother me any.

I suppose I'll stick with GNOME on Triela for now, since I don't feel like going through all the hassle to reinstall/reconfigure Manjaro... I might be able to install XFCE and remove GNOME (I found instructions for going from XFCE to GNOME on Manjaro's wiki), but I think a reinstall would be less of a headache to be honest.

Tomorrow I will test openSUSE Leap 42.1 Milestone 1, since I'm still waiting on the download.

openSUSE Tumbleweed Part 3.5 / Manjaro Linux Part 2.5

With my Manjaro Linux post, I got a comment on Google+ (because I have blogger set up to post the blog entry to G+ once it's posted) asking why I didn't try openSUSE Tumbleweed. I explained to him breifly of the issues I had before and told him that I will give Tumblweeed another try since it's been quite a few months when I last tried it.

At this moment I already have downloaded and burned the Live GNOME Tumbleweed (x86_64) to a DVD+RW and plan on doing a test install on Triela's testbed partition tomorrow after work.

I'm thinking that the VLC codecs are going to be a problem again, but it is part of my test procedures, so we will see what happens.

If the test's successful, will I move to Tumbleweed from Manjaro? As much as I would like to, I'll probably be sticking with Manjaro because of the Arch Linux User Repository (AUR), which allows me to build FreeFileSync, Skype, and Atom (text editor) from source. With Tumbleweed (and even openSUSE), they would be .rpm files I'd have to download and "install" - with the exception of FreeFileSync, as it's able to run on it's own without installation.

So even though I'm quite set on Manjaro, I will keep my word and try Tumbleweed out.

---

One thing that I forgot to mention with my previous post is that I've gotten quite used to pacman and yaourt in terminal, confirming my theory that learning pacman would be fairly easy to learn since it's similar to zypper (yaourt works the same as pacman, but it's for building packages from the AUR).

Manjaro Linux Part 2

Last night I decided to forego the installation of Manjaro onto Melty, which went well until I rebooted after getting the updates. I reinstalled 3 more times after that, doing different things to try to figure out the problem, which was most likely GNOME 3.16.x. Being tired from spending approximately seven hours with it, I grabbed the Manjaro XFCE disk before getting some sleep.

This morning, I stuffed the ISO onto my Linux stick, but somehow the kernel was missing, even after trying writing the ISO again along with trying it on the Dell. I ended up just booting into Windows and using Unetbootin to write it to another flash drive, which tested well on the Dell (GRUB was just a bit strange with "Default" as the first option which didn't seem to do anything).

Installation went just fine, but that obviously wasn't the issue, and while I let it update, I kept system configurations to a minimum, so that if it did break, I wouldn't have lost too much time.

As the screen went from the Manjaro splash screen (which is similar to Ubuntu's, but with green dots instead of orange ones) to XFCE desktop, I held my breath a bit as I hoped that it would be fine, but expecting it to break at the same time. Fortunately, nothing happened and I was greeted by the desktop and panel.

I began installing other programs and getting the settings configured, and tried the XFCE theme I usually use for Pi2, Taiga, and Sae-chan, which made me very slightly cringe as it was a light theme. When I was able to, I began looking for the authors of the theme to see if they had anything dark, and I was able to come across it somehow (I was between DeviantArt, Google, and xfce-look.org).

I first grabbed Ambiance Blackout Flat since it was what I was looking for and RAVEfinity was definitely reliable, since they made the pink Radiance theme that I use for Pi2, Taiga, and Sae-chan. I then grabbed Vivacious Colors and Vibrancy Colors GTK icon themes, seeing that I wanted something else besides the "M(something)-circle" icon theme that was default upon installation - it's an interesting set, but I wanted something that was a bit easier to see against a dark theme (though the default theme was dark anyway).

I really liked the application icons of Vivacious, but liked the folder colours of Vibrancy, so I decided to hack the two together and it worked out okay.... Until I cleaned up the lot of extra themes, which ended up breaking the icon theme without my knowledge. After "finishing" with that, I decided to look at Ambiance & Radiance Flat, since it was essentially an "updated" version of the Radiance theme (I like flat themes, and I don't know why). I took a quick look with Melty and didn't really notice much different, but got everything packed away and uploaded to the Pi2 and the NAS before downloading it to Sae-chan to install it.

It was when I watched the scrollbar flatten that I noticed the difference, and when I looked at the icon theme change, the folders worked, but not the application icons. I then looked on Melty and noticed that the application icons weren't like I remember them. While trying to figure out what went wrong, I found that Vivacious actually did have extra folder colours, but as an add-on pack, so I downloaded it and gave it a test, which didn't make any difference to the icon theme I hacked together (this is technically a good thing), but the application icons were still not there.

It took quite some time, but I found a note in small print on the Vivacious Colors page:

(!) Folder Color Add-on Requires Main Theme to work!

Oh. That explains why the application icons disappeared. I downloaded the main theme again and extracted the "Vibrancy-Colors" folder to where I needed them (in the light/dark XFCE themes I was building and on Melty, so that the theme wasn't broken any longer), double checked the theme, and repackaged the themes yet again.

Unfortunately, it didn't make any difference on Sae-chan, so I just let it be and shut her down, but at the least, I was finally done with the theme.

I finished the rest of the setup, which was just my usual bout with commonly-used applications and their settings.

As to why I haven't a problem with GNOME 3.16.x on Triela but on Melty, I haven't a clue, but I don't mind XFCE at all, since I've already been using it for quite some time. I'm thinking that Lie-chan won't have any problems either, but it's too early to say as I haven't taken the time to update her yet.

Will I be switching from GNOME 3 to XFCE entirely? I can't say, but I think the window managers I used will more than likely be splintered if I don't go with one or the other... Now that I think about it though, I might go with XFCE because the theming is a lot simpler than GNOME (the theme I use for GNOME is a tad bit broken and the XFCE theme is solid, not to mention the "Smallscreen" window border is much thinner than the one I hacked together).

Things I've learned:

• A good testing involves updating all the packages before drawing conclusions on usability
• Keep configurations to a bare minimum during a full testing phase
• Look for and read the fine print on themes
• I like RAVEfinity a lot more than I thought I did? (XD)

Manjaro Linux

Recently I've gotten fed up with having to test/install new versions of openSUSE (and/or debian), and decided to take a look at true rolling releases, but unfortunately it came down to Arch and Gentoo. Since I had a bit of experience with Gentoo, I wanted to avoid it, as nice as it would've been for the machine to run a kernel compiled for it, and so I ended up taking a look at Arch Linux. Unfortunately, Arch Linux isn't much different, and while I wouldn't mind going through all the steps, I also had to think about how many machines I would need to install on (about 6-8), and while the time it takes to install on each machine differs, it's a lot of man-hours I'm not willing to put in while I'm working full-time.

Eventually I looked around, and on a forum, someone else asked a similar question (they were looking for something Arch-like, but simpler), and I ended up checking out one of the two suggestions, which was Bridge Linux. Bridge Linux broke itself on the test hard drive after installing, so it was quickly ditched and so I checked out the other suggestion of Manjaro Linux.

Manjaro was a bit wonky when I tried to put it on a USB drive, so I ended up just writing it onto a DVD+RW instead. The initial test worked well, though during installation on the test drive, the screen turned off and locked, and something glitched out, which resulted in a broken picture. Luckily I was able to reboot and get into the system, but sometimes I'd get the "No operating system" message from BIOS, which was fixed by recycling the power (I think that drive has a faulty MBR or something, would explain why my friend had problems with it).

On the test partition of Triela's actual drive, I decided to not install GRUB2 from Majaro, seeing as that I didn't want to change the options from Manjaro if I were to ditch it, but I wasn't able to boot into Manjaro, so I had to do it anyway (without reinstalling Manjaro).

There were a lot of surprises with Manjaro, one being that I am able to use the user repository for Arch Linux (Arch User Repository or AUR for short), which allowed me to build and install Skype, FreeFileSync, and Atom (text editor) from the package manager. Another surprise was that I wasn't able to find the proper config file for the NTP hosts that Manjaro uses to update the time, so I'm not able to add a custom server (at least for the moment). I was surprised that I had used pacman before (probably for Sabayon), and after looking at the help, it seems that it's quite similar to zypper in simplicity, so it shouldn't be too hard to learn (compared with apt-get for Debian which becomes apt-cache for when you want to search for something...). A very nice surprise was that Manjaro doesn't make Triela idle hot like openSUSE does.

I tested Rhythmbox out and found that the random-crashing problem still exists, though (if I remember correctly) I don't think it had to do with cairo this time, so I decided to stick with Clementine as I have been.

After completing all the necessary tests on the test partition, I backed up all the files I needed to back up in the home folder of openSUSE before I went through with the install of Manjaro.

So far the only issue I've ran into with Manjaro on Triela is that Firefox would glitch GNOME out, but usually only for a second, but I found that it was just kernel 4.1.2-x that was causing the problem and just downgraded to 4.0.x instead.

For Lie-chan, I found that (for whatever reason) GRUB2 from Manjaro and the GPT partitioning table don't play along nicely (I wasn't able to boot into Manjaro at all), and so I had to change the partition table back to MBR (losing the copy of my music library in the process) and reinstall. So far, Lie-chan only has an initial installation (with the keyring being the only upgrade I think) and I haven't been able to test out VLC on her like I normally do (the video file I use for testing also got wiped), but I'll eventually get around to getting her up to date and fully tested. So far the only issue with Manjaro on Lie-chan is with the Sound Blaster sound card, but it might just be the fact that I haven't updated yet - we shall see.

I definitely will migrate my x64 computers (and maybe Ziggy though he's x86) eventually, but it'll be a slow processes.

As far as the 2(DrivePi) and Sae-chan goes, I'll probably sit through the Arch Linux installation with each of them, since I probably don't have much of alternative for them.

I may still test openSUSE from this point forward, but by no means will I have an installation of it that I will frequently use. As I make the transition to Manjaro, I will (figuratively) say my farewells to openSUSE. openSUSE has been good to me over these past 5-6 years, but it's time I move onto a true rolling distribution, so I'm not installing the new version of openSUSE every release cycle.

Fun fact: the distributions I've stuck with for a good amount of time all have a green theme to it (Linux Mint, openSUSE, and now Manjaro)... Maybe something trying to tell me something. (XD)

Website Adertisments Part 2

About a couple weeks ago, I wrote about blocking website advertisements, and about a week ago, I came across another article on it (Why Adblocking is the New Speeding).

I only wanted to revisit this because the author makes a very valid point:

.... Like pretty much everyone else on the outside three lanes of the four-lane motorway, I was over the speed limit.
And what happened? Nothing. I carried on going above the speed limit. Many of us that day were breaking the law. And nothing exceptional happened. No police stopped us. We broke the social compact – the one about obeying most laws – without compunction. None of the people on that motorway that day had an accident there, so is speeding harmless?
It’s also a fact that around one-third of car accidents can be ascribed to excessive speed. Going too fast is highly correlated with accidents.
Yet we ignore it. And we speed. ....

  Just like speeding, people that block ads are going to continue to block ads because there isn't really much immediate consequence to do so.

Similarly, there’s no retribution for adblocking. Nothing happens when you do it, except you get a better experience. Ditto for speeding: you get where you’re going sooner.

The only thing I disagree with this statement is that for speeding, you do get where you're going sooner (results differ a bit depending on distance if you're doing it on the highway or in the city), but the main consequence is that your gas mileage becomes worse above a certain speed (supposedly it's above 55mph, but I think it depends on other things, really). But it is what you intentionally give up to get where you want to sooner.

That was all that I wanted to revisit this topic for.

Cherry MX Ghetto Super Green Keyboard Modification.

Friday, I received the Cherry MX Blue and Cherry MX Gray switches that I ordered to make some Cherry MX Ghetto Greens (a proper Ghetto Green with 80cN force instead of 60cN) to make it harder to accidentally press certain keys (caps lock, scroll lock, num lock, insert, right shift, right click menu) across the two mechanical keyboards that I have (Logitech G710+ and Cherry MX-Board 3.0).

I found that it was quite easy to swap the parts around, but then found that the actuation force didn't seem to be enough for me when I tested the switch between my fingers. I was a bit unhappy with the results before I realised that I could double-up on the springs to get a stiffer response (at the cost of increasing the compressed length). I first tried the blue and the grey springs together, but it didn't work well because the blue springs had more wraps than the grey ones. Obviously, I tried two grey springs and it worked decently well (I think I had to play with it a bit), besides that it was quite stiff (160cN).

I then ran into another problem, I had only ordered 25 switches of each type and I was needing to modify 16 switches total; I was about to get back onto Allied Electronics's site before I realised I could drop 5 switches total. Originally I had planned to modify the super keys (aka Windows key), but since both keyboards have a way to disable the keys, it was an easy way to drop the switch count. I also decided against modifying the right click menu key on the Logitech G710+ keyboard, since the button that disables the super keys also disables that key as well (obviously not the same case for the Cherry keyboard). I then put together the ghetto super green switches together (11 of them total) and set them aside until I was actually able to work on it.

I began working on switching the switches this morning, opening up the G710+ first, as I remembered having difficulty opening it when I was checking it out a couple months after I first bought it. Fortunately, it disassembled quite easily, and I was able to remove the cable for the volume roller, since it's something I never use. The entire time from Friday, I was a bit worried about de-soldering the switches, but remembered that the LED is separate and the tough part would be the switch itself.

At first, I tried to heat up both switch legs simultaneously and also hold onto the plate retention latches to pull the switch away from the plate - needless to say it was a bad idea and didn't work at all. I then decided to try the de-soldering braid on it, and it worked very well to my surprise; I replaced one switch at a time for two switches before doing a step at a time for the remaining three.

The Cherry keyboard was much easier to disassemble, since the keyboard has a detachable cord. It also uses (zener) diodes, but since I was just using the de-soldering braid, it didn't slow me down any. The only trouble I ran into when making the modifications was that the top housing piece of the switches with the LED (the three locks) has a sort of "extension" (presumably to help guide the legs of the LED), and it wasn't compatible with the switch with the diode in it - this was quickly remedied by pulling out the switches with the LED (which hadn't been soldered in at the time) and removing the top housing piece to find the correct one (luckily on the first try).

Since the MX switches I ordered were for PCB mounting (and not plate mounting), the bottom of the housing has a couple extra pegs, which I could have cut off, but I went for just putting the spring and stem into the switch I pulled from the keyboards.

It is very extremely obvious if I'm trying to hit the key by accident, as the force I use to activate keys isn't too much (I'm going to estimate about 45cN, since that's the force required for brown and red keys). I'm quite pleased with the modification, as I won't have to worry about hitting those keys by accident and causing some sort of undesired operation.

Before I begin showing pictures, I'll go into a bit of depth about why I disabled each key.

• Caps Lock: I disable this because I very rarely use it. When I used to use Logitech's Illuminated Keyboard (K740, Y-UY95), Set Point allowed me to disable the Caps Lock key, which was very nice, but when I got the 710+, I wasn't able to do this with Set Point or the Gaming Software).
• Scroll Lock: I don't think I hit this by accident very often, but it is next to the print screen key, which I use on occasion. It's also a key that's hardly used any more, so why not?
• Num Lock: I normally keep it on, as I do use the 10-key for numeric entries, but sometimes when I try to hit slash (/), I'll accidentally hit num lock instead and screw up whatever I was trying to enter. The other reason is that it's the auto-run hotkey in Mabinogi and Mabinogi is programmed with the caps/num lock keys as toggles ("off" when Mabinogi's started, "on" when it is pressed outside of the chat box) instead of just reading the state of the keys (which would have been much smarter in my opinion).
• Insert: I strongly dislike this key when I'm... Rather I should say that overstrike text entry is highly annoying when trying to type things up, especially when it goes unnoticed for a while. That said, it's accidentally hit when I'm trying to use the delete key that's underneath it
• Right Shift: When I learned to type, I never made a habit of using the right shift key for the three left pinky keys (Q, A, and Z) and instead adapted by rotating my hand at the wrist so that my ring finger would hit those three keys while my pinky holds down the left shift.
• Right Click Menu: I'm not sure what this key's supposed to be called, but it's (usually) the one to the left of the right control key. I haven't hit this on accident from what I remember, but it's a key that I've only used a few times in my life, so might as well just modify it anyway.

Cherry MX Blue and Cherry MX Grey, comparison of the plate-mounted bottom housing and PCB-mounted bottom housings, comparison of the brown stem and spring with the blue stem and doubled grey springs.

Doubled spring sitting in the housing, blue stem sitting on the spring, completed plate-mounted ghetto super green.

Fully mounted and soldered.

One other modification I did before this was get some o-rings to change the travel distance of the keycaps, putting two of them on each key (for most of them) so that it would stop the key from travelling further than the necessary actuation distance. Unfortunately, I had to remove one of the rings from certain keys because either I don't use enough force to press the key down for those specific keys, or the total ring thickness is just slightly more than the actuation distance.

If you want to modify your mechanical keyboard, go for it (as long as you have a puck of 1mm de-soldering braid) because it's actually a lot easier than it seems.

---

I redid the springs, read about it in this post.

LED Tester (Version 3)

I took two outdated boards from work (the newer version of the board has solder pads for an added SOT-23 diode) to make one of them into a LED Tester. For quite some time, I was using was an old project box from Radio Shack, one of the 8-pin IC holders and a 2-AA battery holder to test LEDS.

Part of the reason why I didn't like it was that it required batteries, another part was that it's a lot bulkier than it needed to be, and the last is that the IC holder is meant to be put through a perfboard and not a plastic box.

The newer version of the board was being used for the prototype of a different project, but the electrical engineer decided to add some more parts to it to reduce the load of the voltage regulator on the main board. When he received the prototype boards, I was to remove the board from the main board and toss it into the electrical waste bin.

With a fully-functioning LM317 on the board, there was no way I could do that, so I (painstakingly) de-soldered the voltage regulator and one of the 8-pin headers from it before storing the board elsewhere if i needed the other parts from it.

One of the two outdated boards I took home already had parts on it (I didn't realize it was an outdated board until I noticed the missing diode (how I missed it when I was putting the SMD parts on, I haven't a clue) and brought it to the attention of the electrical engineer, who told me it was the older revision of the board (the board that superseded it has ".B" marked with the part number). I had left it alone, since I didn't want to just toss it in with the electrical waste, so I held onto it until I needed it.

The board is the board that sits between the main board and LCD panel (that is made by some other company that we purchase), and was going to be much easier to use than the old prototype board that I used for the adjustable voltage regulator project because of the "built-in" spot for the LM317.

The first thing I had to figure out was what voltage to output so that an LED with a 3.3 volt forward voltage and an LED with a 1.6 volt forward voltage can agree on. With the adjustable voltage regulator, I toyed with it a bit before doing some maths to find that 2.5 volts should be a decent median for both types.

The initial test was fine, and I found it quite nice that it was the exact same resistor value needed for 2.5 volts (Vout=1.25 * x/x), so whatever I was able to find (between 100 and 1k ohms) for the power LEDs would work just fine.

The board has three spots for LEDs, one for power, one for use indication, and one for reversed power. For my case, I only needed two of the three LEDs, but I figured I might as well use all three; I set up the central LED to be the power and the outer LEDs to be a reversed power indicator (so that it's quite obvious if the LED testing board is plugged in "backwards".

With some calculations, I figured I'd need a resistance of about 500 ohms for each of the power indicator LEDs (since I'm running it off of 12 volts), so my best bet would be to either find a resistor close to 500 or to put two 1k ohm resistors in parallel (which is theoretically easy with SMD). When I dug around at the unused parts during lunch, I found the 1k ohm resistors and held onto them as I dug around more. I then found a 700-something ohm resistor reel (remember, this are SMD resistors) before finding 600-something ohms, but then I was quite elated when I found 475 ohm resistors and proceeded to put the other two reels away.

On the board, the two outer LEDs use SMD resistors with a 1206 case code and the centre one uses 0805, which was something I was partially looking for, but because I was able to use the 0805 sized resistors in the 1206 slot, I didn't have a need for the 1k ohm resistors that I brought home with the 475 ohm resistors.

I soldered most of the components onto the board and soldered the LM317 on the "wrong side" (but in the correct pin order) to make the bottom as minimalistic as possible. The next day I thought of adding some diodes to protect the circuit and LEDs so that when the board is hooked up incorrectly, the voltage regulator circuit is protected, and when the board is hooked up correctly, the reversed polarity LEDs are protected. After getting home, I added the diodes in and hooked up the jumper wire to make it work and it did indeed work.

Except for one little problem: the LM317 became really hot even though the output voltage was correct. When I soldered the LM317, I soldered it so that the plastic side was against the board and the tab was in the air, and so I though maybe I needed to actually solder it to the correct side so that the pad on the underside of the board can absorb the heat. I moved the LM317 to its correct position on the board, but nothing changed, it was still getting hot.

I poked with the adjustable voltage regulator project and the tab didn't get hot at all - not even slightly warm - and so I decided to think for a bit. I decided to double check the power path and found that I had not added the jumper wire that connected the ground to the actual ground pin, and after remedying the problem, all was well.

I forgot to mention that I put some header pins into the unused ports of the header to make it obvious which of the header holes to use. I also marked an arrow on the board pointing toward the positive hole, but since it is on the "outside" side of the header, it can't be seen in the following pictures.

Finished top and bottom.

Board has power and is plugged in correctly; board has power, but has power is reversed; board showing an LED being tested.

I forgot to cover the point of the device (and it's convoluted predecessor), which is to test if LEDs are working (which is probably fairly obvious) and to be able to discern the LED's colour (for clear or frosted LED cases). Before having a case that allowed me to organize my LEDs by colour (and case type), it used to be thrown together in a section of another case. This obviously made it horrible because I had to check the colour of the LED every time I needed one.

The first version of the preceding LED tester used a 9 volt battery, the project box, a resistor, and the IC holder - it did the job when I needed it. Eventually I changed it so that it ran off of a pair of AA batteries so that it would be easier to replace the batteries (whenever that would happen) and to reduce the voltage delivered to the LED being tested greatly. For the second version, I also added one of those plastic battery pull-tabs that come with some electronics with pre-installed batteries, so that the drain on the batteries would be further slowed down from air-based discharge (probably really unnecessary, but why not?)

While preparing an LED for the picture, I blew up a dual-coloured LED that was going to be used for my soldering light/fan switchbox, but luckily there were plenty spares at work, since it no longer being used.

The diodes I used are the 4007 (the one further away from the header) and the 5817 (one closest to the header) since that's all I had at home that would be easy to use.

The things I learned from this project is to check the paths before checking the parts, and to keep the LED in the tester for the minimum amount of time so that it doesn't blow up.