systems_glitch

https://irssi.org/2016/09/21/irssi-0.8.20-released/ Upgrade if possible, there's a Perl script to run otherwise. Slackware has updated packages out already, Arch Linux does not at time of posting. If you want to build from src until a package comes out, you can run ./configure --prefix=/home/you/bin && make && make install To build local. Obviously change the prefix path to something that exists

Yeah, when I go into full hack mode, chasing a bug or a weird problem or something, it becomes its own unpaid full-time job for a while. I do it because I like it, not because it makes me money. I don't like it enough to try to monetize it, that's why I'm still a programmer/hardware design guy for a day-job

As long as humans write code, there will be vulnerabilities. A safe career choice, if you like doing it.

I don't think there's anything wrong with it, I think I just had too high of expectations for it. It's a machine from 2011 that's known for having lousy single-core performance. It does compile C/C++ code *really* fast, with `-j18` in the MAKEOPTS. I may end up selling it to a friend -- paid a visit a few weekends ago, and apparently his VM server died, and he's been running his production VMs for his small business off a laptop! I was simultaneously surprised and not surprised that Gentoo was actually slower. I've maintained for years that there's no real speed advantage from Gentoo for most hardware situations, but I didn't think it would be that much slower!

So I added the Samsung SSD and got to pretty much equal run times with my AMD APU box. Obviously multitasking is still way more usable on the Opteron box, with all of those cores! As an experiment, I installed Gentoo and took care to optimize USE and CPU flags for the architecture. After a day of compiling and working around bugs/oddities, I finally got around to running the test suite I've been using as a benchmark -- it's 5 or 6 minutes *slower* with Gentoo I'm sure Gentoo experts will tell me I'm doing it wrong...

I'm pretty sure you're spot-on with the "expected to be using a GUI" remark. I think that's also why the firewalld syntax is as obtuse as it is. Not meant for anyone to hack at anymore. I guess it also doesn't matter if you're using some devops solution like Chef, Puppet, Ansible, Salt, or whatever. I definitely still prefer `ethX` naming, even the BSDs' convention of using $driver_nameX (e.g. em0 for Intel gigabit, vr0 for VIA Rhine), which I at first liked less than `ethX`, is better than the random string of garbage you get nowadays. At least the BSD approach provides additional useful info!

Pretty sure the interface renaming has more to do with systemd migration than anything else. It's supposed to be a unique identifier for the interface for...reasons? Also `ifconfig` is deprecated basically everywhere...I guess the distinction between a system that acknowledges legacy support and one that doesn't is whether the `ifconfig` compat shim is installed in the base system, or if the answer is basically, "fuck you, learn `ip` syntax." And then of course there's the transition to firewalld, which almost but not completely is capable of doing the same things as iptables, and apparently still uses iptables under the hood.

I picked up a 128 GB Samsung SM951 PCIe attached SSD, going to grab a PCIe x4 adapter for full bandwidth. That ought to rule out a disk bottleneck

So I'm against some sort of bottleneck which I haven't had time to identify yet. The full test suite of one of the day-job applications I work on runs significantly slower, but won't even utilize a full core. On my APU box, I was running a load average of 2.5 - 3 with all fans spun up. This sits around 0.75 load average. I'm wondering if it's a disk bandwidth issue, I currently have the 1 TB Hitachi/HGST SATA drive in that shipped with the machine. Thinking I'm going to order a Samsung M.2 SSD and PCIe adapter bracket, I wanted to upgrade to SSD anyway. Direct PCIe attachment will rule out any disk/controller issues. I knew getting into this, from our server deploys, that single-core performance wasn't awesome with these CPUs, but not even being able to load down a single core seems like something else is my bottleneck.

I moved away from it for a while due to everything being locked to "stable" versions, which back then meant old. It seems like Slackware is really keeping up nowadays though, certainly ahead of what RHEL/CentOS ships with most of the time, and IIRC ahead of stock Debian too. That's tracking release branches, not -current.

Slackware64 14.2 installed, running a lot of compiles and building up part of my dev stack. Currently compiling node.js -- `make -j16` is nice Got some correctable ECC errors while building Ruby, so it looks like there might be a RAM upgrade sooner than later...

6200 series is still Bulldozer microarchitecture, Interlagos is a subfamily Piledriver is 6300 series IIRC. But yeah, part of the reason I went with a dual-socket motherboard is the enormous quantity of RAM slots. I can buy cheaper, lower-density RAM which seems to be widely available as cast-offs from other people's upgrades, and still get to a reasonable quantity for this system. Well, the machine arrived today, and it looks like something is wrong with the graphics card Super clean inside though, it smells like a brand-new computer. I kind of wonder if these were used for a trade show or something, and just surplussed as soon as the show was over. The other thing is, no onboard SAS controller -- it wasn't clear from the motherboard documentation that you could have IPMI (which this one does) and no SAS. It did ship with a 1 TB Hitachi/HGST SATA 3gb/s drive installed. There's a small dent on the top corner of the plastic bezel of the case, but that hardly matters. It came with 5x total drive caddies, so it's 3 short of being completely full.

Picked this up off eBay: http://www.ebay.com/itm/262157900280 Expandable to 32 cores for under $50, and will take up to 256 GB of ECC DDR3. The plan is to run Slackware 14.2 on it and use it as my main dev workstation. I'm running enough VMs nowadays that my current 4 core AMD APU box isn't cutting it, with running parallelized test suites for day-job work and whatnot. I've been running ZFS on Linux for a while with no reliability problems, so I'll probably use a bunch of the hotswap bays to do raidz or raidz2. There's a pile of PCIe slots, looking like the Supermicro motherboard in there might actually support my Xeon Phi, too! I'm thinking I will probably end up with a 10gb Ethernet card too, and do a crossover link to my FreeBSD ZFS server.

...because that title couldn't be more spammy, right? So I'm looking at getting an older Cisco switch with 10gb capability, I figure it just needs to be two to four uplink ports since I'll only have two 10gb Ethernet cards to start with. Plus I need a larger access switch, my little 8-port 2960G won't cut it much longer. One thing I always do before buying a used Cisco switch is, ahem, find the most recent IOS image and verify its MD5 against the Cisco site. I couldn't find a copy of the most recent IOS for a 3500 series switch, so I was goofing around with Cisco's JS, trying to see if they (like 99% of web devs apparently) were doing their validations all clientside. Then I thought, "wait, can I actually register for this?" Apparently the answer is yes, you just tell them you're a client, and agree to ITAR encryption export limitations, and you're good to go for LAN base and IP base on a lot of stuff. BTW, with the legit login I traced my way through the JS responsible for processing the download, and no, they're not validating clientside. It appears they go the extra step of validating *again* server-side, even after the login comes back successful -- you can snarf the download URL from one of the JS objects, and it's apparently a one-time-use deal. I couldn't wget it after I'd started the download normally.

https://backchannel.com/forget-comcast-heres-the-diy-approach-to-internet-access-ef1e37bc09e1#.2bdfq5vu8 Interesting read, basically one guy decided to build out his own infrastructure and now it's a huge cooperative.