In-depth news about Linux and Free and Open Source Software.
Headline: Announcing Plasma Studio
Open Source World · 13 minPlasma Studio is a multimedia handling application that features video editing capabilities, raw photo editing, vector graphics, animations, audio editing, recording and streaming, and 3D modeling. It is fully hardware accelerated, implements up to 16bit surfaces, and it is implemented via a
continues at page
Table
of contents
In this issue
9 pieces / pages
Android prefers vibecoders over open-source developers
Legislation · 5 min · p. —
I Made the "Next-Level" Camera and I love it
Open Source World · 19 min · p. —
I made the ultimate productivity device for less than 50 bucks
Open Source World · 9 min · p. —
The political use of operating systems
Legislation · 7 min · p. —In this issue
continued
My childhood dream laptop
Hardware · 13 min · p. —
I'm A Proud Luddite. That's Why I Use Linux.
7 min · p. —
What Have I Learned From Daily Driving Arch Linux For Three Years?
Distributions · 8 min · p. —
Is Linux market share going stonks or not stonks?
Open Source World · 3 min · p. —Help us break even
We only run on donations. We have a goal of reaching 300 subscriptions, which would allow us to hire staff.
If you subscribe, you'll gain access to a few members-only pieces, though we aim to keep most of our content free for all.
no ads · no trackers · cancel whenever
Announcing Plasma Studio
Plasma Studio is a multimedia handling application that features video editing capabilities, raw photo editing, vector graphics, animations, audio editing, recording and streaming, and 3D modeling. It is fully hardware accelerated, implements up to 16bit surfaces, and it is implemented via a QML libstudio library that can be used by any application to offer the same features. It allows to work via a node-based workflow, what-you-see-is-what-you-get editing, or through a code view.
Though the open-source space features plenty of great multimedia applications, they too often lack the ability to integrate seamlessly between each other. As an example, a vector art that requires both animated elements and an embedded video might require switching between Inkscape, Glaxnimate and Kdenlive, each project having limited support for other project files. An user might also want to have the same color-grading effects in Kdenlive as when they edit raw photos on Darktable. Finally, many of these projects do not feature hardware acceleration and are unable to handle heavy multimedia files (e.g. 6k 4:4:2 HEVC) without proxy files.
Plasma Studio wishes to build upon the great, existing effort done by other projects whilst offering a single, unified interface. Our ambition is to make Linux the preferred choice for creators, by establishing a powerful yet simple free-and-open-source alternative that anybody can download and use.
Today we announce the very first early alpha release of Plasma Studio. It only features a few features for each direction, meaning that any established multimedia application will far out-feature Plasma Studio in its scope. Furthermore, the project still has plenty of limitations and bugs; this is only the first step. We'd not get anywhere without a beginning, though.
Video Editing
As mentioned above, Plasma Studio fully features hardware acceleration and high bit depth support; on my machine, I'm able to edit 6K 10bit HEVC 24fps footage in real time even on a integrated Intel graphics card from 4 years ago. Videos are encoded and decoded via FFmpeg, so Studio's compatibility list is the same as theirs.
It features a variety of (barebone) color grading and graphical effects nodes, including: RGB curves, tone equalizers, custom LUTs, colorspace transforms, radial/linear blur, chromatic aberration, vignetting, and more. It also features a few scopes: histogram, waveform, vectorscope, RGB parade, audio levels and a spectrogram. Thanks to the intersection with raw photo editing, all effects will edit the image the same as if you were working on a raw photo (based on available bit depth).
And, thanks to the intersection with vector graphics editing, the preview can be edited as if we were on Inkscape, featuring simple drag and drop, resize, rotate, and shear. It's possible to add custom rulers and activate snapping, as will be explained later.
In order to easily add clips into the project, Plasma Studio offers a Files sidebar that shows all available files on the filesystem; each file can be previewed with a click, and it's possible to use i/o or drag and drop to select part of the video and add just that portion to the current project. Arrow keys will navigate through the playback (horizontally) and through the files (vertically).
Plasma Studio also offers a "Project Bin" section, which shows all media used within the project, with the ability to filter for unused files only, similarly to what Kdenlive does.
Currently, the timeline is quite limited. You are able to select clips to see and edit their effects and properties, drag and drop them and resize them. A razor tool (or a keyboard shortcut) is available for splitting clips, a Ripple tool can resize or move clips whilst also moving following clips as well, and a Spacer tool allows to move around multiple clips at once.
Furthermore, by using a Group (or Concatenate) node, you have the ability to group together clips as if they were a single clip, and then - by double clicking them - you can edit them directly, similarly to Sequences in Kdenlive. The same clip or Group can be inserted multiple time, though not concurrently.
As you might've noticed, however, the project currently does not feature tracks. Though easy to add, I still haven't found a UI and UX that I liked for them, and am therefore seeking opinions.
We currently offer both a Subtitle node that takes a subtitle file, and a Auto Subtitle node that will install a local Whisper model in order to perform the transcription of the given video. A simple chroma key is also offered.
Raw Photo Editing
Plasma Studio offers a Raw Photo node that will demosaic raw photo using libraw to the highest bit depth available. Though the demosaic step currently lacks options, which will soon be added, all other nodes can then work as intended.
Both the Exposure and the Tone Equalizer nodes allow for color input, and the RGB curve can interpolate based on as many points as necessary. All nodes, even the more complex, are hardware accelerated and drawn without any delay.
Masks are fully supported and come in many sizes: rectangles, circles, paths, and gradients. You can also perform unions, intersections, difference and exclusions between different masks to get any shape you'd need. It's also possible to create a mask based on a simple luminance or color range. Masks can also be feathered so that they don't have sharp edges.
Any of the color grading or graphical effects nodes that can be applied to the picture can also be applied to any mask, so that you can do anything with them!
Vector Graphics
As far as vector graphics goes, we support: custom paths (with a full path editor), text (with custom fonts), rectangles, circles, and polygons. All paths can support path operations (union, difference, intersection, exclusion), plus custom outlines and gradients. We however currently lack gradient outlines.
Similarly to Inkscape, drag and dropping from the (optional) rulers will allow to place guidelines; and, drag and dropping elements features full snapping support to horizontal/vertical centers, edges, path points, and more. The UI in the screenshot does not show the ability to toggle specific snap types, but the functionality is implemented behind the scenes and I'm currently deciding whether it makes sense to offer it out of the box.
We also offer various built-it textures, such as (animated) white noise, random noise, and checkboard patterns. All multimedia elements can be used, and they all feature opacity settings and all blending modes; though there's not a dedicated layer functionality, it can be replicated through simple grouping, and a Node Tree tab will be able to show the entire project structure. (All nodes can be renamed for bookkeeping purposes).
Finally, we offer a fair amount of layout options out of the box (column, row, grid, repeat, scatter).
The interesting aspect is that, unlike Inkscape where this actions will immediately reposition the element and do nothing else, the Layout nodes will instead keep existing after they are applied, maintaining the layout of the elements throughout the project. You can still ungroup the elements to get rid of the layout node, if you wish to break the positioning.
Animations
All properties can be animated. As you might've noticed, each setting has a "keyframes" button next to it, and pressing it will show the current keyframes for that property.
Animations are also displayed in a "Keyframes" bottom (toggleable) bar. They are displayed grouped by elements, with the ability to show/collapse both the elements and their specific animations.
Expanded animations will show graphically how the value changes over time, with the ability to change the easing curve (the screenshot does not show the curve within the graph, but that will be fixed ASAP too). Collapsed elements still show the value changing through the different lengths of the dotted line. Animations can be color-coded.
We also offer the ability to walk an element on a path, by using the Along Path node and animating its position element.
Audio Editing
Plasma Studio will offer a special view only featuring waveforms when an element has no graphics. It allows to move elements around, split them, re-join them, and apply a variety of audio effects to a selection.
The waveform is updated to reflect the audio effects that have been applied, though so far there is a small delay to re-construct the waveform. There's also a spectrogram view that displays the same interface but through the spectrogram tool.
Available audio effects include: volume, fade in/out, low- and high-pass filters, bass and treble, filter curve EQ, compresson, limiter, noise gate, amplify, reverb, echo, pitch, and channel manipulation. It's worth noting that I'm personally terrible with audio, so I'm not able to fully attest of the quality of these effects, and we use the MiniAudio library for playback under the hood.
Recording and Streaming
This is an area that still requires some work. So far, it's possible to connect webcams, screen capture, and record through the microphone. It's also possible to set up multiple scenes with a quick switch between them, and - thanks to all of the above features - it's possible to build quite complex scenes too.
The user can both record and render with via CPU or software acceleration at any given quality; however, we currently lack a node for streaming specifically, and it will be implemented soon.
Other work in progress includes the ability to use that recorded video and audio directly within the project without re-importing, for both audio and video editing, and the ability to set up transitions upon switching scenes.
3D Scenes
To be clear, Plasma Studio will never be even remotely as capable as something like Blender. That said, there are some easy wins that we could gain thanks to QtQuick3D, and some 3D functionality can always end up useful.
Studio currently has 3D nodes for simple shapes, extruding 2D elements into 3D, simple lighting and environments, transforms, simple materials, some camera features, grouping, and UV transform. Scenes are rendered via a 3D Camera object, which exposes some UI (as seen above) to directly edit the elements in space. The rendering part uses standard QtQuck3D.
More complex features will be implemented in the future, assuming that they indeed are offered by Qt; that said, I don't expect the 3D side of things to become a major selling point of the application, given just how commercially established Blender already is.
Libstudio
Plasma Studio relies on a simple custom library called libstudio; it is currently shipped with the application, but it will soon be its own library with proper documentations for available types.
All libstudio elements (and all nodes that I've shown you so far) are QML elements that can be imported and used in any project. Switching to the Code tab of a project will also show the required code to implement that project.
Though many elements rely on external libraries to work (e.g. FFmpeg for videos, libraw for raw images, etc.), the project is a real QML scene and Plasma Studio only works as a UI to directly edit that scene.
This means that it's extremely easy to expand the library or offer third-party plugins: any QML element can become a node, and QML is the same (markup-ish?) language that's used for the entirety of the UI of KDE Plasma and many of KDE's applications, so there's plenty of support for that already.
Another interesting aspect is that project files currently are fully valid QML files too, which can be run as applications or embedded in existing ones. This also means that project files are human readable, though not necessarily very pretty.
There's a few (intentional) downsides too. Most importantly, we decided not to use SVG for project files, as they only offer a fraction of the features we need (think of saving a video editing file to SVG), and there's not a dedicated "vector graphics" mode, but rather one unified interface for everything. This means that importing SVG will only import them as images, and there's no SVG export. In the future I'd like to implement some SVG <-> libstudio QML bridge in order to lessen this drawback, but - given that we implement a different set of features compared to SVG - the bridge will necessarily be not perfect.
Secondly, QML files allow for arbitrary code execution; this means that a malign project file can currently run code on your machine. As you can imagine this is a massive security vulnerability, and as thus:
The idea to fix this issue is to implement a subset of QML files that do not allow for any embedded Javascript code, and that are parsed manually by Studio. Again, let me remind you that this early alpha is meant to get feedback on design direction and bugs, and is not meant for real work.
The UI and UX
One explicit goal of Plasma Studio is to keep a very "minimal" and simple interface for even complex tasks, making it easy to find everything you might need.
As an example: Inkscape currently features side panels for exporting, fill and stroke, layout, and so on; however, page settings open in their own pop-up, and filters and extension expose their own UI, and their settings can't be changed after their effect is applied. Many actions, such as path operations, are accessible through the menu bar instead. Same goes for Kdenlive: there's a list of effects, but a popup for rendering options, another for project settings, and a few menu bar-only actions.
This is standard for professional application, but such a design wouldn't work for Studio, which has to cover an unusually large amount of tasks within a single interface. Therefore, we went for an entirely node-based approach: each multimedia input is a node, each effect is a node, the page (called Canvas) is a node, scopes are nodes, and rendering/recording/export actions are within nodes too, each node with its own settings.
This makes it particularly easy to find and change all settings. The shape and color of a rectangle will be within the Rectangle node, its outline settings will be in the Outline node, the look of the page it's drawn in is the Canvas node, and export settings are in the Export node. All settings are displayed in the Effect List right sidebar (or in the Nodegraph view).
All available features are exposed as nodes: you need automatic subtitles? The "Auto Subtitles" node has got you covered, managing the Whisper models in its own settings rather than being a custom popup.
We hope to be able to strengthen this node system over time, introducing more and better nodes with better organized settings; this is a great moment for you to express which features you'd like to see, so that they can be turned into nodes too.
Finally, nodes currently feature a (weak) type system, where they all define its own type (with inheritance) and can specify the type of the node they require, with UI errors when the type is incorrect. We hope to be able to expand this system with even e.g. number/string/vector/texture types, so that all properties of nodes can be connected a' la Blender.
How to test and report feedback
The code is live at this repository and can be built and tried out. You can use the issue section to report issue directly in the repository, and suggestions too! Please do create some issue with everything you'd like to be added, so that I can keep track of it (though I might close it just to transfer all feature requests to a single issue, or a few issues divided by category).
If you'd prefer not to build the application, a flatpak is also available; however, I have decided to make this only available to supporting members of this website at any tier, since they allow the development to keep going. If this project looks promising to you, I'd welcome you to consider subscribing, so that I can keep working on it and, hopefully, spend even more time on it!
How to install the flatpak
Android prefers vibecoders over open-source developers
Allow me to compare and contrast two different choices taken by Android developers.
One. Google announced (at I/O) a new AI Studio application that will allow users to generate new applications by simply asking for specific functionalities, "all from your phone".
See https://blog.google/innovation-and-ai/technology/developers-tools/google-ai-studio-io-2026/
You're able to "share live deployments with your friends to gather feedback and collaborate". I'm not against this: I think AI is a good tool to quickly "create" barebone applications that do one specific task you need that might not be found in existing applications (we all have our niche requirement, after all).
The announcement also states:
Connect your Google Play Developer account in AI Studio to publish your app to Google Play's Internal Test Track with a single click.
The Internal Test Track is a way to privately share an application on the Play Store to test it out, with a limit of 100 registered users. This latter functionality seems to only be available on the desktop version of the AI Studio, but the general approach from Google seems to be to making it easier over time to share with friends or publicly a entirely vibe-coded application.
Two. In 96 days - at the time of writing - it will become significantly harder to sideload Android applications.
Currently, you can install Android applications from any source. Depending on your exact Android derivative, you will be prompted to allow the manual install from your specific source (are you sure you want to install this APK from "Firefox"?). This takes a few seconds.
In a few months, the same task will require the following (taken from Keep Android Open):
- Delve into System Settings, find Developer Options.
- Tap the build number seven times to enable Developer Mode.
- Dismiss scare screens about coercion.
- Enter your PIN.
- Restart the device.
- Wait 24 hours.
- Come back, dismiss more scare screens.
- Pick "allow temporarily" (7 days) or "allow indefinitely".
- Confirm, again, that you understand "the risks".
As Keep Android Open states: Nine steps. A mandatory 24-hour cooling-off period. For installing software on a device you own.
Allow me to express my frustration at this choice: this means that it will be significantly easier to try out a vibecoded app with an user that has no coding experience, compared to try out application from (mostly open-source!) skilled developers.
Forcing users to exclusively install applications from the Play Store means Google has the final pick over whether you can install a certain application or not on your software. Even better, making it so easy to vibecode an application allows Google for even more complete control over your software stack, as the app will directly be provided by them!
As an example, five years ago Google decided to remove an application by Alexei Navalny made to organize tactical voting. According to Reuters,
Russia demanded this month that Apple and Google remove the app from their stores, saying a refusal to do so would be treated as meddling in its parliamentary election.
Both Google and Apple decided to comply with this request. A more recent example was reported by 404 Media:
Both Google and Apple recently removed Red Dot, an app people can use to report sightings of ICE officials, from their respective app stores [...] Google told 404 Media it removed apps because they shared the location of what it describes as a vulnerable group that recently faced a violent act connected to these sorts of ICE-spotting apps—a veiled reference to ICE officials.
As long as users are required (or heavily incentivized) to only use the Play Store as their only app source, those same users will be forced to comply with Google political stances – or rather, the political stances of governments who are able to force the company to comply.
When moving towards heavier integration of tools like Gemini in their Android developer workflow, Google is pushing their influences in the development phase of an application, not just the deployment. I see no reason to think that those same governments wouldn't be able to also force Google to disallow Gemini from creating such applications, not just publishing them.
Generally speaking, Google is under very little scrutiny over its review process of applications. An older example is when they decided to pull an important Emulator application out of the store without providing any reason for it. Though it could be argued that the emulator was infringing trademark, these claims are hard to dispute and generally settled in court; here, Google was able to unilaterally decide on the application's future, and not much can be done about it.
Publishing on the Play Store also requires paperwork and a (small) fee. This is luckily trivial for somebody like me, but as the Keep Android Open project points out, it becomes a significant issues for developers from countries where Google does not allow developers to sign up from, or in regions with limited access to Google infrastructure, or in scenarios where quick deployment is required (e.g. for a local emergency response).
This will soon be required to even share your application with a few friends... unless, of course, you vibecode it! I hope you can see the absurdity in this.
Is there anything we can do? I don't think so.
Here's the options:
- There's an open letter that's been signed by most Free and Open Source organizations. This includes KDE, Nextcloud, the EFF, F-droid, FSFE, GNOME, VLC, TOR, Proton, and more.
- There's a change.org petition with ~160k signatures. I have to say, I highly doubt that this will have any significant consequence.
A more likely path would be the regulatory one. Americans love to make fun of Europe for their digital rights laws, such as USB-C as a standard and the Digital Markets Act, but so far those laws are the single biggest source of user-respecting software from these giant multinational corporations we've seen.
Apple now allows application sideloading, to some extent, and it has finally switched over to USB-C for their phones too. Users are now asked for their web browser and search engine of choice. Interoperability is coming to messaging applications, and so on. These are all important victories that make everyday software more user-respecting, the opposite of what, in my opinion, Google is trying to do here.
However, I don't think this approach will yield significant results here. I'm afraid that Google will still argue that, technically, you're still able to install applications from third party developers easily (as long as they registered with Google, as described above), or even unregistered developers (through the mentioned nine steps process). They're not effectively closing down the ecosystem, but they are making it significantly harder to avoid it.
Nonetheless, I'll ask my local MEP (Member of the European Parliament) about this the next time I see him. Who knows! (Sorry Brando, I have to try.)
I Made the "Next-Level" Camera and I love it
This is one of my favorite lenses: the Helios 44. It has an "aperture" of 29mm, meaning that if you look straight through it, the circle that you see has a diameter of 29 millimiters. Why do we care, you might ask?
You probably know that pictures can be out of focus. But why does "out of focus exist"?
Well, without getting too technical, the lens takes the rays of light emitted by an object and then converges them into a single point; if you place the camera sensor in that point, you'll be able to see the object. However, if you place the sensor closer or further away from where the rays of light intersect, then you'll get a circle and the image will be out of focus.
Now, here's the kicker: the bigger the focusing lens is, the larger the cone of light rays is, meaning the the out of focus parts of the image will be more out of focus:
This is (partly) why phone cameras can't naturally reach the same levels of background-out-of-focus that camera can reach: they have such small lenses!
This is the camera lens that I do most of my work in. As you can see, this lens is much bigger; indeed, its (maximum) aperture is more than 53mm, almost double what the Helios can offer, which allows for a very strong separation between the subjects and the background.
The question now is: how big can we go? How much blurriness can we get out of a lens?
Well, assuming we're okay with carrying around a lot of weight, we can go pretty big. As an example, take the Sigma 135mm f1.4; this lovely lens (which I sadly don't own, yet) has a majestic aperture of 96mm,
and it can deliver pictures like the following one. There's a catch, though: due to physical constraints, all of these large lenses are also always very "zoomed in"! Take your phone camera and set the zoom to 4x: that's roughly what you're going to get with this Sigma lens. This can be great for some scenarios (and it's my favorite focal length indeed) but what if we want to keep the same giant aperture but with a wider field of view too?
Well, we can't.
The reason is: remember the cone of light rays above? The bigger the lens is, the bigger the cone of light is too. But also: the wider the field of view of a lens, the bigger the cone of light too.
And, the combination of wide-angle-view and super-high-aperture would literally require light to pass through the metal of the camera in order to reach the sensor:
In order to work around this, you'd have to quite literally tear your camera apart in order to expose the sensor. Somebody has done it, namely some "Stanley Kubrik" guy, and - of course - the lovely folks at Media Division:
But even so, Kubrik only reached ~71mm of aperture, and that's still on a 50mm focal length lens, which is 2.7x wider than the 135mm mentioned above, but also not exactly a wide angle lens either. Media Division instead went for 136mm of aperture, but on a focal length of 100mm, awfully close to the 135mm. Also, I'm not taking my camera apart. And, finally, all of these solutions require these giant pieces of lenses that are extremely rare and pricey.
Luckily, there's a solution to all of these problems. Meet the Charles Beseler 18" Series III:
As you can see, it's absolutely huge. It's also really cheap to get: I bought to for around 200€, including shipping costs. These lenses were produced a lot of time ago and they were used as projector lenses, in machines like these:
They are no longer used nowadays, and can be bought for cheap. And, as one can see by naked eye, they have a giant aperture. I can only provide an estimate for it, since there's no specs sheet for it, but it should be around 125mm.
So, you might ask, is this a wide angle lens? Well, the 18" in the name is telling us its focal length, and - converted to metric - that's ... 457mm. Which is roughly a 13x zoom in your normal camera, and so much more than we were looking for. Oh, no. Well, we knew it was physically impossible anyway.
Also, look how crazy of a contraption you have to build in order to connect this giant lens to a camera:
Though, it would produce some pictures, and indeed we can see a lot of out-of-focus (but also a lot of zoom...):
Fear not, though, the Charles gives us an extra tool to work with. So far, we've always assumed that we were working with a camera like mine, with a "standard"-sized sensor (it's called "full frame").
Suppose instead that we have a sensor that's double the size of mine. That would make for a pretty big camera, but still: a bigger sensor is able to capture a bigger image, effectively "zooming out": thus, our 457mm lens would become a 228mm lens. That's still not enough.
Let's double the size again. We're zooming out by a factor of 2 again, reaching a focal length of 114mm. That's still too much zoom. Let's double the size of the sensor again. We're now at 57mm. This is better already, though we should probably make the sensor just a bit bigger still, so that we can be around 40mm.
This means that the size of the sensor needs to be: the original size, times two, times two, times two, times one point five; that is, we need to increase the sensor size by a factor of 12.
My camera sensor size is 35mm by 24mm. Multiplied by 12, we get 420mm by 288mm. That's, uh, 42cm by 29cm. It's, like, pretty big. That's the size of a painting you'd hang on your wall. This gives us two issues:
Firstly, such a sensor simply doesn't exist. Films shot on IMAX use very big "sensor" (it's film) areas and we're talking about ~7cm by 5cm. It's not even "it's expensive" territory, it simply... does not exist.
Secondly, lenses usually can't project an image big enough to cover such a large area. Most lenses are designed to be used with Full Frame sensors nowadays, or slightly bigger ones (such as "Medium Size" – look, I don't make the names).
The good news here is that the Charles was not built "nowadays". Maybe back then they didn't get the memo about future sensor sizes. How can we check how big of an area our lenses can cover?
It's thankfully pretty easy. If you simply put a lens near a white surface, you'll be able to see what the sensor would see. The Helios projects a rather small image on my white wall, but that's just enough to cover the similarly-small full frame sensor in my camera.
I do also have lenses that project bigger images. As an example, this weird lens that found in some used market gives us a pretty big image circle. It certainly covers a camera sensor, even a "Medium Size" one, but not a the 43cm by 29cm area we need.
The Charles produces a giant image. It's tough to see it exactly because the lens has to be very far from the wall now, thus the image is very faint, but it's there. I'm not sure how big it is, but it's bigger than 43cm by 29cm. This is it.
Now we have to deal with the incompetence of the human mind and quickly invent a new giant sensor, bigger than anyone has ever seen. It should only take a few minutes.
Jokes aside, what we need to make this work was invented a long time ago for camcorders. Back then, we were dealing with a similar problem: we had these consumer video cameras with very small sensor, and we had "pro" camera lenses that were designed to handle much bigger sensors. We needed some kind of "adapter" that would allow to connect the two.
This adapter is called a Depth-of-field adapter, and here's how weird it looks.
The idea is the following: we build a big "fake sensor" that's actually just semi-trasparent paper, and we focus the camera lens onto that "fake sensor". Of course paper by itself is not going to "capture" any image, but we can then go on the other side and take a picture of the resulting image, like this:
This is a rather weird two-step process, if you think about it. It needs to have a first lens that supports a bigger sensor area, then you project to a big "fake sensor", and then you need another (smaller) lens that captures the image coming out of the "fake sensor" onto the actual, real sensor of the camera.
All of this works because "semi-transparent paper", when lit by the lightrays coming out of a lens, will allow us to see exactly what a sensor would see if it was placed there. The reason is that the "semi-transparent paper" scatters light randomly, and so it deviates the lightrays from traveling straight to traveling towards our eyes (and all other parts of the room).
Let's see what's required to build this in our scenario.
Firstly, we have the Charles lens, which has to see the world on one side, but should be within a box or something on the other side, so that no there's no light messing with our image.
Then, within the box, there should be the 42cm by 29cm "fake sensor", and it should be made by some semitransparent material that scatters light without absorbing it. The Charles has a focal length 457mm, which tells us that the fake sensor should be at least 45cm away from the lens. Also, in order to focus the lens, this distance needs to be able to increase if necessary (even by ~2x!).
Then, beyond the fake sensor but still within the dark box (otherwise light will mess everything up), there needs to be an actual camera that takes a picture (or a video) of the fake sensor. The distance here depends on the exact camera and lens, but it's usually around 35cm.
Great. Let's build this.
Since the distance between all components will need to be adjusted, and since all of these components weight quite a bit (the lens is around 3kg!), I decided to go with a metal sliding rail (more technically, a vslot 2080) for the base. Then, bought a few sliding plates for it, which have a variety of holes in them.
Let's start from the Charles lens; we need to hold this lens at a certain height and attach it to the base plate. My solution was to hold a second plate up through some long screws and nuts to adjust the height. Then, to hold the lens, I found a couple of telescope holders which have three axis adjustments and support lenses up to 15cm. They had holes in the bottom to screw them onto the plates. Then, I can just insert the lens within the telescope holder and tighten the adjustment screws all around.
Then, on the opposite side, I went with the same idea to hold my actual camera; however we didn't need any telescope holder here, as there's a ring holder for my specific lens which can be just as easily screwed on the base plate.
Onto the fake sensor, then. Firstly: what should it be made of? I tried the following.
Paper. This does not work, as it captures almost all light that it receives, and thus you cannot see through it.
Papier-mâché. This lets some light through, but still very little, and it adds a very heavy texture to it. Also not ideal.
Baking paper. A surprisingly good solution, but it still doesn't let much light through, and you can see a light texture. Still, this is great for quick prototypes, and I used quite a bit of it.
IKEA PUCKELFLY. This is a frosted window film, which does roughly what we want, since it lets light through but also scatters it. This worked pretty nicely and was a great option to me, but it also introduced some heavy texture to the image, as you can see the grains in the image.
Wax. This almost sounds like a joke, but if you're able to create a ~0.3mm thick layer of melted wax, this should act as a great scattering surface that still lets a lot of light through. I spent quite some time attempting this, but I was ultimately unable to create an uniform layer. I still have kilograms worth of wax and I'm not sure what to do with it.
Homemade frosted glass. There are a few ways to achieve homemade frosted glass, and the easiest is to use some fine grit material between two sheets of glass and rub them together. I had issues finding the right grit, and was ultimately put off by the amount of work that this option requires. However, it's also the option that should provide the best results.
Photographic diffusion film. Okay, context: when you have a small but bright light, this will cast a very hard shadow, like the sun. Sometimes, you instead want to turn this into a bright, large light, that casts softer shadows. The easy way to do that is to put a diffusion film in front of the light, which will diffract the light around and effectively act as a bigger, softer light. This layer should absorb little light by design, and it's available in most photography shops. It's also relatively cheap, I paid 10€ for it, it works well. The only issue is that there's plenty of options, and all of them have some texture to it.
After much experimentation, I went with a "Lee Filters - 251 - Quarter white diffusion", which provided the best results for me. Note that it needs to be kept between two layers of glass, since it's a sheet of film.
Next up, I need some component that keeps the layers of glass and attaches to the base plate. I decided to go with a 40x30cm picture frame. The benefits of this choice are that it's a standard size that's easy to find glass for, and there's plenty of frames too. There's also a drawback: cameras don't record in a 4:3 aspect ratio, but rather (in opengate) 3:2, a bit wider. Thus, I'll have to either record more area and crop, or only record part of the fake sensor. It's not a big deal.
In order to secure the picture frame I simply used a few screws. It's more stable than you'd think. Note that, just like for all components here, I went through multiple iterations and the frame that you're seeing is, like, the 5th different picture frame I bought.
Now, we're finally able to position all components correctly! It sounds simple, but it took months just to get to this step. I had to receive most components from China and go through multiple iterations, but we got there. Now, for the hard part. We need bellows.
Camera bellows are these components that can change their size but remain rectangular in shape, allowing to change the distance between lens and sensor but without letting light in. They. Are. EXPENSIVE.
Luckily, it's easy to manufacture a small bellow. Sadly, we need an enormous one, and we still need to manufacture it ourself.
There are multiple ways to do it, (and I've tried them all!), but I'll keep the details light here. The general idea is that we need some materal that can bend (such as paper), but within it we need some places where it can't bend. Usually this is done by attaching precisely cut cardboard onto some paper.
Then, you can bend specific parts to make the bellow. This is a rather time-consuming and fatiguing process, when the bellow is as large as I needed it to be! But, after much thought, I was able to come up with two tricks to simply it.
Firstly: all bellow images I've shown you so far were of bellows where the entrance rectangle is bigger than the other side, and thus they have this trapezoid look to them. This is appreciated, since we've got a 40x30cm sensor on one side, but the lens on the other side is much smaller. However, this makes them harder to manufacture, so I decided to go with a much simpler bellow that's 40x30cm on both sides.
Secondly: I used IKEA curtains. No, I'm not kidding. Meet the SCHOTTIS.
This curtain is provided folded in ~3.4cm stripes, and it's available in a black color. Since it's a curtain, it's also able to block light effectively, and since it's IKEA, one of the side is plasticized and thus tough to break or tear apart.
This makes our job much easier, as now it's just a matter of leaving the folds where IKEA intended them, cut the curtain into four different pieces, tape them together in a different direction, and re-fold the entire thing correctly. The final folds on the bellow are either the existing ones in the provided curtain (possibly in the opposite direction), or in the places where we cut the curtain, so everything else gets to remain more rigid.
This was still a multiple-hours-long process, especially since I had to manufacture a couple of bellows to test different properties. This year I decided to catch up with Severance and I'm not joking when I tell you that I watched the entirety of the first season whilst folding IKEA curtains, cutting them, and taping them together again.
Ultimately, I had my bellow. It doesn't look stylish but it works. On the lens side I placed another picture frame with cardboard inside and made a hole at the center, so that I had 40x30cm components on both sides.
Then, let's talk about the space between the fake sensor and the camera. There's no way that I'd make another bellow, but thankfully the distance here has to be fixed (depending on the taking lens). I measured the most convenient distance and made a cardboard element with the correct sizes. It's not as sexy as the bellow but it does the trick, and - if necessary - I can still insert the lens within the hole at various distances for small adjustments.
There's one final component to put in place. Right now everything works, but I get some heavy vignetting, i.e. the corners of the "fake sensor" are dark. This is expected: the frosted surface reflects some of the light, but most of it just goes through it and we don't see it.
There's an easy solution to this: before the "fake sensor", we can place a lens that will change the direction of the light from outwards to towards the sensor. This way, most light will still travel towards the camera after passing through the sensor.
However, you should see an issue coming up: a lens that's big enough to physically cover a 40x30cm sensor would require a diameter of 50cm. That's a gigantic lens: the Charles felt pretty big already and that was just 14cm. It would be extremely hard to manufacture and very pricey.
This is where lighthouses come to the rescue. Yes, you read that right.
Each lighthouse has a big source of light; however, in order to make that light shine in the right direction and the maximum intensity, you also need to place one lens in front of it. However, a lighthouse light is even bigger than our fake sensor, and the required lens would have to be absolutely gigantic.
Because of this, a new type of lens was discovered! It's called a Fresnel lens, and it works similarly to a normal lens, but it's flat:
Thus, a lighthouse was able to use big flat lenses, which are much, much easier to manufacture, as they don't require huge chunks of glass:
Fun fact: you can actually see fresnel lenses in multiple places where a normal lens would be too big or expensive. As an example, my own building places fresnel lenses in front of exterior light to direct the light correctly!
Anyhow, the good news is that we can just use a fresnel lens without worrying about it affecting image quality, or being too expensive. They can be bought for cheap on Aliexpress. They come in various sizes, including (thankfully) 40x30cm.
And that's everything really. Having placed the fresnel lens, we're not able to get an usable image on the whole 40x30cm sensor. The only thing that's left to do is, well, shoot some scenes with it!
The good news is that I had already planned to shoot a short film last month, so I brought this along and used it for multiple scenes that specifically required a very thin depth of field. I was genuinely shocked by how good the results were, and - amongst the many mistakes I've done in production - this was one of the few things I'm very proud of.
Here's some more pictures with an earlier prototype:
Now, there are a few details that should be improved in the next iteration of this system, which I've decided to call Lampone.
Firstly: I need to build a longer bellow and buy a longer rail. This would allow to keep the lens further away from the fake sensor, which would allow to focus on closer objects. Right now, the minimum focusing distance is awfully large.
Secondly: I should probably work on the structural integrity of it all. Any camera movement will generate weird wobblyness within the video too. Overall I thought it was reasonable and I've included a few pans in these scenes, but more stability would be beneficial.
Thirdly: you can definitively see the texture of the diffusion film, and even the pattern of the fresnel lens. You can fix the former by using better ground glass, and the latter by placing the fresnel lens further away from the diffusion film. There's also visible dirtness on the fake sensor; I didn't really care because I felt like it added to the image, but to get clean video you should be extremely careful when assembling this part.
Even if all of this was fixed, one remaining issue would be that this thing is huge. Not only it requires a large minimum focusing distance, but it's also 120cm long by itself, and it's pretty heavy too (my tripod could barely hold it). This is not a problem by itself, but it does mean that it's only possible to use it when there's enough room on set (and sometimes there just isn't).
Another intrinsic issue is that you are losing a lot of light by doing this. There's no way around it: scattering the light around in the fake sensor means less light reaching the actual camera lens. You should consider about a 3 stops light reduction compared to your taking lens, i.e. the lens that you use to photograph the fake sensor. That's a lot of light loss, sadly: scenes just have to be well lit.
Finally, I would like to thank the many people who posted details online about their builds. The video that inspired all of this is, of course, by DIY perks:
He named the build a "Next-Level Camera", so I decided to go with that name too. I think I went for a different enough approach that it justified its own video. There's also a great detailed video by Media Division:
I loved that they decided to include a second video for patrons with exact details for the components that they chose; it was really helpful when doing my design, though I eventually went with quite different takes.
And, finally, there's the F-Zero project too which tried to make this type of lens possible to be bought instead of just built at home:
I didn't quite have the budget for that, and I feel like I ended up with slightly better specs compared to the F-Zero, but the design by them is incredible and definitively an inspiration going forward.
Anyhow, I will be using this again, and I loved the experience. If you want to watch the short film: thanks! It's still in post-prod., but it should come out in a couple months. Feel free to subscribe to this website and I'll post an article when it is out. Also, if you need to shoot something with this camera or want to play with it a bit, feel free to reach out.
I made the ultimate productivity device for less than 50 bucks
I do realize this website has gone a bit astray in the last few months, focusing more on hardware reviews than on FOSS news; however, as I slowly turn back to what my job should be, I would like to dedicate a few articles on some personal projects that I've developed in the past few months and that I'm particularly proud of.
Therefore, meet Mirtillo.
Simply put, Mirtillo is a digital agenda. It keeps track of what you're doing, your open tasks, events, it suggests you a schedule to follow, and it keeps track of your budgets. Its code is open-source and, well, I wrote it.
Let's take a step back. This story begun in January, when I realized I was still mostly unhappy with my events and tasks handling. My workflow was the following: I added everything I was meant to do and my events into TickTick, and at the end of each day I would take a few minutes to schedule all of my tasks on my calendar, and I checked whether I was able to do all the tasks that I had assigned to that given day.
However, this made it quite easy to continuously postpone daunting tasks, and it was not particularly flexible: any unexpected event or delay in the day would make me much less willing to follow the schedule I had established. I'm the kind of person that heavily relies on these "productivity" systems to live my days, and I change them often; this year, I simply realized I had to go ahead and just build my own system instead of relying on apps that didn't truly understand me.
Initially, my goal was to build my own app. However, I don't know how to do that. It didn't make sense to me to learn the Android development kit from scratch to build a tool that was meant to better organize the plenty of tasks I already had to do. It had to be something that I could develop in a few days.
My backup plan was to build a Telegram bot. I spend much of my day on Telegram anyway, and there are an incredible amount of features available to bots there. I even made a solid mockup of how it would work, but I was mildly annoyed by the fact that there was no way to have some sort of "dashboard" on my home screen to see my current and future tasks.
This is when I started thinking of how cool it would be to have a dedicated, e-ink device that was entirely made for productivity. I don't know about you, but back in January my Twitter timeline was full of images of the X4 e-ink device, a little sexy thing that magnetically attaches to the back of your phone and has buttons to interact with it.
However, a few buttons would not fit my usecase. I needed more, and I needed to be able to write my own code. After some research, I found out just the perfect device to use.
This is a M5Stack Paper S3, a development unit that features a 4.7" e-ink touchscreen, a good 1800mAh battery, Wi-Fi and Bluetooth capabilities, a microSD card slot, a buzzer, and nothing else. It runs on a ESP-32 chip and costs less than 50€, shipping included. It's a steal! I immediately bought one.
Oh, and the back is magnetic, so I can attach it to a great variety of metallic surfaces around me! This is a particularly great party trick, and the device as a whole is a good conversation starter (which, for an introvert like me, is a drawback!).
Developing applications for the PaperS3 is wonderfully easy. You can use MicroPython, which I was familiar with, and there's a half-decent documentation of the provided draw functions. The only drawback is that no high-level UI element was included out of the box, so I very much had to build the whole thing from scratch!
Luckily for me, the device was shipped right before my week-long vacation with my girlfriend. I brought my laptop with me and spent the whole vacation coding away, from each morning to each night. Surprisingly enough, my girlfriend never complained. I guess that after seven years of relationship she has sort-of given up on fixing this side of me.
That said: what exactly was I developing? It had to be something that implemented a specific workflow that was built on my specific needs and habits, as otherwise I could've just used any Android application. After much thought, I decided to go for what I'd like to call a "non-deterministic task manager". (The project was initially called Stochastic Tasks but my girlfriend didn't quite like the name so I changed it to Mirtillo, which means blueberry in Italian).
My model of myself was: I'm someone with a certain amount of events and tasks, both of which have a "fatigue" level (relaxing, low, medium, high). I also have a personal fatigue level, and doing tasks of a given fatigue will make my fatigue slowly match the one of the assigned task, depending on how long it is.
Now, Mirtillo can try to propose me tasks to do, but it knows that the less fatigued I am, the more likely I am to accept them. I initially wrote an hardcoded probability function here that depends on my fatigue and the fatigue of the proposed task, but the idea in the future is to track how often I actually decide to go for certain tasks and use actual probabilities.
Furthermore, each task is assigned an estimated duration. Again, I'm initially blinding trusting my time estimation skills now, but the idea is to, over time, collect data on whether I over or underestimate the duration of tasks (and of specific recurring tasks) to have a probability curve of the actual duration of the task.
Finally, each task also has a value, which is based on how important it is (recreational, nice to have, normal, important, vital) and based on whether it has a deadline, a "best-by" date, and how long ago I created it. The goal then becomes: how can Mirtillo build my schedule around the given events by placing my tasks so that it maximized the expected value of the score of the next few days?
This is an extremely difficult task to solve in a deterministic way; instead, I decided to handle this as a one-player game with a very large branching factor (at each given moment I can do more than 20/30 different choices of tasks to do). And, as one naturally does in such a scenario, I went with montecarlo simulations.
The idea is: whenever Mirtillo has to pick a task to try to make me do, it simulates a random possible future by picking random tasks, collapsing the probability functions of tasks duration into a single value, and using the probability function of how likely I am to do the proposed tasks. It does this until the end of day, and then again, and then again, hundred of times. Then, it looks at the average score I got, and picks the top-level task that has the highest average score and suggests it to me.
This has one big drawback: it's slow, especially on ESP32, so I can't run that many simulations. It also has may benefits, though: it means that I can collect data over time on how I actually perform and decide to do tasks, and that data will actually be usable to improve the simulations. It also means that, as an example, Mirtillo automatically suggests relaxing tasks in-between higher fatigue ones so that I'm more likely to actually stick to the suggested schedule.
So that's the idea behind the scenes. The user-facing implementation is much more simple, though. The application has four sections: Tasks, Clock, Budget and Events.
In the tasks section there's the list of all open tasks, with the importance and fatigue level of each, sorted by score. You add a new task or click on any existing one to see all of its information: effort, importance, duration, valid from, best by, deadline, repeats N times, and how often it repeats. As long as I maintain this list to be accurate, Mirtillo is going to do its best to propose me the best course of action at any given time.
The events section is almost identical: there's a list of tasks to do, with each having its start and duration. It looks horrible, I know, and I even know how to fix the UI using headers for the different days, but I haven't had time to actually work on it.
The clock section tells me the current task, how much time left it has, and the next event. I can tell it that I'm done, and it's going to ask me whether I want to generate a new item, start the next event early, or create a new event starting now. If I do choose to generate a new item to do, as an additional data point, I'm also asked how I'm feeling. In the future, this should also be used as a data point for the probability function of how likely I am to accept a given task.
The cool thing is that, since e-ink display keep showing information even when they're turned off, Mirtillo always shows the clock, even when I'm not using it. I made it so that it turns on every few minutes to update the number and then it turns off again. This way the battery lasts a few days, which is still not as good as I'd like it to be (it should be weeks... ) but it's a great start. Further power management optimizations are planned in the future.
Finally, there's the budget section. This is a somewhat recent addition: it's simply a list of values that I'm tracking and that increase at a given rate. As an example, I have a "small expenses" section value which increases at a rate of 17€/day, and I just subtract here all of my small daily expenses. This makes sure that I roughly spend around 500€/month of this category. There's a kcal tracker that works the same way: it slowly increases over time, and I subtract the estimate of the energy of each food I eat to check how much I'm eating.
This approach is extremely simple but powerful, I think. In the future I'd like to experiment with budgeting time in a similar manner: I could have a "minutes" counter that slowly increases over time, and each time I commit to some responsibility, I take off the amount of estimated minutes that it's going to take, to make sure I'm not over-committing my time.
And that's it. Mirtillo is a dedicated device that's the ultimate productivity tool for me, simply because it's built by me with myself in mind and it works exactly how I want it to work. Anytime I want to change some code I can just go ahead and change the code, and it only took a few days to develop. It certainly will require even more time to fully develop (the data collection part is still missing, and so is any kind of backup mechanism) but it has already helped my schedule the past three months.
So, to recap: if you want to build your own productivity tool that works around your exact needs and wants, you can just do that. Sure, you do need to know a bit of Python, but honestly it doesn't get easier than that.
In next week's video I'll showcase the other cool new invention of mine, called Lampone (raspberry).
The political use of operating systems
Politics is the science and art of organizing, constituting and managing a state and the direction of public life. Expressing these directions represents a power, a duty and an honour, and even though the common belief behind the political participation is that it is enough to vote during the elections, referendum and political initiatives to be part of the political participation niche, it is also possible to argue that there are multiple and diversified ways to make a political choice. One of the latter is the deliberate choice of the technology we use every day. And the everyday use of the technology starts from the personal computer and the operating system that runs on it. Operating systems not only shape and govern the way we interact with our material hardware but also the way we interact with institutions, private entities and peers.
Choosing an operating system means not only choosing the stack of our virtual life, but it also means adopting a particular perspective, prioritizing certain needs and choosing the way we interact with technology.
Making a political use of the technological power means choosing to change the direction of our computing life, gain consciousness on the alternatives and in a way that is equivalent to voting for a party or another, with the discussions, the drawbacks, and the advantages that come with it. This is the power of not letting others choose for us.
This power of choosing comes with the necessity of observing the alternatives, and if OS producers are like parties, each of these parties is bringing a priority or an issue to solve. Microsoft, Apple, RedHat and other vendors explicitly state the issue they are trying to solve: Productivity.
But other parties have other issues and other priorities, what if productivity wasn't the most important issue to solve for some? Are there any entities, producers, or institutions with other priorities that can drive the development of a distribution?
It is impossible to analyze the multiple implementations of the human perspective in this wide spectrum. Here, we tried to analyze the distributions based on the purpose that drives the development of the distributions. We hope it might entertain you and if we are lucky, even inspire you.
As of today, it is possible to clearly see a pattern and group OSes into four major families based on the purpose that drove the development of each of these software.
Military Purpose
Even if the productivity-oriented operating systems such as Microsoft's Windows and Apple MacOS are widely used in military organizations, most of them want to maintain a high grade of independence and control over the classified information, especially those who are not very supportive of the western world. A famous example is Astra Linux. Astra Linux was developed by the Russian Army and other intelligence forces. It provides data protection and mandatory access control, and as of now it is used by many educational, healthcare and state institutions as well as industries such as RZD and Gazprom.
Another focus of government institutions is information military defence where in a Cyber Warfare scenario having a robust and inaccessible OS creates a high advantage. This is the case of Kylin. it was created to make Chinese computers "impenetrable.", Kylin was developed by the National University of Defense and Technology in China. The first versions was based on FreeBSD with which it shared 99.45% of the similarities. It slowly proceeded to a more personalized grade with the newer versions, such as NeoKylin used by the government offices, national defense, energy and other sectors, as well as the 42% of Dell's personal computers in 2015.
In 2013 Canonical reached an agreement with the Ministry of Industry and Information of China to create the first Ubuntu-based OS, called Ubuntu Kylin OS.
But the OS distribution could not only focus on defending national security from the outside. Some institutional entities, having established a dense network of military alliances and defense mechanisms, consider it vital to have strict control over the population in order to avoid people's self-organization and free circulation of ideas.
Perhaps one of the most famous (or infamous) OS in this domain is Red Star Os. This OS was developed by the Korea Computer Center in North Korea. It has multiple controlling mechanism over the user, including a watermarking tool for tracing the spreading of a file from one computer to another, "antivirus" capable of removing censored files, a strange group called "administrator" which is the only one to have root privileges, and a mechanism able to detect the system's integrity and that checks that "certain files" have not been touched.
Software Independence
The military purpose is not the only need for a government; many other entities invest in software independence to cut costs and gain advantages over closed systems.
The advantages of having an independent Operating System are mainly related to the capability of the user not to rely on software governed by a third party, the possibility to autonomously develop the parts of the software that are needed and to better adapt to the necessity the software itself. This is the case of GendUbuntu. This operating system was developed by the French National Gendarmerie to become independent from US proprietary software after the end of the development of Windows XP and Vista by Microsoft. This solution cut the costs of staff training and licenses, and still saves the French Government the costs of buying computers with a proprietary OS. Most of the computers bought by the Gendarmerie do not have an OS and GendBuntu is installed by the Gendarmerie Technical Department.
Some argue that another purpose of the free software could be the IT education and this is the proposal that brought the Venezuelan government to build Canaima Linux. Canaima Linux was created in accordance with the presidential decree 3390 of the Venezuelan Government. This OS is one of the most used in Venezuela, in particular, after the efforts done during the "Canaima Educativo" project were the goal was to provide school children with a basic laptop computer and with the basics educational skills in software utilization.
Canaima is now the default operating system for the Venezuelan public administration, and it is also the most used Linux distribution in Venezuela, thanks to the widespread adoption of the distribution by the public schools.
But the adoption of FOSS software in public entities wasn't always successful. An example of this is LiMux. LiMux was developed by the city of Munich in order to replace the software on its desktop computers and abandon Microsoft Windows. During the development of LiMux another software called Wollmux was developed to extend OpenOffice capabilities in areas required by the Munich Council, including managing letterheads, templates, and saved blocks of standard text. Unfortunately, OpenOffice received much criticism for its productivity shortage, so the administration considered returning to Windows software. The spokesman of the Munich city council argued that those productivity problems could have been solved by switching from OpenOffice to LibreOffice, but the city council had already decided.
Another purpose of the Independent Operating systems if often fight back against embargoes and limitations from producing countries. The Cuban government began the development of Nova Linux just after the beginning of the US embargo and it was developed in Havana by the University of Information Science by students and professors. The emphasis was particularly drawn to the FOSS aspects of the project with the Director of the University stating: "The free software movement is closer to the ideology of the Cuban People".
Research
The creation of a research-oriented OS always drew a keen interest among the Open Source community. Usually, research-oriented distributions contain necessary software and optimization specifically designed for a particular area of research.
Some examples are Scientific Linux, which focuses on High Energy Physics (its firt name was HEPL or High Energy Physics Linux), which was developed starting from FermiLinux, a Linux distribution developed at FermiLab, Chicago and then enhanced by CERN, DESY and the ETHZ of Zurich.
Another OS developed by the Chinese Academy of Sciences in 1999 was Red Flag OS, built with the aim of serving the Chinese research community with a research-focused OS that could substitute Microsoft's distribution.
Unfortunately, it never reached a wide computer population.
Other distributions started as research platform and quickly gained popularity among wider communities, an honorable example is Kali Linux, which was designed as a Cybersecurity Research platform and it quickly gained popularity as a penetration testing and digital forensics tool.
Hardware and Software Ownership
These are only some of the purposes that drove the development of some distributions, but possibly the most widely and recognized reason not to use proprietary software is the possibility of having more control over the hardware and software of the computer. For this reason many user centric distribution were developed. Some are easier for the user to be managed, like Ubuntu, Fedora, Manjaro and Debian and some less, like Arch and Endeavor. The idea behind the complete ownership of the computer is that once a product is bought, the producer should not have any right over what it is executed on it, whether it is the data or the software. Computers are almost always shipped with a predetermined operating system, limiting the choices of the user and proposing a boring and standardized use of technology. Some argue that the choice of the operating system by every user would make the management of computers more difficult and problems more complex to solve, we argue instead that giving the user the right to choose the operating systems would make people more capable of comprehending their power, gain consciousness over technology and being self sufficient in the reparation of it, creating a less dependent society and a democratization of the knowledge on the technology.
The wide variety of human needs and ideals brought to the creation of a colored spectrum of Operating Systems and distributions, and even though the adoption of many of them could not be wide enough to call them "popular" it is still possible to say that each of them deserves a certain attention, whether to escape from a boring afternoon on a virtual "testing" machine or to escape the monotonous use of the computer, relegated to just being objects with the sole and only purpose of the productivity instead of seeing each program as a projection of the human need.
In a way we can say that if art is the proof of human existence on this earth, then computer programs, operating systems, languages and compilers are little forms of art.
My childhood dream laptop
In my limited adult(-ish) life, I've only ever been genuinely excited for an hardware lineup once, and it was - surprisingly - Microsoft's Surface, between 2016 and 2022. However, I never had the luck to own any of their devices – until now; and yet, it's too late: Surfaces now only represent only a fraction of my childhood excitement around them, having discontinued and walked back on everything that made them unique.
This article contains three important sections: firstly, I'll review the Surface laptop I have just bought - the Surface Studio 2 -, then I will tell you how Linux runs on it, and - finally - I'll tell the tale of the lost soul of the Surface laptops. (I'm an old man screaming at clouds at 24 years old already, ouch).
The Surface Laptop Studio 2
The Surface Laptop Studio 2 nails it. I love it.
Let's start by its defining feature: the screen. By now, I have daily-driven both 360 degrees hinges and multiple detachable keyboard laptops.
Though I still love the form factor, they both have significant drawbacks: 360 degrees hinges require a full rotation to enter tablet mode, an action that's annoying enough that you'll hardly reach for it.
Detachable keyboards are easier to get into tablet mode (though, you'll still be left with an hanging keyboard) but are much worse as laptops, in the sense that they need a flat table to rest the kickstand on.
The Laptop Studio avoids both these issues by allowing you to "fold" the back of screen in half, letting the screen slide over the keyboard until it either rests above the touchpad, or lies down in a full tablet mode. This action is easy enough that it feels natural to do it whenever you want to be closer to the content you're watching and want to interact with it through the touchscreen, but it preserves the look and feel of a traditional laptop whenever your workflow doesn't require that.
Even better, you can even flip the screen entirely to lie on the back of the laptop lid. If you then rotate the laptop you enter a different tablet mode, where you get even closer to the screen (with no keyboard in-between). Or, you can use this to show the content of your screen to someone sitting across you.
This last example might sound stupid, but I actually had the chance to do exactly this: I was working with a colleague in a pub, and they had to verify that I had the correct video files to work on; instead of rotating the laptop so that they could see, it felt natural to me to just flip it.
The following day I was in the airport, doing some finishing touches on the project, when my gate was called for boarding. I did not want to close the laptop as the video was rendering, but all I had to do was to fold the screen on top of the keyboard, and grab it as if it was a tablet (with no detached keyboard to handle).
And even now, as I'm typing this review on a nightly transfer on a pullman with very little leg space, whenever I need to scroll some content to read through, it feels natural to me to just fold the screen enough to make it fit the available space.
None of this is groundbreaking: however, they keyword indeed is "natural", as if this laptop allow you to fold and open it as you need.
The screen is 120Hz and decently bright (it's meant to be HDR, but god knows if Linux handles that correctly). It's 3:2, which is the correct aspect ratio for a laptop. It's an LCD instead of an OLED, which saddens me, but considering that this laptop was released 4 years ago, I'll take it. We weren't ready.
It's a laptop that's built for productivity. It features two USB-C ports, a USB-A, headphone jack and micro-SD, which is all in all a great combo. In the few days I've used this as my work machine, I've used all of these ports plenty - except the headphone jack, and that's only because I forgot my wired headphones home and had to fallback to the higher-latency Bluetooth ones. My current work requires traveling, videomaking and video editing and the go, and this is the right hardware to do it with.
I've also had the chance to do some notetaking with it, and - through the Slim Pen 2- this laptop is up to it. I still don't think the feel of the pen is as good as it is on a e-ink device, but it was still an okay experience. The Slim Pen docks magnetically underneath the touchpad in a lovely way, and I have no complaints about it.
The keyboard is great. The touchpad is great, and haptic. I'll never be able to go back to a mechanical one. The whole build could be ever-so-slightly thinner (the bezels are quite big, the touchpad has empty space around it, …) but it's a nitpick.
This laptop has a Nvidia 4050 dedicated graphics card. How is it? Err, well, more on this later. Spoiler alert: it's probably one of my biggest regrets of this laptop.
Finally, battery life. This laptop is not good on battery life, but through some tweaking (including disabling the Nvidia card, hey, more on this later) I managed to get a decent battery life out of it. Browsing and light workloads will yield between 7 and 9 hours of battery life, and during intensive work - such as rendering videos - I'll get something like two, two and a half. It's half the battery life I'd be hoping for in a device like this, but ultimetly I need to surrender to the fact that the old power-hungry Intel chips are not it. I bought a 25000mAh powerbank that outputs at 100W and called it a (sad) day. More on this later, though.
Considering that I love its design and feel, I really think this is a great portable workstation. Which is probably why Microsoft decided to kill it two years ago, stopping its production without any successor. You're therefore able to find this laptop at a decent price on eBay, even though it was prohibitely expensive when it was first released.
Now, before I move on: yes, there are multiple improvement areas for a laptop like this. The latest Phanter Lake chips would yield better or comparable performance at a much better battery life, the screen should have a tandem OLED option and smaller bezels, and the build should be overall thinner and lighter (this machine is thick!). Sadly, we'll probably never see any improved versions of comparable hardware: I'm not sure if there's any patent on the screen design, but no other company currently has this folding mechanism in any of their products, and nothing tells us that this will change anytime soon.
I'll have to move to a better laptop within a year (these new chips seem to be truly a step forward), but I'll probably keep this hardware on display to remind myself of what has been. More on this later.
Linux on the Studio 2
Making Linux work on Surface devices is as painful as you imagine it to be.
Firstly: I'm not running the standard Linux kernel, but rather the surface-linux fork that has some fixes for these machines. Switching over to this kernel allowed me to have touchpad and touchscreen working out of the box.
A surprising amount of components worked out of the box too: I had no issues with the webcam ((in)famously a pain points for Surface devices), or speakers, or ports. Wi-Fi and Bluetooth gave me no issues either, and (yay!) tablet mode was also detected. That's where the good news end.
Screen autorotation was missing out of the box; apparently, some sensor packages were missing. When I installed them, Ubuntu stopped booting. I had to remove the packages in a live boot. After some testing, I managed to get autorotation to work through the git versions of those packages. No idea what's up with that.
The touchpad randomly died during usage. This was particularly annoying, as I found no online references to this issue. Google Gemini suggested it might be due to the touchpad going to sleep and never waking up again; as a solution, it proposed a kernel flag to disallow components to sleep at all. That worked, and with some tweaking, I managed to make sure that battery life didn't take a hit.
Except it didn't fully work. Most of the times, the touchpad will not work when I boot the device for the first time in a long time; I'll always have to reboot the first time around. It's not a dealbreaker, but it's annoying.
Even worse, sleeping is currently all wrong. Letting aside the whole mess that Microsoft made by removing deep sleep (sigh), trying to close the lid will make the machine fire error messages non-stop to journald, keeping the CPU at 100% and draining the battery as fast as it can. Again, the Internet did not help me out, and Gemini was not able to handle this one either. So: I currently shutdown the device everytime I want to close its lid, which is obviously not ideal. Actually, it's a pain in the fucking ass.
There's also little issues here and there. Waking up from the little sleep that this machine gets with its lid closed takes a weirdly long amount of time. I also once got 15/20 seconds delays when booting for no reason, though I was mostly able to fix that (don't ask me how, though, I have no clue).
I'm confident that I'll be able to address most of these issues over time, but it's obvious that it will take effort and time; effort and time that would probably be better spent, as an example, by doing videos for you, and not by debugging this weird adolescence that this laptop is going through. Sigh.
One final issue is that, when the screen is detached and sitting on top of the touchpad… the touchpad should still working! I'm not sure if this is KWin disabling all input hardware when tablet mode is enabled or what, but I've found to way to override this behavior, and thus I'm left with a touchpad that's again useless even though it's right in front of me. Again: Sigh.
It's also time to talk about the GPU. Even though it's a Nvidia, it thankfully gave me no big issues on that side. However! This is my first time having a dedicated GPU, and I thought it would be nice to have one, given that my work is now all around video editing, raw images editing, OBS recording and such.
However, it turns out that my preferred video editor, kdenlive, does not support hardware accelerated rendering; the only task that can be handled by the GPU is the encoding part, which is not the bottleneck on my machine and yields no extra performance. It turns out that very few video editors are able to really take advantage of the GPU, the most famous of which is Premiere (which is proprietary! Not a big fan). A possible alternative is Shotcut, which allows for GPU accelerated effects through the movit package; I haven't had the time to test that out, but I'm also not exactly excited to switch to a new video editor (especially Shotcut, as I really don't like its interface - sorry!).
However, as great as Kdenlive is to edit program (it's feature-packed and easy to use, in my humble opinion), I'm having issues dealing with its performances. Even ignoring its speed (it sometimes lags when editing over proxy clips…), it uses an incredible amount of RAM, which is often higher than all of its project files disk size combined. Sadly I only managed to get the 16Gb version of this device (yep, that's on me) and it's soldered (that's on Microsoft, though). In order to edit a video without crashes, I had to set up 64Gb of SWAP on my SSD. It seems to work, but I fear that will create an additional burden on performances. Given that speed is a big constraint of this work I'm doing, I'm getting anxious enough that I'm now rendering projects by calling melt on the command line instead of using kdenlive's built-in render button. And, hey, it uses less RAM, I think!
And, of course, my raw image editors don't seem to benefit from running on the GPU either. Which makes me ask: as somebody who has a dedicated device to play games on, why on earth did I just buy a dedicated GPU!? The only task I seem to hardware-accelerate is OBS recording, which is the one thing that my CPU was handling just fine. I've even been wondering if I could open the device, remove the GPU and replace it with additional battery (obviously, I can't!).
Overall, I am left wondering how should I change my workflow to best address my quick turnaround on video project needs. I'm open to suggestions, and please do explain to me how I did not waste money on a dedicated GPU. Right now, I've just disabled it, and that has gave me some extra battery life. Maybe I should sell it for a quick buck. (Just kidding – I'm well aware it's soldered).
The Lost Tale of Surfaces
Now, I'm not going to keep using this laptop for too much time, I'm afraid. The latest Intel chip is such a generational leap forward that I'll probably switch to it as soon as some company I like (read: Framework) will ship with it.
However, I actually bought this device for a different reason: a (somewhat expensive) form of collecting. A few years ago, the Surface line was genuinely exciting, with many innovative ideas throughout their line of devices. Now, all of that excitement has been killed of and replaced with empty Copilot+ stickers.
I've spent a lot of time talking about the unique form factor of the Laptop Studio, but let me introduce you to the Studio itself.
It's an all-in-one computer featuring a 28" touchscreen display that folds towards the user. This means directly interacting with the content, and as it supports the pen too, potentially drawing or taking notes directly on the giant screen. The design is sleek and the latest version was quite powerful, featuring 11th-gen Intel and dedicated NVIDIA cards. As someone who works on photos and graphics, this feels so exciting! (It was discontinued a year and a half ago).
As an additional way to interact with the screen, Microsoft also offered a "Dial" that would rest on the screen, and allow for extra input. It could be used to change the color of the pen, rotate the canvas, and more. Also discontinued a couple of years ago.
Before the Laptop Studio, we even had the Surface Book, which was yet another attempt at a new 2-in-1 form factor for high-powered machines. This was a detachable device, but the keyboard featured additional battery and a dedicated NVIDIA graphics card, plus a hinge that would fold flat on the table to make sure that you could use this as a traditional laptop without any use of stands.
You could even rotate the screen around and re-attach it, using the keyboard base as a stand for the tablet part of the device. And, of course, it was again touchscreen and supported both pen and dial inputs. It wasn't necessarily a good idea - again, I think the folding display on the Laptop Studio was just a better idea - but at least it was an unseen one.
And, even when the traditional Surface Laptop was announced in 2017 (I watched the stream live, I still remember it!), it featured some vibrant colors, a sleek design and —
The infamous Alcantara texture on the keyboard! This had some durability issues over time, but it still feels miles ahead compared to the metal plates that we are handed nowadays; the design made the laptop feel super-thin when on a surface, and the same material was used for the Surface Pro line as well. Ah, of course, this was still all touchscreen and pen-enabled, which is sometimes useful for quick annotations.
Finally, of course, the Surface Pro line was (and still is) the reference implementation on how to do a detachable keyboard device! It features an integrated kickstand (instead of a bulky magnetic one), a pen that hides within the keyboard, a keyboard that does not lay flat on the table, great screen-to-body ratio, slim and light design, the Alcantara texture instead of rubber…
Even its little brother, the Surface Go, shared most of these good features, and was objectively a little cute thing! (Now discontinued).
Compare all of this to the current lineup. We've got a rather boring-looking, all-metallic Laptop 7 (which ships with an ARM chip that still pales in comparison to Apple Silicon):
And, the Surface Go was replaced with a lil' Surface Pro 12, which features a keyboard laying flat on the table and a rubbery keyboard, both design decisions that feel to me like clear step backs:
Everything else has been discontinued, except for the Surface Pro, which stands as the only still-exciting device of the lineup.
Overall, it's impressive how quickly Microsoft turned its hardware department from a place to push for the limits of Windows devices into a good but rather boring set of laptops. My hope is now to go ahead and try to collect as many of these little machines as possible, picking up defective units on eBay to display in some display window somewhere in my house. And why not start with the Laptop Studio?
I'm A Proud Luddite. That's Why I Use Linux.
The term “Luddite” has changed in meaning over the years. These days, it is a near-synonym for “technophobe”, someone who is afraid of or doesn’t trust new technology. It is often used to dismiss critics of the way technology is used as “backward” or “closed-minded”. But if we look a beyond the surface and examine the Luddite movement of old properly, we will find something much different. In this article, I will examine the Luddite movement and connect it to the ideology of the FOSS movement.
To start, a bit of history. The industrial Revolution lasted roughly from 1760 to 1840. This was a time of great social and economic upheaval, with many jobs being replaced by machines. Per Wikipedia:
“This transition included going from hand production methods to machines; new chemical manufacturing and iron production processes; the increasing use of water power and steam power; the development of machine tools; and rise of the mechanized factory system. Output greatly increased, and the result was an unprecedented rise in population and population growth. The textile industry was the first to use modern production methods, and textiles became the dominant industry in terms of employment, value of output, and capital invested.”
The fact that the textile industry was at the forefront of this, is important to the history involved. According to legend, around 1779, a weaver named Ned Ludd smashed two knitting machines in protest against the increasing industrialization. There is no independent evidence that Ned Ludd really existed, but the idea of him became a symbol of resistance. By 1811, the Luddites, as they now called themselves, were an organized and structured movement, going on raids, sabotaging machines and protesting the abuses of power in their industry. A cursory look at their surviving writings indicates that they were not afraid of the technology itself (in fact, many of them were highly skilled in using machines – very few people still weaved by hand). Rather, they were protesting the loss of dignity, the loss of pay, the declining quality of the product, and all the other nefarious things that were being pushed on them by the emerging capitalist class. One example of this is in an article in the Nottingham Review from 6 December 1811:
“The machines, or frames ... are not broken for being upon any new construction ... but in consequence of goods being wrought upon them which are of little worth, are deceptive to the eye, or disreputable to the trade, and therefore pregnant with the seeds of its destruction.”
It is clear from articles such as this that the Luddites did not have issues of principle with the advancement of technology in and of itself; rather, they were concerned with how this technology was being used to control their output, their livelihoods, their very lives. Their issue was not with the machines themselves, but rather with those who wielded the machines as hammers, beating down the working class. This was not about some short-sighted stubbornness or a refusal to accept progress; this was about the dignity of labour.
This was about self-determination and agency.
I don’t think it’s a massive stretch to connect this to the FOSS philosophy. In the modern day, we have no shortage of headlines about how the adoption of AI is threatening jobs, or game development companies laying off huge swathes of their employees. This is at the forefront of many people’s minds. As an example, take No Other Choice, the latest film from South Korean director Park Chan-Wook. The film deals with a man who loses his job due to downsizing and the adoption of AI, who then turns to desperate measures to find a new job. The thing is, the film is based on a book that was published in 1997. In the book, the issue is mechanical automation and the rise of computers, rather than AI. But the principle remains the same: technology is being used to oppress workers in the name of making a quick buck, with no regard for the human cost involved. So the director, Park, saw something in a book that is nearly 30 years old, which is concerned with the same issues that drove the Luddites to rise up over 200 years ago. All this to say, there is something universal, something almost inherent, in the human spirit and its insistence on dignity.
Apart from this, there is also the advent of the social media algorithm. We are being manipulated by Big Tech for our information, and our sustained attention. We are being milked and squeezed dry because it allows Mark Zuckerberg to buy another yacht, with zero consideration given to the notion of whether this is actually good for us, the users. In fact, there are several studies that claim to have found that excessive social media use can be quite bad for us. In a 2018 article in The Guardian, Mattha Busby explains how social media companies use similar tactics as slot machines to trick us into neurological addiction. The interface, the algorithm, the design language; all of these are carefully constructed to stimulate our brains in just the right way to keep us glued to our screens and give them more of our precious attention. Social media addiction is not a bug, it’s a feature. So, what can we do? What is a viable form of resistance against this creeping invasion into our professional and private lives? I argue that one way to push back, even if it is just a little, is simply to use Linux instead of a proprietary OS.
On 3 March 2025, The Conversation published an article titled, “Digital Luddites are rising. They want to democratise tech, not destroy it”. In this article, the authors have this to say about the Luddites and their connection to FOSS:
“Their rebellion was violently suppressed. But their core critique lives on: technology should benefit all of humanity, not a privileged few.”
In the article, the authors discuss three main strategies for dealing with the problems we face in the digital world, namely Resistance, Removal and Replacement. I will not delve too deeply into these three strategies here (Go read their article if you want to know more – it is a very good read), but it is not difficult to connect this to FOSS activism, or even the simple act of using Linux as an individual. When an individual chooses to use a Linux-based operating system instead of Windows or OSX, they are, deliberately or not, making a statement. They are declaring themselves to be autonomous and independent. They are rejecting the coddling, the hand-holding, the babysitting that our tech overlords want to subject us to. They are reclaiming their digital agency, their right to dignity and self-determination.
Beyond the personal and on to the societal, there are plenty of examples of FOSS activism with exactly the kind of motivations the Luddites had. Take for instance the Electronic Frontier Foundation’s new initiative, Take Back CTRL. The mission statement on their website says they are fighting for the following rights:
· Your right to speak and learn freely online, free of government censorship
· Your right to move through the world without being surveilled everywhere you go
· Your right to use your device without it tracking your every click, purchase, and IRL movement
· Your right to control your data, including data about your body, and to know that data given to one government agency won’t be weaponized against you by another
· Your right to do what you please with the products and content you pay for
If this isn’t in line with the philosophy of the Luddites, I don’t know what is. Dignity, self-determination, agency. That’s what it’s always been about. I’m not trying to convince you of anything with this article; I am not looking for converts. I am just trying to point out that the FOSS movement is not anything new, not really. It is just another manifestation of a drive that has been with us since time immemorial: the thirst for freedom.
For me, the conclusion seems simple: if Ned Ludd could see the modern world, he would not be smashing knitting machines. He would be smashing data centers. Not because he was afraid of them, but because he wanted people to have some dignity in how they interact with their belongings and their technology. He wanted people to be able to take pride in their work, and to claim ownership of their output. To conclude, I leave you with this quote from the Conversation article discussed above:
“Digital Luddism doesn’t reject innovation. It demands technology serve stakeholders, not shareholders.”
What Have I Learned From Daily Driving Arch Linux For Three Years?
Long story short: about three years ago, I made the decision to install Arch Linux on my main PC, which I use extensively for all my professional work, including photo and video editing.
I was a bit reluctant at first (pun intended) and sceptical about the idea. After all, I’d been daily driving Pop!_OS back then and had only tried Arch on my spare laptop. But I was also captivated by the promise of the lightweight and reliable system that I could adapt to my specific needs, so I decided to take a leap of faith.
KISS principles
Everyone in Linux space knows that Arch follows a strict "keep it simple" policy, but I never realised how "simple" it is until I tried installing it myself.
For those who have no idea what I’m talking about, KISS means "Keep it simple, stupid" which, in the context of operating systems, means stripping away unnecessary packages and delivering a streamlined experience. And by "unnecessary packages" I mean "all unnecessary packages".
I learned this lesson right after I finished installing Arch Linux for the first time via the archinstall script and found out that it didn't install the NTFS driver by default. My first thought was: "Wow, this can't be true! This is the basic package that everyone needs, why didn't they include it in the basic desktop installation?".
Turned out it wasn't the archinstall’s fault. It did ask me whether I wanted to chroot into installation for post-installation configurations. It was me who selected "Exit archinstall" in the terminal window.
Later It would make me realise that if I want to see something on my computer, I should go and install that for myself. This could be applied to everything else, from the CUPS utility and music players to a Bluetooth stack. All of them doesn't come pre-installed with Arch Linux.
This is a pure manifestation of the DIY-philosophy: nobody knows what exactly you need, and only you can choose what to install on your system. Otherwise, you're going to get a bloated system. Beginner-friendly? Maybe, but a bloated one.
Arch is the best distro to learn Linux
This approach might seem daunting at first. However, it allows you to learn what exactly you need to make your PC work for you. It helsp you to evade packages and creating dependencies you don't require, making your system much-much lighter.
The act of selectively choosing what to install allowed me to see each package and every systemd service as a piece of a larger puzzle, and that the overall behaviour of my system depends on the combination of those pieces.
This level of personal responsibility is so important to the learning process. You have to completely ditch the third training wheel in order to learn how to ride a bike. Even if it means falling down and grazing your skin.
Everything I know about Arch Linux I’ve learnt from a mix of sources, including YouTube tutorials, Reddit discussions, and, of course, the ArchWiki. And all three sources made Arch Linux feel really approachable.
So ArchWiki became my best friend! I’ve spent countless hours scrolling through its pages, looking for a help with a troubleshooting and learningn new useful Pacman commands.
After all, learning Linux is more than just memorising terminal commands and getting used to a desktop environment. It's all about seeing the "underlying architecture" and understanding the way it works on a very deep (and sometimes, when you try to fix Bluetooth for a couple of hours — very personal) level.
Plus, there is a funny side effect: this whole thing about KISS principles not just turned Arch a perfect distro to learn Linux, but also helped me appreciate and respect distros that work out of the box like Ubuntu, Pop!_OS, Mint and Fedora!
Arch is reliable
When I was installing Arch for the first time, I was intimidated by the idea of a rolling release distro. And it wasn't completely my fault: the language that people on YouTube and Reddit use to compare Arch to "stable" and "beginner-friendly" distros kind of implies that Arch is not a stable distro and definitely not a beginner-friendly one.
Arch turned out to be way more stable and way more reliable than I expected. So-called "bleeding edge packages" that people were talking about online turned out to be just normal, up-to-date versions of apps that I wanted to use on my system anyway, and, when it comes to maintaining an operating system, Arch pleased me with some pretty reasonable safety checks!
For example, Pacman package manager always stores its downloaded packages in /var/cache/pacman/pkg/ and does not remove the old or uninstalled versions automatically, so you could downgrade them later if something goes wrong. This also helps if you need to reinstall recently deleted packages directly from the cache directory, without the need to download them again from the repository.
The most preferable method of updating the system, sudo pacman -Syu, updates all packages automatically, eliminating the risk of creating dependency hell. Pacman also doesn't allow you to remove a certain package if it is listed as a dependency for another app.
It literally took me a few days to set up DaVinci Resolve, Reaper, GIMP, and RawTherapee and these four apps covered most of my professional needs for the recent years.
I was also using this PC for gaming, and over the last three years and it was working like a charm. I haven’t had any significant issues or instabilities. Arch is a reliable distro. Or at least it was up until 2025, when I installed GNOME 49.
Wayland is a hot mess
GNOME 49 did one thing that disrupted my whole creative workflow: it disabled X11 session by default and forced me to use Wayland, which made life much harder.
The bitter truth that I had to learn myself was that user experience under the Wayland session is sub-par. My desktop is built around RTX 3070 which I needed for GPU-accelerated video rendering and VRAM management under the Wayland session is broken.
Swithcing languages on GNOME 49 under the Wayland session was making the whole system freeze, drag and drop support was bad, and global hotkeys? Still non-existent.
To fix this, I had to manually restore X11 session downloading and rebuilding mutter, gdm, gnome and gnome-shell packages myself. And it's not just GNOME Problem. KDE Plasma also has a similar issue: with the recent split of kwin into kwin-wayland and kwin-x11, users running the old X11 session on Arch Linux needs to manually install plasma-x11-session if they want be able to login.
It would be fair to mention that this whole Wayland rant is not really related to Arch directly, since your particular Arch-based system can be whatever you want it to be. I am are free to install Arch with XFCE and never give a damn about Wayland.
But as someone who’s using Arch Linux for all my professional work, I can’t separate the distro from the user experience that comes with the DE, especially since we are talking about two of the most popular desktop environments on Linux, and transition to Wayland was the single biggest source of issues for me.
I do understand that there are development reasons for deprecating X11. However, a major desktop environment moving too fast on Wayland adoption brings a net harm to the Linux community. It just reinforces the misconception that Linux is not ready for the general public. It'll also hurt the perception of Arch Linux, which I was using perfectly fine for three years.
The biggest problem that Wayland creates is not about Wayland itself. It still may be the best display server protocol in the whole world, but I don't care how good it is if it breaks the user experience. No project is more important than the users of the project.
The upshot
After three years of daily driving Arch Linux, I found myself in love with this system. Arch Linux is precisely everything I've read about Arch Linux: It's reliable, it's blazing fast, and, what's more importantly, it respects my choice, even when I choose not to install NTFS driver.
As they say, with great power comes great responsibility.
Now I totally understand why it got a reputation as a cool kid Linux distro and "I'm using Arch, btw" became such a meme. It sits in a perfect sweet spot between beginner-friendly distros and DIY distros like Gentoo and LFS, that require you to compile individual packages.
ArchWiki has gave me a solid understanding of underlying Linux concepts, including package (and service!) managers, it taught me how to maintain my system and I also learned the hard way the difference between two existing display server protocols.
When it comes to Linux, you are the only one who's responsible for installing maintaining your own system. It's going to be as stable as I want it to be and his is especially true when it comes to Arch Linux.
Is Linux market share going stonks or not stonks?
Every couple of years, I see multiple articles about Linux market share suddenly dropping or rising within a few months, reaching new all-time highs or all-time lows. This might raise the question: Is the Linux market share growing or shrinking overall?
Well, it's difficult to say, because we don't have a good metric for it. However, we do have a few data sources, all of which could be taken into consideration.
Sometimes, articles refer to the Steam Hardware & Software survey, which asks a random sample of Steam users for their current platform, including the Operating System. Of course, that data is bound to be highly biased towards gamers, but it's nonetheless one indicator we could listen to.
Alternatively, some articles use StatCounter's data, which tracks pageviews from supported websites and tells us which percentage claims to be coming from which Operating System. This is meant to be a bit more reliable, as it samples from billions of page views, but it still might introduce some biases.
ZDNet even ran an article claiming that Linux had 6% market share according to US government records, which might surprise some of you. Though obviously biased in favor of the US, we do have the analytics from the government's AdSense account, which is yet another data point.
And there's even more: W3Counter has its own Operating System tracker, and then there's one from CloudFlare, and we could even go looking at the StackOverflow yearly survey of developers, and so on…
It might be hard to keep track of every single thing. However, after looking at the data, I can tell you that Linux market share is, sadly, not stonks. (Or at least, it's not growing noticeably in the last couple of years.)
Here's the aggregated data of all of these data sources over the last two years:
There are a few weird things about this graph, but I'll get through it.
Before that, I want to mention that this graph (and many more) can be found on the page thelibre.news/linux-marketshare, continuously updated for everyone to see. It took quite a while to automate grabbing data from all of the different sources and building the graphs automatically, so go give it some love!
Now, overall, I believe that we can safely say that there's no visible upward trend in Linux market share. The only datapoint showing a stable increase is the Steam H&S Survey, which is probably driven by Steamdeck sales (thanks, Valve!).
It's also worth noting that W3Counter data is unusually high and unusually low on different time frames. That's because that website only provides the top 10 most used Operating Systems, including both desktop and mobile ones. When Linux doesn't make the top 10, I get no data, and I have to mark it as zero. However, I don't have a good explanation for why it was giving such high numbers around Sept '24!
On the webpage itself, you will find an in-depth explanation of every data source, and a graph for each one, too. I'm also working to bring more data than just the last two years, and to show geographical data, filtering by country.
Check it out:
Niccolò Venerandi
About
Hi! I'm Niccolo Venerandi, KDE developer and Linux Content Creator since 2021.
I have created LibreNews to host all the content by me and my collaborators.
Our focus is to provide an in-depth, accurate analysis of the Linux and Open Source world. You can sign up for free to get all of this content by e-mail, or join as a paid subscriber to have so extra content delivered to you!
Tags
Authors
Archive
Linux Marketshare
Here is the graph showing Linux market share over the last two years according to five different sources (the Steam Hardware & Software Survey, the US Gov website, w3counter, statcounter, and Cloudflare):
Please note that CloudFlare and StatCounter data are updated daily, whereas all other sources are updated monthly. Though each data source uses very different methodologies, this graph should be able to tell us about general trends over a medium length of time.
You can find more data and a description of the handling of each source on this page. Please note that part of it is reserved for paying subscribers as aggregating the data takes some time, and donations help me work on more features (such as by-country graphs and longer history) and, more generally, to run the website.
CloudFlare
CouldFlare data uses the number of HTTP requests broken down by Operating System. You can explore the data for yourself here.
I have decided to set "Device type" to "Desktop" as I'm only interested in desktop marketshare, and I have kept "Bot class" empty as "Likely human" lowers the Linux marketshare significantly, and I'm worried that Linux users are considered more likely bots.
The data is continuously updated, which is great; however, it's provided as a percentage of HTTP requests each day, and to get the monthly value, I average them. I have found this to be rather accurate, but it does not account for which days have more traffic. Therefore, the number you see might differ from CloudFlare's own tally.
If necessary, we could filter the requests by country and have some more detailed geographical data, but I have not worked on that yet.
Statcounter
Statcounter publishes its methodology here and here, and you can see the data for yourself here. Again, I'm only interested in desktop market share, so I filter by that type of device.
I believe this to be the second-largest source of data after CloudFlare, as they claim to have had a sample of 5.3 billion page views in 2022. Of course, that might not be representative of the larger population.