foresto

Rather than indulging the inevitable argument that most users never read log messages, I hope we can remember a more important fact:

Some users do read log messages, just as some users file useful bug reports. Even when they are a tiny minority, I find their discoveries valuable. They give me a view into problems that my software faces out there in the wilds of real-world use. My log messages enable those discoveries, and have led to improvements not only in my own code, but also in other people's projects that affect mine.

This is part of why I include a logging system and (hopefully) understandable messages in my software. Even standalone tools and GUI applications.

(And since I am among the minority who read log messages, I appreciate good ones in software made by other people. Especially when they allow me to solve a problem immediately, on my own, rather than waiting days or weeks get the developer's attention.)

> Deterministic randomization is a thing if you don't want the numbers to count sequentially.

What are your favorite ways to approach this?

I think a maximal period linear feedback shift register might fit well.

What stuff do you have in mind?

I was disappointed by Go's poor support for human-focused logging. The log module is so basic that one might as well just use Printf. The slog module technically offers a line-based handler, but getting a traditional format out of it is painful at best, it lacks features that are common elsewhere, and it's somehow significantly slower than the json handler. I can only guess that it was added as an afterthought, by someone who doesn't normally do that kind of logging.

To be fair, I suppose this might make sense if Go is intended only for enterprisey environments. I often do projects outside of those environments, though, so I ended up spending a lot of time on a side quest to build what I expected to be built-in.

I haven't explored enough of the stdlib yet to know what else that I might expect is not there. If you have a wish list, would you care to share it?

Thanks for the tip. Unfortunately, it doesn't seem to be the cause of my one-way serial port issue. Adding the udev environment variable makes no difference, nor does stopping the ModemManager service.

> it turned out some kind of modem manager service was messing with the port, and needed to be disabled.

Curious. What service was that?

I have an on-board serial port that's only working in one direction, which is something I've never encountered before. I wonder if the service you're referring to could be causing my problem.

You can map known-bad memory regions to avoid using them.

https://www.memtest86.com/blacklist-ram-badram-badmemorylist...

Why even consider hand-written SVG when drawing tools like Inkscape exist?

Sure, there are occasions to write markup from scratch, but vanishingly few in my experience.

If I'm contacting a company for help from a human, it's because I haven't found the solution in the manual, the out of box experience, tutorial documents, FAQ pages, and so on and so forth. More often than not, I'm calling to do the company the favor of reporting an unaddressed failure mode in their service, often with technical details that would help them quickly identify and fix the cause (and reduce their support call volume)... if only that information could be delivered to the right people.

I don't have infinite time or patience, though. When blocked by a moat of hold times, chat bots, first level support scripts, etc, I will give up.

Yes, calls like mine are in the minority. But they are especially valuable, and I think well worth their share of the costs you describe.

Maybe companies should be identifying customers with above average tech skills, and routing them to better support channels next time they call.

Maybe we need shibboleet.

I don't know what the best solution is, but there must be a better way to do triage than funneling everyone into a flowchart of counterproductive misery, as is widespread today.

For those who don't know how to properly get the active terminal's color escape codes...

green=$(tput setaf 2)

normal=$(tput sgr0)

echo ${green}Color${normal} text.

...or if you plan to run on non-POSIX systems that lack tput...

green=$(tput setaf 2 2>/dev/null || true)

I have read that people still use 9term. Its terminfo entry doesn't show any sign of ANSI escape code support.

If I remember correctly, ANSI-like terminal emulators in RGB mode (aka direct mode) only support 16-color and red/green/blue escape codes. Not the 256-color palette used in this article.

ANSI-compatible terminal emulators widely disagree on whether RGB values should be separated by semicolons or colons.

I have read articles (possibly on hackaday) this decade by people working on retro hardware projects, expressing frustration with command line programs that spew ANSI garbage to their non-ANSI terminals. At least one author resorted to the screen program, because it can translate some ANSI-isms to the correct codes for the active terminal.

I had genuine TeleVideo 912 glass terminals hooked up until not terribly long ago.

In any case, I don't view this as a matter of whether unusual terminals are "notable". We have an abstraction that plays nicely with them (and allows new terminal protocols to be developed). It's a POSIX standard. It's easy to use. I suggest using it.

(I'll put examples in a separate comment.)

> A happy home: I love having both plants and homemade projects in my living space.

This reminds me of various programs I've made to improve the quality of my digital life. Humble little things that I didn't want to build, addressing minor problems that could be mostly solved by other means, but nevertheless appeared on my mental wish list often enough that I eventually dedicated some time to creating them.

These tools do exactly what I need, all day, every day, quietly making things more pleasant than they would be otherwise. With them, I feel at home.

> Mumble should work a bit on that.

Mumble is a labor of love, not a commercial product. I expect they would appreciate your help.

Mumble is fantastic for voice chat. Its text features are very basic, though, so people fleeing Discord would probably want something additional to handle that. Maybe Matrix.

> Are you really a hobbyist if you aren't desoldering and reclaiming parts?

Fun memory from who-knows-how-many years ago:

While installing a Playstation mod chip, I accidentally dislodged a nearby surface mount resistor, pulling off one of its metal contacts in the process. (Is that what happens when you overheat them?) I didn't think that was fixable, and since it was Sunday, the local electronics shop was closed. I ended up disassembling an old junk digital camera that hadn't yet been taken to the e-waste recycling drop, and finding inside it a resistor that seemed close enough to maybe work. The transplant was a success, and the Playstation ran great thereafter. Very satisfying.

(And my point regarding support on Google/Facebook was that their users could chat with me over XMPP without having to leave their familiar sites, sign up for anything new, or do anything else special. That put it in easy reach of the masses.)

Fair enough. (Although all the XMPP clients that I used supported multiple accounts, so it made little difference from where I was standing.)

In any case, it contributed significantly to XMPP's reach and utility, and it's gone now.

Google Talk support for XMPP: 2005-2013

Facebook Messenger support for XMPP: 2010-2015

Jabber.org support for new accounts: 1999-2013

First-class integration with two of the world's largest social networks put XMPP in practically everyone's hands for a time, but when all the major hosts left, network discoverability and typical account longevity dropped drastically. The landscape is bleak today.

And since then, our collective needs and expectations of a chat platform have expanded. XEPs have been developed to bolt much of that functionality onto the base protocol, but that has led to a fragmentation problem on top of the bleak server landscape.

This unfortunate situation might be navigable by a typical HN user, and perhaps we could guide a few friends and family members and promise to keep a server running for them, but I think the chances of most people succeeding with it are pretty slim today.

I haven't used Signal desktop, but I find Electron apps in general to be very wasteful of system resources. Out of curiosity, I once compared an Electron-based chat app to a C++ alternative, and found that the former used about 25 times the RAM and generated more CPU load.

If GP's system resources are usually dedicated to other tasks, perhaps trying to run an Electron app on top of those led to resource contention, and poor performance. You wouldn't notice this if your hardware is overprovisioned for the things you do with it.

(Tangential to your comment but apropos of the Discord news...)

Have any of the Matrix/Element teams seriously considered taking advantage of current events by offering a gamer-focused class of premium account, for Discord refugees who want to redirect their Nitro budgets to fund Matrix gaming features? (Perhaps on a separate homeserver, to avoid the lag during times when matrix.org is overloaded.)

If it were positioned as Patreon-style crowdfunding rather than selling a finished product, and expectations were set appropriately, I wonder if it could end up a nontrivial source of income with which to develop features that Matrix deserves but corporate/government customers won't pay for.

Yes, you could.

Whether or not authorities with jurisdiction over you would notice your instance (homeserver) or bother you about age verification is an issue you'd have to consider for yourself.

Reminds me of a comment from a previous time this story was posted here:

https://news.ycombinator.com/item?id=41509748

Thanks for sharing. I think the design of MatrixRTC (especially the scaling via hierarchical SFUs) looks promising. It's nice to see someone actually using it at this early stage, even if only for 1:1 calls.

Matrix screen sharing is a feature of Element Call / MatrixRTC (in development).

For now, I think they do it through their Jitsi integration. I don't know how easy it is, as I haven't tried it.

https://docs.element.io/latest/element-cloud-documentation/i...

Can you be more specific about your criticisms? I have gripes about Matrix, but your assessment doesn't match my experience.

This is incorrect. POP3 does not require fetched messages to be deleted from the server.

> I was able to replicate that protection mechanism just by scratching a diskette with a pin.

How did you figure out where to scratch it? Was the laser mark visible on the original disk, or did you have to read the code and orient based on the diskette's index hole?

Also: https://micropython.org/

Do any audio filters/plugins exist that are effective at disguising a voice in real time, such that it would be difficult to identify the speaker / match against samples of their unfiltered voice?

(Pitch shifting is easy and widely available, but also trivial to reverse, so it's not good enough.)

I'm mainly interested for anonymity in online gaming, but I could see it also being a helpful privacy measure in other situations.

Here are a few examples of problems systemd has caused me:

System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted.

Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope --property=Delegate=yes <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable.

At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back.

There are more examples, but I'm tired of re-living them and don't really want to write a book. I hope these few are enough to convey my point:

Systemd has been a net negative in my experience. It has made my life markedly worse, without bringing anything I needed. Based on conversations, comments, and bug reports I've seen over the years, I get the impression that many others have had a similar experience, but don't bother speaking up about it any more, because they're tired of being dismissed, ignored, or shouted down, just as I am.

I would welcome a reliable, minimal, non-invasive, dependency-based init. Systemd is not it.