The linked account is very busy.. almost 10,000 repos. Whoever the asshole is behind that attack, it’s the reason the public has lost the ability to create a new account on nixnet.

This matters in particular because Nixnet is the only gitea/forgejo host that has both a clearnet and onion host -- apart from disroot, but disroot’s onion is dysfunctional.

Note that the XMPP support channel is shut down because that was attacked as well.

The stock lemmy web client has had this annoying shitty bug as long as I remember. Not sure how or why ppl have tolerated it for so long.

I started this thread:

https://lemmy.sdf.org/post/52956979

Then I wanted to cross-post to !IRC@lemmy.cafe. The first defect is that it’s impossible to enter the full address of the target forum. Lemmy forces us to enter only part of the name and choose from a pull-down list. Then from there it’s not even smart enough to prioritise the user’s subscribed forums to the top. So entering “IRC” gives a long list of circle jerking forums, while the more simple match !IRC@lemmy.cafe is pushed off the list.

cross-posted from: https://lemmy.sdf.org/post/52956979

It looks like the most common method to use irssi over tor is to use a transparent proxy to tamper with network libraries, like torsocks or using proxychains4. Those approaches are useless when you also use Irssi with #Bitlbee, because bitlbee runs a local agent obviously becomes unreachable with torsocks in the loop.

So I must use a more complex approach:

$ socat -T9999999 -s TCP4-LISTEN:13999,ignoreeof SOCKS4A:127.0.0.1:libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion:6697,socksport=9050,ignoreeof &
$ socat_pid_libera=$!
$ irssi
$ kill ${socat_pid_libera}

Then irssi is configured to point the libera network to 127.0.0.1:13999.

That’s the idea. There is a separate socat process for every IRC host I might reach, which is about a dozen in my case. Apart from ugly tediousness, it works for like 30 min on avg then dies. I believe that’s the nature of Tor. Circuits die and get replaced, and when that happens socat is left with a dead connection for some reason.

Is there a remedy? I there a way to make socat resilient to tor volatility?

When a daylight savings change occured recently, all my DAB radios failed to update. An alarm clock would have been off by 1 hour. This is apparently because DAB radios only listen to the time signals that come from radio signals they are tuned into, thus only when playing.

All my humidistats and thermometers all had the correct time because they are always listening to time broadcasts.

My smartphones and PCs always have sufficiently correct time despite being offline because they have a locality configuration which implies when daylight savings is expected.

I think all my household DAB radios have alarm functionality, so it’s perhaps a widespread bug. Shouldn’t the radio software be able to detect the locality from the radio signals, and then use that to schedule time changes? Or short of that, it should be able to silently listen to a DAB signal from 1am to 1:15 am to set the clock from the signal.

Imagine as well that when the alarm triggers and DAB plays, the clock is then updated. So you get alarmed at the wrong time but imagine the confusion when the clock gets corrected before you look at it.

I also wonder what a disaster it must be when a DAB signal becomes too weak to make sound. Then what? Does the alarm clock try to wake us up with silence? Is this another case where FM is superior, or are any DAB radios smart enough to switch to a preprogrammed sound when there is no DAB signal?

It looks like the most common method to use irssi over tor is to use a transparent proxy to tamper with network libraries, like torsocks or using proxychains4. Those approaches are useless when you also use Irssi with #Bitlbee, because bitlbee runs a local agent obviously becomes unreachable with torsocks in the loop.

So I must use a more complex approach:

$ socat -T9999999 -s TCP4-LISTEN:13999,ignoreeof SOCKS4A:127.0.0.1:libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion:6697,socksport=9050,ignoreeof &
$ socat_pid_libera=$!
$ irssi
$ kill ${socat_pid_libera}

Then irssi is configured to point the libera network to 127.0.0.1:13999.

That’s the idea. There is a separate socat process for every IRC host I might reach, which is about a dozen in my case. Apart from ugly tediousness, it works for like 30 min on avg then dies. I believe that’s the nature of Tor. Circuits die and get replaced, and when that happens socat is left with a dead connection for some reason.

Is there a remedy? I there a way to make socat resilient to tor volatility?

The link goes to my findings, which are simply a count of CTAN listings.

I would like to find a good forge to host a latex package. Not Github. Fuck Microsoft.

CTAN.org shows the repo for each of the packages known to CTAN, but I am struggling to get a list of repos. It seems we can only see one repo at a time by visiting each package individually. There is no public dataset, correct?

It would be useful to see which forge is the most popular (after nixing github).. or whether there is a gitea forge that is TeX-focused.

There is an API to make it easy enough to harvest the CTAN DB → https://ctan.org/help/json

I bought a 2nd-hand Lenovo USB-C PSU (ADLX65YLC3D) which indicates a range of voltages (20v, 15v, 9v, 5v) on the label. Tried to charge a few different bicycle lights but the charging indicators did not light up on any of them. I almost tossed it because the 2nd-hand market I bought from is definately dodgy. But then I tried to power a Rasberry Pi and it seems to work on that. So wtf? An a/c adapter either works or it doesn’t. What would cause this: works on some devices but not others? The Rasberry Pi needs 5v just as the bicycle lights. That is the default voltage for USB-c.

I bought a 2nd-hand (but new-in-box) Kenwood radio that requires USB-C @ 9 volt 1.5A. It did not come with the original charger, so I bought a separate universal USB-C charger (145 watt, full range of voltages incl. 9v 3A). The charger is not Kenwood, but it should work, no? Because we have standards, right?

I plugged it in and LCD was dead for like the first 45min. Then it started to show the 3-stage charging indicator. The device would never power on. I assumed it had to be well charged, but then saw in the manual that it’s expected to function while it charges. It never got fully charged and the display eventually simply went off.

Day 2:

I plugged it in again and it was again dead for like 30 min before it started charging for hours. LCD went off again. Never made charging progress and never powered on.

Day 3:

I plugged it in and the LCD was off, as usual. But this time it stayed off. It no longer shows a charging indicator even when plugged in overnight. I wonder if the charger killed the radio (or the internal battery).

I went to a retail shop that has the same model radio on display. The display model had no juice but I plugged it in and it instantly indicated it was charging and also instantly powered on. Then I noticed the stock factory PSU is strictly 9v. WTF?

Is that compliant? USB PD chargers are supposed to default to 5v until the device asks for more. There is a handshake process, per the spec.

So WTF is Kenwood doing making a USB-C PSU that is strictly 9v? Did they actually just hardwire a 9v PSU to USB-C connector and build a device that skips the USB PD handshake?

The manual says: only use the Kenwood PSU that is made for the device. When I read that shit, I thought: yeah yeah, the usual liability bullshit. They want us to be loyal and only use their products. But now I wonder if they did something seriously obscure to where it’s in fact true that only their 9v PSU will work -- and yet it does not seem to be sold separately.

I brought the dodgy radio into the store and plugged it into the Kenwood OEM PSU. It’s still dead, which I suppose is concrete proof that the radio is toast.

I love DAB but it has problems:

1. DAB tuning is slow. The receiver must collect data and spend 3+ seconds decoding before sound is output. Flipping through channels is annoying as opposed to FM. FM plays instantly.
2. Multiple DAB radios simultaneously tuned to the same station results in unsychronized output. So forget about having radios in different rooms tuned to the same signal as you walk around the house (cleaning, throwing parties, etc). Also means a group of cyclists cannot simultaneously tune the same DAB station. FM is immune to this problem.
3. Many stations share a single transmitter. When a signal goes bad for one station (e.g. bad weather), it’s also bad on ~20—30% of all other DAB stations. Many eggs in one basket.
4. Weak DAB signals are intolerable. The sound cuts off and on repeatedly oscillating between silence and sound (as opposed to analog where there is a relatively steady amount of static that is often tolerable). E.g. In Brussels Bruzz on FM is decent but Bruzz on DAB rarely works. Some people report getting terrible DAB reception indoors.
5. Vulnerable to Internet down time & cyber attacks, I suspect, because the DAB transmission tower likely sources its signals from the cloud.
6. All receivers vulnerable to EMF pulses (thus solar events, nuclear war, and artificially generated EMF). No digital radios use vacuum tubes. Importance of functioning radio is greatly heightened in these scenarios.
7. Most DAB radios do not feature manual tuning. And auto-tuning is unreliable. My current frustration is knowing that a good BBC4 signal reaches Brussels but none of my radios tune it. A Brussels retailer’s demo shelf had a DAB radio playing BBC4, but after auto-tuning the channel was lost.
8. DAB probably does not work well in mountainous areas -- unlike AM, which will likely be ditched with FM.
9. Reduced range regional applications possibly complicated or non-viable. E.g. some airports transmit their announcements about flight delays/cancellations over a limited range AM radio which only tunes as you approach the airport.

When stations have both FM and DAB transmissions, you can quickly channel surf on FM. When something good is heard, you can then switch to the DAB version. Newer cars with DAB+ devices automatically switch between DAB and FM variations of the same station. They will lose this advantage when FM is gone.

FM can also seek in realtime. That is, it quickly finds the next strong signal at a given moment. With DAB, you apparently must run a scanning procedure in advance and that takes time. Then those stations are stored but signal quality can change from one hour to the next. Or if DAB can seek for the next station in realtime, I’ve not seen that on any of my radios. In DAB mode, the seek functions are gone.

I have never seen an Attorney General take action on a consumer complaint. The best outcome I’ve seen is they make the complaint public record, then do nothing. Other AGs reply to say “not a violation of deceptive trade practices”. And some AGs do not respond at all - they just ignore complaints.

The FTC and CFPB are also options but those are also often deadbeat agencies particularly under republican governance.

What’s the recourse? Who generally oversees a state’s AG?