A blog (by Patrick Louis in Lebanon) consisting of well researched articles about Unix, philosophy, and more. From deep dives to well-rounded overviews that remove mysticism, everything is easily explained in a consumable way. Every article tries to take a new point of view, to link ideas together, and to tackle topics that haven't been before.
Let's explore and deobfuscate the input stack on Linux. Our aim is to understand its components and what each does. Input handling can be divided into two parts, separated by a common layer. We’ll try to make sense of all this, one thing at a time, with a logical and coherent approach.
Time flows through us so quickly, like rivers and ravines; but also, like travelers, we're advancing on its endless plains, mountains, and ridges. Aren't we living contradictions, and embracing the elements. Let's sit down and write about a few things that happened since the last time.
Throughout the countless years of research on this blog a common thread always comes up: Some features and toggles are often hidden under mountains of hubris that nobody understands. It could be because the software is under-or-badly documented, that it's 'too-flexible' and made to handle cases that never materialize, or just that people don't capt what they're dealing with and never bother looking under the hood. These software are crying to have better interfaces!
Take a look at your process tree, it's likely that you might notice a new service: rtkit-daemon, the RealtimeKit Daemon. It seems nobody on the internet is talking about it, so let's explain what it's about in this article.
We often get absorbed in the moment, it's tough to take a pause and reflect. However, if we never do we might forget our stances and essential parts of ourselves. So here comes the time to stop, and refresh about what I've been up to, to judge and think about the direction of things.
´Life is what happens in the space between´. Indeed, since the last update article a world pandemic has passed, truces have been signed in some countries, new wars have started in others, climate is going increasingly haywire, and the global political and economic turmoils have led to protests and revolts in countless places. The world keeps moving and I'm but a tiny spec in the grand scheme of things. Yet, you're reading this article, so you're interested about what I've been up to!
Plenty of cheesy quotes often say that total security stands on the opposite of total freedom. Undeniably, in computers and operating systems this is a fact. This article will focus on the topic of access control on Unix-like systems. Sit back and relax as it transports you on a journey of discovery. We'll unfold the map, travel to different places, allowing to better understand this wide, often misunderstood, and messy territory. The goal of this article is to first and foremost describe what is present, allowing to move forward, especially with the countless possibilities already present. Because how can we better shape the future if we don't know the past.
It's already been quite a while since the last update article in Spring last year. The dynamics around the pandemic have changed but it is still omnipresent and the constant weight is taking its toll on everyone. Similarly, I'm hearing an echo that can't be silenced, that of a need for change and return to what captivates me. As some readers might have noticed, I haven't posted nor been very active the past few months.
The PipeWire project is slowly getting popular as it matures. Its documentation is still relatively sparse but is gradually growing. However, it's always a good idea to have people from outside the project try to grasp and explain it to others in their own words, reiterating ideas, seeing them from their own perspective.
It's been seven months since the last update article in October 2020. We're still in a pandemic and living a more self-reliant, distanced, and introspective life. I've personally taken the stance of slowing down, to use this intermittent time to my advantage for personal growth. Slow living and the enjoyment of little things.
Audio on Unix is a little zoo, there are so many acronyms for projects and APIs that it's easy to get lost. Let's tackle that issue! Most articles are confusing because they either use audio technical jargon, or because they barely scratch the surface and leave people clueless. A little knowledge can be dangerous.
Resolving hostnames (DNS?) might not seem like it, but it's complicated. Let's take a moment to see if we can at least demystify what happens on the client side instead of seeing it as a big tangled mess of configurations, libraries, and tools.
Seven long and perilous months have gone by since my previous article, what feels like an eternity, and yet feels like a day — Nothing and everything has happened. All I can add to the situation in my country, that I've already drawn countless times, is that my expectations weren't fulfilled. Indeed, after a governmental void and a horrific explosion engulfing a tremendous part of the capital, I'm not sure any words can express the conflicting feelings and anger I have. Sentimentalities aside, let's get to what I've been up to.
We live in a world that is gradually and incessantly attracted by over-rationality and order. In this article we'll burst the enchanted bubble and embrace corruption and chaos — We're going to discuss the topic of image glitch art.
Freetype, included in the font stack on Unix, is quite complex. There are so many layers to get it to do what it does that it's easy to get lost. From finding the font, to actually rendering it, and everything in between. Like most of the world, I use a rather low screens definition (1366x768 with 96 dpi) and rather old-ish laptop, unlike some font designers that live in a filter bubble where everyone has the latest macbook. Thus, good and legible font rendering is important. Let's play with lesser known toggles available to us when it comes to font rendering and see what they do, let's have fun and explore possibilities.
Compilers, these wonderful and intricate pieces of software that do so much and that so many know little of. Similar to the previous article about computer architecture, I'll take a look at another essential, but lesser known, CS topic, Compilers. I won't actually dive into much details but I'll keep it short to my notes, definitions, and what I actually found intriguing and helpful.
Computer architecture can be considered a boring topic, one that is studied during CS education, then put aside, and leaves place to the shiny new toys that capture the attention. I've recently revisited it, and I'd like to summarize some takeaways.
Dbus and Polkit are two technologies that emanate an aura of confusion. While their names are omnipresent in discussions, and the internet has its share of criticism and rants about them, not many have a grasp of what they actually do. In this article I'll give an overview of these technologies.
In a previous post, I've underlined the philosophy behind Domain Driven Design, DDD, and now I'd like to move to a practical approach that handles real issues in software development and architecture, requirements that constantly change, and models that are never precise, never current, and/or never using the best technology available. One of the solution to such problems is to build an evolutionary architecture.
We're used, as software engineers to try to make things perfect, to see things from above, to think we're great architects and creators. What's more important though is to create software that does an important job for someone. What are the best ways to create such software?
An article covering everything you need to know about time on Unix. Time, a word that is entangled in everything in our lives, something we're intimately familiar with. Keeping track of it is important for many activities we do.
What are software distributions? You may think you know everything there is to know about the term software distribution, but take a moment to think about it, take a step back and try to see the big picture.
Here comes another life update. My biological clock seems to have chosen to remind me to post these updates once every 6 months, with seasonal changes.
No this isn't a post trashing shell scripting. Handling files on the command line is most of the time a non-reversable process, a dangerous one in some cases (Unix Horror Stories). There are tricks to avoid the unnecessary loss and help in recovering files if need be.
Let's have a discussion about all the kinds of trust stores found on Unix-like operating systems. For those not in the know, trust stores are places where the operating sytems generally, or the specific software, stores private and public keys (asymmetric), trusted CAs, and symmetric keys (decryption keys).
We often hear discussions about X configuration files and their roles. Namely, xinitrc,xserverrc,xresources,xdefaults,xprofile,xsession,xmodmap. So let's try to clear up this mumbo jumbo of words.
As the field of SE/CS is getting more press, graduates are flooding the market. Yet, the curriculum given in many universities still seems barren when it comes to professionalism, forcing newcomers to learn via unpolished street creds. Not only is it leading to mysticism about what skills are required but is also leading to a lack of discipline, duty, and craftsmanship.
In Lebanon conspiracy theories are such a common occurrence that the whole world but yourself is to blame for your ailment. I usually dismiss them but the one in this post got on my nerves, and moreover a quite simple experiment could finally shatter it and remove it as an option from all conversations.
In the blink of an eye 6 months have gone by. Since then, I've written a single article about time on the internet and thus the blog needs an update on my latest endeavours.
The new year has begun... A while ago! My last post Was almost 9 months ago, more than half a year has passed. A lot has happened but I still feel like time has passed quickly.
In this article we will put some light on a lot of tools used in the world of Unix desktop environment customization, particularly regarding wmctrl, wmutils, xev, xtruss, xwininfo, xprop, xdotools, xdo, sxhkd, xbindkeys, speckeysd, xchainkeys, alttab, triggerhappy, gTile, gidmgr, keynav, and more. If those don't make sense then this article will help. Let's hope this can open your mind to new possibilities.
In this post I'm going to go over "fonts for xcb" a mini-project I've been working on recently and I'll document the parts that are not usually found online.
In this article we're going to go over the big list of words found in the title. When I worked on 2bwm I didn't have much experience with X programming in general. I've sort of learned it on the spot. That's why I'm trying to gain more knowledge before continuing to re-rewrite 2bwm from scratch. Now that I've got a bit more background I think it's good to share it with the world, for others that are like me, looking for knowledge and good articles on the topic.
Let's say you've been using a machine for a year or two and over time you gradually become more attached and dependent on it. This is a situation I've found myself into more than once and it is quite annoying, it's straining for the brain. I've been through it the past few days and it and I kept wondering about the ways I could make it less of a pain. Imagine if today you suddenly lost access to your current work machine, what would you do? This all rotates around the concept of having "less ties", "fewer worries", "better or lighter workflow". And there are no exact step-by-step guides to reach this, only nebulous and vague ideas that rotate around it. However, checking some of them might make it less straining on the brain, less of a burden, for possible future changes.
Today we take for granted the concept of software as a tool but it didn't always exist. Mini-scripts, the interoperable programs, the small utilities for specific tasks, etc. This is what we're going to discuss, where do they come from, the history, and a bit more.
Libraries and banks, amongst other institutions, used to have a filing system, some still have them. They had drawers, holders, and many tools to store the paperwork and organise it so that they could easily retrieve, through some documented process, at a later stage whatever they needed. That's where the name filesystem in the computer world emerges from and this is one of the subject of this episode. We're going to discuss data storage on Unix with some discussion about filesystem and an emphasis on storage device.
Logos and artworks in the Unix world, where do those come from. We'll try to analyse a bunch of popular Unix mascots and logos. Throughout my research I could distinct two groups of mascots and logos. Even though it's not fun to have a binomial vision of the world, black and white, but this is what I found and this is mostly what it is.
In this episode we'll tackle a topic that joins many parts of the systems and so is hard to fully cover. It has a relationship with everything in the system, it glues it together. We're going to be discussing processes on Unix.
It's been four months since the last post about my personal projects and endeavours. These past months I've been following, slowly but steadily, on the activities I had set the pace for previously.
The topics in this episode are fairly simple, even basic, but I'd like to tackle them from a different perspective. The information in a computer is represented in binary form. For them the bit is the basic unit of this information. Bits are binary, and binary means that there can only be two states, or it's the first or the second state, nothing else. The CPU has some built-in commands to manipulate a fix set of those bits. The set of bits with a fixed size for a processor, that this processor is designed to handle at a time, is called a word. This varies between processors. Because of how tied and low level binary operations are, they are operations directly supported by the cpu, they are faster than higher level abstractions and consume less memory space. For this reason it is sometimes chosen, at the sake of clarity, by some programmers as a data structure. We're going to discuss some topics related to words and some usages of bitwise operations in Unix.
At the beginning of time there was nothing... But that all depends on your definition of nothingness, what is nothingness... A power button is pressed, and suddenly BIG BANG... After a while, you get a Unix login prompt. Have you ever wondered what led to this, what happened behind the scenes from the time you pressed the power button until this prompt appears? In this episode we're discussing the boot process and what is specific to Unix about it. I'm venam and you're listening to the Nixers podcast.
Browsers, your windows to the WWW What do you use, customize, the problems you've stumbled upon, how we're using those browsers in the Unix world, the most used browsers, why we use them, and all the problems we've encountered I'm venam and you're listening to. The nixers podcast
You've certainly heard of daemons, those processes that lurk in the background and do what they're supposed to do. You might even have written and run programs that are daemons. Today we'll talk about them, those daemons ({day,dee}mon), what there is to know about their mechanism and details. A big generic overview of daemons on Unix.
A set of dynamic values, helper or configuration values, that can affect the way a process runs. Usually it's the process that queries those values, they are part of its "environment" and consequently the name. They are there so that the process can know the suitable values of the system it's running on. They are metadata, so to say. For example, the temporary location to store temporary files, or the home directory. This defintion is vague, the implementation could be done in a lot of ways. What's really an environment variable... Well, this isn't clear. Are those environment variables respected, forced? Also, this isn't a clear thing.
An executable is something that causes a computer to perform some tasks according to encoded instructions. It's in opposition to a data file which must be parsed by another program to be meaningful, for example an image or video. The instructions are usually in machine code, read by the cpu and so dependent on the cpu architecture. An executable once compiled will only work on a particular family of processor because the machine code instruction differs within the families of processors. It also differs depending on the hardware, let's say the GPU. An exception to this are the fat binaries which include the code for multiple hardwares in a single binary. It makes it bigger though, obviously. There aren't many implementations of this in the Unix world but the most relevant example are the OSX and ios binaries, which are architecture independant, they are fat binaries, which explains why their binaries are huge. We've said the instructions were in machine code but more generally they can be in any format, interpreted and reconstituted into bytecode by a scripting language or a middle man program that will do just in time compilation or anything else so that the machine understands. An emulator for example, java bytecode is also a good take.
Understanding how the fonts work on Unix isn't simple. I had never thought when starting this research that this field was this deep. Not only is it overwhelming, but the information around the subject is also not easily digestable. The last two weeks I've been researching this and in this podcast you'll barely find but the essential. It's still skimming the surface of the topic. If I explain something in a wrong manner, be sure to correct me in the extended podcast discussion thread. The people that truly understand the full font stack can be counted on one's hand, I'd like to salute those true heroes. They deserve respect. And if they had an anthem I would've played it at the beginning of this episode. So yes, we're going to discuss fonts.
The world of licenses is the legal world, a world where the literal meaning of words is important and where all the crevasses are exploited. I'm not a lawyer, nor have I studied laws, and whatever I say will be based on what I understood from my reading. In this episode we're going to do a small overview of the topic of licenses on Unix. But beware, a "small" overview in the legal world is quite heavy!
What would you say or give as advice to newly unix users. What is there first to dabble with. Today we're discussing advices and tips you'd like to tell newcomers. Remember the first time you laid your hands on a Unix box, most probably you were lost, just like most people. Now that you've got some experience with Unix in general what would you tell yourself from the past. Guests, thlst, abhx/stark
We've had an episode about display servers and libraries, and then we had another episode about window managers and desktop environments, and so the next logical step is to do one about ricing and customization. This is what we're going to do today in the company of xero, neeasade, and halfwit.
Everything is a file, right. Files on Unix have no specific format, nothing is imposed about how they should be, and there's no need to incorporate anything specific for them to be files. There's no file type, all the files are the same. But that's not really true. There are two differentiations. One is at a higher level, a meta level, using mimetypes which we discussed in an earlier episode about default programs. You can listen to it to get a small overview. The other difference is at a lower level, and that's what we're going to discuss.
System calls are one subject that scares many people. Actually most of the low level stuffs happening on the operating system scares a lot of people. I admit, I was a bit afraid of dealing with this subject. Not because it's hard or anything but because it's something that we're not used to dealing with every day, it's like a hidden magic spell. I was also afraid of dealing with this subject because I thought I could make mistakes while explaining it and giving other people false assumptions about the mechanism of their Unix operating systems. But that's ok... We'll explain everything slowly. In this podcast we're discussing system calls on Unix operating systems, it's going to be a quick overview of what's happening there. If you're someone that hardly know anything about them then it's the episode you need to listen to.
We spend so much time typing at a terminal and yet the underlying mechanisms and history behind it are often overlooked. The TTY is an integral part of Unix, and we take most of its behavior for granted even though it has a huge history baggage that it carries to this day. For instance pressing control-C or control-Z to stop or put in the background a process, or using control-A to go to the beginning of the line. You might think that the control-A comes from the EMACS keybinds but it doesn't, it's the opposite, the EMACS keybinds are inspired by the TTY. In this episode we're going to dive in the world of terminals. A big, rough, and unhoned overview of this part of Unix.
Understanding the Unix philosophy and what makes a Unix system Unixy. Let the good discussion flow, let all arguments and ideas be put down on the table.
What's a shell, what does it do, why would we need that? A shell is a program that acts as an intermediary between the user and the operating system, the kernel. It lets you execute commands on a computer. Specifically, on Unix, the shell is a command-line interface, a prompt that waits for commands entered by the user, interpret and execute them, and when its done, prompts again for a new command. It stays in this state that we call REPL, read evaluate print loop, or interpreter. All that while hiding the details of how it did it.
The idea of green text on black background comes from the "Green screens" aka monochrome monitors. It was nicknamed Green screen even though the monochrome monitor came in many other different colors other than green. A monochrome monitor is a monitor that only has one color, as the name implies. It was used before color screens were invented in the early days of computing, from 60s till the 80s, as a successor to the teletype terminal, which was a typewriter, with papers connected to a machine.
We've had a previous episode discussing xcb, x11, wayland, all about display servers. I've said in the beginning of the episode that it would not be about window managers. Well, today folks we're going to do just that. This one is going to be about window managers and desktop environments.
You check your processes and see some hanging around with a weird status and using no resources. You don't know if you should remove them or not. Then you try removing them and it doesn't work. In this episode we're going to discuss zombie processes.
Welcome to hell, choose your default program! You'll soon learn in this podcast why this subtitle was chosen. Let's go, follow my train of thoughts and don't get lost. The default programs...
Mind maps are, from wikipedia, A mind map is a diagram used to visually organize information. A mind map is hierarchical and shows relationships among pieces of the whole. It is often created around a single concept, drawn as an image in the center of a blank page, to which associated representations of ideas such as images, words and parts of words are added. Major ideas are connected directly to the central concept, and other ideas branch out from those.
What's happening here! This isn't a podcast about window managers and the ways to make one. (Though we might record one in the future) It's about the architectural differences between the different ways of interacting with the system to display graphics. Be it by interacting with other layers such as X11 or higher or by directly drawing them on the screen. It's really not about how to use the functions, and the technicalities and intricacies of every one of the softwares we're going to mention. We might do that, but again, it will be the subject of another episode. This one will only be an introduction. In this podcast you'll get a general overview of x11, xlib, xcb, and wayland.
Signals have been there since the very first version of Unix. They were just a bit different from what we know today. For many reasons in fact, they've gone through many iterations of development and ideas. Today we have one single system call to catch all signals but that only appeared in version 4 of Unix and before that there were different system calls to catch different types of signals. In version 7 of Unix signals received a symbolic name for the number corresponding to the signal, for instance, "KILL" "HUP". The kill command appeared early on in version 2 of Unix. BSD soon added the SIGUSR1 and SIGUSR2 signals to their version with the aim of using it for IPC.
Hello fellow readers, In this post I’ll list some of the projects and experiments I worked on or finished since last time, or planing to work on in the next few weeks.
Hello fellow readers, In this post I’ll list some of the projects and experiments I’m working on or just finished. My last projects update was in February.
Hello fellow readers, In this post I'll discuss what programming and computing are for me. Computers are tools. Their functions can be summed to entertainment, utility, and information. It's common to find persons loosing themselves to a tool, slave to their creation. Programming is something useful. It's a big domain where you learn languages to instruct a machine to take actions. Those instructions can range from outputting things (maybe screen pixels but not limited to that), taking inputs from the outside world (not necessarily a keyboard or mouse), doing calculations at very high speed, storing data, and transferring data.
Hello fellow readers, In this post I'll talk about group and community projects. Everyone has been part of multiple group projects throughout their life. From school researches, to university presentations, to work. It's only by sharing ideas and finding common grounds that goals can be achieved. However, it's hard to maintain cohesion and investment in a group. There's a multitude of problems that arise, the reader can certainly assert it.
Hello fellow readers, This week is TTY week at nixers.net. Last summer we did the same challenge and it turned out a pretty enjoyable and a great learning experience. I'm going to add logs in this post and hopefully it'll render beautifully (because I can't check my blog from the TTY.)
Hello fellow readers, This post is about a little adventure I had with maths. I'm currently reading a book called `clever algorithms`, I go along at my own pace doing researches on hard subjects or things I forgot from high school. Digging through the cross entropy algorithm I had to take a break and learn more about distribution. Namely, I wanted to refresh my mind about the normal/Gauss law.
A hot subject these days is privacy. Since the Snowden's leaks we have been getting headlines about privacy every two or three days. This post is not about something new but it's to dwell into ways of thinking we haven't been accustomed to. I don't personally have any interest in conspiracy theories and secret societies but it's still interesting to relate it with terrorism, as we are in an era of psychotic people.
Hello fellow Unixer, This thread is about a must have software engineer tool called an UML(Unified Modeling Language) designer. More precisely, it's about finding the open source UML Editor/Designer that you need.
Hello fellow readers, This thread is about obfuscating the content of a webpage. This might not be so useful, security wise, because all the sensitive information should be kept server side. However, for the ones trying to reverse engineer the page this is a huge obstacle.
Hello fellow Unixers, In this thread I'll explain how to enjoy playing games on free Unix OS for a cheap price. The rumor that gaming on Unix is bad has been around for quite some time now. While it's almost true for the newest games with the 3D rendering that makes hair looks so real that it feels like your own hair are fake, it's still not true for all games. I won't start blabbering about "Steam"TM because the internet is already infested with it. I won't, also, write about running games through wine for the same reason.