Marcus Müller

https://mastodon.social/@funkylab

Public Key

npub1ergwyxh54mpk33mepkpaqmwzthzmwrysez673grmdfsqdqdsw4gqdagjez

NIP-05 Address

funkylab_at_mastodon.social@momostr.pink

Profile Code

nprofile1qqsv358zrt62asmgcausmq7sdhp9m3dhpjgv3d0g5pak5cqxsxc825qprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmnt8xrhqe

Publishing to

relay.momostr.pink

Author Public Key

npub1ergwyxh54mpk33mepkpaqmwzthzmwrysez673grmdfsqdqdsw4gqdagjez

Show more details

Last Notes

2026-02-20 14:44:50 UTC

- reply

can fully see how this is a problem esp. for Icelandic, but certainly not for French (probably ~ third or fourth most-written indogermanic language in available literature sets)!

2026-02-20 14:35:26 UTC

- reply

That's what I'd argue, too, but: this very basic theory and reality, especially of really available implementations, might diverge there.
Thing is that @npub1hr7…jxyc is actually someone from the field, so his word does way heavy to me, even if it doesn't reflect my own experience with translation quality.

2026-02-20 14:02:35 UTC

- reply

days, wonder how it does these days. I imagine that's the technology you've got in mind when you think of non-LLM translation?)

2026-02-20 14:01:45 UTC

- reply

Color me really surprised; paragon and derivatives (at least for German) were definitely worse; I remember the (2008-ish?) surprise when ANN-based translations started to achieve higher rankings than purely Bayes-based/statistical methods.
(Oh and I do personally remember things like the Babylon spyware thing, which wasn't really good. IBM Watson didn't work as well as Google translate when that came out, for German<->English at least. I had played with Aperium in its earlier …

2026-02-20 13:46:05 UTC

- reply

(I'd argue that's probably the thing their design lends itself to rather well – analyzing which tokens in which context. Certainly will never reach human translator qualities, but saying "machine translation was good before", um, no, it really really wasn't.)

2026-02-20 13:44:54 UTC

- reply

no offense, but LLMs are really really good at translations, compared to the state of the art before. (and e.g. Google Translate was a lot more LLM-style AI for years than people think)

2026-02-07 07:59:50 UTC

- reply

yes, as explained; sorry getting tired of re-explaining, see other thread

2026-02-06 21:40:29 UTC

- reply

I honestly find the opposite to be the case - HDDs can expose mechanical degradations (air barriers, motor bearings) that tend to work against you when you leave them unpowered. But this isn't about HDDs; it's about the myth that powering on an SSD will help data retention.

2026-02-06 21:12:16 UTC

- reply

Ray, I'm sorry, but do you actually understand how flash memory works? powering on the SSD does exactly *nothing* to the cells until you at least read them (in which case you get a slight read wear on the cell and its neighbors), and you won't increase the charge levels inside a cell unless you erase and rewrite it, which does more damage, so the speed of charge leaking is higher than if you've just let the data alone.
(I mean, you're an EE – so model your gate capacitor!

2026-02-06 20:18:32 UTC

- reply

that is a very poor-quality source; modern SSDs indeed hold data for years, and powering them also doesn't increase data retention; they're not in any technical sense related to static (which needs constant power, very little) or dynamic RAM (which needs refresh cycles every few milliseconds).
You can be pretty certain that a not end-of-write-life SSD will retain data for years to decades. If you care, some SSDs actually specify more than just a overall MTBF (often in the 10⁶ h)

2026-01-03 19:26:10 UTC

- reply

BTW, if people are interested a bit more in the tech side of the argument the EFF/ALA could make back then in the face of the Brodcast Protection Discussion Group, I can recommend @npub1p8f…tcuc 's talk at 2025's GRCon
https://www.youtube.com/watch?v=KL8I7OGWhMM&t=390s ¹
and maybe this little text on the cultural significance of access to the radio spectrum that I wrote https://www.baseband.digital/foreword.html
¹sorry, we haven't cut and uploaded the videos individually yet, so we only got the whole-stream recording on YT
https://files.mastodon.social/media_attachments/files/115/832/807/035/835/974/original/a50616118ec36446.png

2025-10-29 00:14:45 UTC

- reply

that is truly utter nonsense; I think you're just trolling at this point

2025-10-29 00:11:23 UTC

- reply

no, not a major portiin of the internet, only matrix.org, which is relatively little (veryveryvery little) compared to us-east-1 going down. No, things did not still work, that's simply not true. It's nice you&your friend have HSs. Could you administrate 69,999,998 more please, for the non-techy folks, in a reliability somewhere close to that of signal or matrix.org?
I'm sorry, a pair of homeservers to enable friends to communicate: not even the same problem class

2025-10-29 00:02:40 UTC

- reply

yes, rendering the sprinkled small homeservers mostly useless, because a tiny percentage of orgs have spare admin capacity to run their own HS; also we know that many small instances choke for prolonged periods of timev reconciling large state shifts, once the large instance comes back up.
The world literally was in that situation a few weeks ago, and we're all happy how little state actually got lost.
Could we not paint that as unambigously great, please?

2025-10-28 22:25:57 UTC

- reply

Your claim is especially questionable, and I'm a bit surprised @npub1m9z…whzq is boosting this so indiscriminately, they should know better:
EMS, without doubt the largest homeserver operator, does not operate customer matrix homeservers themselves on-prem; their infra runs on AWS, which, if you asked me, is as hyperscaler as they come; try
$> dig fosdem.ems.host
and get
fosdem.ems.host. 300 IN CNAME k8s-core-coreingr-e213c56b76-ef68a8798c5364b0.elb.eu-central-1.amazonaws.com

2025-10-28 22:15:39 UTC

- reply

knowing the compute efforts flowing into keeping a-couple-thousand-user matrix homeserver afloat… not so convinced you could scale that up to 70 million active users without a couple rather large datacenter racks; federation doesn't make that problem easier, at all.
if you're not in a situation to operate globally distributed datacenters at a high level of trust in reliability, I'm somehow not convinced the racks alone do the trick.

2025-05-14 19:11:19 UTC

- reply

i mean if all it did (according the linked emulator code) was compare 9 address + 1 data bit to a constant, then basically any cheap cpld or fpga would achieve the same; would boil down to an adapter pcb

2025-03-18 16:30:37 UTC

- reply

Ach schau her, der [@bert_hubert](https://fosstodon.org/@bert_hubert ) erklärt keine 11 Tage später in viel anschaulicherer Terminologie als ich, warum "The cloud is just other people's computers!" ein schrecklicher Fehler ist, wenn man Leute von amerikanischer Cloud weg holen will. Netter Artikel!
(Dank je wel, [@bert_hubert](https://fosstodon.org/@bert_hubert ) !)

2025-03-04 19:24:23 UTC

- reply

der Sticker war 2015 noch ganz cool (ich hab den auch auf'm Laptop gehabt!), ist aber heute einfach an der Realität vorbei, weil das Angebot von AWS, Azure, GCP und co eben nicht nur der gemietete Rechner, sondern die Gesamtinfrastruktur ist, die halt mehr als nur "ich kann jetzt jemand anderem seinen Rechner nutzen, und was ich damit mache, hängt nur von meinen Fähigkeiten ab".
Sprich: guter Spruch, aber leider seit knappen 10 Jahren überholt.

2025-01-19 17:43:17 UTC

- reply

… languages work (as in, comparison operators in JS and PHP, it rears its head in more modern (REST and similar) distributed APIs, where omitted fields are tacitly assumed and quickly become compatibility problems when one realizes a field's implicit behaviour needs to change, and of course, the idea that writing something is better rather than saying "sorry, I can't (even)" in the face of uncertainty is what underpins the whole LLM financial hype.

2025-01-19 17:40:04 UTC

- reply

I know that feeling. I think "do the thing the user *probably* wanted is in case of error" comes into fashion periodically (specifically, everytime a field discovers a new way of specifying APIs), and afterwards everybody curses and uses the `xyz_fail_if_you_would_need_to_guess` variant of functions. It's certainly present in the earlier code in various libcs (no shame on the developers there! They needed to write *useful* software), it's very much present in how early web-era…

2025-01-17 19:17:11 UTC

- reply

it's pretty awesome to document something as "in most cases, we parse, but don't actually use the following fields", without specifying in which cases that'd be the case.
So, only way I could see that: parse as you're doing, minus the ` %Z`, then use its retval with `sscanf` to get the time zone string, then use that copy that to the `TZ` environment variable, then call `tzset()`, then get the seconds west of UTC from `long timezone`, then set fire to everything&move to woods.

2024-12-22 12:13:16 UTC

- reply

I think there's a sizable allocation at 3.4 GHz, isn't there?
6 GHz is kind of a "cheap technology" barrier when it comes to low-loss boards, and when it comes to realizable isolation, so staying below is pretty natural.

2024-12-22 12:06:51 UTC

- reply

You'll need some space; for small beamwidths, the horizontal length of the antenna system is roughly the wavelength divided by the 3dB beam width, so , with a pi/90 wide beam, and a 2m carrier, you need an antenna system 180/pi m ~= 60 m long, broadside to the directions you want to beamform to. (you can use the good ole rule of thumb above, or do the math where you realize that when you put emitters on a regular distance next to each other, the DFT links the …

2024-12-22 11:47:35 UTC

- reply

yeah, being RADAR-specific would sound a lot like ITAR in practice. (Also, guess what one of the 5G/6G research hot topics is right now: joint communications and sensing (JCAS), conveniently evading terminology like the much older "OFDM Radar", though also exceeding the scope of that.)

2024-12-22 11:41:25 UTC

- reply

I'd need to check on that, but without further qualifications, that'd put a couple hundred thousand 4G/5G base stations on a list.

2024-12-22 11:34:43 UTC

- reply

an LWIR sensor only sees the surface temperature, which is a poor proxy of the 3D field you need to adjust to heat the cold internal spots.
LWIR sensors being the least of your technical challenge with "my" oven design; and actually steerable antenna arrays are ITAR in specific applications anyways. (i.e., don't take that microwave onto something that goes beyond a certain altitude.)

2024-12-22 11:28:39 UTC

- reply

considering microwave ovens came from radar microwave tubes back when these were military controlled equipment, I'm afraid it wouldn't be the first to be export controlled, but since they predate ITAR, that might work.
But yeah, having a steerable beam (or rather, controllable resonance pattern) would be pretty neat. It'd need quite a few RX antennas on the inner surface of the oven cavity to sample the state of the standing wave inside, and then substantial compute to …

2024-12-21 14:44:30 UTC

- reply

files this short don't even benefit super much from dictionary compression schemes, so, my guess is that this is straight 4, 6 or 8 bit µ-Law PCM. I'd start by figuring out DAC sample rate (record audio, look for spectral repetitions = harmonics at multiples at the sample rate; this thing will have anything but nice reconstruction filters), use that to divide file lengths by number of samples to get bits per sample. If that happens to be darn near to an integer, yeah, no…

2024-12-21 14:38:34 UTC

- reply

flac would be an extremely unlikely choice for a low-fi toy ^^" same decoding effort as something more efficient (but lossy), and nobody to notice it's lossless.

2024-11-24 17:53:47 UTC

- reply

not taking it too seriously, just curious what Options I do have when I don't need all the bells and whistles of AWSzureGCP.

2024-11-24 17:34:18 UTC

- reply

I recognize OVH, the rest I don't seem to recognize. Would you care to list them out?

2024-08-22 19:17:36 UTC

- reply

and imho, that's excellent. It's nice that we can unify so many things, but USB low/full speed is exactly the thing you'd want to build robust low-speed peripheral networks. A mouse really doesn't need to support BAR or be safe to map using an IOMMU, and neither does a thermal sensor or blinkenlights.

2024-08-16 17:34:34 UTC

An issue that GNU Radio *really* needs your help on:
https://github.com/gnuradio/gnuradio/issues/7472

2024-03-07 20:36:14 UTC

Cool project find of the day:
QBDebris - A CubeSat formation for space debris characterisation
which plans to deploy a duo of cubesats into lower earth orbit. They will maintain a defined distance, and use radar to characterize space debris in the size of 1 to 3.2 mm – which is smaller than what can be detected from earth using radars, and too large to be analyzed from collecting dust.
Juha Vierinen is involved, who's also famous for his other ionized gas and other space radar applications,…
https://files.mastodon.social/media_attachments/files/112/056/282/926/614/963/original/74c6cc0e150b237a.png

2023-03-03 20:07:10 UTC

- reply

It does get weirder, though: That's actualyl *two* standards in one: There's the one-screw-over-the-flat-side standard from the previous mastulence, there's also this dual-screw variant which has two screws, one flanking each short side of the USB-C connector.
https://files.mastodon.social/media_attachments/files/109/961/133/145/420/084/original/1cae9f1f80ca600b.webp

2023-03-03 19:55:28 UTC

Over on the twitters, in one of the "cursed USB connectors from all over the world" threads, I thought @npub1g8x…7wul was joking when they said that there's two USB-C standards: One for the rotatable USB-C plug we all know, and one where you need to orient correctly to screw in the D-Sub-style screw.
Turns out: that wasn't a joke.
https://www.usb.org/sites/default/files/documents/usb_type-c_locking_connector_specification_rev_1_0_20160309_0.pdf
#USB #USB-C #WhyCanIOnlySearchByHashtags
https://files.mastodon.social/media_attachments/files/109/961/098/367/952/685/original/e202532090355919.webp