HN user

catherinecodes

72 karma
Posts2
Comments34
View on HN
Tcl 9.0 2 years ago

Absolutely. It's even been remarkable stable--programs written 20 or 30 years ago work without any kind of modification.

Me too. Was there some regulatory change that makes spraying SMS more difficult? It'd be great to hear from someone that works there or at Vonage which sees to have suffered the same fate.

Yes, the new channel, even with the bridges in tact, is still much quieter. Here's an sample from my client logs:

$ wc -l tcl2023* | awk '{s+=$1} END {print s/NR}' 116.333

$ wc -l tcl2020* | awk '{s+=$1} END {print s/NR}' 314.556

Less than half the activity before/after according to this non-scientific analysis (my client wasn't always connected and it looks like the logfiles contain topic/names and other output).

Go 1.22 2 years ago

At work, we upgrade when there's a compelling reason (structured logging in 1.21 came close; we haven't finished migrating from our old logger yet). Before deploying that version, we typically bump versions in all our Go repos and run the tests in those repos. Having the same version across apps gives some people on our team a bit of comfort (with Go, it's not as important as some other runtimes).

Go 1.22 2 years ago

Came here to say the exact same thing. chi has been reallly great for a couple projects--in fact, it's easy to forget it's even here. Moving them into the stdlib means they'll always be maintained and ensure that approach is used in many Go programs.

This is definitely a hard problem.

One technique is to never upgrade clusters. Instead, create a new cluster, apply manifests, then point your DNS or load balancers to the new one.

That technique won't work with every kind of architecture, but it works with those that are designed with the "immutable infrastructure" approach in mind.

There's a good comment in this thread about not having your essential services like vault inside of kubernetes.

Native Americans routinely burned the landscape—to foster the growth of useful plants, to clear space for farming, and to improve the conditions for hunting. ... In addition to maintaining parklike conditions, these managed blazes prevented fuel from building up, and so staved off larger, potentially unmanageable conflagrations.

Much of the world still operates like this. Check out the Chiang Mai, Thailand burning season[1].

The US and Canada are some of the only countries where wood is the primary building material. In the rest of the world, stone is used which doesn't catch fire so easily. That might help explain the fear of fires in the US.

1: https://thaifreu.de/chiang-mai/burning-season/

The author describes the alerting and notification workflow really well.

We use IRC at work for this purpose. Prometheus alerts flow into channels that anyone is free to join or leave depending on what they're working on at the given moment.

Same here. ZNC on Debian (apt install znc) on an Entrywan instance.

The freenode debacle impacted a handful of my favorite channels. #tcl is noticably quieter and a couple others are still trying to decide whether they're an official channel or not (this affects #channel vs ##channel naming). I'd bet that the number of active users has dropped but I don't have any emperical evidence.

If anyone is considering ZNC, here are a couple suggestions to change to the default config:

1. AllowWeb = false (only enable the web interface if you need it)

2. For each channel, add Buffer = 10000 so that you can have history for more than a day or two (the default is quite small)

3. Add these two lines:

LoadModule = chansaver LoadModule = clearbufferonmsg

to get better history tracking and avoid duplicate messages.

For example, a bundle may provide 200 minutes of calling during a 7-day period for a discounted price. To avoid losing unused minutes, we learned that as people near the end of their bundle’s time period, some use available minutes to call back unusual numbers in their incoming call-log, which they had not answered.

This probably explains the reason for the accidental social ties.

I lived in a country where mobile phone calls were expensive relative to wages. Much of the time you'd receive a call that only rang once. The caller would hang up after only a single ring. This signalled they wanted to talk to you but didn't have enough "talk time" left. If the caller was a contractor or someone on your payroll, they would almost always employ this tactic to keep their costs down.

Right. Flux was a handy little tool[1] that sync'd yaml manifests in git repos to live clusters. The concept was fascinating, and the tool was well done--small and efficient. Easy to learn.

In 2019, they announced they'd be "merging" with argocd[2]. It seems the merge never really took place, and after that they deprecated flux and announced flux2[3].

The sudden changes of course were a little confusing and perhaps not too well communicated.

1: https://github.com/fluxcd/flux 2: https://discuss.kubernetes.io/t/flux-cd-joins-forces-with-ar... 3: https://github.com/fluxcd/flux2

Absolutely! I recommend Gentoo in a separate thread below.

LFS has the topic of package management covered quite nicely I think[1]. They describe the contraints and approaches that might be possible, and what the real world solutions to those are (PRM, DEB, et al).

There have even been some package managers designed (or at least discussions of what the design would look like) for LFS explicitly over the years, but none seemed to have come to fruition, and I can't find any links to them.

1: https://www.linuxfromscratch.org/lfs/view/9.0-systemd/chapte...

Void Linux is great for minimal installs. Gentoo fits the bill nicely too. Both allow for small init systems and, at least in the case of Gentoo, multiple bootloaders and initramfs tools.

Google’s guidelines for a good code review include: - Continuous improvement over perfection

This seems like the biggest win of all. All too often, PR reviews just focus on superficial or subjective items such as code formatting or variable naming (not that variable naming isn't important, but these discussions rarely yield any fruit).

It's not clear, though, how Google's Critique tool, specifically, facilitates that, or any of the other objectives.

I'm sure Critique is a great tool, but the article's claims about "taking the pain out of reviews" isn't very convincing.