Linux-Fan

I wrote about it extensively here: <https://masysma.net/37/why_terminal.xhtml>.

Short summary: No animations, No symbols, No touch optimization, no responsive design and I do most of the other stuff in the Terminal anyways so TUI is better "integration" YMMV :)

Nice, didn't think of that approach and It should work very well for the purposes of static headers and footers.

One key benefit of putting up an own server is that there are no limitations on file types and much fewer restrictions on what kind of content you can create.

For serving static files, I can (and have) lived a long time with one of the "free hoster" sites -- from times before Github Pages or S3 were a thing I guess, today I'd go for Github Pages.

A key advantage of moving to an own server was that I can enable the odd feature or technology any time. E.g. most recently I wanted to have some "private" subspace with fancy authentication and it was easy to add with proper access to the server config.

Unlike Framesets I think XML includes were never really supported in many browsers (or even any major browsers)?

I still like to use them occasionally but it incurs a "compilation" step to evaluate them prior to handing the result of this compilation to the users/browsers.

Nowdays it is sometimes the other way around: Pages are all JavaScript so no good experience in the first place. I have encountered difficulty trying to get a proper “link” to something multiple times. Also, given that Browsers love to reduce/hide the address bar I wonder if it is really still that important a feature.

Of course "back then" this was an important feature and one of the reasons for getting rid of frames :)

Isn't this what proper framesets (not iframes) were supposed to do a long time ago (HTML 4?). At least they autoexpanded just fine and the user could even adjust the size to their preference.

There was a lot of criticism for frames [1] but still they were successfully deployed for useful stuff like Java API documentation [2].

In my opinion the whole thing didn't stay mostly because of too little flexibility for designer: Framesets were probably well enough for useful information pages but didn't account for all the designers' needs with their bulky scrollbars and limited number of subspaces on the screen. Today it is too late to revive them because framesets as-is wouldn't probably work well on mobile...

[1] <https://www.nngroup.com/articles/why-frames-suck-most-of-the...> - I love how much of it is not applicable anymore and all of these problems mentioned with frames are present in today's web in an even nastier way?

[2] <https://www.eeng.dcu.ie/~ee553/ee402notes/html/figures/JavaD...>

There is even some sort of “de-facto” standard for this purposes: Debian COPYRIGHT files: <https://www.debian.org/doc/packaging-manuals/copyright-forma...>.

It may not be perfect for all cases (e.g. if some sort of dependency is linked but not present in the source tree it is naturally not really accounted for by Debian copyright files) but then there is always the options of either adding copyright information to every source code file (I don't like that style for redundancy but it is for sure a very clear way to do it) or to hand-craft a human-readable variant similar to the Debian approach but less formally.

In any case it seems that nothing is new aobut this and developers working with FOSS software should very well be aware of these concepts.

I usually try to avoid the "makefile effect" by learning the technolgoy I use reasonably frequently (like e.g. Makefiles, Shell Scripts, ...).

However, despite the fact that I used to use LaTeX very much, I always copy-pasted from a template. It is even worse with beamer presentations and TikZ pictures where I would copy-paste from a previous presentation or picture rather than a template.

For TikZ I am pretty sure that the tool is inherently complex and I just haven't spent enough time to learn it properly.

For LaTeX I have certainly spent enough time on learning it so I wonder whether it might be something different.

In my opinion it could very well be a matter of “(in)sane defaults”. Good tools should come with good defaults. However, LaTeX is not a good tool wrt. this metric, because basically all my documents start something like

~~~ \documentclass[paper=a4, DIV9, 12pt, abstracton, headings=normal, captions=tableheading]{scrartcl} \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage[english,german,ngerman]{babel} \usepackage[english,german]{fancyref} % ... \usepackage{microtype} \usepackage{hyperref} ~~~

Most of this is to get some basic non-ASCII support that is needed for my native tongue or enable some sane defaults (A4 paper, microtype...) which in a modern tool like e.g. pandoc/markdown may not be needed...

Hence the purpose of copy-pasing the stuff around is often to get good defaults which a better tool might give you right out of the box (then without copy/paste).

I am rather ambivalent about these rules. I disagree with a lot of the individual points, but I am also sure that I have probably often written bad tutorials myself where some of the rules would have clearly helped... :)

> 5. Make code snippets copy/pasteable

I like to use the prompt to identify the language and also the user (root `#` vs. user shell `$`) to perform the action under. I advise against copying random commands off the internet especially those that run as root and may break your system (like `apt` and `--yes` together...). Of course, today, it is often assumed that you have sudo setup and then `sudo ...` is used to indicate the use of root privileges. It is an interesting convention although in my opinion this sometimes hides the actual intent.

I prefer:

    # echo 3 > /proc/sys/vm/drop_caches

over

    echo 3 | sudo tee /proc/sys/vm/drop_caches

The example given in the article is exactly one where attention is required: It adds a PPA as root, thereby giving "full control" to the PPA author. Never straightout copy-paste such stuff.

> 6. Use long versions of command-line flags

I am so much more used to the short versions hence I prefer `grep -RF` over `grep --dereference-recursive --fixed-strings`. Also, my go-to documentation about these commands (POSIX) doesn't even know about the long options.

I know that the advice to prefer the long options is repeated pretty often so it might just be me :)

> 7. Separate user-defined values from reusable logic

Ever followed some "enterprise-grade" software setup tutorial? Sometimes they start by assigning 20 variables to some generic values that you don't change most of the time and then go about to reference them on the next 20 pages or such making it close to impossible to know what is really going on. Also I find that for simple cases this greatly complicates the input process.

I think the example doesn't really show the difference because it has some variables (just not in shell syntax) in the code already like `YOUR-API-TOKEN`. Of course it is better to write `$API_TOKEN` rather than `YOUR-API-TOKEN`. I often prefer to see the example value in the example i.e. not `YOUR-API-TOKEN` but some real string (if feasible). In many cases I won't change a value in the beginning to see how far I get with a “known valid input”. Also, I often prefer to pattern-match some real value against what I have available, e.g. I have a key which I think could be the API key but if the format is totally different from the tutorial I may realize that this is an "app token" rather than "API key" and that I may need to get a different value if it fails to run with my input or such.

> 9. Let computers evaluate conditional logic

If dosed correctly, I think this is good advice. I'd strongly prefer the conditional boxes from the “bad” example over the “good” monster shell script command. In my opinion a tutorial shouldn't optimize for speed of execution but rather foster the understanding by the reader. There is no help if I find this post 10 years later and it helpfully outputs “ERROR: Unsupported platform” on my Debian 16 system. If the text instructions are given as in the “bad” example, I quickly realize that all of this is outdated and I should probably try with the most recent package name (example-package2) rather than meddle with some script.

I use Firefox + uMatrix to achieve a similar setup.

One advantage of using only a script blocker in favor of a proper ad blocker is that I don't shut off reasonable ads but only the ones that do shady stuff with a lot of computation and tracking on the client PC.

uMatrix has the advantage that it additionally blocks cookies by default, making the tracking even harder.

I use a dedicated alarm clock.

Recently, I have built my own: <https://masysma.net/37/dcf77_vfd_raspi_clock.xhtml>

Before that (and now for redundancy, I think my own one still has some minor bugs), I used a cheap one by "OK" <https://www.mediamarkt.de/de/product/_ok-ocr-310-2172968.htm...>.

I don't like that I have to mash some tiny buttons to set the "OK" up and also to stop it. The LED that shows that the alarm is active is also hard to read for me. Hence I tried to improve upon this in my own design. I also found a solution to avoid the backup battery, but it is probably not what the "general public" would like to have either :)

What became of "don't ask to ask" (https://dontasktoask.com/)? Although it may take some getting used to, I find it convincing that one shouldn't need to ask about whether it'd be OK to ask for short questions because the question for permissing is interrupting just as much as the actual question except that with the former it may be impossible to estimate how complex it is whereas it may be much easier to decide if the question is known.

For longer issues, could it make more sense to schedule an (online) meeting?

And on the receiving side of interruptions: Ocasionally it has helped me to just keep the "chat app" closed when I want to concentrate on something. If anyone has something urgent, they could always elevate to performing an old-style synchronous phone call, but interestingly this rarely happens with "text-chat" people :)

> * Simple markdown-like markup language with math support for my website/blog. I did it so that I get nice SVG equations that show up without things jumping around all the time while it's rendering. https://github.com/dllu/dllup

Nice design and nice page :) I was wondering whether I should post my own take which has a set of similar requirements, too, but figured that at least currently it does not give much “productivity” but is more of a free-time activity for myself.

Productivity software for myself:

I have added an undocumented option (--ical URL) to my script `mai3bar` that by default displays CPU, RAM and HDD usage alongside a wall time clock. When the `--ical` parameter is added, it detects whether there is an appointment within the same working day and counts down the minutes to it. Once the event is 15min away, it turns yellow and then red at 5min to go. This way, I can attend the events without having any distracting prior ”notifications”. Just occasionally glance the colors in the status bar... <https://masysma.net/32/i3bar.xhtml>.

Another productivity measure was to write down many of the “vector workflow” commands that I use to pre and postprocess various graphics, including making aliases for hard-to-remember syntax of commands (rsvg-convert ... -> svg2pdf here: <https://github.com/m7a/lp-conf-cli/blob/master/svg2pdf>). The vector graphics stuff is collected in a long, searchable document here: <https://masysma.net/37/vector_workflow.xhtml>.

My start page “Information and Links” helps me to quickly access the accurate and applicable documentation for some programming environments that I work with and allows keeping a list of links in the same UI <https://masysma.net/32/ial.xhtml>. Complete with VI-inspired key bindings :)

To me its a sane choice on my own single-user machine. I used to create a top level `/data` directory to put my stuff into (before Android was widespread :) ). Nowdays, my data resides in `/data/main`. This scheme has served me well for more than 10a and through various OS migrations (Windows -> Ubuntu -> Debian).

I don't want to have all this `.cache` and similar stuff to take up my expensive backup storage, nor do I want to waste time cleaning up after all the applications that create/expect files in `$HOME` or think this a sensible place to put executable files. I don't want arbitrary applications (heard of tracker?) to start indexing my files and waste CPU on that etc.

Also I don't believe in /home being portable across multiple Linux distributions because e.g. different application versions might require config files to be migrated. Hence I opt for `/data` that can safely be shared across multiple systems because it contains actual data and not some OS-related state files.

On multi-user systems, the `/data` approach doesn't scale. There, I prefer to do just as boomboomsubban writes: I create a subdirectory in $HOME (usually, I call it `wd`, the "working directory") and treat that like my local `/data/main`. For large/temporary files (e.g. application downloads etc.) I add a `$HOME/large` directory to keep the `wd` reasonably small in such cases such that I can again include it in backups without having to worry about the size.

YMMV

Of all the features that you have listed, I use only the syntax highlighting. I have never tried to turn it off for longer than a few minutes when it worked.

When it is broken (e.g. wrongly coloring stuff) I sometimes turn it off, but this is usually not long enough to find out if I am really better without the colors.

Turning off the syntax highlighting is still one of the things that I would like to try out some day...

Working over SSH is not the only TUI advantage: IMHO one of the greatest benefits of TUIs is the usage of characters to display the UI. This way, the font size is always equal (no unreadably small fonts).

When designing TUIs I found this to be limiting in a creative sense -- I have to really think about how I arrange the TUI elements and information because I cannot put as many elements as I can on a GUI in the same screen space.

Also, TUIs seem to be mostely unaffected by the trend to make every GUI element “touch-friendly” large which is an advantage for me as a Desktop user.

Full rant here: <https://masysma.net/37/why_terminal.xhtml>

Strongly resonates. The first time I saw the CLI Guidelines I even stopped reading them upon reaching that section. This time I read through the remainder and found it quite OK.

> Content-addressed backups sound something like how git stores data, is that the best way to think about them?

I think it is a valid way to consider them. Another option is to think of the backup as a special kind of file system snapshot that manifests itself as real files as opposed to data on a block device.

> And if so, what would be the main differences between just committing to a git repo for example?

The main difference is that good backup tools allow you to delete backups and free up the space whereas git is not really designed for this.

> I've seen RSS styling before but it does feel like an oddity. I think I'm so used to the code view that when I see a styled feed page, it makes me wonder if I'm on the real URL. But at least the page does explain itself.

Indeed, that was my greatest concern for adding a stylesheet to the RSS on my website. I tried to solve it by including a screenshot of the source tree :)

On my website, the RSS is announced through metadata only on the news page. Per the “Exposed RSS” statement, it should be linked from all pages? I wonder whether it really makes sense for someone to subscribe to a page without even checking it out on such a cursory level as to find the news page, though?

One of the major benefits of software is that you do _not_ need to re-create it if it already exists and solves your problem.

An unmaintained app that solves a specific problem is never going to break by itself “in a not distant future”. Only if its environment changes so much that it cannot be run anymore (including security fixes missing in the app) does this happen.

I recall a firm making good money while using their internally custom-built software for MS DOS with no way to change it whatsoever -- the software firm that wrote it was probably already long out of business, source code was not available -- and that was in 2019 which was already long past the days of MS DOS.

I think it is worthwhile for OSes and other core software infrastructure to support running even unmaintained apps as much as possible because it reduces the need to rewrite (or overhaul) programs only due to a lack of maintainance for the existent one.

Not caring about this is IMHO accepting to waste a huge portion of the advantages that software gives us compared to other technology (software by itself never breaks from physical defects or continuous use, does not stain, etc.).

Termshark can be a live saver if you need to analyze large packet captures. The GUI of Wireshark was almost unusable with some large (30 GiB or something?) capture on my development laptop and some filters. Termshark did not process that data quickly but at least allowed me to get the job done.

Writing should certainly go first. But once you have passed the first iteration of your own self-built static site generator or website the "initial" content may already be there from the previous iteration.

I certainly learned to keep the featureset of such a program to a minimum in order to have a chance to "complete" and publish it.

Btw. the article lists five points that really come close to how such a generator may work. I think mine only leaves out the CSS compilation stuff and offloads the Markdown processing to pandoc...

Indeed, thank you for pointing this out. I have added a footnote to the page accordingly.

They missed the most prevalent everyday use of water pipes (except for their originally intended use cases maybe...):

<https://www.country-reiten.de/magazin/tipps-tricks/112-klein...>

Bupstash (https://bupstash.io/) beats Borg and Kopia in my tests (see https://masysma.net/37/backup_tests_borg_bupstash_kopia.xhtm...). It is a modern take very close to what Borg offers regarding the feature set but has a significantly better performance (in terms of resource use for running tasks, the backups were slightly larger than Borg's in my tests).

I have started to use this system shortly after having first heard of it. I think the greatest challenge is that as I constantly create new things while only completing a fraction of them, I'd end up with a very “sparse” set of numbers being “active” in the end and unlike what is claimed by the system the relevance of directories for me is rarely linked to the time of their creation. Hence I needed to tweak this system a little to be useful to me and while it is a minor improvement over before I am still dissatisfied with the outcome...

An alternative organization system which is more lightweight and could also work well -- I am not affiliated, but would like to try to add some of these ideas to my own structuring approach: https://plaintext-productivity.net/3-02-file-folder-structur...

During the course of time the License of the JD system itself seems to have changed to a CC “NonCommercial” license. This really contradicts that this system is intended to be also useful in business contexts. I shall only look at my old copy where it is still under a DFGS-compliant license, but I wonder whether it is even possible to claim ownership on an organization system by means of a license? Wouldn't the only way to protect against it being used or described anywhere be a patent?

Having never written anything in Rust but read and “translated” some code (maybe 3k LOC?) from Rust to Ada, I can tell that I found Rust rather hard to read and harder than e.g. Ruby (which I also do not know how to write but translated to Java once).

Here is what I guess makes it hard to read for me: There are many terse keywords (fn, mut) and symbols (&, [], ->) along with some things that look like Java annotations and are equally hard to understand without knowing the language. Array slices look easy enough to understand [a..b] but surprise: b is actually exclusive? The definition of arrays is the most weird one I have ever encountered [u8; n]. To me Rust looks much like C++ with a twist and people rightfully complain about C++ often :)

The documentation about language and libraries was solid for my cases and most of the time it seemed enough to ignore most of the tiny key words and symbols without losing much understanding of what the code intends to do. If I were given the choice I'd probably still prefer Rust's weird syntax with added safety over the clarity of C which offers no safety at all (not talking about obfuscated code contests here).

Maybe I am biased because I work in embedded :)

Before that I also encountered similar issues at the other end of the performance spectrum: When working with parallelized C++ code that required more than 64 GiB of RAM the overhead of a debugger can make the difference between being able to run the program or not.

I still believe that in almost all cases it is possible to use a debugger even there, but it is always a significant setup required.

And in the modern languages like Java and Python there are stack traces which already greatly help with the “debugging” such that even there I rarely missed the option to step through a program. I never worked with any really complicated Java or Python codebases, though.

I am personally also not using debuggers much -- I think within the two last years it was only the backtrace functionality of gdb twice for a crashing C program :)

I still wonder whether it would make sense to learn more about using them, though. My reasons for not using a debugger often are primarily:

* I work with different kinds of systems. Printf or some equivalent is always available, Debuggers always require a system- and programming-language dependent setup and incur an additional learning curve.

* The hardest bugs I have encountered so far were timing-dependent and could not be reproduced when running under a debugger.

Instead I prefer to work with the printfs and some tools which work non-interactively like strace and valgrind. To me, it makes a lot of sense to look at the code when there is a problem and consider the problem in my mind, although I would not go as far as saying that this is in any way fundamentally superior to stepping through the code interactively?