Hope no one minds me being slightly off-topic in a relatively inactive group, but it’s the best fitting community I could find for the question.

I plan to build a directional wifi antenna using a can (aka the Pringles can antenna). I am baffled at how costly the connectors are. Why are the prices so high for a connector? Cantenna instructions always say to use an N-type connector. Is that really necessary? Coax cable connectors are a dime a dozen. Would those work?

Or what if I just strip the end of the coax cable to the right length and find a way to skip the connector and secure it to the can.. will that work?

Otherwise it’s ~$12 for the panel mount N connector + $10 for the connector that mates to it + $10 for the RP-SMA connector that attaches to the wi-fi AP. So over $30 for a home built wi-fi antenna. Fuck that.

Fujitsu abandoned their Celvin NAS customers. The proprietary software is over 10 years old. And worse, Fujitsu had an app store to get apps that were not part of the stock stock distro, like a bittorrent app, which are no longer reachable.

The hardware uses a Marvell arm SOC. FreeNAS is x86 only. QNAP has some fairly recent distros that may be compatible. It’s proprietary and perhaps somewhat risky. What are the chances that a QNAP image from 2024 bricks my Fujitsu from 2013?

Is QNAP my only option, or is there a FOSS option? There are at least 15 FOSS NAS platforms:

https://techcult.com/best-free-and-open-source-nas-software/

but I have no idea if any are built for a Marvell arm SOC. Anyone know?

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.