- 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…
The media in this post is not displayed to visitors. To view it, please go to the original post.
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
In the last year, I’ve spent about 200,000 words on a kind of personal journey where I’ve tried again and again to work out why everything digital feels so broken, and why it seems to keep getting worse, despite what tech’s “brightest” minds might pr…
@f4grx @ve3qbz @Nekoplanet @Forbearance that's the MO of a lot of corporate tech evangelists tbh, story often goes like "I think X technology is going to change the world but its being used in Y way which is causing damage and I'm the only one who can save it". those are the kindly deluded ones at least, some of them are just turbo scumbags who know their work is harmful but do it anyway
Weird - by 2002 when I moved from an area where one area code covered a significant portion of our side of the state to a metropolis that had 3 different areas codes in the same city, it was still "local" to any of those 3, but only if you didn't dial 1. Telephone switching has always been a little weird I guess.
By that time we were able to stop using the 1, but it was still "local long distance" for a few years after that, at least. I have no idea when the area started requiring 10 digit dialing because I had stopped using a land line by early 2007.
A brief but surprisingly exciting 1984 video showing the preparation and live, real-time cutover from Step By Step switching system (SXS) to a new electronic...
Yes! They weren't considered local calls so they were billed per minute. And since they weren't technically "long distance" we couldn't choose a different long distance provider for them. Pretty sure it was just a racket.
> The tools we use in our daily lives outside of our devices have mostly stayed the same. While buttons on our cars might have moved around — and I’m not even getting into Tesla’s designs right now — we generally have a brake, an accelerator, a wheel, and a turn signal. Boarding an airplane has worked mostly the same way since I started flying, other than moving from physical tickets to digital ones. We’re not expected to work out “the new way to use a toilet” every few months because somebody decided we were finishing too quickly.
Makes me think - sending someone a letter in the mail hasn't changed basically at all since 1963 with the addition of the Zip code. And even if you leave that off, USPS generally gets the mail to the place anyways.
Like there's probably nobody alive who hasn't had the "send a letter" workflow for their entire lifetime of: Buy a stamp Put a stamp on the top right of the envelope Write a person's name, street number, street name, city, and state Put letter in mail
Landline phone calls have changed a bit more. In the US we moved from 4 digit and call the operator if you want long distance to 7 digit and dial 1+area code for long distance to dial area code and 7 digits for pretty much all calls, but it's not THAT much different at least, just adding more numbers to the same basic interface. Well, also the change from pulse to touch tone.
Yearly UPS battery deep test 7 years-old VRLA batteries 7% load 100->10% in 51 minutes Nominal operation runtime is above 5 hours for that load, 8+ with shedding.
Ah, you need to own and operate your own hardware — a specialist thing! I had hoped it would be an online boutique service where you can upload the design and have it lasered for you like the way CafePress makes T-shirts!
@f4grx I will make some burning this week. I can "take orders" if some of you wants. Lets say I can book a total of 10 blank slate coasters for mastodon people.
I need a picture B&W (or vectorized) for ~9x9cm (the tile is 10x10cm but the hammered edges prevents nice result)
I propose 4€ each (without postage cost, to be added depending where you live).
Code analysis firm sees no major benefits from AI dev tool when measuring key programming metrics, though others report incremental gains from coding copilots with emphasis on code review.
The media in this post is not displayed to visitors. To view it, please go to the original post.
Alan Turing didn't have our modern boolean circuit notations, so he described circuits by the minimum number of high input lines required to trigger an output. You can almost see it as a neural net rather than logical gates, except when the ≢ sign appears for XOR. The lines with zeroes written over the node outlines are inhibitors.
The semicircles are delays measured in bits, which (as this was a serial machine) can achieve all sorts of shifting and rotation operations. The rectangles are delay lines (mercury tanks designed by Tommy Flowers at the Post Office research centre in Dollis Hill), and the number inside indicates the number of bits cycling around (although in some pages it's the number of 32-bit words, confusingly). Smaller delay lines could buffer a word for combination in a future operation.
@scottearle and you can guess where I'm actually going with this. I'm trying to figure out how I can put a ... Internet-something which hams can connect to and blast packets at without necessarily needing to be on the Pacific Northwest or tying up a HF antenna.
@AMS @scottearle this was just me playing with audio cables, no radio yet, so its moot here, but I will be sure to be 100% Part 97 compliment when I actually blast packets over radio.
@AMS Sorry, I’ve not played AMPR for thirty years. Where I’m living now there’s no 70cms, and nobody is using 2m for AX.25 or TCP/IP. Otherwise I’d have some oldskool TNCs talking to a RPi or similar. I’ve got a box with about three of them upstairs somewhere. If only there were a network they could talk to!
@scottearle @AMS Well the idea is to see if I can reasonably capture the output of Direwolf and transmit it via say EchoLink, or failing that, something bespoke with Asterisk.
That way, people can connect to my BBS just by getting a two way audio stream if they can't hit my dipole.
I figure you know, I asked for 16 IPs for radio usage, I should actually *use them on the radio*.
@scottearle Well this was me just blasting raw TCP/IP packets through a radio link, cause I learned that's a thing you can do with Direwolf.
It's actually shockingly easy to use it as a wirelessRS-232 replacement, and keep it legal to boot. Actually doing AX.25 framing is scaring me on how obtuse it actually is.
I also need to figure out a better way to start a keyboard to keyboard connection than JNOS, cause man, that thing is hard to setup.
New 35 mile link and repeater brought up on the regional network thanks to involved parties. I'm implementing dark mode on our dashboard so our users with browsers in their car can display the call log without being hindered by light in the night. A few nuts and bolts need to be adjusted with the map, but we're almost there.
@Foxarc in the PQC discussion, it is about switching key agreement and key signing (a lower priority) away from weaker cryptographic technologies (which today are computationally-hard, but in a post quantum world are no longer considered computationally-hard) in less than 10-20 years.
If you can call a software transition over 10 years agile..
It is also about making things easier to switch, should the newer tech introduced suddenly have weaknesses that were previously unknown, such as SIDH.
While at a high level it sounds like "great, I can just swap parts" as better ones come, the truth is that these PQC technologies have different protocol level requirements, storage and communication sizes, as well as computational overhead far different than what we have today, and change is fundamentally difficult to have backwards compatibility for.
See, they wanted to call the DirectX -> Vulkan layer "IndirectX" but found out the term was already used for something else!
Specifically, for Indirect X Rendering over the GLX/Xorg pipeline using the LIBGL_ALWAYS_INDIRECT=1 Mesa flag to use the older indirect OpenGL renderer for remote X connections
Andrew Zonenberg
in reply to aki-nyan • • •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.
Like how ~all ARM SoC boards boot.
aki-nyan
in reply to Andrew Zonenberg • • •@azonenberg That could be neat.
I remember this whole "linux booting linux" thing that made some noise *years* ago and I think it shared that idea, can't recall though.
Everything should just standardize on OpenFirmware :v
Simon Richter
in reply to aki-nyan • • •@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.
Andrew Zonenberg
in reply to Simon Richter • • •@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...)
Simon Richter
in reply to Andrew Zonenberg • • •@azonenberg exacty — also, DTBs don't know how much RAM you have, the board revision, ... It's just unmanageable for users.
RISC-V, in the spec, say that the DRAM init code shall deliver a device tree to any later stages, with the hardware inventory hardcoded,
In practice, I need U-Boot specifically to patch the broken device tree. If it were correct, I could use Linux directly after the DRAM init code.
Andrew Zonenberg
in reply to Simon Richter • • •@GyrosGeier > how much ram
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.