systems_glitch

You sure do forget all the little tricks and keyboard shortcuts in a hurry! Don't trust bulk pack bargain bin CD-Rs with important data?! I've got a few spindles of Verbatim archival grade stuff for work and really important permanent backups. Stuff that changes some times gets put on Magneto-Optical cartridges.

Oh man, board layout with AutoCAD We had some legacy products at previous jobs where the layouts were all AutoCAD from back in the DOS days. Using a real EDA tool makes life *so* much easier!

That's the approach I go with -- small, highly portable laptop, let the desktop do the heavy lifting. Works out being cheaper anyway, since you can get beefy off-lease workstations for good prices. My poor Lenovo X201 laptop is nearing retirement though!

Ouch! You can tell the iMac's thermal management was definitely designed to try and keep the fans off. The ones at the office got uncomfortably hot on top before the fans would come on. I guess most iMac owners don't use them the way programmers use them, or something.

Hah, true! I had a Shuttle XPC with a Core 2 era Xeon in it that would do basically all development-related tasks faster than our first gen i7 iMacs at work.

link to the Hack a Day article: http://hackaday.com/2017/01/19/autodesk-moves-eagle-to-subscription-only-pricing/ Feeling pretty good about that decision to move to KiCAD with the 4.0.0 release

Yeah, not sure what the posting of the bill is about. I can't speak for Vonage in particular, but with other ATAs like the Digium IAXy, the conversion from pulse is done in the ATA itself. In the case of the IAXy it leave as IAX (Inter-Asterisk eXchange) protocol, which encapsulated the voice stream, digits dialed, et c. I don't know if there are FXO boards that would then allow you to convert digits dialed into pulses for a line that only has pulse service, but if there was you could probably effectively do pulse in -> pulse out. If such a thing existed, you'd also end up doing DTMF in -> pulse out.

Finally decided to get MPLAB X up and going on my Slackware workstation, so I can pull the SSD out of my laptop and do a clean install on a new SSD. MPLAB X is NetBeans based and mostly Java, but apparently there are some system libs that are 32-bit x86 only Up til now, I just used it on my Arch Linux install on the laptop, since Arch makes multilib pretty painless. Slackware64 is "multilib ready," but does not include multilib stuff in the base install -- this gives you a clean 64-bit Slackware. I've never needed multilib under Slackware before, turns out it's not difficult. I followed alienbob's multilib guide: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib Beware that the mirror he gives is *very* slow, I ended up letting it run overnight. It worked fine, and provides everything you need to run MPLAB X (some GCC libs, X libs, et c.). Decided to do a proper SlackBuild and make a package. It's not been accepted to slackbuilds.org yet but you can find it here: https://github.com/chapmajs/mplab_x_slackbuild

Since getting the HP 420 squared away with a proper mirrored ZFS volume, I've been working on getting to the point where I can shut down my old workstation, which was still limping along running a few applications, like my Dynamic DNS widget. I needed somewhere to run things like the Dynamic DNS system, and leave a tmux running for persistent IRC. I don't have a server rack up yet, so my old VM hosting box is currently offline. It's really too loud to run out in the main workshop area (you can hear it upstairs, the workshop is in the basement). Until then, I dug into the junk bin and put together a server: The case is a massive Lian Li aluminum ATX server case. I picked it up at a local tech surplus auction for, I think $10, with a power supply and a DVD drive. It looks kinda silly with so little hardware in it: The motherboard is an Intel Desktop Board DP43TF from a machine I built in probably 2009 and dismantled in 2010 or 2011 -- it developed a RAM error and I stole the Xeon CPU out of it to use in something else. The CPU is an Intel Core 2 Duo E4300, 1.8 GHz LGA775, 2 MB cache, that came from a computer we found in the trash that had exploded motherboard caps, but a good CPU and RAM. Power supply came from a friend's junk PC that I was given when he replaced it. There's no onboard video on the DP43TF so I've got a GeForce 8800GT stuck in there for the console at the moment 8 GB DDR2 came from another junk PC someone gave me. DVD drive and WD RE4 250 GB drive were on the spare parts shelf. I updated the BIOS to the 2011 release (was the original 2008 release) which is supposed to improve stability. It's currently running OpenBSD 6.0 AMD64, with various applications deployed to it with Capistrano (manages your deploys over plain SSH). Telephoney is going to send me a less power hungry PCIe card with VGA so I can get the GeForce 8800 out of there! I've though about finding another Xeon X3360 (quad core, 12 MB cache) for the board -- that's what I originally ran in it, and it's the fastest thing it will support, but it doesn't really seem worthwhile since this box is pretty old and should be temporary anyway.

I forgot to run `lilo` after a kernel update, and finally powered the machine off last night for some rewiring, so this morning it kernel panic'ed on boot and I took the opportunity to redo the system with proper drives and configuration -- I just transplanted the disks out of the AMD Bulldozer machine, so it was booting off of a 128 MB boot partition (on a 1 TB drive, lol) and using a SSD as root, since the Bulldozer box's BIOS couldn't boot M.2 PCIe SSDs directly. New config: * Upgraded to BIOS 3.91 for M.2 boot support * Samsung SM951 M.2 SSD PCIe x4 128 GB * 2x WD RAID Edition 4 250 GB SATA drives * UEFI boot/UUIDs for disks * Slackware 14.2 x86_64 * ZFS on Linux, 1x mirrored volume across the two SATA disks BIOS update was the hardest part. The BIOS on the z420 will let you flash updates through the BIOS menu itself -- no having to come up with a DOS boot disk or anything. I didn't have a USB Flash drive around, so I tried with a CF card in a multi-card reader, which it didn't like. You can use a CD, too, so I dug out a spindle of CD-Rs only to get an unhelpful message about the BIOS image being missing or corrupt. Turns out the CD must be in the drive when you power the machine on! I had to clear CMOS settings using the little yellow reset switch on the motherboard after the update, it locked up after counting RAM. Slackware + UEFI was easy, I'd never done it before. The only "challenge" was that `cgdisk` had some issue where it was complaining that the console terminal wasn't at least 80x14, so I had to use `gdisk` (GPT version of `fdisk`). You of course use `elilo` instead of regular `lilo` with a UEFI system. Slackware's setup was able to successfully insert a Slackware entry into the workstation's EFI menu, so if I punch ESC at boot-up Slackware is now listed as an option, along with CD/USB/Network/et c. So, it boots directly from the M.2 SSD without having to have a boot partition on a SATA disk, and as a bonus, the BIOS update seems to have fixed my flaky SATA channel issue (I could run the SATA 3gbps channel in IDE mode, but AHCI mode would intermittently not boot). Ended up using GPT UUIDs for mounting the root disk, since adding the two WD drives threw off the boot order. Again, this is really easy, you add it to `/etc/fstab` and `elilo.conf` and that's it. ZFS on Linux was the usual simple Slackbuild install, I already had the packages built so I just copied them over from the fileserver. New install is working fine, and it's nice to be able to offload files to a mirrored ZFS volume, and keep the SSD free for stuff that actually needs fast access/high bandwidth. Plus now I can put the side cover on

So, one of the things with Puppet/Chef/Ansible/Salt, et c. is you get a base configuration set up, and you work off of that. A quick way to get up and going is to play with Vagrant, which includes many premade generic "boxes" (VM appliances, whatever you're used to calling them): https://www.vagrantup.com/ We usually skip Chef on our development VMs and just use the command line provisioner -- you just script it like you would a regular bring-up before all of these devops tools were available. Our VMs that use Chef in production are written with Vagrant first, though, so we not only have a same-as-production VM to develop against, but we also don't have to use a remote VM to get the Chef recipes tweaked. I don't know if it's just us, but it seems to me that every time we Chef a VM, it takes an order of magnitude more time to get the Chef scripts just right as compared to manually deploying the same number of machines. I guess the benefit is repeatability and documentation. It often seems like these tools are trying to solve social/organizational problems with technology, which ultimately I think is doomed to fail. Yeah, dumping legacy tools is frustrating. I like that both Slackware and Arch provide a replacement for `ifconfig` -- I don't know if it's the old code or merely a wrapper around `ip`. I find `ip` syntax to be kind of obtuse. It feels like it tries to do too many things.

Apparently someone else thought about this a few years ago, but I was working on my Dynamic DNS project last night and thought, how many websites grab DNS or reverse DNS information and just pass it to the browser, unescaped? Apparently nonzero: https://dig.whois.com.au/dig/hax.bv.theglitchworks.net Click the button The following site works for both forward lookup on hax.bv.theglitchworks.net and reverse lookup on 2001:470:1f07:b75::1337 http://www.webdnstools.com/dnstools/dns-lookup-ipv6 Another example of how no external data should ever be trusted!

GlobalProtect can die in a fire. A client required that we use it for remote access, nothing but problems. They used RSA tokens with it, we pretty much lost sync on at least one token during the course of a week. We use OpenVPN for everything we control at work. We've integrated it into a few clients' applications so they can manage certificate generation, revocation, and emailing of "click to install" config packages.

Layering is for sure the way to go. It also lessens the load on your border firewall. Host-based firewalls make host-based blacklisting far simpler -- you don't have to try and dynamically control firewall rules on another system.

https://irssi.org/2017/01/05/irssi-1.0.0-released/ Guess that means it's done