Tag Archives: Instructional

Joining a GNU/Linux machine to a Microsoft Active Directory has been possible for years, but it’s always been a bit of a science project that involved touching half-a-dozen obscure config files and usually resulted in me getting completely locked out of the machine. Various commercial packages such as Likewise and Centrify aimed to smooth out the process, but they weren’t universally accessible across distros, and often produced inconsistent results.

After upgrading a system to Debian 8, I noticed a new option for joining the domain, courtesy of the folks at RedHat: realmd. Realmd puports to make joining an Active Directory domain dead simple. How does it do?

In the previous article of this series, I covered a variety of “remix” distributions of Linux aimed at older computers, and posed the question “why not build our own”? In this article, we’ll look at doing exactly that.

Our goal will be to set up a basic desktop system, using only the necessary components, such that it will run reasonably well on a roughly ten-year-old computer.

I’ve been coding Python in Emacs for years now, and for the most part it’s been a satisfactory experience. After experimenting with various python modes and utilities, I’ve had a pretty good environment that marries Emacs editing to syntax highlighting, real-time error highlighting, the ipython shell, linting tools like pylint and pep8, and various other goodies. But the one hole, the one sore spot in the whole works, was code completion. Something even idle can do out-of-the-box was simply beyond my ability to get functional in Emacs.

I’d tried just about every solution the internet could offer: PyMacs, company-mode, anything-mode, ipython completion, standard autocomplete-mode. Everything I tried either gave unacceptable results (like autocomplete-mode, which just scans the current buffer for completion information), or just flat-out didn’t work no matter how many tutorials I followed.

Here lately I’ve been trying to work a lot more on my Pythoning, so I decided to see if the state of the art has caught up with this need. Echo base, I’ve found it. Repeat: I’ve found it.

If you follow my posts or projects much, you know that, when it comes to GUI toolkits for Python, I’m a confirmed PyQT guy. QT is arguably the most advanced, polished, complete, and powerful GUI toolkit do-everything programming library out there, and a treat to use. But sometimes it’s overkill, and when I have to put together something quick for certain legacy OS that lack decent package management, having to load in Python and extra libraries just to get a couple text fields and a button doesn’t make sense1.

Wouldn’t it be great if there was a really simple, easy to use, lightweight graphics toolkit built right in to the standard Python libraries, so you could pop together those little one-window GUIs without loading in extra stuff? Well, hey, what’s this dusty thing over here in the corner? It looks like… Tkinter!?!??

Emacs’ window-splitting functionality is an ergonomic way to view multiple files at once without having to deal with shuffling around floating windows or clicking between tabs. Anyone who does much with Emacs probably knows already that they can use C-x 2 or C-x 3 to split the window vertically or horizontally.

What always bothered me about this feature was that the newly-created window defaulted to the current buffer, which in layspeak means you had the same file or content open in both your new window and the old. The was almost (but not quite) never the behavior I wanted, since usually you split the window to have multiple buffers on screen at once. Typically, I would do this right after opening a new file or buffer to compare with whatever I already had open, so that I would have the old buffer in one window and the new buffer in another.

This is where having an extensible editor rocks; because in Emacs, if you get tired enough of a behavior, you start hacking elisp and fix it…

By now you’ve got that old computer purring along like a panther with your new favorite distribution of Linux, loaded to the brim with educational software, ready to propel your child to the heights of intellectual stimulation. But before we launch this starship, let’s take a bit to make sure the safety equipment is in order and reign in some potential problems.

The story so far…

Back around 2005 I took my first leap into the world of writing useful programs armed only with my laptop, a Pentium II running Debian, and a fat book on PHP5. Though I’d taken a few classes on C++ and tinkered with BASIC on a few different platforms over the years, I’d never managed to produce anything that actually did anything practical (or, did it very well, at any rate); with PHP, though, it didn’t take long to spread my coding wings and take to the air as a novice web developer.

Before long, my skills proved useful in some critical situations at work, and my place as a web developer was cemented. My PHP code became more mature as I learned hard lessons of experience and combined them with the programming theory and computer science I was avidly consuming on the web.

Around the same time, I got interested in Python when I saw a coworker using it to build powerful desktop applications quickly and effortlessly; I wanted to round out my programming skills with a “desktop stack” as quick and simple as PHP, and Python turned out to be a good choice.

So for a few years now I’ve written mainly in these two languages, PHP for the web and Python for the desktop. As my applications have grown bigger and more complex, I began to develop a growing discontentment with PHP on a number of levels. So when people started talking about doing web development in Python, I had to see if I could make the switch.

The last article in this series described some of the more general realities of running Linux on a child’s computer. Now that I’ve (surely) convinced you to go ahead an put GNU/Linux on your child’s computer, it’s time to get down to nuts and bolts: which distribution, and what software?

The word processor has been a part of computing platforms since the earliest days of the home computer; I’ve used a number them over the years, including PFS-write on the Apple IIc, WordPerfect (both DOS and Windows versions), Microsoft Word, OpenOffice, and AbiWord.

A couple years ago, though, I got frustrated with the whole word processor concept, and found a way to create text documents that works a lot better for me. This article aims to describe the how and why of that move, for the benefit of others who find they just don’t like working with word processing software.

The default theme for KiLauncher. Ok, so it kind of looks like your gramma’s formica breakfast table from the 1970s.

I’ve been doing a lot of tinkering on my KiLauncher project over the last week or so, and it’s not only shaping up into a nice useful little application, but an educational opportunity as well

My goals for KiLauncher were to make it both theme-able, and configurable with plain-text files. The natural mechanism for this (for the theme, anyway) was CSS, a format with which any self-respecting UI designer is familiar. Fortunately, Qt supports a subset of CSS to style its GUI classes, sometimes referred to as QSS.

Check out my books!

My latest book, Mastering GUI Programming with Python, is a great choice for intermediate Python programmers who want to explore the powerful features of PyQt5. It can be ordered now in print or e-Book from Packt Publications or Amazon.

My first book, Python programming with Tkinter, is aimed at beginning programmers who want to start creating GUI applications using Python’s built-in Tkinter toolkit. It can be ordered now in print or e-Book formats from Packt Publications or Amazon

About

These are the thoughts of Alan D Moore, offered for your benefit or entertainment.