Latest articles

Can't update Arch/Manjaro Linux because of 4kvideodownloader or ffmpeg2.8? No problem!

I recently ran into an issue I'd like to talk about in case anyone else has hit the same problem.

On my main PC, I run Manjaro Linux (an offshoot of Arch Linux). Recently, when I tried to to perform a system update, I started getting errors preventing me from updating. The problem was a conflict relating to package "ffmpeg2.8", which was in turn required by "4kvideodownloader". Now, you may or may not be familiar with 4kvideodownloader, but the details of it aren't especially important (aside from the fact that it's freaking awesome and I highly recommend it). What is important here is that I like 4kvideodownloader, and there are reasons I don't want to give it up.

This left me with a dilemma. The 4kvideodownloader tool (via its "ffmpeg2.8" dependency) were blocking me from updating my machine. The obvious choices were to either stop making any updates to my machine forever, or uninstall both "ffmpeg2.8" and "4kvideodownloader". I hated both options.

So I took a gamble. I uninstalled both "ffmpeg2.8" and "4kvideodownloader", hoping I would then be able to update my Manjaro/Arch-ish system and able to get "4kvideodownloader" installed and working again.

Which brings me to the whole point of this post:

The gamble paid off! Once I uninstalled "ffmpeg2.8" and "4kvideodownloader" via yaourt (turns out, both are AUR packages), I had no trouble updating my system. And then, best of all, I had no trouble re-installing "4kvideodownloader" (along with its dependency, "ffmpeg2.8") afterwards.

Summary (ie, that's ordinary English for "TL;DR", for any of you hipster, fashion, Portlandia-as-everyday-life nerds out there.) :

You don't have to give up 4kvideodownloader, or wait for a AUR update to 4kvideodownloader, to update your Arch Linux-based system. Just uninstall them so you can update your system, and then you should have no trouble re-installing both. It worked for me...

Read more

Shaddup Navi^H^H^H^HSteam...

Yes, Steam, that is still my email address fuck you very much neo-Navi m&^*$&$&**%*&(#..........

Read more

Mozitos: Or...What To Do With Your *Other* 5 1/2 Bottles Of Zima

Say you're part of my generation, and those classy, spiffy looking little bottles of intriguing Zima dissapeared from store shelves just before you were old enough to (legally) find out for yourself just how unworthwhile they really were.

Sure, everyone said it was horrible, nasty crap. Sure, in all your years you've never heard anyone say one good thing about Zima (not even that one dude who had just the weirdest taste in drinks...) But now they're back, and dagnabbit you're well over 21 this time, with a bucket list and some hard-earned cash.

And partway into one bottle, yes, you too can now check one more item off that bucket list - that slight cringe on your face is your badge of honor: You finally know for yourself exactly why it was ridiculed and dissapeard for over a decade. And you too, can now join in on the ribbing. Mission accomplished.

But, shoot, what do you do with the rest of the five and a half bottles in that six-pack? It never did feel right to toss even the most vile booze down the drain. What a shame. What's a dude[ette] to do?

Make Mozitos!


  • 1/2 Bottle of chilled but still nasty, overly-sugary, slightly beer-ish, not-very-citrusy swill that because of "malt and citrus" sounds like it should kinda taste like a shandy except it really doesn't (aka, "Zima")
  • However many shots of whatever proof vodka you choose. You're on your own here, but one word of advice: Go with the cheapest one you can find. It's a freaking mixed drink - it's not like you're gonna notice the difference. (Rum would likely work well too, athough it's not as cheap. Just make sure not to use a sweeter one like Parrot Bay, at least not for this recipe. The Zima has plenty of sweetness already.)
  • Juice from 1/2 a lime (Roll the lime hard on a countertop before slicing it open - That'll make it a lot easier to extract all the juice. Some people suggest slightly heating it in a microwave, but I think rolling it is easier, much more fun, and words just as well.)
  • Several leaves of fresh mint (Or a bunch if you really love mint)
  • Three ice cubes


  1. Take your serving vessel (ie: "cup") and add the lime juice and mint leaves.
  2. Use a muddler to mash the mint leaves (Carefully! You don't want to chip the glass if the glass The releases the mint's minty flavor into the drink.
  3. Since nobody has a muddler, and most people don't even know what a "muddler" is, just use the handle of a knife or whatever else you have in your kitcken that looks like it'd be good for mashing mint leaves in a glass. (Hmm, maybe I should have mentioned this before step 2.)
  4. Add your vodka (Or rum. Or whatever.)
  5. Add ice.
  6. Fill the rest of the glass with (roughly) 1/2 bottle of Zima
  7. Serve. (That's fancy-talk for "Bottoms Up!")
  8. Swear to never buy Zima again. Until the next time they bring it back as a "Limited Release"...

Read more

We're Overlooking A Key Part of C/C++ to D User Migration

In the D community, we have a strong belief in D's potential as a suitable and favorable alternative to C and C++ for areas commonly served by C/C++. This isn't surprising, since that's exactly how D was originally designed and envisioned.

To help facilitate that, D has always been designed to easily interface and directly link with C code. More recently, major improvements have also been made in interfacing D with C++. Naturally, one major benefit of this is to provide D with access to the wide array of existing C/C++ libraries. But the other key idea here is to help encourage D uptake. How? By making it easier for existing C/C++ projects to include D portions without the entire project needing to be ported.

This C/C++ interoperability is a fantastic feature for D to offer, and is essential in encouraging and facilitating migration to D. Building off this, we have Deimos, to offer D projects ready-made bindings to C/C++ libraries. Other projects in may offer to auto-generate D bindings or wrap existing Deimos bindings with D-centric benefits and simplifications. All of this, we hope, will make D appealing enough and entice C/C++ users to try out D in their projects - and potentially, commit more fully down the road.

But we're overlooking a key part of the picture. We're looking at something backwards:

Our whole approach to giving D inroads into the C/C++ world relies on convincing C/C++ users to actually try out writing D. Even before they do that, they must actively decide to go learn some D. We've had some success, but as many of us have learned, this can be a significant uphill battle. The status quo is strong with programmers (and understandably so).

Take our existing focus, offering C/C++ libraries to D projects: What if we flipped that around and started using D's C/C++ interoperability to offer D libraries to C/C++ projects?

Think about it: If a D library came with its own C/C++ bindings, then it may as well be a C/C++ library as far as most C/C++ users are concerned. Then just slap into a C-world-compatible makefile into the library, which auto-detects a D compiler and, if none, does an automatic project-local download/install of DMD/LDC/GDC (this could all be offered to D libraries via a single D tool up on, or even just include precompiled library binaries, and done: on any platform D supports, C/C++ users can use your D library just as if it were another C/C++ library.

That gives D inroads into C/C++ projects without requiring any C/C++ user to ever have to touch one line of D. Then, later, when coders wonder how the library they use works so efficiently and reliably, and is developed so productively - they can glance into the lib, see how simple it really is compared to a C/C++ equivalent, and see how much easier still it would be to use the library from D. Nice, D has just marketed itself.

tl;dr (In my day we called that a "summary"): I propose free C/C++ bindings with every D library! The D community should strive to offer them as a standard matter of course. Tools should be created to help D library authors offer their own C/C++ bindings. This will take us much farther into the C/C++ domain than merely offering C/C++ libraries to D users will.

Read more

WTF is the Deal With T-Mobile's Service Coverage?

For the past couple years, I've been a Verizon user with a deep seething hatred for Verizon. I won't get into why I despise them here, other than to say it's been for both real-world practical and ideological reasons. But, for various reasons also not worth getting into (such as other people on my group plan, and one particular catch involved in the "We'll pay your early termination fee" deals that's personally a show-stopper for me), and let's face it, there's no such thing as a good telecom company, I've been stuck until now.

I've been eyeing T-Mobile a lot lately. I'm not sure sure about the whole "uncarrier" moniker, but they do appear to be an improvement over Verizon in many ways. And from what I can tell, they seem the least offensive and questionable of all the options available here in the US.

However, as anyone who's looked into them knows, T-Mobile's famous Achilles heel has always been questionable service coverage. Aaaaannd...that leads straight down a rabbit hole: This year, T-Mobile's been saying a lot about their greatly improved network. Some users confirm it, some contradict it, and others just ramble about..."band 12"??? WTF is that??? Who even wants to know?!

After researching more and more, I think I've finally gotten a handle on just what is going on with T-Mobile's network lately. Here's what I've found out:

"If you haven't tried our network lately, you haven't tried it period." - Frequent T-Mobile tagline

Turns out, there's a lot of truth to that statement...depending on your phone. But back to that in a bit...

Ultimately, the key concept here is that there's two types of radio frequencies used by cellular carriers: Higher frequencies and lower frequencies.

Lower frequencies travel farther and do a good job of penetrating walls and buildings (See what FCC Chairman Tom Wheeler said about this last year). But there's a downside: They can't handle quite as many people at the same time. So the carriers have to make up for that by building more cell towers. This works out perfectly for the larger carriers who can afford it. In fact, for many years, and up to at least as recently as one year ago, "AT&T and Verizon control nearly three-quarters of low-band spectrum in the US".

Higher frequencies can support more users doing more things at the same time. This makes it attractive to underdogs carriers like T-Mobile who use it because they can support more customers with fewer towers at a lower cost. But the downside is that higher frequencies don't travel as far, and have trouble penetrating walls and buildings. So, historically, T-Mobile has been making do with fewer towers, each with less range. This is why T-Mobile's network works great when you're in range (their higher frequencies can handle more people and more data), but also why actually getting a signal could be difficult (their higher frequencies, from fewer towers, don't travel as far or go through as many walls and buildings).

This past year, T-Mobile's been spending large amounts of money to do two things: First, they've been building new towers to help compensate for their signals not traveling as far as Verizon's. This gives them coverage across a much larger portion of land than before, and fills their coverage map with far more of their flagship pink. This is why some T-Mobile users, particularly ones in suburban areas, have been reporting their coverage has improved. (Although, rural areas are still lagging - albeit not by quite as much as before.) But, since high-frequency is still high-frequency, these additional towers alone don't do much to solve the problem of getting a good signal indoors, or around many large buildings. This is why other T-Mobile users, especially ones in urban areas, have been reporting they're still getting spotty coverage.

Addressing that is the second big thing T-Mobile has been working on recently. Early last year, they spent $3 billion buying a chunk of lower-frequency (700MHz) spectrum from Verizon, and have been bringing it live this year, especially over just these last few months, and they're continuing to utilize more of it even now. They also plan to buy even more (600MHz) at an FCC auction early next year.

This lower-frequency 700MHz range that T-Mobile bought from Verizon and has now been bringing live is what they're calling "Extended Range LTE". In more technical circles, this specific section of 700MHz is also known as "band 12".

But if T-Mobile now has all this new "works well indoors and through buildings" capability, why have some users been reporting they still get bad indoor coverage? They're probably on an older phone: Older phones are, well, older, and so don't support T-Mobile's new "band 12"/"700MHz"/"Extended Range LTE". For reference, here's the current list of phones which do support it. The list is also available here. (Unfortunately, that does exclude the phone I wanted, the Note 3. Damn. So long USB3 and hardware menu button :/ ). But it seems safe to expect all major current and upcoming phones to support it moving forward.

So, bottom line: T-Mobile is currently in the middle of a big shift improving their coverage. Some of this is already here, particularly in suburban areas, but some is still yet to come. The big caveat is that the improvements to indoor reception require a newer phone compatible with T-Mobile's new "band 12"/"700MHz"/"Extended Range LTE".

Read more

Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more

New update to Scriptlike: v0.9.4.

Scriptlike is a library to help you write script-like programs in D.

The two highlights in this release are string interpolation and a full set of examples in the documentation. Also of note are the new functions removePath and tryRemovePath which can be used to delete files (like remove) or directories (like rmdirRecurse).

For the full list of all changes in this release, see the changelog.

String Interpolation


AFAICT, a string mixin is necessary to accomplish this in D, but otherwise it works much like other languages:

// Output: The number 21 doubled is 42! int num = 21; writeln( mixin(interp!"The number ${num} doubled is ${num * 2}!") );

The interpolated sections are handled via std.conv.text(), so they accept any type.

Bikeshedding requested! I'm not 100% sold on the name interp for this long-term. Suggestions welcome.


The homepage/readme now provides sample code demonstrating all of Scriptlike's various features.

There is also a demonstration of suggested practices for how to use Scriptlike in a D-based script.

And finally, all examples are included as actual runnable programs (all automatically tested by dub test, to ensure continued freshness).

Read more