- Entries under this category -
UPDATE: be sure to check out my updated entry on MPD!
I recently grabbed a bluetooth speaker, intending to mostly use it with my phone, but I quickly found myself wanting to play my laptop's MPD through it. Today I'll describe how I got it going - and In the process we'll also resolve some issues with the setup described in my other MPD post. The process was pretty straight forward but it didn't just work so I figured I would talk about it a bit here.
This is a follow-up to my earlier post about editing python with Emacs, as well as the start of a series on using Emacs effectively with a number of languages. I'll go into what I use for editing python with Emacs and why, as well as how I set it all up. Let's go!
If you want the satisfaction of putting together a fine python editor, that is also capable of serving as a sophisticated editor for many many other languages, with the added benefit of having at least some control over how it all works, then read on! You just might learn something ...
UPDATE! Check out my other post on MPD to see how some of the flaws of the setup described here are resolved!
Recently, out of a desire to use less memory while listening to music, I've been exploring different ways of listening to music under GNU/Linux. There's a wealth of GUI-based as well as terminal-based music playing itrfaces out there, and I've never really been a fan of most of them. Terminal-based players never appealed to me; I'm not someone who needs to do everything in the terminal and find it limiting for some things.
For a few years now, I've been using (and still really like) Clementine, but the size of my collection (more than 10,000 tracks) causes it to use quite a bit of memory. This becomes a problem when I'm doing other things that are also memory-hungry (virtual machines, games, most anything java) and I start swapping. But what are the options if you want something minimal?
In this (long) post I'll talk about using MPD for local listening enjoyment!
I've been using Debian since I first began using GNU/Linux. Through the years I've tried other distros, and ultimately settled on a Debian-based distro rather than vanilla Debian. But now the time has come to leave my comfort zone behind and go boldy where I've gone but not really loved before - away from my comfort-zone distro!
But wait! Why do you want to mess with Windows' version of Steam when there's a native client for GNU/Linux systems?
The fact is that although the number of games for Steam on Linux is pretty large and growing fast, there is a massive number of games that aren't currently slated for release outside of Windows - or they have a FOSS implementation that isn't loudly advertised (if at all) on whatever store you happen to find a game on. In some cases, it is an easy way to gain access to game files that you want to use with a particular reimplementation of a particular game.
Steam has a gold rating on the WineAppDB, and tools like winetricks make installation and usage a breeze. There's nothing really special about the process, but seeing as there are so many ways to do this I thought I should lay out what works really well for me.
UPDATE: Please be sure to check out the Part 2 to this entry Where I describe other awesome bits like Jedi! It's an update as well as an errata for this one.
The recent business with JetBrains' licensing is a great example of how quickly things can change (though this seems to have been resolved). Other things, like GNU Emacs for example, don't change too terribly much over very long periods of time.
I really love PyCharm and have been a license holder for several years. It's sort of hard to imagine working on Django projects without some of the neato bells and whistles it provides, and although I'm not 100% certain I won't continue to be a JetBrains customer, this news had made me really think about how far I am from just using Emacs for all of my Python dev work.
Can I do this? Or will I go insane from the lack of convenience?!
UPDATE 2015-09-25: It looks like wine-staging will soon be integrated into the main wine codebase!
Wine sometimes seems to get a bad wrap, but it really is an amazing project. With it, GNU/Linux users (and Mac users, too!) can run Windows applications - many of them nearly flawlessly. One thing I've found that's helped me get the most out of wine is to use the latest development versions. Debian and friends usually only keep stable releases in their repositories, so you can easily miss out on a lot.
If you aren't using a rolling-release distribution it can be hard to find up-to-date packages for your package manager. Or maybe it isn't exactly hard to find them, but I personally don't love adding 3rd party repositories (especially just for one package.)
But hey, this is free/open source software we're talking about, so why not just build and package it ourselves?! In the spirit of DIY, I'll go over installing the wine-staging patchset, compiling wine, and then finally, package it up into a deb. Get your compilers ready kids!
When I was first learning to use GNU/Linux and scripting, I was dead set on creating the bestest backup script. You see, during this period I would very frequently hop distros and I wanted an easy way to restore various settings I wanted. I had never really used any kind of version control system, so methodical usage of
tar seemed like the logical choice. Even if it wasn't the best solution, I was trying to do what I could to get the most out of my experience working and playing within this ecosystem. I wanted to shape it as close to exactly what I wanted as possible, and maybe along the way find out new things to try and add to the mix.
It wasn't until a few years later that I was able to implement a system for achieving exactly what I was trying to do with a backups script but without making any traditional backups at all.
The first computers I ever used were Apple IIe systems. At the time, to me they were machines for playing video games that my SNES couldn't. They were magical devices.
Two years later, I found myself using some sort of Microsoft-running machine for typing class. We even had cardboard boxes covering our hands so we couldn't cheat for a better WPM score! Not as fun as Oregon trail, but I was still fascinated by these things.
Finally, one day during my senior year of high school my anti-tech father decides he wanted to buy a computer. I wasn't asking why, at last I could have my own Diablo II machine (although it also came with a couple of other games, I didn't really give two shits about them. Some nice ones, too including Elite Force II and the original Tropico.)
Just another vessel of escapism... but little did I know that one day...
Hello, world! Greetings and welcome to this, my website and blog. I'm just a dude that grew up in the midwest and has always been enamored with music, games, technology, and nature. I'd like to use this blog as a place to share my thoughts and ideas, especially those that ...