Hacker Newsnew | past | comments | ask | show | jobs | submit | myself248's commentslogin

Paper.

Not even kidding.

With any other media, you have to hope that the drives are still available. Paper routinely lasts hundreds of years and we all have readers built right in.


I like simple solutions. But paper has severe storage capacity limitations, which makes it impractical for storing large amounts of data.

It's surprising that it can't be done programmatically, since "minimize the color difference above and below this super obvious line" seems like it should be a pretty straightforward success criterion.

AI may be the “killer app,” for these kinds of “back up and squint” judgment calls.

Alternately, run OpenWRT on the APs themselves, and then you just need one provisioning protocol.

Does it support seamless roaming of clients between group of APs?

Last time I've tried, it was not supported by any open source solution.


Seamless WiFi roaming is mostly a client decision. The best you can do on AP is to:

a) optimize signal strength for coverage (stronger signals aren't always better in multi-AP deployment);

b) provide hints via 802.11k/v/r to help clients make, hopefully, better decisions;

c) forcefully drop and disassociate clients when signal is weak enough.

But if the client has bad WiFi implementation, there's nothing much you could do.

OpenWRT currently supports 802.11k/v/r, but optimizing coverage by adjusting signal strength and channels is left for experienced users to deal with manually. There is the are where some commercial offerings will do, but the result greatly varies. AFAIK there's no ideal system anyway coz physics is hard.


Well AFAIK the core seamless roaming in Unifi is using hostapd, which is the same AP software you use on OpenWrt. See 802.11r Fast Transition.

I think it should even be possible to get seamless roaming between Unifi and OpenWrt with correct configuration of hostapd.


This is brilliant! The techniques remind me of a lot of my Toughbook modding, back in the day, which I did not document nearly enough.

I still have the shell of a CF-17 that's just begging for new guts... but I'd have to aim for something quite a bit lower-power as it's a sealed chassis with no provision for air cooling. Perhaps a CM4-based build...

Aaah! Why must other people be so productive! It gives me too many projects!


It's essentially random at any given moment. If I peek, mine will say it's running anywhere between 700MHz and 3.4GHz. Sometimes I think it goes even faster, but only if it's weirdly cold at the time.

Upgrading and Repairing PCs 4th edition even says directly, that some shady resellers will put a heatsink on a chip that they're running beyond spec, but that Intel designs all their processors to run at rated speed without one.

I had a PC with an old PII or PIII cartridge.

The cpu and heatsink was fully integrated into what looked like a NES cart, with an integrated fan and everything. It was not really possible to separate the cpu and the heatsink as the locking mechanism to keep the cart in place on the motherboard interfaced with the heatsink assembly.

So I'm a little dubious of that no-heatsink claim.


I've never seen a Xeon without a heat sink, I don't believe they are designed to run without one.

Indeed, even the oldest, slowest Xeons shipped in SECC cartridges with integrated heatsinks.

But that was several years after the book cited by the GP was published (1994, shortly after the release of the original Pentium).


Ah I missed that on my first read, was more focused on the claim at the end of the sentence. Thanks.

The first Xeon looks to be released 1998, so sounds about right

> in the early 90s. They were only powerful enough to control external equipment like synthesizers.

Tell that to ScreamTracker!


In case anyone's wondering:

https://youtu.be/roBkg-iPrbw


Screamtracker was sampling. Great for the days and much more accesible for the teenager I was than buying and controlling synths but that was not exactly same. More a competition to the early akai MPCs.

And we were mostly ripping those samples from records on cassettes and CDs, or other mods.


Well now that you mention that, my very first steps actually were with Soundmonitor on a C64, one of the OG trackers probably (even though not called tracker yet IIRC). I kind of forgot about that, as that was still very amateurish (I mean what I made with it, not the software).

https://www.c64-wiki.de/images/f/f1/rockmon3.png

Or also at https://www.youtube.com/watch?v=roBkg-iPrbw&t=400s in the video already linked below. And yes, I had to type in that listing.


> I could also speculate that the overlap between Linux kernel developers and automotive and industrial embedded systems is pretty low.

Agreed.

> So the high bug severity in the CAN driver could be developers contributing patches from a very different programming background?

Background and situation. Their mindset is "I need this to work, right now", not "I need this to work, and not break anything else, forever".


I think branding and reputation basically encapsulates all the build quality and support and stuff you mentioned. Non-technical consumers will see this, decide that it's probably better than a Chromebook, and be right.

There's a compelling value case here. It might well be my first Apple purchase.


Last time I went looking for LFL's, the map data quality was terrible. There's no way to flag a defunct location as defunct, since only the "owner" can edit their own entry. If they don't respond, it's a permanent ghost on the map.

I've taken to mapping them in OSM using amenity=public_bookcase (and amenity=food_sharing for the similar little free pantry). This way anyone can update the entries over the years.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: