Linux-Fan

Don't know about efficient, but there is at least two ways which seem to work OK-ish (although not all that efficient, I gahter):

* Do regular certifications. Before certification, check if the document is up to date. If not, update it.

* Share the documents to answer teammates' questions. Like with a WIKI it may turn out that the important stuff is actually missing/undocumented/outdated. This is then a good opportunity to fix the document.

> > a Google Account that isn't tied to anything else.

> Isn't that pretty much impossible? You need a phone number for verification, which effectively ties it to that phone number.

I just want to follow-up on this because some people claim this is not correct because they have managed to create accounts without phone numbers.

Indeed, I think to this day, under special circumstances (like e.g. on reasonably recent Android devices) you might be able to setup a Google account without phone number.

The trick is, that in the general case, you can not keep this account online indefinitely.

I once worked out a trick to get it going and I was feeling safe because I had setup 2FA and backup codes (see https://masysma.net/37/google_how_to_create_an_account_witho...).

First thing to note: This way of account creation does not seem to work anymore.

Second thing to note: After once logging in from a different country, trying to login again REQUIRES me to provide a phone number after successfully giving username/password/2FA code. No way to use the recovery code instead...

Also, given that this account was never before connected to a phone of any kind, by definition, the addition of a phone number cannot provide additional security confirmation (it's data that simply wasn't present before and any "personal" phone number could potentially do -- of course I haven't tried, because that's the point of not linking a phone number).

I think this way it is finally proven that they only do this to harvest the data/phone numbers and any claim of enhanced security is void.

I write this after having lost the second account to the phone number required screen despite being in possession of all the credentials which were ever assigned to that account...

I use the terminal for most things which are not web browsing hence for me it makes sense to prefer TUIs for "lightweight" GUI needs.

I love how I have to configure font size and family only once in the terminal emulator and not for each program/GUI toolkit again.

Of course, there is no way to replace graphical-heavy programs (GIMP, QGIS etc.) with TUIs.

<https://masysma.net/37/why_terminal.xhtml>

I was asking myself the same question and looked it up:

<https://pubs.opengroup.org/onlinepubs/9799919799/utilities/t...>

The most important differences seem to be:

* `:` is a builtin vs. `true` is an utility * passing arguments to `:` is safe but for `true` its not hence `:` is the right thing to use here.

Please continue to blog about the obvious stuff. It happens all of the time that I want to explain to someone what I think is an obvious concept and then I am sometimes surprised to find out that there are no good blogs where I could link to for an explanation...

I like the Lobsters stance on AI. Also posts are tagged hence you can decide for yourself if the topic may be interesting despite being touched by AI.

I haven't found a way to join Lobsters yet hence for the meantime I keep posting here only. Not so much of an issue since I am mostly a happy lurker.

I don't know why you are being downvoted, but I totally thought about that AT protocol first.

Apparently, the OP refers to <https://atproto.com/> per the FAQ at <https://docs.rocksky.app/faq-918661m0#what-is-the-at-protoco...>

On Github, there is a way to leave individual comments in the code and in addition give a review a summary.

In addition to hitting the "approve" button, I typically spell it out explicitly in this summary: "Please check my comments and see if anything makes sense to implement."

Often, I also take this opportunity to point out the "one" most valuable change in my opinion.

If the developer of the code doesn't find any of the comments to be applicable/usefuly, they can always go ahead and merge it right away.

Where I work I can and am still allowed to push to mainline directly, as are all other developers on the team.

Some new colleagues started with PRs and since then it has been a slow move towards using PRs more and more (but still not mandatory).

As of now some colleagues don't typically do PRs and push directly (minority), some decide on a case-by-case basis (I am among those, among a small majority in our team) and some have been using PRs for each and every change from day one (also a minority).

The criticisms by the opponents of PRs are as follows:

1. People relying on PRs too much causes them to propose code which is not production quality as of the PR whereas before (i.e. "no PRs") if your code was not correct, you or someone else either noticed shortly after (checking the tests on CI etc.) or it would make it into the release. I don't believe this to be generally true but sometimes thought similar when reading some PRs. The frequency of large bugs being found by code review in the PR has gone down in recent times which leads me to believe that the colleagues have adjusted their development style to come up with good quality solutions in the first attempt already in most cases.

2. Code review is hard to do in many cases. In our team this is typically resolved by going over a PR together for the “hard cases” (e.g. in a videoconference).

I think PRs are mostly worth the effort because any bug that can be avoided before the release saves a lot of downstream effort (e.g. support) and the effect of building a shared knowledge about the code page is valuable (although hard to quantify).

`set -o vi` is quickly typed in anger...

Another way to make XML awesome (especially for config files and the like) is to completely avoid CDATA i.e. no <config><key>value</key><key2>value2</key2></config> but rather: <config key="value" key2="value2"/> -- simple constructions can then do with just a root element. Of course this pattern only pays off if you need the XML parser for other parts of the application, too...

I liked the content of the article enough to read it to the end, but I did have a hard time due to inflation with LLM-isms. Then again I am not a native so how would I know if this is good English? I can only tell that to me, it is hard to read despite interesting content.

After some search for programming languages which promise to reduce the number of bugs, I decided to give Ada (2012) a try.

I like it better than C and C++ and the compiler is included in Debian in a reasonably recent version that it can compile the code that I need.

Ada is particularly nice for programming RPI 2040 microcontrollers because for my needs I didn't need additional libraries. For both of my RPI 2040 projects (one of which is online here: https://masysma.net/37/dcf77_vfd_raspi_clock.xhtml), my code had fewer bugs than I had anticipated.

For general purpose systems programming the lack of free software libraries is still a concern e.g. while working on a custom backup restore program I had to write my own LZ4 extractor and Blake3 hash function implementation because there wasn't any existing libraries that I could find for the purpose.

> - Since maintainers do owe basic human politeness, and they know people will be interacting with them, maintainers do owe this culture some form of communication of their intentions. If they don't want to take any changes, put that in CONTRIBUTING and turn off GH PRs. If they want to take changes, but no AI changes, put that in CONTRIBUTING. If they don't want to do support, turn off GH Issues. If they require a specific 10-point series of steps before they look at a PR or Issue, put that in CONTRIBUTING. It's on the user to read this document and follow it - but it's on you to create it, so they know how to interface with you.

In general it is already in the license. Even permissive licenses like Expat have (in ALL CAPS no less)

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO [...]

There is zero need to indicate anything about CONTRIBUTING whatsoever because already it is clear that the developer already indicates that nothing can be taken for granted.

Of course it helps to be open about expectations.

I for instance don't put CONTRIBUTING instructions online but so far all of my stuff gets so little attention that I have received almost no feedback about my free software at all.

To me, this is perfectly OK and in line with the expectation that I for instance put my code online mostly for my own benefit. If it helps anyone else, all the better. But don't derive any more expectations from it because it's free...?

My exposure and usage of “AI” has been very limited so far. Hence that is what I am and have been doing all the time: Read the text mostly irrespective of origin.

I do note that recently, I wonder what was the point the author wanted to make more often only to then note that there are a lot of what seems to be the agreed on standard telltale signs of excessive AI usage.

Effectively there was a lot of spam before already hence in general I don't mind so much. It is interesting to see, though, that the “new spam” often gets some traction and interesting comments on HN which used to not be the case.

It also means that behind the spam layer there is possibly some interesting info the writer wanted to share and for that purpose, I imagine I'd prefer to read the unpolished/prompt input variant over the outcome. So far, I haven't seen any posts where both versions were shared to test whether this would indeed be any better, though.

This is a powerful technique that has helped me a lot in the past as well, especially for those projects where I rarely progressed on (mostly private stuff, the work topics are more streamlined).

Nowdays in my private projects I often use a combination of the git commit messages and comments left in the code to indicate where to continue. Of course, this is not useful for work, either.

For work I like to use the ticket system and a separate text file and a paper notebook each to a slightly different effect.

The text file is the log what was done and is done per day grouped by ticket, typically ~10 lines for a day. The notebook contains meeting notes, design thoughts, general notes etc. and is very verbose (often six or mor pages per day, A4 paper) but sometimes helps to identify how/why/when a given decision was taken. The ticket contains what might also benefit others such as technical insights, meeting summaries (derived and summarized after the meeting from the paper notebook), summaries of important (design or product) decisions etc.

UNIX provides the Makefile as go-to tool if a simple pipeline is not enough. GNUmake makes this even more powerful by being able to generate rules on-the-fly.

If the tool of interest works with files (like the UNIX tools do) it fits very well.

If the tool doesn't work with single files I have had some success in using Makefiles for generic processing tasks by creating a marker file that a given task was complete as part of the target.

I wonder if this is due to Linux being harder to work on or because it is possible to fix some errors which would be catastrophic on other OSes?

Back when I used Windows a lot (Windwos XP times...) I also had the "long, scarring evening of frustation" rather often. It was usually solved by a reinstall.

In recent times, the “standard” seems to be smartphones (I use Android). The logic of smartphones it: It works or it dosen't and if it doesn't there is nothing you can do about it. Like ... not supporting some docking station because its network interface is called usb0 rather than eth0 ... no bypass, no solution, buy another docking station.

Of course this is faster than debugging the issue and maybe fixing it for good or maybe waste the evening on it.

Effectively Linux giving you the option to do something about errors doesn't mean the workarounds from other OSes like “reinstall”, “buy a new one”, “use a friend's system because it doesn't work here” are still readily available?

Reminds me of https://xkcd.com/293/

https://masysma.net - my site doesn't fulfil the “well received in past HN discussions” requirement, though.

I don't think anybody needs all of the features at once but people have different preferences. E.g. I typically do well without bold formatting (I only need one level of emphasis which is served well by italic) but I want tables, links and lists very often.

Also I like the WYSIWYG feature of Markdown where it has an advantage over the traditional Markup languages like HTML, LaTeX, groff etc. of being easier to read in the text file. Dedicated syntax highlighting can go a long way to make markup easier to read, though.

I don't think that is sufficient for the general case because I would like to be able to use the markdown like _emphasis_ or [hyperlinks](https://www.example.com) even inside the table rows and this doesn't render properly when using fixed pitch “tables as source code blocks”

The original Markdown has fewer features than listed for the more advanced formats in the table. Hence if someone uses reStructuredText it is more precise than just saying “Markdown” because Markown could refer to anything from the original minimalist featureset to the vastly extended format supported by pandoc if given the appropriate CLI arguments.

Some text-based formats have more options for tables e.g. alignment of columns (it may help with numbers to right-align them) or multirow/multicolumn options. Some formats support definition lists (corresponds to <dl> in HTML) - a feature which I often find valuable but was not included in the original Markdown IIRC.

One advantage of using a text-based format is that it can be exported to either LaTeX or HTML and Markdown seems to prefer the HTML output by explicitly supporting inline HTML as an escape hatch for more complex constructs (e.g. tables with rowspan/colspan). In addition to often not being supported for a non-HTML export-type it also hurts the WYSIWYG experience when reading the file like plain text.

> precise time syncing with PTP: https://www.youtube.com/watch?v=dOt-zRIG5co

I am not so much into videos but due to some extended interest in the matter I decided to watch the recording of that talk and I do not regret it. Much recommended to everyone who is interested in the state of the art of precision time synchronization over network. Also, in my opinion this talk is presented masterfully with most of the time actually spent on a convincing live demo.

https://media.ccc.de/v/39c3-excuse-me-what-precise-time-is-i...

Fun to think of it but I think my website actually got removed from that list because it has a logo on top of each page. It is available as “text only” (although not text/plain but text/markdown) by substituting the .xhtml with .md in the URL unlike some other pages on the textonly.website list, though :)

I do it and it works.

The only thing you might be missing: I don't think it helps many people really.

I personally still like the feature because I put my website under a free software license and then it is only fitting that you could view the actual source code. Having the `.md` next to the `.xhtml` available helps to achieve this.

I don't know of any list, but I know at least of the following “clubs” pages:

size-related

- <https://14kbclub.com/> - only learned about it today but I am not sure if my site would qualify (it is only ~12 KiB, but does multiple requests...)

- <https://250kb.club/>

- <https://512kb.club> - my site got removed as “ulta minimal” :(

- <https://1mb.club/>

not specifically size-related

- <https://no-js.club/members/>

- <https://xhtml.club/>

- <https://textonly.website/> - my site got removed (I guess because it has a logo and this makes it not text-only...)

There used to be also a 10 KB club and per its rules my site would have qualified except for the requirement to be featured on HN or otherwise be a “noteworthy site” if I recall correctly. However, 10KB club seems to be offline for some time already...

In general the issue with these kinds of pages is mostly that they only check _one_ page (typically the homepage but sometimes I see people submit a special “reduced version” of their homepage, too...). Of course if _all_ pages were to be relevant I think even my (pretty miminmalist) page wouldn't qualify because some pages have high-resolution images I guess...

The signature function of the German ID card (“neuer Personalausweis”).

Its 2025 and we still haven't solved secure online identification and we are still not using end-to-end encryption for e-mail, most e-mail is not even signed.

Interaction with state agencies is still mostly via paper-based mail. The only successfully deployed online offer of the german state administration seems to be the online portal for tax filings “elster.de”.

The use of a private key on the national ID card would have been able to provide all this and more using standard protocols.

At least for identification, there is an expensive effort to re-design something similar in a smartphone-centric way and with less security and not based on standard approaches called “EUDI wallets”.

For encrypted communication the agreed-on standard seems to be “log in to our portal with HTTPS and use our proprietary interfaces to send and receive messages”...

Why did it die: Too expensive (~30€/year for certificate, >100€ for reader one time) and too complicated to use. Not enough positve PR. Acceptance at state-provided sites was added too late. In modern times, everything must be done with the smartphone, handling of physical cards is considered backwards hence this is probably not going to come back...

Edit: Anothther simiarly advanced technoloy that also seems to have been replaced by inferiror substitute smartphone: HBCI banking (a standard...) using your actual bank card + reader device to authenticate transactions... replaced by proprietary app on proprietary smartphone OS...

I have a few old PCs (towers) here which don't support amd64 mostly Pentium 4-based.

They all still have DVD reader drives and are nice for ripping CDs. Despite the fact that the drives are nearing 20 years of age (machines are from ~2005) they still perform better than most “new” external drives. Of course one could also move the drives to a newer machine but many of them use the IDE connector which is not commonly found on modern systems. Also, modern cases typically don't account for (multiple) 5.25" drives.

The other use case is to flash microcontrollers. When fiddeling around with electronics there is always a risk of a short circuit or other error that could in worst case kill the attached PC's mainboard. I feel much safer attaching my self-built electronics to an old machine than to my amd64 workstation.

Due to their age, I think the old machines may not live much longer -- I fear not even 10 more years, some of my old 32-bit laptops have already failed. Hence even for me it does not make sense to try keeping up the software support. Maybe I switch them to a BSD or other Linux distribution if they live long enough but for now the machines run OK with Debian Bookworm (newly oldstable), too.