I am happy for you. But also don't care. But also lightly irritated by you distracting me from the task at hand with your "great news". By showing unwanted popups to your users you tell them "our desire to show you something matters more than you".

Don't show popups. NEVER show popups.

Y'all just don't like the answer that people who commit suicide gave. And that forces you to create those hotlines and yell about them (and suicide) on every corner into the faces of people who struggle with that question.

Read Ernest Becker.

Golang is easy to learn and perfect for beginners, and as a newer language, it offers better-optimized features and less time typing. Go code is more compact and doesn't have unnecessary parentheses in its syntax. On the other hand, Java is an object-oriented language with many libraries.

Oh, really? "better-optimized features"? Like what, like a terrible package management system?

Less typing? Is that the criteria we have for a good SDL? Not a good package management system, not a thought-through class system that encourages good design, no. Having to type func instead of public void method makes a better language now?

There was functional programming, object-oriented programming and now we've got keyboard-oriented programming? Have you heard of auto-completion?

In my practice, any language that uses abyrvalgs (watch "Heart of a dog", you brutes!) like func sacrifices readability of the language and is not suited for any large or commercial projects.

Why? Because large and commercial projects require millions of dollars to be spent on supporting them and your ugly abbreviations make it only harder.

P.S.: Oh, and don't get me started on that "modern" feature of aliasing imports. Having the ability for the same library to be represented by different names in different importing source files is just begging for chaos in larger projects.

I installed HomeAssistant onto my old Android Phone. It wasn't easy: first, I had to enable adb and install my termux-launcher without being able to use the broken touch screen (that's why it's an "old" phone :). I was hoping that hass would be able to run directly on it, but that didn't happen because of the dreaded cryptography module issues thatprevented it even from being installed :(

So, I had to install debian using proot-distro. Luckily, hass agreed not only to install onto it, but even (after some editing of the usb component) was able to start, despite three levels of containerization (android, termux, and then proot).

But now... oh, now my boat got some Android brains, which I, an Android developer, am very excited about :)

I also finally received plywood and now can start building the galley. I'll update you on that part of the project next week.

These are challenging days for IT. The amount of data our systems need to process grows exponentially. This challenge is further amplified by the growing complexity of data. Information is useless without its context, and context is established by relations between different data points, but each relation also requires logic and processing resources. As a result, demands on our data storage and retrieval systems and their management complexity increase, rendering manual database management practices less and less viable.

Luckily, this is not the first time engineers faced a problem like this. Our history is full of inspiring examples of how to deal with growing demand. From the first windmills through steam engines, and screw-cutting lathes to Ford’s conveyor belt — looking back at the Industrial Revolution, one can conclude that appropriate and successful automation can ignite new levels in productivity and increase economic growth.

Kubernetes as a Lathe

Another example of successful automation comes from the early 2010s. At that time, we faced a similar problem but with software architecture: The internet changed everything about how a user application works. Our first approaches, rooted in applying well-known centralized architectures from the client/server era, did not work. Big, centralized application backends just could not provide the flexibility required to scale from thousands to millions of requests per second. Most of us probably can remember at least a couple of cases when “monolithic” web applications were experiencing severe performance issues after going viral.

The solution to this problem came from adapting an approach where organizations split these monoliths into smaller “micro” services running on docker containers that can be horizontally scaled both independently of each other and much quicker than monoliths. With each microservice adding to the demand on development operations, this strategy, however, wouldn’t be so successful without container orchestration frameworks like Kubernetes. Introduced publicly in 2014, Kubernetes, formerly known inside Google as Borg, quickly proved itself as a top choice for automating deployment workflows and today is one of the industry standards for modern development operations.

Also, being an open source, cloud native component, Kubernetes continues to evolve and improve. Echoing the idea of automated software installation packages, Kubernetes not only abstracts away specific infrastructure implementations but also automates environment creation and deployment procedures. Most organizations that use Kubernetes trust it to run at least 50% of their overall workloads.

Autonomous Operators

Today, we find ourselves in the early days of the data revolution. And, just like at the dawn of the Industrial Revolution, the world is expecting us to meet the demand in data processing by automating the management functions of our data platforms.

When it comes to working with data and databases, automating management operations can give impetus to the growth of any organization relying on data insights and decision-making: stability as well as agility through repeatability. Human operators, while being great at solving problems and innovating, are not that great with routine tasks and quickly become error-prone. Operations tasks like scaling up and down, backups, patching and routine database maintenance are examples of such activities. Hearing “oops, wrong command” from your database administrator can be a nerve-wracking experience.

The problem to solve is to take the best practices of these human operators and efficiently automate them in a standardized way.

Ten years ago, creating an automated management system for databases required a lot of effort, as it had to be built from scratch. This naturally caused the emergence of managed database-as-a-service (DBaaS) solutions. AWS was the first big company to create such a service with their DynamoDB launching in 2012. Following its success, other big players rushed to the new market as well. Using a generic DBaaS, however, has its problems (e.g. vendor lock-in, usage requirements for specific versions, minimal customization for specialized workloads, etc.).

The evolution of Kubernetes into an automation Swiss Army knife changed all that by providing a great and stable software management framework. An especially important milestone in this evolution was support for stateful sets and persistent volumes, as databases are a textbook example of a stateful application.

Employing elements of control theory, Operators work as Kubernetes extensions/plugins and use custom resource definitions (CRDs) to define and control the state of your services. Building your database environment with declarative CRDs is fairly easy: What you type is literally what you get. The operator reads your CRDs of the desired state of the system and not only creates it for you but also monitors the environment using internal events and ensures that the system is always close to the desired state. No more complicated setup scripts — your whole database system is standardized, described in a declarative language (YAML) and is self-explanatory.

Couchbase Autonomous Operator was one of the earliest products to utilize this framework extensively for database automation. Many other community-built database operators for Kubernetes have also become popular in recent years. Several communities and interest groups have also arisen around the technology, for instance, the DoK (Data on Kubernetes) community.

The New Horizons

The rise of DevOps, DBaaS, Kubernetes and Operators creates a compelling end-to-end platform for distributed applications. Developers need not worry about how their code is deployed, or how different components communicate with each other. Instead, developers can concentrate on the data and the logic that governs its evolution to provide improved insights and decision-making abilities for the business. Finally, the same consistent tool/framework can be used for managing all layers of the application stack, including the mission-critical database layer. Freeing important resources of organizations from routine labor-intensive tasks, automation creates space and time for innovation and further progress.

More widely within the industry, the future looks bright. Cloud providers are turning to fully managed services to offer a new business model. With most of these database innovations being open source, some of the cloud providers added a wrapper around those open source technologies and offered it as a DBaaS. Unfortunately, this strategy hasn’t been good news for everybody. It has greatly impacted other database vendors’ revenue, forcing them to change their licenses. While the precise approach has differed from vendor to vendor — with some opting for Business Source Licenses (BSL) and others for Server Side Public Licenses (SSPL) — the end goal has been the same. However, this is an evolving landscape, and it’s hoped it will settle down to a state where it benefits most and original research and innovation are rewarded.

You can read it in detail here: https://github.com/chedim/cliffhanger/blob/main/FFI.md

TLDR -- all communication between cliffhanger application components will be done over network sockets, even if all components are running locally on the same machine.

In a sense, cliffhanger FFI interface is an RPC protocol.

You may rightly wonder why I chose this particular interpretation -- network calls are orders of magnitude more expensive than procedural calls, which means that cliffhanger applications will be very, very slow compared to applications built using classic languages like Java, Go, Rust, C++ or even python.

Well, so what if it is going to be slow? Cliffhanger is not a systems programming language. It is a data manipulation language, designed to glue microservices into a single application. This makes it more important for cliffhanger to be a useful programming language rather a fast one.

Using a network protocol to interact between application modules would allow independent deployments of CH application components. Clifhanger libraries are not just libraries in a classic sense -- they are services that can be hosted by their developers (or, if a developer allows that -- downloaded an run locally). It would also allow a single application to securely span across all the network barriers of the Internet. In a sense, cliffhanger is not a programming language, but a devops tool.

That's why I think that making CH a natively network-aware language is more beneficial to it than making it fast.

What do you think of my decision? Please leave your thoughts in a comment below or tweet them @chedim :)

i3lock &
(while pidof i3lock; do
  if (fprintd-verify | grep verify-match); then 
    killall i3lock
  fi
done) &

Thank you for reading this second post in my blog about computers, software engineering and cloud applications. In the first post I introduced myself and my philosophy around coding and computer systems. This post marks the beginning in our exploration of how computers work and how humans build the incredible interactive experiences of the modern Web.

I named this blog "Down from the metal, up through the cloud, and back to the UX" because it captures the general flow of data in modern computer systems. This title will also serve as my plan for publishing articles on this blog. And so, in this article, I am getting down to the metal and exploring how human input devices capture our thoughts and ideas and transform them into electric signals useful for computers.

Computers work by performing a list of repeatable operations (a program) on some data. It is common to refer to this as Von Neumann architecture . Guaranteeing repeatability and correctness of these operations was the main problem of early computer technology as the entropy of our world tends to destroy any organized data. Von Neumann architecture addresses this problem by creating an isolated computational environment that communicates with the world only via a set of specialized input/output devices.

Many different types of input devices were invented throughout the history of computer technology. But none of them was as impactful on our world as computer keyboard, which makes exploring how it works the best starting point for learning about computers and data.

It is hard to trace who authored the source code for the first keyboard controller and driver, but it likely to be someone who worked on MIT's Multics operating system as it was the first computer system to introduce the computer terminal as we know it.

So, how do keyboards work? I will answer this question using the mobile keyboard I designed for my phone as an example. And, as a bonus for my readers, I will publish for the first time design files for this keyboard at the end of this post.

An early prototype of my mobile keyboard on the back of a Surface tablet

Although it may not look like any other keyboard you've seen before, it uses the same principles, technologies, and components that you may find inside of any other desktop or mobile keyboard produced in the last 40 years or so. The journey of any textual data entered by humans into a computer system can be traced to the most fundamental component of the keyboard. And so, please welcome the queen of computer technologies - the keyboard matrix .

A keyboard matrix is an electrical circuit that allows computers to capture the state of multiple keyboard keys arranged into rows and columns. It may seem excessive and too complex to people somewhat familiar with analog electrical circuits. Some of my readers may even wonder why can't the keys be connected directly to the computer as you'd see on the classic electric circuit that shows a single switch and a bulb. Although it is possible to build a keyboard by connecting the keys directly to a microcontroller, such a solution requires more connections to the controller, and using more pins (points of electrical connection between the controller and its circuit) means using either more complex and more expensive microcontrollers or, alternatively, more less powerful microcontrollers (which ends up being even more expensive than using a single more capable controller). There are other hardware design problems that affect reliability of such a design, but diving into them is out of scope for this post.

For example, one of the most popular microcontrollers, the ATMega32u, has 4 8-bit GPIO ports, which results in 32 pins available to the designer. One would need at least five ATMega32u to read the state of a regular keyboard if the keys were connected directly to the controller, while arranging keys in a matrix pattern allows one to read the same state with just a single microchip.

To be able to read the state of the keyboard keys, a microcontroller needs to know how exactly is it connected to every key of the keyboard. This is where keyboard firmware first comes into the picture. The basic element of any keyboard firmware is the matrix scanning loop, during which the state of every key is read and stored into the microcontroller's memory.

The matrix state, however, does not represent the information a user enters on their keyboard because such a state is just a snapshot in time. All it can tell us is that some of the keys are pressed while others are not, but it tells us nothing about the order in which these keys are pressed. The information we enter using our keyboards is retrieved by the keyboard firmware by continuously comparing these snapshots to each other. Only by looking at the changes between these snapshots the firmware can detect what exactly and in which order was entered by the user. And it is these changes, not raw matrix states, that microcontroller's firmware sends to the computer that keyboard is connected to. When you press a key, it changes the state of the keyboard matrix that is read into the microcontroller's memory. Comparing this new state with the previous allows the firmware to detect a keypress and report it up to the computer.

Calculated by the firmware matrix state changes are usually sent to the computer using a special set of predefined codes called scan codes. Every time a new matrix state change is detected and its scan code is calculated, the keyboard firmware notifies your computer about such a change. For example, one scan code can be used to notify your computer that the "A" key was pressed on your keyboard, while another will be used when it is released. Different protocols and transfer mediums can be used to send these changes and reviewing them all is well beyond the scope of this article. Instead, I will describe this process in general terms of x86 architecture and will leave a more detailed review of HID protocols for future articles.

In x86 as well as in many other architectures every input or output device is connected to the main CPU of your computer via input/output ports, repeating the same pattern we saw when talking about microcontroller pins. When keyboard firmware wants to send a new scan code to the computer it sets the port through which it is connected to the computer into a special state. In the real mode of x86 architecture, such a change results in a special kind of event called an interrupt. It is called that way because in early computers handling such an event would involve interrupting the currently running application by switching the CPU to execute the event handler.

A keyboard interrupt handler, when invoked, would read sent by the keyboard firmware scan code from the port and put it into the computer's keyboard input buffer, from where it can be later read by the computer's operating system or a user application, which would process the scan code either by transforming it back into entered by the user text or handle it in some different way. In a sense, the only job of the interrupt handler is to ensure that data flows from the keyboard into the system buffer without being lost or corrupt in the process.

Describing how user input is handled inside of an OS is, however, a topic for a whole different article that will continue our journey through computer technologies later. But to prepare us and make these next steps easier, I want to finish this article by providing you a bigger picture of the keyboard input subsystem and pointing out the long-reaching implications that can be drawn from such an overview. The easiest way to do so is to represent the keyboard subsystem as a set of layers through which the data you enter has to travel to reach your computer:

A simplified overview of a typical keyboard data pipeline

Understanding general principles of how computer keyboards work is very helpful to understanding how modern computer systems work. By guiding our journey to the first glimpse into what data is and how it wants to be handled it shifts our focus from learning algorithms to learning about how data behaves inside computer systems. It shows us that, on the lowest levels, data is not just a set of bits and bytes. Instead, it is more beneficial to think of information as history of changes that some system (in this example - the circuitry of a keyboard) goes over time. This view is not limited only to textual data and is also applicable to audio and video: audio information describes changes in air density of a system and video information most often describes changes in visible part of electromagnetic spectrum.

Although knowing how keyboards work is not required to be a coder, going through this showed us some fundamental properties of information that dictate how modern computer systems are built:

Any data processed by a computer can be viewed as a stream of changes of some state over time. Thus, one can say that data is not simply operated upon or stored by computers but that it flows through computer circuits in the form of events and electrical signals. As it flows through the system, data goes through different layers of logic and causes that system to change its state. Every logic layer analyzes the data that flows through it and adds more meaning to it. This additional meaning is used then by higher levels to either perform some action or to add even more meaning to the data. Therefore, engineering computer systems comes down to designing these layers and adding more meaning to data as it flows through the system. This pattern governs how all computer systems behave and can be observed in every single one of them. The OSI network model, a cornerstone technology of the Web that I will review in one of the next articles, is a great example of a system design that uses these principles with great success.

Even if you don't write firmware or device drivers and your work is mostly concentrated in building web applications, adopting this datacentric view and promoting data and its flow to the center of your thinking about a computer system will allow you to avoid many bugs and performance bottlenecks and design better computer systems, be it a simple calculator application or a complex decentralized social network that runs on millions of physical nodes built with different internal designs.

Please stay tuned for the next article "Down from the metal: making sense of the input", in which I plan to go over how computers parse keyboard (or any other) input and use it to react to the changes in the surrounding world and satisfy requests from their users.