Home directories have been a fundamental part on any Unixy system since day one. They’re such a basic element, we usually don’t give them much thought. And why would we? From a low level point of view, whatever location
$HOME is pointing to, is a directory just like any other of the countless ones you will find on the system — apart from maybe being located on its own disk partition. Home directories are so unspectacular in their nature, it wouldn’t usually cross anyone’s mind to even consider to change anything about them. And then there’s Lennart Poettering.
In case you’re not familiar with the name, he is the main developer behind the
systemd init system, which has nowadays been adopted by the majority of Linux distributions as replacement for its oldschool, Unix-style init-system predecessors, essentially changing everything we knew about the system boot process. Not only did this change personally insult every single Perl-loving, Ken-Thompson-action-figure-owning grey beard, it engendered contempt towards
systemd and Lennart himself that approaches Nickelback level. At this point, it probably doesn’t matter anymore what he does next, haters gonna hate. So who better than him to disrupt everything we know about home directories? Where you _live_?
Although, home directories are just one part of the equation that his latest creation — the
systemd-homed project — is going to
make people hate him even more tackle. The big picture is really more about the whole concept of user management as we know it, which sounds bold and scary, but which in its current state is also a lot more flawed than we might realize. So let’s have a look at what it’s all about, the motivation behind
homed, the problems it’s going to both solve and raise, and how it’s maybe time to leave some outdated philosophies behind us.
Continue reading “Pack Your Bags – Systemd Is Taking You To A New Home”
Direct from the “Just Because I Can” department, this blog post by [Eddie Zhang] shows us how easy it is to get the Xiaomi robotic vacuum cleaner working as what might be the world’s most unnecessary Spotify Connect speaker. Will your home be the next to play host to an impromptu performance by DJ Xiaomi? Judging by the audio quality demonstrated in the video after the break, we doubt it. But this trick does give us a fascinating look at the current state of vacuum hacking.
For the first phase of this hack, [Eddie] makes use of Dustcloud, an ongoing project to document and reverse engineer various Xiaomi smart home gadgets. Using the information provided there you can get root-level SSH access to your vacuum cleaner and install your own software. There’s a sentence you never thought you’d read, right?
With the vacuum rooted, [Eddie] then installs a Spotify Connect client intended for the Raspberry Pi. As they’re both ARM devices, the software will run on the Xiaomi bot well enough, but the Linux environment needs a little tweaking. Namely, you need to manually create an Upstart .conf file for the service, as the vacuum doesn’t have systemd installed. There goes another one of those unexpected sentences.
We’re certainly no stranger to robotic vacuum hacking, though historically the iRobot Roomba has been the target platform for such mischief. Other players entering the field can only mean good things for those of us who get a kick out of seeing home appliances pushed outside of their comfort zones.
Continue reading “DJ Xiaomi Spins Beats And Brushes At The Same Time”
Getting a home music streaming system off the ground is typically a straightforward task. Using Apple devices with Airplay makes this task trivial, but if you’re a computing purist like [Connor] who runs a Linux machine and wants to keep it light on extra packages, the task gets complicated quickly. His goal is to bring audio streaming to all Linux platforms without the need to install a lot of extra software. This approach is friendly to light-footprint devices like the Raspberry Pi that he used in his proof of concept.
[Connor] created a set of scripts which allow streaming from any UNIX (or UNIX-like) machines, using only dependencies that a typical OS install would already have. His Raspberry Pi is the base station and streams to his laptop, but he notes that this will work between virtually any UNIX or Linux machine. The only limitation is what FFmpeg can or can’t play.
We definitely can appreciate a principled approach to software and its use, although it does seem that most people don’t have this issue at the forefront of their minds. This results in a lot of software that is bulky, making it difficult to maintain, use, or even know what it does, and also makes it harder for those of us that don’t want to use that type of software to find working solutions to other problems. It’s noble that [Connor] was able to create something without sacrificing any principles.
In an earlier installment of Linux Fu, I mentioned how you can use
inotifywait to efficiently watch for file system changes. The comments had a lot of alternative ways to do the same job, which is great. But there was one very easy-to-use tool that didn’t show up, so I wanted to talk about it. That tool is
entr. It isn’t as versatile, but it is easy to use and covers a lot of common use cases where you want some action to occur when a file changes.
Continue reading “Linux Fu: Easier File Watching”
If you started using GNU/Linux in the last 10 years or so, there’s a very good chance your first distribution was Ubuntu. But despite what you may have heard on some of the elitist Linux message boards and communities out there, there’s nothing wrong with that. The most important thing is simply that you’re using Free and Open Source Software (FOSS). The how and why is less critical, and in the end really boils down to personal preference. If you would rather take the “easy” route, who is anyone else to judge?
Having said that, such options have not always been available. When I first started using Linux full time, the big news was that the kernel was about to get support for USB Mass Storage devices. I don’t mean like a particular Mass Storage device either, I mean the actual concept of it. Before that point, USB on Linux was mainly just used for mice and keyboards. So while I might not be able to claim the same Linux Greybeard status as the folks who installed via floppies on an i386, it’s safe to say I missed the era of “easy” Linux by a wide margin.
But I don’t envy those who made the switch under slightly rosier circumstances. Quite the opposite. I believe my understanding of the core Unix/Linux philosophy is much stronger because I had to “tough it” through the early days. When pursuits such as mastering your init system and compiling a vanilla kernel from source weren’t considered nerdy extravagance but necessary aspects of running a reliable system.
So what should you do if you’re looking for the “classic” Linux experience? Where automatic configuration is a dirty word, and every aspect of your system can be manipulated with nothing more exotic than a text editor? It just so happens there is a distribution of Linux that has largely gone unchanged for the last couple of decades: Slackware. Let’s take a look at its origins, and what I think is a very bright future.
Continue reading “Making The Case For Slackware In 2018”