heresy! The 68030 wore it better! . . . Which is another way of saying “this is very cool”, and “could you please make a 68030 or 68040 of it?” (No 68LC040, please.)
pam_bcpasswd lives! (^o^) Now you'll be able to avoid transmitting your password in clear text over the air, especially useful if you have a backup access over AX.25. I need to check if I can use it directly with axspawn during the initial authentication... Sources to be published once the debian package can be built. I've got a few ideas for secure password rotation (using OPAQUE) and to implement a 3-way alternative of SCRAM to provide mutual authentication :3c
It works like the original challenge-md5 mechanism in axspawn: it issues a random challenge (size adjusted to provide better randomness), and then checks that ascii-hex(md5(concat(challenge,password))) matches.
In terms of security, this is far from being perfect (which is why I'm hoping to replace it by SCRAM in the long run), but at least it's better than cleartext password or baycom authentication, for now.
I may be a sinner for building a Layer 7 HTTP accelerator for constrained ham channels, but I never wrote (and will never write) a Network/Port Adress Translator there are limits to a lack of decency 😸
A REQUEST: If you own a French CD-ROM computer game called "Pop Anim'", please let me know. I could use it for some research but haven't been able to find a circulating copy yet. (It's at the BnF but I can't get there right now.)
C'est un rapport factuel, donc qui contient les données techniques. L'analyse de l'origine sera publiée dans le rapport qui devrait sortir dans 4 mois environ.
TIFO axspawn (the linux utility to handle incoming AX.25 connections) has a built-in inline compression feature (your client needs to send "//COMP ON\n" once the LAPB bearer is established. Axspawn then sends "\rCOMP 1\r" and turns on huffman compression).
Currently working on an ALS162 time receiver. Getting my paws on NF C 90-002 really helped to think of an easier strategy to acquire and sync with the signal.
Turns out this signal is a 40Bd 3-state TCM.
First step, however, is to write a stub that will generate a baseband clone of the signal. For now I'm able to generate a static frame. The scrambler is implemented, and I'm working on the CRC-13.
Honestly, the choices that were made are quite elegant, imho: out of 9 phase transitions, you can recover up to 4 bits in 4 cases, more than 1 bit for 4 others, and the last, which is the XOR of the 3 previous bits. This means you can recover erasures in many cases ✨💜✨
- Thunderstorms depends on it to grow. - It juts out into the sea, watching waves crash below. - You won’t find it on common folk, but legends let it billow.
Still waiting for someone to make an x86 platform that just shoves uboot and/or a kernel/initramfs, plus a DTB, into SPI flash and just boots straight from that without needing any "firmware" at all.
@azonenberg flat device trees aren't cute. Device trees are only flat when they are stressed.
Basically, the idea that you need a DTB to boot is wrong. The device tree needs to be provided by the firmware. We went through this with ACPI already, people replacing their broken tables on the command line, and it had not suddenly become a sensible strategy twenty-five years later.
@GyrosGeier it makes much more sense to have a data driven boot process and not have code running on the platform before the OS starts.
(Doing this right would of course require that things like RAM init be handled in silicon or by the kernel, which is a whole other can of worms where silicon vendors are concerned...)
Isn't that the whole point of SPD (since PCs ~always used DIMM/SODIMM based memory)? You just need some board-independent init code that reads the eeprom from each slot, figures out how much is there, and brings it up.
I don't see why you need per-board firmware when the entire point of the eeprom is discoverability.
Basic summary of my comment to FCC filing 25-201, with regard to a secondary spectrum allocation on the 430-440MHz band (you have until 2025-07-21 if you wish to do it too: fcc.gov/ecfs/filings/express?p…)
Currently writing a middleware that interfaces a D-Star Radio with packet applications. On this video: Winlink e-mail transfer over DV Fast Data. youtube.com/watch?v=rKkFJ9TmqQ…
Rewrote my DExtra / D-Star dissector, I'm able to read DV Slow data packets, DV Fast Data should come quickly once I'm laying my paws on a pcap trace to validate a few assumptions. Payload reassembly, superframe-wise, is being written.
FBB Dissector for Wireshark: here you go, code qualification has not been completed, I need to continue bug hunting (some additional traces needed). github.com/dscp46/dissectors
Finally took another take to implementing the FBB protocol dissector. The command interpreter is almost finished. The last obstacle is to implement LZHUF decompression in LUA to decode payloads.
De moins en moins d'écrans CRT fonctionnent et c'est normal, les composants s'usent notamment les condensateurs. Beaucoup d'écrans ont été jetés et ça devient de plus en plus rare d'en trouver alors si possible ne les jetez pas, vendez-les ou donnez-les pour pièces.
(ceci était un message du Comité de Restauration des Tubes)
Add passkeys to the list of things that didn't advance as much in 2024 as we thought they might. That's because some companies are still making the process complicated. pcmag.com/news/the-passkey-fut…
These cancer cells have destroyed so many retro computers. It's extremely sad. And if you have an old computer around from the 386 or 486 era, I suggest you check and remove that thing ASAP #retrocomputing #vintagecomputing
Funny JS hack (not yet in production, but soon to be): you can detect a slow internet link using readyStateChange events to offer a lighter web page :3
Eric
in reply to Nanoraptor • • •stdevel
in reply to Nanoraptor • • •cyborg mouse
in reply to Nanoraptor • • •Dr. Juande Santander-Vela
in reply to Nanoraptor • • •.
.
.
Which is another way of saying “this is very cool”, and “could you please make a 68030 or 68040 of it?” (No 68LC040, please.)
✧✦Catherine✦✧
in reply to Nanoraptor • • •guenther
in reply to Nanoraptor • • •Nanoraptor reshared this.
Dentaku (Thomas Renger)
in reply to Nanoraptor • • •John Francis 🦫🇨🇦🍁💪⬆️
in reply to Nanoraptor • • •Alda Vigdís
in reply to Nanoraptor • • •josh g.
in reply to Nanoraptor • • •Nanoraptor reshared this.
yuubi
in reply to Nanoraptor • • •JensRestemeier
in reply to Nanoraptor • • •Даша, подруга ворон 🐦⬛
in reply to Nanoraptor • • •Plaid
in reply to Nanoraptor • • •Limey_Tank
in reply to Nanoraptor • • •1.3.6.1.4.1.61513
in reply to Nanoraptor • • •Michelle Hughes
in reply to Nanoraptor • • •