zootboy

I know this is just a weird workaround, but you can put your mouse cursor on top of the scroll bar. The scroll wheel still works like normal there (at least in my tests on Linux / Firefox).

I wish this had a "I can't tell" option. A few of the really hard ones I got right, but I'd say it was more of a lucky guess than a genuine ability to discriminate the difference.

It really depends on where (and when) you're going. I've had a decent number of partly full flights going to oddball small airports. But the big hub-to-hub flights tend to be nearly if not completely full.

The ultimate frustration is when you have no real ability to fix the core problem. NTP (and its 'roided-up cousin PTP) are great, but they require a degree of control and influence over the end devices that I just don't have. No amount of pleading will get a battery vendor to implement NTP in their BMS firmware, and I don't have nearly enough stacks of cash to wave around to commission a custom firmware. So I'm pretty much stuck with the "black box cat herding" technique of interoperation.

Yeah, it was a "fun" surprise to discover the errata sheet for the microcontroller I was working with after beating my head against the wall trying to figure out why it doesn't do what the reference manual says it should do. It's especially "fun" when the errata is "The hardware flow control doesn't work. Like, at all. Just don't even try."

Indeed. I've been building systems that orchestrate batteries and power sources. Turns out, it's a difficult problem to temporally align data points produced by separate components that don't share any sort of common clock source. Just take the latest power supply current reading and subtract the latest battery current reading to get load current? Oops, they don't line up, and now you get bizarre values (like negative load power) when there's a fast load transient.

Even more fun when multiple devices share a single communication bus, so you're basically guaranteed to not get temporally-aligned readings from all of the devices.

And here I sit, longing for the days when trackpads had separate, physical buttons underneath them.

I wonder if that's even technically possible these days. Given the fact that the heads have to float on the moving air (or helium) produced by the spinning platter, coupled with modern data densities probably making the float distance tolerance quite small, there might be a very narrow band of rotation speeds that the heads require to correctly operate.

It's kind of funny that every example the article shows is a screenshot or video. Not a single one was actual ASCII text in the HTML...

And the photos of said C-hooks are pretty damning:

https://www.nbcbayarea.com/investigations/new-images-of-pge-...

For the unaware (including myself): https://en.wikipedia.org/wiki/Zalgo_text

If you really think you need to programmatically detect and reject these (I'm dubious), there is probably a reasonable limit on the number of diacritics per character.

https://stackoverflow.com/a/11983435

To be fair, Arch's base NetworkManager package does the same thing:

https://wiki.archlinux.org/title/NetworkManager#Checking_con...

Though Arch has a decidedly more privacy-friendly stance on their ping endpoint: no logging at all.

There's nothing silly about wanting to avoid the sandcastle-built-on-quicksand world of web applications.

Sadly, the world of native apps, at least in the commercial space, seems to be drifting away from the tenants of stability and user control that the space used to exemplify. Excel 365 (or whatever the hell MS wants to call it) randomly auto-updates itself without warning or confirmation.

I've seen the "overzealous barcode scanner" issue happen with some gas station POS systems, to the point where the seasoned cashiers know to cover the QR codes with their fingers before attempting to scan an item.

I've been pushing an average of 10 TiB per month through my Sonic 10 Gbps fiber, mainly upload. Never had an issue or complaint. And really, even if my XGS-PON fiber is split between 32 customers, that's still ~300 Mbps per customer, which I'm nowhere near hitting.

It's saying that it could be either +/-50 ppm from the actual reading, or +/-5% from the actual reading, whichever is worse.

Of course it did, it was less than 14 kB.

But in all seriousness, this sort of site is what I wish more sites were like. No ridiculous JS rendering engine, or 11 billion AJAX requests to 3rd party servers, just simple HTML and CSS.

Yet another "Hey, this reminds me of a similar thing" contribution: Sean Barrett (of the STB header-only libraries fame) has a series of coding livestreams going over his OpenGL voxel rendering library and sort of turning it into a game:

https://www.youtube.com/watch?v=kD93nsghj9A&list=PLMkT-w6m06...

Indeed. I've seen a retail toy use a similar microcontroller from Nyquest to accept infrared control commands and drive some H-bridge drivers to make a simple, cheap RC car.

It's a bit hard to find good pictures of it, but the original Kyocera Torque from 2013 was IP 67 and had a user-replaceable battery. Its back had a large fingernail-turnable latch and pretty well-designed seal.

Say what you will about the aesthetics of the handset, it's proof that waterproof, user-replaceable batteries are absolutely possible on a consumer handset.

https://www.gsmarena.com/kyocera_torque_e6710-5270.php

https://www.turbosquid.com/3d-models/3ds-kyocera-torque-e671...

Patents on codecs are probably the worst offenders in my mind. Codecs benefit significantly from network effects, so making it a question as to whether you can legally use a codec muddies the waters and drives people away from good solutions. You wind up in ridiculous situations where you have hardware in your CPU that you can't legally use without paying for a license.

Plus, there are so many parties with a vested interest in making good codecs, I really don't buy the argument that they require patent protection otherwise they wouldn't be researched.

This kind of shit is why we can't have nice things. Software patents' only use is as cudgels for large companies to beat other large companies with, and they leave a hazy minefield in their wake for software developers to wade through.

Abolish software patents.

https://endsoftwarepatents.org/

Very cool that they were developing the one-gyro control mode all the way back in 2004, and had in-flight tested it by 2008. Seems like they were well prepared for this eventuality.

Ah, yes, that's the detail I missed for why #2 is relevant. So the answer to #2 is "not by default, but easy to enable." Though other comment threads here have discussed the potential for this to impact NAT hole punching.

Well, of the three mitigations suggested in the article:

1 - Random NAT port allocation

Seems like the answer is "not by default." According to iptables(8), SNAT defaults to using the pre-translated ports whenever possible, so it's up to the connecting client (victim's TCP stack) to randomly select source ports. There is a "--to-ports" option that lets you limit the usable source ports, but it's not mentioned how the ports are selected in that case.

2 - Reverse Path Validation

I'm not really sure how this helps in the described situation. If the attacker and the victim are on the same wifi access point, then both of their traffic will be sourced from the same network interface, so even strict RFC 3704 validation will pass for spoofed packets from the attacker. But for completeness, you can turn that on by setting a sysctl (rp_filter = 1).

3 - TCP window checking

I _believe_ that the vanilla linux kernel does check this by default, as the mentioned adjustments to OpenWRT seem to be removing a non-standard option to disable the TCP window checking

https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce...

No mention of Android and how to DeGoogle it? I mean, I suppose this is mostly an advertisement for ProtonMail & friends, but still...

This is, for me, the area where DeGoogling has the strongest downsides: losing access to the ability to install apps from Google Play, and not being able to run the majority of modern android apps due to the heavy reliance on Play SDK. I definitely get some funny looks when people tell me to "just install the app" and I respond with "I can't install apps."

Yes, the Pirate Bay is still a thing:

https://thepiratebay.org/index.html

Feel free to look up your favorite movies from 2024. They're on there.

I run a NAS on a USB 2.0 boot disk, and the only issue I have with it is that systemd-journald really isn't built with slow disks in mind. Doing a journalctl operation with 6 months of log files takes a good minute or two because of journalctl's non-optimal file access patterns.

The main technical reason is that the vast majority of UPSes cannot take what they give. If you have a 1000 VA UPS that is loaded at or near 1000 VA, it will draw significantly more than 1000 VA during periods of recharging, or if you make use of the non-protected outlets on certain models, or if the model is a double-conversion type. Thus, daisy-chaining two identically-sized UPSes will never work; they always need more input power capacity than they can output.

Then there's the issue of output waveform. Cheaper UPS models put out a hideous square wave or modified square wave waveform. This is adequate for being fed into a PC's PSU to be turned right back into DC, but most UPS line status detectors will not be happy being fed in such a bad waveform and will consider the grid faulted. Thus, as soon as you have an outage, both UPSes will go into battery mode, and you will not be able to use the "upstream" UPS's capacity. I suspect that even nicer UPSes may have issues accepting the power generated by another UPS, as their voltage and frequency regulation may not be good enough to satisfy the grid stability tests.

But the larger part of my reasoning for why you shouldn't daisy chain UPSes is that it's attacking the problem of reliability from the wrong angle. By daisy chaining UPSes, you have added an additional single-point-of-failure to your system. If instead you used a redundant PSU, you would have decreased the number of single-points-of-failure.

In my personal experience, I have seen far more power supplies die than I've seen UPSes, so the first thing I would do if I wanted a more reliable power setup is go for the redundant power supply. Only then would I consider attaching multiple UPSes (but I probably wouldn't under normal circumstances).

They don't explain it because it basically never makes sense to daisy-chain a UPS. If you want redundancy in your power supply chain, use a dual-PSU computer. If you want longer backup times, get a UPS with a bigger battery.