LOST
Name: SummerLast seen: Last week
Character traits: Warm to hot, sunny, dry
Special needs: Cooling with water or moving air
If found, please return to Europe
THANK YOU!
I just canceled some domains that I had registered. Among them were the domain names mixblog23.de and mixlog.de. Both of which were once used for a blogging platform of mine that wasn't alive for a long time. But I kept the domains just in case. (I don't know which case that would have been.)
The platform was initially supposed to be called Mixblog, but I couldn't find a free domain name that I liked. So at some point I registered mixlog.de, which by now sounds better and more familiar to me anyway.
The point of mixlog was - apart from me having a website to build and something to learn on - to create personal feed of content from different blogs on that website and other sources (RSS feeds). It could essentially be used as a feed reader in a web browser with the ability to publish stuff on the same site. RSS aggregation wasn't scaling well, so it would have been difficult if many people would have used it as a feed reader for many feeds. But that wasn't its main purpose anyway. So, you could post blog posts, image galleries (which technically were blog posts too) and links to posts on other websites (which imported the content and worked as a repost). You could follow blogs and repost and fav posts from bogs on mixlog and from other blogs as well. Classic blog comments existed too. Pingbacks and RSS feeds were supported as I still liked to think was standard back then.
I saw the platform as like sort of a twitter with fewer members, more features and without contrains (no small character limit, reblogging and following blogs from other websites was supported). When I later learned about tumblr, I started to think of mixlog as like sort of a tumblr with more features and a less professional design and UI. But I don't think tumblr even existed when I stopped working on mixlog.
So why isn't mixlog around anymore? At its peak there were three active users on the platform (not daily active, far from, actually). That included me, a friend who tested it with me in the early development stage and another friend, who tried it out for a short while. Altogether there were four user accounts/blogs. And mine was the only one that showed sings of prolonged motivation to post stuff. So when it became clear to me that nobody but me would be using it I thought it to be overblown for a personal weblog, stopped adding features and eventually took it offline instead of fixing a potential vulnerability of the underlying framework.
I guess this here is just to say: R.I.P., mixlog! You will forever have a place on my backup RAID.
(tba: screen shot)
Here are in short my tips to reduce hoarding of stuff you think you may need some day but almost certainly won't. If you're not really a hoarder - as in the worst examples that TV likes to portrait - but do have a problem throwing things away despite not having space to store all that clutter, this may help to clean out your storage. (I'm assuming it may because it does for me.)
If you have too much money you then buying storage or land to store things without having them clutter up your house is an alternative. But it's not really worth it. It's just paying money so you can keep that warmish feelng of still having access to everything but you'll also keep your problem. I mean unless you're really collecting something valuable or you become "that guy" for your town with large property where everybody goes before buying anything other than foot. Some towns have such a guy who stores avery piece of wood and metal they see so others can browse for their DIY projects. I like these guys. But you don't have the property for such a stock, do you? So don't try to be that guy for you town, for your friends or just for yourself. It takes the same amount of space in either case.
Being a digital hoarder myself, I'm hypocritical enough to have a different opiniont about data hoarding. But I'll write about that another time.
If you don't know what the CCC camp is, I'm not going to try and explain it. You'll find introductions and it's history explained. (See the links below)
I wnet again this year. For me it's a rather expensive vacation. But it's worth it and I'd probably even do it if I didn't know where to get food until my next salary.
There are so many thoughts about this event. It's just such a unique and overwhelming experience. It feels good to see that the community is able to create such an overstimulating and incredibly welcoming world. It does feel like a different world, and I'm sad every time it is over. I thought I'd write at least a few entries about the event. But I find it hard to put into words what Camp is for me and what it feels like. So I guess I'll leave it at that for now.
Here are some links to open directories I deem interesting or deemed interesting at some point for some reason or another. This list is not maintained; expect dead links.
When I still had some motivation to go out to take photos I used to take photos of fireworks whenever there was an opportunity. I especially like these pictures of a show at Dürkheimer Wurstmarkt (multiple years). There are some more in my gallery at DeviantArt.
To the extent possible under law,
steeph
has waived all copyright and related or neighboring rights to
this work.
So in this entry I kind of just want to introduce SBWG a bit. Even though it's not the first time I post about the project here (it's Dec 2021 now) I realised there is no explanation on what I'm making and the page on the tag cat:SBWG consists pretty much only of updates. This is mainly a personal weblog and not a project web site. So a bit of background should be part of this introduction. To have the entry in the right place and order, I dated it back to Jan 2020, before I started to post updates about SBWG.
Every now an then I develop or intensify an existing interest in a topic and it becomes my main hobby. I've liked shell scripts ever since I started to use Linux. But I really started to write shell scripts for my own use properly in 2019. I wanted to write better and more rebust scripts. Learning a language or improving language skills works best by actually using the language. SBWG is my project that makes me use Bash to archive many different things that I previously didn't know how to accomplish.
SBWG (steeph's bash website generator) is a bash script that generates static HTML from simple text files. A tool that generates/updates this web site when it's run. Bash surely isn't the right choice of programming language for such a task. But I like Bash and don't really care. I try to make SBWG professional in all other respects. But it is a learning project. So there will probably always be things in the code that could be improved. The more features I implement and the more I learn the more I notice that I could have done better. But I do want to keep implementing new features (My list of ideas is long.) and not just rewriting what already works.
For information about the script, have a look at the project page. The README file in the downloadable package has extensive information about how it can be used.
SBWG (steeph's bash website generator) is a bash script that generates static HTML from simple text files.
This entry does not have current information on SBWG. It was initially intended to hold an up-to-date introduction of SBWG with a download link. But I don't want to edit this blog entry all the time. So this stays obsolete and incomplete and I point you to the correct URL.
SBWG (steeph's bash website generator) is a bash script that generates static HTML from simple text files. I wrote it just for fun this website. And
it's pronounced sibwig (because why not). It is not professional, not very adaptive to other website structures and does not have many features compared to
most other static website generators. But if you know HTML and bash you can certainly adapt it for creating other websites. Or use it as it is, if you happen
to want the same website structure as I have. If you want, you can download the latest version that I've published here
.
The script creates a HTML structure from whatever text files it finds in the source directories.
The script generates an HTML file from every file in the directories pages/ and entries/, as well as blog-like listings for every tag
found in these source files. Page files are generated into the html/ directory. Entry pages are generated into the html/entries/
directory. For every tag found in the entry source pages an additional HTML file is created in the html/tags/ directory. You can add more files to
the html/ directory. As long as there is no file with the same name being generated or copied by the script, they won't be affected by the script. This way you
can add more CSS files, media files, JavaScript files or anything else you might want to add to the website.
head and header.html/.This is where the script puts the resulting web site. It can be used as live webroot/symlink to a webroot or you copy your finished website from there to the webserver.
This directory is empty when you start a new website. You fill it with source files for entries/blog posts. An HTML page will be generated from each entry source files, all entries will be included in the all.html blog view and entries with tags will be added to the relevant tag pages. Entry source files start with an HTML comment that resembles a header that typically contains the creation date, a title and tags (categories, topics, langeage). All of these are optional. But the structure (the HTML comment) needs to be there in any case) See below for a detailed description of the source file headers with an example.
This directory contains source files for static pages that are not blog posts. An HTML page will be generated from each page source file. You can use it for a front page, contact page, etc. Page source files are similar to entry source files but they contain no tags. See below for a detailed description and an example.
This directory can contain directory of images that will be generated into a gallery view. Each subdirectory will become a gallery. If a subdirectory (gallery) and an entry source file (blog post) have the same name, thumbnails of the images will be attached to the blog entry and a link to the gallery view will be placed at the top of the blog entry. A link to the entry will also be included on the gallery page. A gallery does not need to have a corrosponding entry though. You can simply create galleries by putting JPEG and PNG files into a directory and this directory into the galleries directory. Currently only files ending in .jpeg, .jpg or .png are recognised by the script.
In this directory you can put files that should be available on the generated website but not be processed by the generator script. The content of this directory will be copied to html/files without any check. You can use this for any files that will be linked in pages and blog entries, image files that are not part of a gallery, JavaScript files, etc.
This directory is used by the script to store information about tags found in entry files during the generation process. It is solely a working directory. Files stored in this directory will be deleted during a complete website generation. You can just ignore (er empty or delete) it. A future version of SBWG will likely switch to a better method of keeping track of the tags used and will not need this directory.
The sidebar file contains the last generated sidebar of the website. This file will be included in everey generated HTML file to enable navigating the website structure. You can ignore this file.
The head file contains the head of the HTML page structure. It will be used as the beginning of every generated HTML file When starting a new website it contains the neccessary things to generate a sample website. You can edit it to add meta tags and link or include style sheets.
The header file closes the HTML head and starts its body. It contains the header that will be included in every generated HTML file. When starting a new website it contains a logo and the name of the website. Feel free to include anything that you want to be on the top of every page of your website, like a menu, etc.
Having the head and the header files separate enables the script to add tags to the HTML head for individual pages. This is currently only used to add the page's title.
The footer file contains a footer that will be included at the end of every generated HTML file. Feel free to edit it to include anything that you want at the bottom of every page of your website. It also closes the HTML tag structure.
More files can be placed at the top of the directory structure. As is the script copies the file style.css from here to the html directory. All other files (not mentioned above) will be ignored unless you edit the script to do something with files tht you have added.
Every source file (files in the directories pages/ and entries/) is supposed to start with at least three lines of HTML comment.
Example source for a page file:
<!--
This Is The Page Title
-->
This is the page content. It may consist of HTML or only text.
The first line can be used as an actual comment and is ignored by the script. The second line is used as the page title/entry title. For entries, any additional lines inside the HTML comments are used as tags/topics (one tag per line). The comment should be closed with a line only containing -->. Everything after that is the actual page/entry content. HTML can be used here and will not be filtered by the script. This may change in the future.
Example source for an entry file:
<!--
Blog Entry Title
1970-01-01
lang:en
cat:Category
top:Topic 1
top:Random Topic 2
top:Topic Three
top:Some other tag
top:#hashtagsworktoo
-->
<p>This is a blog post.</p>
(tbd)
(tbd)
(tbd)
If the script is run without arguments it's using what I use regularly, which is options t, e, a, r and p. If arguments are given, the script will only generate the part that was selected with its corrosponding option. The following options exist:
Not all of these options are implemented, yet, but at this point, all except the RSS feed generation works well enough. Keep in mind though that this is all work in progress and I'm only meeting my own needs as I'm not aware of anybody else using this script.
Not all available options can be set through command line arguments (yet?). There are a few variables that are being set at the beginning of the sctipt. Check out the first few lines. The comments above the lines where variables are being set should be sufficiant explanations of those variables. There you can set for example the size of gallery images and thumbnails, the number of blog post per page or the directory where the generated HTML site is placed to.
RSS feed, nice layout and styles
I'm not sure I really like the fact that GTK has been ported to Haiku. Of course it's great when open source works that well and people put the work in to make something available for more people! For many more people than it has been before, Haiku has become a viable choice as their main desktop OS with Beta 4. Not too many apps are developed for Haiku natively and even the old BeOS apps, if you have one that you would still like to use, don't run on amd64. With GTK more useful apps became available.
But Haiku is a low-resource and especially low-latency OS with defined goals of keeping this spirit alive. It does still run on 25 year-old and older PCs. The few applications that exist for #Haiku you can trust to be much more careful with using available resources than the average GTK application. I don't believe that Haiku will become as wild as Linux. The OS still is much smaller and will stay that way. But if more and more #GTK applications will become the standard solution for tasks, there will be less gaps to fill and less gaps will be filled by new, small, low-latency GUI applications.
I'm not saying I don't like this development. I'm sure I'm going to make use of it. But I'm not sure I like it, too.
Edit: There is a blog post with a very interesting discussion in the comments about this: Haiku isn’t a BeOS successor anymore by Thom Holwerda