Entries tagged 'cat:Software'

Entry created on 2026-04-16 author:steeph (372) cat:Computers (21) cat:Software (53) cat:Thoughts (71) lang:en (254)

IT systems become more complex over generations. There's always something that could be made simpler by adding another abstraction layer. This can not go on indefinitely. But it will probably go on for longer than we all wish it would.

Sorry, this might be a totally stupid and banale thought. But it feels relevant right now and I don't know how to explain my point more concise. Let me know if you think I should. (Of if it's because I don't really have a point.)

When you think back about how computers were used in the 1960s, the 1970s, the 1980s, the people who used them back then really knew their systems, as it's often put. With each generation more people began using computers. So while some were still designing, improving and expanding circuits, others would work on inventing higher-level languages, operating systems. When you think a bit further, the 1990s, microcode became more complex, operating systems started to became more complex, software interfaces between applications were developed. But we still needed people who maintained OS kernels, worked on processor architectures and knew serial and parallel interfaces on a low level.

You can look at any small part of computers and will find that new abstraction layers have formed over time. E.g. Your fan speed controller. I bet you don't even know what processor it is utilising and what it's capable of. Even if you study an open source driver for it, you'll likely just see an imitation of some things a Windows driver is doing. There are probably only a handful of people in the world who really understand that tiny part of your computer.

Let's not get into networking, the internet and the complexity that was added to everything in the last couple of decades.

My point is: We will need people who understand every little thing of these hugely complex systems at least at some point. Otherwise systems will not run smoothly or reliably. In the silly little example of the fan speed controller, if that would not work with newer systems anymore for some reason, documentation would probably be good enough to find a workaround. If it would have to be replaced in future systems, that's also doable, or you can just run fans at full speed all the time. But there are so many other components (I'm mainly thinking of software) that don't just have to work reliably on their own but interact with other, evolving components.

Not every little thing can be maintained continuously with the amount of attention it deserves. Be it the often used example of a small open source software component that 90% of software somehow relies on, maintained by a single person at the risk of, well, anything that might happen to a human. Or a commercial product that's driven to make as much money as possible with next to no work hours. Or end of life of some software that still runs on millions of machines.

These are disruptions in IT that happen right now. With increasing complexity of systems, failures that have not been properly planned for will probably happen more and more often. It's not even unusual today that when a service goes down, the people responsible for keeping it up don't understand what has happened. They have to start a research into the matter; if they have the time or it's deemed important enough. Because there's a gap between the coders, who know the languages, frameworks and tools they're working with, and the system administrators, who know their OS, config, containers with other OSs, their config and somewhat the services that are running. But in between there are frameworks, huge libraries that depend on other libraries you don't even know about, cloud services you have no insight into. The code written, if it's still written by a coder at all, may be compiled into another language that's interpreted, at each layer adding Gigabytes of dependencies you have never read and can't possible stay updated on.

All of those components have bugs. The more we add, the more failures will occur. More projects will be kept hardly alive because they're still needed to delay another failure. Just as you – even as a computer enthusiast – likely don't know what physical signals are needed over your USB port to make it do what it does, people responsible for keeping a service you rely on running don't know how most of the systems work that they are keeping online.

This growing complexity can be seen in almost every field. But I think it is growing especially fast in medical science and IT. Both will have negative effects on our lives. But with medicine it is a side effect of a science that's working to improve and prolong our lives. So it might be worth it. IT does not have that noble goal.

SBWG 0.13 Entry created on 2025-11-10 (edited 2025-11-18) author:steeph (372) cat:Bash (31) cat:Code (31) cat:Computer (78) cat:Linux (36) cat:Projects (41) cat:SBWG (18) cat:Scripts (28) cat:Software (53) lang:en (254) top:Projects:Code:Bash Scripts:SBWG (16)

Wow, has it been more than a year again without publishing a new SBWG version? Another year where I didn't have much energy for things besides work. But I finally worked on it again. It's still evolving a lot. But the list of things I still want to do is slowly becoming shorter.

SBWG 0.13.0 is a pretty stable version again. I've tested it with several sites for a while and I'm now also using it to generate this web site. You can get it from there.

Apart from the almost permanently ongoing task of cleaning up the code formatting line by line because I started out with a mess of tabs and spaces mixed in different circumstances, I find the following changes worth describing here.

File attachments: Image files are now only embedded as a thumbnail and displayed as a gallery if the file type is one of the following: image/avif, image/bmp, image/gif, image/heic, image/jp2, image/jpeg, image/jpm, image/jpx, image/jxr, image/png, image/svg+xml, image/tiff, image/vnd.microsoft.icon, image/webp or image/x-jp2-codestream. Even though not all of them are supported by most web browsers and there are browsers that support formats not on the list, those are the image types that I find widely supported enough to try to display their contents instead of only linking to the original files. If a file attachment is in a subdirectory, the same sub-path is now used on the generated web site, allowing for several files of the same name to be attached to different entries. That is something that is now possible because file attachment now not necessarily need to be named after the entry they are attached to. Their file name does not matter if the directory they are in is named after the entry. For axample: ENTRYNAME, ENTRYNAME-files or ENTRYNAME-images

Since SBWG sometimes changes how certain features work, it is possible (as in thinkable. It's not like SBWG is used by so many sites that there has been an actual example of it.) that a web site created for one version of SBWG is not generating as expected with a newer version of the script. That is why it is now possible to declare in a site's settings file that it may not be generated by a SBWG script newer than a certain version. If your site uses hooks it may be a good idea to use this new feature so that you get a message when trying to use a wrong version of SBWG instead of noticing after a possibly long generation process that everything does not look right. To activate this restriction, simply add a < sign followed by the latest version allowed to the first line of the site's settings file. For example: #SBWG <0.13.0

Accessibility as an afterthought: For some reason I didn't many things wrong from the start when it comes to accessibility. I've always felt that design decisions are and should be subject to my personality and mood. This is why SBWG is only written for Bash (so far) and so many specialty features are the way they are. I guess I've let this policy spill out on decisions like how readable generated sites are. I've never been good with designing web pages entirely on my own. I'm better at implementing CSS than at design decisions. But this goes so far that I've created an image gallery feature (for image file attachments) with modal preview without using any JavaScript. To realise that I had to break some HTML rules and create HTML that is not viewable without a basic minimum of styling (to hide some elements). I am very very slowly drifting off that course of not caring about things like that. As a start, I've changed the layout of web sites generated with SBWG to contain their menu after the content. For a styled site there's no difference (e.g. using the default "elth" style). But in text browsers (and hopefully also screen readers) this means the entire menu with all topics and the whole tagcloud isn't displayed/read before getting to the actual content of a page. To make it easy to access the menu, there is now a "Jump to the menu" link at the top of every page. Another improvement in this regard is inclusion of image descriptions as alt attributes where descriptions are found in the meta information embedded in the image files. SBWG now looks for all sorts of tags that might hold a useful description of an image, or at least a title or keywords. Fields meant for image descriptions are preferred over others that probably only hold inferior information. This should in some cases already generate useful alt attributes. But I know that I'm going to have to actually write those image descriptions for images used on my site. It's a start. Like I said. I'm moving very very slowly on this.

Style set handling: The most recent large change has been the rewrite of everything related to fetching and embedding style sets. I made some minor compromises but simplified some parts a lot. Changes emerging from the re-write include: Style sets can be placed in different directories now. SBWG looks for the requested style sets in the web site's own styles directory as before. If it isn't there, it continues looking in the user's home directory (`~/.local/share/sbwg/styles/`), then in a global styles directory (`/usr/local/share/sbwg/styles/`), then in the styles directory relative to the script file (in case SBWG is used as a portable directory, not installed). This way styles can be provided globally, e.g. with an install script, additional or altered styles can be installed by a user for their own sites and additional or altered styles again can be limited to a single web site. And lastly a stylesheet file can be chosen by path no matter where it's localed. But this file will be its own style set. Special use case, I know. But if you happen to have a use for that feature, there you go. Style files named reset.css are no longer treated specially. It wasn't a requested feature and I never used it myself. If you use alternate styles on your site (which is unlikely enough) and there are style definitions you want to be included in all style sets, simply include them in all style sets. If you want to refrain from using redundant CSS, put that code in a separate file like before with reset.css) and create links for each style set. The result will be same as before but more self explanatory. When using alternate styles on a web site (so the user can select from them in the browser), all non-styling files from all style sets are now being used. Again this is more in line with what you would expect. Although I might change this again later because the way it used to be was more practical. There were good reasons for it. The basic minimum of styling that should be applied to a site generated by SBWG is now hardcoded. If no style whatsoever is requested, a file with those minimal rules is generated and linked on generated HTML files.

Other than that it's mostly code improvements, HTML cleanliness improvements, formatting improvements and UI/style improvements of a tiny nature. But I'm glad I have two of the larger todos - attachment changes and the style rewrite - (almost) done.

HelenOS Entry created on 2024-11-23 author:steeph (372) cat:#100DaysToOffload (41) cat:Computer (78) cat:Operating Systems (24) cat:Software (53) lang:en (254)
This entry is referencing the entry 'Alternative Operating Systems'.

HelenOS

One of those operating systems that is used for operating system research here and there. I think that's also what it was made for. The last releast was earlier this year, which makes it seem one of the more actively developed research OSs. With the release there are also prebuilt ISO for a variety of platforms including the usual, Raspberry Pi, other ARM platforms and older PCs.

There are similarities to UNIX-like systems but it is clearly not a POSIX system. Basic utilities are included as well as some basic console and graphical applications and demos. I didn't look for any additional software, yet. I'm not sure if I will use this os much more. But by booting flawlessly without any changes and effort, this is one of the more usable OSs I've tried. So I might. It has network capabilities, a basic GUI and TUI, window manager and its own shell.

The GUI is optional. Most applications run in the console mode as well, which is a TUI that mimics the GUI with its start menu. Which is good to have because the GUI is really slow to the point that the mouse pointer is lagging behind.

On my desktop PC neither a PS/2 nor a USB mouse worked. But the touchpad in my old latitude worked fine, including the second set of mouse buttons that work in almost no OS. Graphics mode worked with the appropriate resolutions automatically. Above that I haven't tested any hardware.

There are screenshots in the official wiki.

Alternative Operating System: Haiku OS Entry created on 2022-03-29 (edited 2024-11-15) author:steeph (372) cat:Computer (78) cat:Haiku (2) cat:Operating Systems (24) cat:Software (53) lang:en (254) top:Software:Alternative Operating Systems (18)
This entry is referencing the entry 'Alternative Operating Systems'.

Haiku OS

Haiku OS is a BeOS clone. I didn't use BeOS back in the day (although I wish somebody would have showed it to me). So I'm not sure, but Haiku seems to be pretty much the same experience. But Haiku is open source, still actively developed and compatible with newer hardware. It ran relatively well on the Core2Duo PC I've tested it on. Except for the included web browser. That thing crashed. For a lot of people whether a desktop OS is usable is decided on how good of a web browser is available for it. Haiku OS Beta 3 looked promising with its WebPositive using WebKit 612.1.21. But at least on the old PC I've tested it on it wasn't usable. It was slower than imaginable and kept crashing after one or two page loads. (The simple included help pages at that. I didn't even feed it something complex, like YouTube or Google Docs.) But I've heard others hat a pretty good web experience with it. At least as long as nobody asks about security. The rest of the system is snappy enough. It's no KolibriOS, but on any x86 or x86_64 from the last ten years it should be as fast as anyone wishes their OS to be and much older computers run it just fine. There seems to be a not so small community of users and developers. Every new Beta that is released comes closer to a desktop OS that has everything that people ask about/for. (Let's not talk about big games people are familiar with.) And because of the growing community and the fact that the 32 bit version can still run many applications compiled for the original BeOS this is not just a small OS with theoretical goals bigger than its community. It's really usable already and it looks to me that it has good chances of becoming more important in the future. I'm not sure if I'd have said that five years ago. It's moving slowly (compared to Windows and Linux), but consistently towards its goals.

Edit 2024: The have been two new alpha releases since I wrote about Haiku here. It is definitely capable of being an everyday desktop OS even though the release candidate's version labels are modest. The biggest change recently has been that GTK3 has been ported to Haiku, meaning that a large number of graphical applications becomes available or portable. Applications that have been written with other operating systems in mind. This has been demonstrated with Inkskape and GIMP. But many more applications will follow, I'm sure. I suspect that this also means that Firefox or some fork of it will be the web browser most people will use on Haiku. It certainly makes it more usable as ther main OS for many people.

File Attachments (4 files)
Haiku_OS-1.png (image/png, 346461 B)
Haiku_OS-1.png (image/png, 346461 B)
Haiku_OS-2.png (image/png, 288045 B)
Haiku_OS-2.png (image/png, 288045 B)
Haiku_OS-3.png (image/png, 260590 B)
Haiku_OS-3.png (image/png, 260590 B)
Haiku_OS-4.png (image/png, 814785 B)
Haiku_OS-4.png (image/png, 814785 B)
Alternative Operating System: Essence Entry created on 2022-03-29 (edited 2024-11-15) author:steeph (372) cat:#100DaysToOffload (41) cat:Computer (78) cat:Operating Systems (24) cat:Software (53) cat:incomplete (22) lang:en (254) top:Software:Alternative Operating Systems (18)
This entry is referencing the entry 'Alternative Operating Systems'.

Essence

This is one I'm continuasly disappointed to not have been able yet to get running on real hardware. I like what I've seen. But I can't get it to boot, as do others. I don't know too much about the internals of Essence. But it seems to be relatively far in develpment. There is a sleek GUI with tabbing windows in the look of early Chromoium browsers, which looks very inviting, if only I could get it to even try to boot on any computer. The focus has not been on making the OS actually boot on real hardware so far. And unfortunately there has been no release since 2022 and no update to the code for over a year. So I stopped hoping that it might be working soon. I was looking forward to getting to know a knew OS that doesn't take a Unix-like approach and has nice tabbing windows.

(tba:screenshots)

Other new OSs not for real hardware

While Essence is what I created this entry for because I really hoped to be able to try this GUI on real hardware, I'll use the spacce left by the lack of an experience report to mention a few other PSs that look promising but aren't (yet) made to run on actual hardware.

Munal OS

An experimental operating system fully written in Rust, with a unikernel design, cooperative scheduling and a security model based on WASM sandboxing.

TacOS

My from-scratch OS with its own kernel written in C and assembly

TacOS is a UNIX-like kernel which is able to run DOOM, among various other smaller userspace programs. It has things like a VFS, scheduler, TempFS, devices, context switching, virtual memory management, physical page frame allocation, and a port of Doom. It runs both on real hardware (tested on my laptop) and in the Qemu emulator.

Go To Navigation Page
Show/Hide Navigation