Pi-hole is a DNS sinkhole designed to block ads at the network level by acting as your DNS server; it’s like using AdBlock for every device on your network. It’s especially useful for iOS and Android devices since Pi-hole can block ads in both the browser and apps.
Installation on my Ubuntu 16.04 box was dead simple:
curl -sSL https://install.pi-hole.net | bash
After running it for almost a week, I accumulated the following stats below; it’s amazing how many requests were blocked since I’m already using uBlock in Chrome.
After rebooting the system Pi-hole was running on, I noticed the DNS resolution was broken because the dnsmasq service was not running:
samfisher@Skullbox:~$ service dnsmasq status
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2018-08-05 16:24:18 PDT; 19s ago
Process: 864 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=2)
Process: 835 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
Aug 05 16:24:18 Skullbox systemd: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Aug 05 16:24:18 Skullbox dnsmasq: dnsmasq: syntax check OK.
Aug 05 16:24:18 Skullbox dnsmasq: dnsmasq: unknown interface eno1
Aug 05 16:24:18 Skullbox systemd: dnsmasq.service: Control process exited, code=exited status=2
Aug 05 16:24:18 Skullbox systemd: Failed to start dnsmasq - A lightweight DHCP and caching DNS server.
Aug 05 16:24:18 Skullbox systemd: dnsmasq.service: Unit entered failed state.
Aug 05 16:24:18 Skullbox systemd: dnsmasq.service: Failed with result 'exit-code'.
Apparently there is a bug in Ubuntu 16.04 with the dnsmasq service trying to start before network interface is up. Thanks to this, I was able to fix it by adding the highlighted lines below to the [Unit] section of /lib/systemd/system/dnsmasq.service:
sudo vi /lib/systemd/system/dnsmasq.service
Description=dnsmasq - A lightweight DHCP and caching DNS server
Recently I managed to get my hands on the GDEMU – an SD card reader that takes the place of the Sega Dreamcast’s optical drive. With it you can place multiple Dreamcast game images on an SD card and load whatever game you want from a simple menu system named GDmenu. I set mine up with a SanDisk Extreme Pro 128GB SDXC and was able to fit all the games I cared about. The best part is you can play 1:1 dumps of Dreamcast games instead of burning rips to CD-Rs or scouring eBay for original discs. There is a noticeable decrease in loading times as well since there are no moving parts.
In addition to the GDEMU upgrade, I also replaced the original 30mm Dreamcast fan with a 40mm Noctua NF-A4x10 5V using a 3D printed mounting kit I bought off eBay (listing is gone but you can find the files for the kit here). Supposedly the Dreamcast runs hotter with the GDEMU because the GDEMU doesn’t use the 12v rail on the PSU which causes it to spike in voltage thus creating extra heat. There are some guides on the internet for either adding a resistor to load the 12v rail or removing the regulator for 12v entirely. I decided it was simpler to add a 12v fan for load and provide additional cooling to the PSU; I put a 40mm Noctua NF-A4x20 FLX in the back blowing into the PSU. Even with 2 fans, this entire setup is nearly silent compared to a stock Dreamcast.
I’ve been working on a new emulator build using Windows, Launchbox, and Retroarch. For my controllers I’ve always used Qanba Q4RAF sticks for arcade games and Xbox 360 controllers for consoles. I decided it was time to upgrade the controllers to something newer so I decided to pick up the 8Bitdo SF30 Pro and SN30 Pro Controllers. They’re basically replicas of the old SNES controller in both the Super Nintendo (SN30 Pro) and Super Famicom (SF30 Pro) colors. You can find plenty of in-depth reviews of these controllers on YouTube or Google; overall I’m quite pleased with these controllers for emulation usage.
Some things I noticed:
- Everyone says to update the firmware out of the box; my SF30 Pro was already v1.25 (newest at the time of this post) but my SN30 Pro was v1.22.
- The D-Pad on my SN30 Pro feels more worn and isn’t as stiff as my SF30 Pro’s D-Pad.
- They pair quite easily with Windows 10 over Bluetooth; you can also use them wired (flat style USB-C cable is included)
- You can pair both the SF30 Pro and SN30 Pro to your Windows PC for multiplayer games; they show up in Windows as “8Bitdo SF30 Pro” and “8Bitdo SN30 Pro” respectively. Not sure what happens if you have 2x SF30 Pros or 2x SN30 Pros since they share the same device name.
- Works great with RetroArch; shows up as “Bluetooth XINPUT compatible input device”. If you have the SF30 Pro and SN30 Pro paired, then they will appear as “Bluetooth XINPUT compatible input device (#1)” and “Bluetooth XINPUT compatible input device (#2)”.
I recently did a clean install of Windows 10 on my primary workstation. After installing most of my apps again, I noticed that the search function in the Start Menu was only finding some of the applications I had installed. Instead of clicking on shortcuts to launch applications, I’ve grown accustomed to using Windows Key to search for the app I want to launch; a habit that stems from my time spent on a Mac using Command-Space bar to search for and launch applications. Not being able to find every app that is installed was very annoying; also puzzling since I had just done a clean install of Windows. In googling this problem, I found different answers regarding rebuilding the index cache, checking the Windows Search service, reinstalling Cortana, or deleting some registry key. I didn’t find a solution until I stumbled onto this Reddit thread – apparently if you disable background apps under Settings > Privacy > Background apps it prevents Windows Search from working correctly.
Funny enough, this answer is in the first result from my Google search above but I didn’t see it until I wrote this post; I just never bothered to scroll down far enough.
I successfully upgraded my Hackintosh to OS X 10.11 and it appears everything is working as expected including audio and Intel SpeedStep. I performed a clean install of El Capitan by using this guide; I was pleasantly surprised to discover that in 10.11 you can restore all of your applications/data/settings from a Time Machine Backup using the Migration Assistant. Initially I had trouble getting the new OS X installation to boot correctly; the Unibeast application used for making the installer has changed to the Clover bootloader. Clover has support for booting in UEFI mode and it seems some ASRock boards have issues booting from it. To fix this I had to create a manual entry for the Clover bootloader in my UEFI Boot menu; it’s not enough to just configure the drive as first boot device in the BIOS. I found the necessary commands thanks to the following guide (under section 4.1).
After booting from the Unibeast USB and selecting “Start UEFI Shell 64” you will be greeted by the following screen:
On this screen we have entries for FS0, FS1, etc. which are the partitions detected; we need to find the one that corresponds to the EFI partition of the drive where OS X was installed. If you look at the strings beginning with “PciRoot (0x0)”, you will see some of them contain “/USB”; you can rule those out since that is the Unibeast USB. For my particular system I found the EFI partition under FS2.
For example, lets enter the partition FS2 and check the contents:
If we see a directory labeled EFI in the ls output, then we’ve found the right partition. Now we get a list of the current boot entries with:
You should get output similar to the screen below; this is from my Hackintosh after I already added Clover to the UEFI Boot menu.
Use the following commands to add Clover to the ASRock UEFI Boot menu:
# X is boot option number, use 0 if you want Clover first, 2 for second, etc.
bcfg boot add X BOOTX64.EFI "Clover"
# check if Clover is really added
bcfg boot dump
After going back into the BIOS, you can change your first boot device to Clover and OS X should boot normally.