Aparently this is somewhat a famous thread at least in the Linux community. But I'm neither a frequent reader nor a subscriber of any usenet content. So I didn't see it before.
Linus Torvalds in 1992 on comp.os.minix, apologizing for overreacting and ignoring netiquette: "my first, and hopefully last flamefest"
I guess hope wasn't enough. :)
Why is the Windows Subsystem for Linux called the Windows Subsystem for Linux when it is a Linux Subsystem for Windows?
There are too many Linux distributions to list and too many Linux-based systems to try all of them out just for fun. There also wouldn't be much of a point to doing this. And there's nothing to say about Windows or MacOS in this entry. But I'd like to write a bit about operating systems not very many people have heard of. Specifically, I took a look at several lesser known desktop operating systems. This entry is like a forword to my coming entries about those alternative PC operating systems.
There are a few other operating systems that aren't used on as many computers, aren't as well-known as the big three (Windows, Linux, Mac OS) and their derivatives, but are still important for their use case or niche. There's the extended family BSD, MINIX, the PlayStation system and many other Unix-like systems, there's Illumos and other actual UNIXs, a variety of DOSs and many even less widely used OSs for small niches. Those all deserve an article. But this is not one about any of those.
There are many UNIXs and Unix-like operating systems that aren't actively developed or not even officially supported anymore but still in use in various industries. (Never touch a running system!) There are many old systems that are still sometimes used by retro computing fans, users with nostalgia attacks and people who just never updated their machines since the 80s or 90s. I'd like to write an entry about those systems. But not right now.
There's also a huge landscape of operating systems on embedded systems that are not primarily seen as computers, such as DVRs, cars, household appliances, toys, parking meters and many many industrial tools and machines. An article about how this landscape of proprietary in-house systems turned into a stable of Linux systems would also be worth writing. Or one that takes a look at some sleek systems, from tiny, incredibly efficient environments for 90s microcontrollers to larger systems like Palm OS. But my motivation for this entry right here is about something else.
And there are operating systems that don't fit any of the beforementioned categories, but still have a reason to exist or at least had a reason to be made at some point. Independently developed OSs for personal computers that emerged from a single person or a small group of computer enthusiasts as learning projects, to prove a point, or as a recreational coding project. Those are the OSs that I'm interested in this entry.
For a long time I thought that such operating systems don't exist, don't reach a state in which they are worth checking out or aren't shared publicly. I did wonder why nobody seems to write alternative OSs just for the sake of it. Maybe the landscape of existing OSs and the tiny adoption of any OS that isn't one of the big three (or four, or five, depending on where you make the cut) takes away any motivation to start yet another small OS from people who would otherwise pursue such an idea, I thought. But it turns out that I didn't look closely enough to find them. There totally are working alternative operating systems that were made for the sake of it, despite Linux satisfying all requirements of the project's initiators in most cases. Many of them may have 0 to 1 users and some of them may have never and may never be used as anybody's main OS. But some of them are very interesting systems. I'd like to point out a few of those.
My initial intention with this entry was to write a paragraph or two about one or two handful of OSs. But I found that there is more to write and more projects to share about this topic for several different reasons. I will write separate entries about a dozen alternative operating systems when I find the time to check them out myself. I'll use the category Operating Systems for these entries. Since I found more than I thought I'll restrict myself to testing only systems that check the following boxes:
Those are critera that I thought of and wrote down after searching and finding most of the projects I'll write about and after deciding which ones I find interesting. And I might ignore or change those criteria further when I feel like it. They are here just to give an idea on what sort of projects I'll pick out and write about.
There are more alternative desktop operating systems than I expected. I thought after the 90s the landscape has become very flat. But development of a number of commercial and non-commercial operating systems went on for much longer. There have been many large projects I had never heard about. Some of those have been officially ended over the years (like eComStation and Syllable Desktop), others are still worked on (like Redox, MenuetOS and MorphOS). I stumbled over so many names of OSs that are in a state in which they're not really usable as a daily desktop OS, that had been published on some now offline website or that have been discontinued years ago. I thought I'd try out most of what I can find and write an overview of the alternative desktop OS landscape. But that would be a project in it's own that would be huge and take far more time than I want to invest in it. Many names worth mentioning have not been mentioned here and many cool projects also won't be mentioned in any of the articles to come. For example I ignored commercial OSs, like ArcaOS. I just don't want to pay 129 $ just to test a system that I'm likely not going to use.
I can already, after having only briefly tested a few systems, say that there are usable, stable systems that hardly anybody has heard of that are as good as any commercial OS from the 90s. That's good enough for most desktop users. Each with their own set of features and unique selling points, there are real decisions to be made when selecting an alternative operating system that go beyond the questions one asks when selecting the next Linux distribution during distro hopping. I am happy that there are more than one or two systems in a usable state that focus on supporting old hardware and/or using less hardware resources than we got used to with Windows, Linux and MacOS. Whether you're looking for something to run comfortably on an 80286 or something that runs ridiculessly fast on a modern 64 bit system. There are systems to choose from.
So many ideas, so little time. So many todos, no little time. So little time, so much rest of my life. But the todo list has actually started to become a little shorter for the first time in a long time. As with the previous entries about my progress with SBWG, I'm not going to address or list everything that I've improved or added. But I feel like it's time for another update.
File attachments pretty much work as intended now. Text files still can't be file attachments to entries, because text files are entries. But I think that will stay as it is for now because I don't need to attach text files to entries and if I would, I could gzip, bzip or 7z them. I mainly wanted file attachments for entry images and podcast support. Both works as well as I need it to. But some things could still be improved in the future.
Referencing tags are improved, their notes look better and there is now a way to mark an entry as an update of an other entry, giving both entries a note that tells the reader about the newer/older version. And since this works now, I dropped the idea to introduce any form of content revisioning. An entry revision system would be over the top for a feature that I hardly use. This could still be implemented just with hooks.
SBWG was relying on a feature of ImageMagick's mogrify that turned out to be a bug and was fixed. So I had to switch to convert with worse tolerance/support for broken image files. That's annoying, but I'm over it now. I mean, I wasn't complaining. Those tools are amazing and I'm so glad that they are free.
There were a number of other bugs that I've fixed. Some of them old and overlooked. But most of them were introduced not long ago. Well, I guess that's what happens if you don't do proper tests every time. SBWG is starting to become a feature-rich tool and every new feature that gets implemented could cause trouble with other features or combinations of features. In early versions of SBWG I didn't always test everything I changed. I now do, and I now also try to think of some related things the change could have effected unintentionally and test those basically. But proper tests of all sorts of scenarios every time I publish a new version? That would be professional but not worth the effort in this case. If I'm not using a feature, it doesn't matter much if I break it. I think I'll probably do more extensive tests every now and then.
Entries can now have comment links. If there is an email address available for an author, all their entries get an email link below them to allow readers to reply to them. For a public blog it might be best to use throwaway addresses that can quickly be replaced if they start to receive spam. I'd have some ideas to improve the email composed by this comment feature. But they would have to become HTML emails. So I forgot about them again.
New tag types, expanded README file, improved navigation by adding parent links and things like this, improved CSS a bit here and there, very small improvements to the code style. I didn't make any relevant improvements or corrections in terms of code quality. I think this is where SBWG could improve most. It's not a professional thing, so I declare myself fine with the way it is (which isn't that bad compared to some other software, I think) but I could learn a lot there.
Command line options can now be grouped to make typing commands easier. Long options (starting with --) didn't change (I may make those things POSIX-like, too, some other time) but short options (starting with a -) now don't need to be separated and all have their own dash. So sbwg -v -p -e blub can now be shortened to sbwg -vpe blub. And if you want to run the command again but with added verbosity, you can add the second -v wherever you want.
There is now a waiting animation that starts to play if there is no update on stdout for three seconds. Both the animation frames and the time delay can be changed. The animation is only enabled if SBWG runs with any verbosity. Then it is enabled by default. It will be disabled by default in future versions though, I think, because it's such an unnecessary messing around with terminal output. It does work pretty well though. I thought it may be harder to make it work as smoothly as it does now (which isn't 100% perfect, but pretty good).
The new default style set 'elth' is a working hybrid with different styles for small phone screens and larger screens of phablets, tablets and laptops. It's composed of several CSS files, which should make it easier to create a custom style now, since just the basics (without any colors and fancy embolishment and without any tag-specific stuff) can be copied for a template, or just the mobile style can be copied and used to create a new mobile style. Style sets can now also include files whose name don't end in '.css'. That means they can contain any file type. So JS or background images or whatever will be copied as part of the style set and placed in the 'styles/' directory of the generated web site.
More things are now cached that may be used more than once in one run of SBWG. Permament caches (option -C/--cache) can now be enabled for only parts of the web site. I still need to decide how permanent caches should be managed. The way I had/have it in mind does not seem very intuitive. It is to me because I know how it's built. But... well, maybe it's enough that I think that it makes sense. Maybe I should just start using it and if it works well, write it down in the README file.
Added new hooks, gave the helper scripts makeovers, made how HTML footers are made logical, sorted much of the remaining todos. Overall: progress.
So, I've published SBWG version 0.10.7 now. I wish I'll find the time to create and publish new versions more frequently again in the near future. But I doubt I will.
I know, my entries on SBWG are too chaotic to follow what's happening with the project in detail. But who cares, really? I'll just continue to write broadly about the progress that I make with the script.
So, after re-deciding that I'm not going to make a version 1.0 because it's just not the kind of software that can ever claim for itself the thoroughness that I myself would expect from a piece of software that's labeled v1.0, I finished the testing and bug squashing that I, for a short while, had intended to lead to version 1.0 to my satisfaction, and started implementing new features again. Great, now I can make the script take longer to finish again. :)
During my testing and bug squashing spree I already implemented a routine that I call the pathreducer. If enabled through command line option, it reduces paths to conform with the file and directory name restrictions of most file systems out there. I took this a bit far and it can now even conform to filenames of the 6.3 format, if the user wishes. I have ideas to improve this further, including making it automatically conform to the exact limitations of individual file systems instead of stripping and replacing characters that aren't allowed in file names in many file systems whether it would have been necessary in the present case or not. But that's for another time. For now it works well for what it is supposed to be: a workaround for too long and otherwise invalid file names that would be generated by the script when naming files after categories, topics and other tags, as well as a solution to problems that might occur if SBWG would be used to generate a web site onto a file system that has more restrictions than those commonly used on Unix-like systems.
As part of the improvements made during the no-new-feature time, I fixed many bugs that I didn't expect at all when I started (which is why I prohibited myself from implementing new features in the first place), learned a lot about Bash again, and made some small improvements that I wouldn't call new features, but are still neat to have. One of them makes tag lines more intuitive. Forbidden characters are removed or replaced and leading and trailing whitespaces are removed, leading coincidentally to the fact that you can use a space after the tag type (e.g. 'cat: Example' instead of 'cat:Example') or not and the tag will be recognised as being identical in both cases. I'm mentioning this because the first person to type a SBWG tag line besides me typed a space intuitively and I had to tell them that that's not how that works. Well, now it is, if you prefer it. Maybe case-insensitivity will be next. I'm considering it. Wouldn't be hard to add. I'm not sure if I want it, though.
Another thing that improved drastically in that time is the time it takes to generate huge web sites. SBWG never had problems with giant files, even entry files with gigabytes of text, because the content body isn't parsed. But with thousands of entries or thousands of tags in one entry, generation time would previously go into hundreds of years (theoretically/calculated, of course). By improving some routines and caching some parts during the generation process I got the generation time of an example torture web site that I created, from over 300 years down to just short of 72 hours on my Core-i5 ultrabook onto an NVMe drive. Any reasonably sized web site even with a relatively large weblog is completely generated much quicker. So it would be possible to e.g. let SBWG re-generate a web site automatically multiple times a day without problems. I have other ideas that will speed up the generation process significantly, namely parallel processing and skipping of existing unchanged content. But both those features are not mature enough, yet. I will probably attend to them again when I have packed SBWG with so many features that slow down the process compared to the current version that I feel more parallelisation and more drastic caching will be necessary.
So, the first new feature on the list were entry pictures. A way to bind pictures, image files, to entries without having to include <img> tags. This feature now already developed into a general way to attach files to entries. Images are resized, embedded and linked to their originals, audio files are embedded as an audio player if the browser supports this, and other files are linked to allow visitors to download them. Video files will also be embedded as a player in future version. The file attachments feature is not done, yet. Enclosures in the RSS feed, presentation of the download links and many small things have to be improved. But the initial idea of entry pictures already works. There is a naming convention that makes a file an attachment to a certain entry. (The same naming convention as is used for style sheet sets.) See the README of version 0.10.2 or above for detailed information.
The next feature on the list is comment links below blog entries. Simple mailto links to let readers e-mail comments on entries to the author. I will probably start to work on multiple features at the same time again, as I did before.
So, I've published SBWG version 0.10.2 now. I hope I'll find the time to create and publish new versions more frequently again in the near future. But I doubt I will.