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”
Ten years is almost ancient history in the computing world. Going back twelve years is almost unheard of, but that’s about the time that Palm released the last version of their famed PalmOS, an operating system for small, handheld devices that predated Apple’s first smartphone by yet another ten years. As with all pieces of good software there remain devotees, but with something that hasn’t been updated in a decade there’s a lot of work to be done. [Dmitry.GR] set about doing that work, and making a workable Palm device for the modern times.
He goes into incredible detail on this build, but there are some broad takeaways from the project. First, Palm never really released all of the tools that developers would need to build software easily, including documentation of the API system. Since a new device is being constructed, a lot of this needs to be sorted out. Even a kernel was built from scratch for this project, since using a prebuilt one such as Linux was not possible. There were many other pieces of software needed in order to get a working operating system together running on an ARM processor, which he calls rePalm.
There are many other facets of this project that we aren’t able to get into in this limited space, but if you’re at all interested in operating systems or if you fondly remember the pre-smartphone era devices such the various Palm PDAs that were available in the late ’90s and early ’00s, it’s worth taking a look at this one. And if you’d like to see [Dmitry.GR]’s expertise with ARM, he is well-versed.
Thanks to [furre] for the tip!
Getting into the weeds of operating systems is daunting work. Especially when the operating system involved is a fully featured modern PC operating system with millions of lines of code all working together to integrate hardware and software seamlessly. One such operating system “weed” is figuring out how to handle simultaneous tasks when the processor can only really handle one thing at time. For that, you’ll be looking at the difference between spinlocks and mutexes.
Both of these are methods of making sure that the processor completes a task sufficiently before moving on to the next task. Modern computers are so fast (even ignoring multiple cores) that it seems as if they are doing many things at once. In order to maintain this illusion, tasks need ways of locking the processor to that specific task for a certain amount of time. Of course the queue for performing the next task can get complicated as there are often many tasks waiting to use processor time. Spinlocks are a simple way of holding the processor and mutexes are a slightly more complicated way, but which one is the most efficient use of system resources isn’t that straightforward.
If you’ve ever been interested in operating system details, this one goes deep into the intricacies of features most of us have never even considered the existence of. It’s definitely worth a read, though, and is very well written by someone who is clearly an expert. If you want an operating system challenge, you can build your own operating system as well.
TI certainly have certainly seen off rivals such as HP or Casio to capture the lion’s share of the calculator market. The TI-84 is a real staple, and with as many units as there are out there, hacking them is a given. However, selecting an operating system for the machine can be a hassle. TI-OS is proprietary and doesn’t really want to let you do everything you’d like to. There are alternatives, but many of them won’t let you easily use your calculator to be — well — a calculator.
[Siraben] has zkeme80 which is essentially ANS Forth (mostly) with extensions for the TI hardware. You can easily extend the system, of course, because it is Forth. You can also use the machine for its intended purpose easily.
Continue reading “Pocket Forth Invades Your TI Calculator”
Writing an operating system is no small task, but like everything else it is easier than it used to be. [JSandler] has a tutorial on how to create a simple operating system for the Raspberry Pi. One thing that makes it easier is the development environment used. QEMU emulates a Raspberry Pi so you can do the development on a desktop PC and test in the virtual environment. When you are ready, you can set up a bootable SD card and try your work on a real device.
The operating system isn’t very complex, but it does boot, organize memory, displays on the screen, handles interrupts, and manages processes. What else do you need?
Continue reading “Roll Your Own Raspberry Pi OS”
Even though it seems like there are a lot of operating system choices, the number narrows if you start counting kernels, instead of distributions. Sure, Windows is clearly an operating system family, and on the Unix-like side, there is Linux and BSD. But many other operating systems–Ubuntu, Fedora, Raspian–they all derive from some stock operating system. There are some outliers, though, and one of those is HelenOS. The open source OS runs on many platforms, including PCs, Raspberry PIs, Beaglebones, and many others.
Although the OS isn’t new, it is gaining more features and is now at version 0.7. You can see a video about some of the new features, below.
According to the project’s web site:
HelenOS is a portable microkernel-based multiserver operating system designed and implemented from scratch. It decomposes key operating system functionality such as file systems, networking, device drivers and graphical user interface into a collection of fine-grained user space components that interact with each other via message passing. A failure or crash of one component does not directly harm others. HelenOS is therefore flexible, modular, extensible, fault tolerant and easy to understand.
Continue reading “Forget Troy. Try HelenOS”
In today’s digital era, we almost take for granted that all our information is saved and backed up, be it on our local drives or in the cloud — whether automatically, manually, or via some other service. For information from decades past, that isn’t always the case, and recovery can be a dicey process. Despite the tricky challenges, the team at [Museo dell’Informatica Funzionante] and [mera400.pl], as well as researchers and scientists from various museums, institutions, and more all came together in the attempt to recover the Polish CROOK operating system believed to be stored on five magnetic tapes.
Originally stored at the Warsaw Museum of Technology, the tapes were ideally preserved, but — despite some preliminary test prep — the museum’s tape reader kept hanging at the 800 BPI NRZI encoded header, even though the rest of the tape was 1600 BPI phase encoding. Some head scratching later, the team decided to crack open their Qualstar 1052 tape reader and attempt to read the data directly off the circuits themselves!!
Continue reading “Raiders Of The Lost OS: Reclaiming A Piece Of Polish IT History”