Posts in category 'hacking'
Running Debian Buster on an OLPC
Back in 2008 I got an OLPC XO-1 during the G1G1 program. Question: Can you successfully run Debian Buster on this modest hardware? Answer: Yes!
Way back in the before time, in the long long ago of 2008, I decided to participate in the One Laptop Per Child Give One Get One program. The vision of the program was compelling: play a small part in enabling childhood education by providing children in the poorest parts of the world access to cheap, simple, rugged computers. Load them with electronic books and educational software. Add support for wifi and mesh networking to enable connectivity. Unlock creativity in kids the way computers unlocked creativity in me.
Things didn’t exactly pan out as everyone had hoped, but I still ended up with my very own OLPC XO-1, and it’s sat quietly in a closet ever since, a toy that I take out and play with occasionally.
Well, we recently did a top-to-bottom purge of our house, and in doing so I once again ran across my XO-1. So I decided to take it out and play with it again. In particular, I was curious: what would it take to run the very latest version of Debian on this modest little device?
Turns out not much! But where it got tricky, it got really tricky…
Continue reading...- (https://b-ark.ca/eaioyc)
The ai thought leader on Twitter is now one of my favourite things (and also makes me want to play around with GPT2)…
- (https://b-ark.ca/UiEMeu)
After finishing my DIY keyboard project (http://b-ark.ca/MIYO2i) I’ve been trying to decide what I want to try as my next hardware hacking project, and this is definitely on the list…
Fun with themes
For kicks I wanted to build a dark mode for my blog, which led me down the garden path of CSS custom properties and easter eggs…
One of the many things that attracted me to tech, back in the day, was the total DIY freedom of hacking computers to do whatever I wanted. And when you’re a kid, it’s even more fun because you aren’t looking at your pet projects through the lens of “value” or “product market fit” or “differentiators”. You just… do stuff, simply because it’s fun!
Or, put more simply: You play. And as adults, we have play beaten out of us. And that is just a darn shame.
Well, one of the fun things about running your own blog on your own server with software you control is that it’s a wonderful place to play! Heck, the re-design of this blog started off as just me screwing around for the fun of it.
So, while on vacation, I thought it would be fun to build a dark mode theme for my blog using the technique outlined in this post (which it turns out is one of many).
If you want to see the results… well, first off, if your OS is set to use a dark mode theme, you might already be seeing it! Otherwise, the little lightbulb icon in the navbar toggles the themes.
In addition, if you poke around in my site, you might find an easter egg that enables a couple of additional retro themes designed to honour the computers of the past that inspired me and lead me to where I am today!
Continue reading...On Algorithms
So, generally speaking, I’ve typically adhered to the rule that those who develop software should be aware of various classes of algorithms and data structures, but should avoid implementing them if at all possible. The reasoning here is pretty simple, and I think pretty common:
- You’re reinventing the wheel. Stop that, we have enough wheels.
- You’re probably reinventing it badly.
So just go find yourself the appropriate wheel to solve your problem and move on.
Ah, but there’s a gotcha, here: Speaking for myself, I never truly understand an algorithm or data structure, both theoretically (ie, how it works in the abstract, complexity, etc) and practically (ie, how you’d actually implement the thing) until I try to implement it. After all, these things in the abstract can be tricky to grok, and when actually implemented you discover there’s all kinds of details and edge cases that you need to deal with.
Now, I’ve spent a lot of my free time learning about programming languages (the tools of our trade that we use to express our ideas), and about software architecture and design, the “blueprints”, if you will. But if languages are the tools and the architecture and design are the blueprints, algorithms and data structures are akin to the templates carpenters use for building doors, windows, etc. That is, they provide a general framework for solving various classes of problems that we as developers encounter day-to-day.
And, like a framer, day-to-day we may very well make use of various prefabbed components to get our jobs done more quickly and efficiently. But without understanding how and why those components are built the way they are, it can be very easy to misuse or abuse them. Plus, it can’t hurt if, when someone comes along and asks you to show off your mad skillz, you can demonstrate your ability to build one of those components from scratch.
Consequently, I plan to kick off a round of posts wherein I explore various interesting algorithms and data structures that happen to catch my attention. So far I have a couple on the list that look interesting, either because I don’t know them, or because it’s been so long that I’ve forgotten them…
Data Structures
- Skip list
- Fibonacci heap
- Red-Black tree
- Tries
- Radix/PATRICIA Tries
- Suffix Tries
- Bloom filter
Algorithms
- Various streaming algorithms (computations over read-once streams of data):
- Heavy hitters (finding elements that appear more often than a proscribed freqency)
- Counting distinct elements
- Computing entropy
- Topological sort
And I guarantee there’s more that belong on this list, but this is just an initial roadmap… assuming I follow through, anyway.
Sometimes You Actually Have To Rewrite It
So, a couple years back I started doing some subcontracting work for a buddy of mine who runs a little ColdFusion consultancy. As part of that work, I took ownership of one of the projects another sub had built for one of his client, and the experience has been… interesting.
See, like PHP and Perl, ColdFusion has the wonderful property of making it very easy for middling developers to write truly awful code that, ultimately, gets the job done. And so it is with this project. My predecessor was, to be complementary, one of those middling developers. The codebase, itself, is a total mess. Like, if there was a digital version of Hoarders, this code might be on it. But, it does get the job done, and ultimately, when it comes to customers, that’s what matters (well, until the bugs start rolling in).
Of course, as a self-respecting(-ish) developer, this is a nightmare. In the beginning, I dreaded modifying the code. Duplication is rampant, meaning a fix in one place may need to be done in many. Side effects are ubiquitous, so it’s difficult to predict the results of a change. Even simple things like consistent indentation are nowhere to be found. And don’t even dream of anything like automated regression tests.
Worse, feeling no ownership of the code, my strategy was to minimally disturb the code as it existed while implementing new features or bug fixes, which meant the status quo remained. Fortunately, around a year ago I finally got over this last hump and made the decision to gradually start modernizing the code. And that’s where things got fun.
One of the biggest problems with this code is that data access and business logic are littered throughout the code, with absolutely no separation between data and views. And, remember, it’s duplicated. Often. So the first order of business? Build a real data access layer, and do it such that the new code could live beside the old. Of course, this last requirement was fairly easy since there was no pre-existing data access layer to live beside…
So, in the last year, I’ve built at least a dozen CFCs that, slowly but surely, are beginning to encompass large portions of the (thankfully fairly simple) data model and attendant business logic. Then, as I’ve implemented new features or fixed bugs, I’ve migrated old business logic into the new data access layer and then updated old code to use the new object layer. Gradually, the old code is eroding away. Very gradually.
Finally, after a year of this, after chipping away and chipping away, finally, while there’s still loads of legacy code kicking around (including a surprising amount of simply dead code… apparently my predecessor didn’t understand how version control systems work–if you want to remove code, remove it, don’t comment it out!), the tide is slowly starting to turn. More and more often, bugs that need to be fixed are getting fixed in one place. New features are able to leverage the object layer, cutting down development time and bugs. And some major new features coming down the pipe will be substantially easier to build with this new infrastructure in place. It’s really incredibly satisfying, in a god-damn-this-is-how-it-should-be sort of way.
The funny thing is, this kind of approach goes very much against my natural instincts. Conservative by nature, I’m often the last person to start rewriting code. However, if there’s one thing this project has taught me (along with a couple wonderfully excited, eager co-workers), it’s that sometimes you really do have to gut the basement to fix the cracks in the foundation. And sometimes, you just gotta tear the whole house down.