HN user

zootboy

1,003 karma
Posts0
Comments196
View on HN
No posts found.

Life expectancy really depends on how the hardware gets used. I run a small fleet of servers that are heavily CPU / GPU loaded, and the most frequent hardware failure I see is power supplies, with RAM as #2 and spinning HDDs as #3. Each of these (on enterprise-grade gear) has some amount of reporting / monitoring, but it's rarely the case that I get any advance warning before a failure. The RAM is probably the nicest, as it sometimes starts with correctable ECC warnings. Nearly all of the PSU failures have been sudden deaths, with the only saving grace being N+1 redundant supplies usually keeping the victim server alive.

Is it hurting the batteries of my devices?

Unequivocally no, assuming your chargers are reasonably spec-compliant (e.g. not Aliexpress garbage). This is the whole point of type-C / USB-PD: chargers and devices should be more or less interchangeable. It's up to the device, not the charger, to charge its battery at an appropriate rate. The worst that can happen is plugging in an undersized charger, which may cause the device to charge slowly or not at all. If the device accepts a charge from the charger at a rate you find acceptable, then you're golden.

Battery failure is a "when" because batteries have a limited number of charge-discharge cycles. Modern lithium-ion batteries have a life expectancy in the range of 300-600 cycles. So if you've never had such a failure, it probably just means you're not a heavy user of your devices.

I try to keep my cell phones as long as I feasibly can. Every single one I've used for more than 3 years has had its battery fail (as expected for a device that sees such heavy cycling). My current phone is on its 3rd replacement battery.

I'm not certain that the git committer tells you the full story. I don't believe the AUR enforces that the git commit email is the same as the current maintainer email. So this could have been an orphan package, adopted by a malicious user, generated a malicious commit with the previous maintainer's git info.

Unfortunately, I don't see a way of viewing the ownership history of a package in the AUR. I know you get emails with ownership changes if you're subscribed to a package, but I don't see this info in the web interface anywhere.

It's not outdated, you just actually need to follow it. 3 copies of data in separate S3 buckets is ignoring the "2" in the 3-2-1 rule: 2 different mediums, and also the "1" rule: 1 copy offsite. In the cloud era, offsite means not on the same cloud provider. Different mediums ideally means a non-cloud provider (e.g. a NAS at your office under your control).

...affluent people leaving all of their moop because they don't care about the deposit

This is why I suggested an increasing deposit for repeat offenders. Leave a huge pile of trash? Next year's deposit is $100k. Do it several years in a row? $10MM deposit.

Sounds to me like there ought to be a MOOP cleanup deposit charged upfront, that only gets returned after this inspection. If the cleanup crew has to clean your site, you forfeit part or all of your deposit. Repeat offenders get charged increased deposits each time. Repeat inoffenders(?) get their deposit reduced.

It's behind a UPS and a good surge protector.

To be clear, neither of these things are intended to address EMI/RFI. Most consumer-grade UPSes directly pass the AC power through when not on battery, so any noise on the lines will also pass through pretty much untouched.

Surge suppressors are just MOVs (metal oxide varistors) and a circuit breaker. If the line voltage rises too high, the MOVs try to shunt the voltage. But if the EMI's peak voltage is below the MOV's trigger threshold, it will do nothing and the EMI will pass straight through.

The DUP profile is meant for use with a single disk. The RAID* profiles are meant for use with multiple disks. Both are necessary to cover the full gamut of BTRFS use cases, but it would probably be good if mkfs.btrfs spat out a big warning if you use DUP on a multi-disk filesystem, as this is /usually/ a mistake.

Metadata DUP (not sure if it's across 2 disks or all 3) should be expected to be robust, I'd expect?

No. DUP will happily put both copies on the same disk. You would need to use RAID1 (or RAID1c3 for a copy on all disks) if you wanted a guarantee of the metadata being on multiple disks.

Here's the actual TSA list: https://www.tsa.gov/travel/security-screening/identification

But fun fact: even if an ID is on that list, if it's not one that their little scanner machines know how to read, then it's effectively not on that list. I've been hassled every single time I try to use my TWIC card at TSA, and they invariably demand to use my (non-REAL) driver's license, since their dumb scanners can manage to read that one. They often then have the gall to give me one of their "You need to have a REAL ID" pamphlets. I can't wait to see what happens next time I travel with this new fee in effect.

I've always thought it would be neat if the accelerator pedal on cars had some sort of force feedback that was proportional to the amount of power the engine is putting out. That way the driver would be able to feel how hard they're demanding the car to work, and hopefully they would adjust their driving habits to go slower on steep hills, not hard accelerate out of traffic lights, etc.

A little bit of educated guessing on my part:

The purple frames have a bunch of gradients to white, which looks a lot like what happens when the infrared filter on most color cameras is removed and a bunch of IR light is shone into then. For some reason the green cells are less sensitive to IR, which results in a purple-ish hue. So in this case, perhaps the lava striking the camera melted through the lens holder and shifted the IR filter out of place, or is just able to shine intense IR light into the gap between the filter and the sensor.

In those same frames, the dark areas with noisy borders are I believe an artifact of the CMOS sensor digitization process when cells get strongly overwhelmed. I've seen the same patterns on cameras where an extremely intense light (e.g. a laser pointer) is shone into them. It's like the cells get so overwhelmed they roll around back to zero.

The amorphous shapes at the very end are clearly from the lens being totally detached / moved out of position, allowing defocused light to hit the sensor. I didn't spot any interesting sensor or encoder death frames before the video ends, so likely the lava severed the ethernet cable or destroyed the electronics at that point.

My original Palm IIIx 11 months ago

the non-backlit screen

If I'm not very much mis-remembering, this Palm actually did have a backlight? I think you had to long-press the little green button to activate it.

No 12 months ago

I find out that the seller is actually just doing arbitrage from Amazon

Please report these sellers to eBay. This is explicitly against their terms of service:

https://www.ebay.com/help/selling/posting-items/setting-post...

However, listing an item on eBay and then purchasing the item from another retailer or marketplace that ships directly to your customer is not allowed on eBay.

Commercial Tier 4F diesels of the John Deere variety have latching fault codes when they relate to the aftertreatment system. It requires the manufacturer's proprietary scan tool (which they will not sell to you) to clear the code, even if the actual issue was something as simple as a connector left unplugged for too long.

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.