There is a serious question of why people get so upset about glasses that record as opposed to cell phones, etc. I have a theory on it and that is that, despite all the emphasis on eye contact, humans actually find it really aggressive and threatening. Traditional camcorders, cameras, and taking cell phone video all either outright block the eyes or at least the eyeline. You are not staring at them, you are staring at your phone. I think that is, at least in part why devices like smart glasses make people more aggressive than other recording.

The clear counterargument to that though, in the case of face mounted recording devices, is that they don't force a choice between helping/calling police or filming. True, that should not be a real dilemma, the obvious choice should be to help. The thing is, that problem in crowds of no-one stepping forward to help does not exist purely because of people recording. There are lots of reasons people don't put themselves forward in situations like that. One of them is the assumption that someone else will be able to handle it better than them, or simply waiting for someone to step forward and lead, etc. There are also concerns about liability, possibly about self-endangerment and a dozen or more anxieties and neuroses that can cause the problem. Recording with a cell phone probably exacerbates the issue though, by giving people an activity that, in the moment, their mind can rationalize as doing something. If recording is a less active and more passive process, leaving people free to actually do something and taking away their excuse for rationalization, it might encourage more people to actually help.

Mileage may vary, of course. On balance though, it seems like head mounted recording devices are more of a solution to the problem you were talking about than an exemplar of it.

One major difference, assuming you've got full platform support(should be the case on any server or workstation that isn't an utter joke; but can be a problem with some desktop boards that 'support' ECC in the sense that AMD didn't laser it off the way Intel does; but don't really care); is that ECC RAM can (and should) report even correctable errors; so you get considerably more warning than you do with non-ECC RAM.

If you pay no attention to error reports ECC or non-ECC are both rolling the dice; though ECC has better odds; but 'proper' ECC and Linux-EDAC support will allow you to keep an eye on worrisome events(normally with something like rasdaemon, not sure what other options and preferences there are in terms of aggregating the kernel-provided data) and, unless the RAM fails particularly dramatically and thoroughly, will give you much better odds of knowing that you have a hardware problem while that problem is still at correctable levels; so you can take appropriate action(either replacement, or on the really fancy server systems, some 'chipkill'-like arrangement where the specific piece of DRAM that is failing gets cut out of use when deeemed unreliable without having to bring the system down.

Sometimes you'd get a BSOD that was a fairly clear call to action; when the error called out something recognizable as the name of part of a driver; but that is mostly just a special case of the "did you change any hardware or update any drivers recently?" troubleshooting steps that people have been doing more or less blind since forever; admittedly slightly more helpful in cases where as far as you know the answer to those questions is 'no'; but windows update did slip you a driver update; or a change in OS behavior means that a driver that used to work is now troublesome.

Realistically, as long as the OS provides suitable support for being configured to collect actual crash dump material if you want it; it's hard to object too strongly to the idea that just rebooting fairly quickly is probably the better choice vs. trying to make the BSOD a genuinely useful debugging resource; especially given how rare it is for the person with useful debugging ability to happen to be at the console at the time of crash(rather than just an end user who is ill equipped to make sense of it; or a system that mostly does server stuff, quite likely not on actual physical hardware, where nobody has even touched the physical console in months or years; and it's more or less entirely useless to display a message there; rather than rebooting and hoping that things come up enough that management software can grab the dump files; or giving up and leaving the system in EMS so that someone can attach to that console.

There seems to be little doubt that the majority of voter suppression in the US comes from the Republican party (see various court cases that have ended up with, for example consent decrees that are later ignored). So, logically, unless they are really, really bad at planning it, it seems pretty clear which way they sway election. Also, consider your claimed position, that claiming a stolen election will sway independent voters away from the party whose members make the claim. Considering all of the activity from the Republicans (and specifically the ones in actual positions of power, like Trump) over claims that the 2020 Presidential election was somehow stolen, compared to the relatively minor activity over claims that the 2024 election was stolen, how do you justify that as a reason for votes to shift towards Republicans to Democrats?

Take apart the clicker and wire the button to your own solution. Or even just have a solenoid that pushes the button that is activated by your own solution. Or alternately, take apart the garage door opener and just bypass their electronics. Or just build your own from scratch. Garage door openers are not particularly sophisticated devices.

Right, makes sense. Because having things delivered started with Covid-19 and the Sears Roebuck catalog was never a thing.

I agree with you in principle. Anecdotally... ehhh.

Interesting there that you're not denying that voter suppression took place, you're just calling them slime for not also pointing out that some of the suppressed voters may have voted for different parties than the others?

Please tell me you recognize the irony in your opinion?

I have replied to myself in the past to add to posts, but usually either because I hit the length limit for a post, so had to split it in two, or because I needed to correct an error. The asking a question then apparently trying to answer yourself thing that you seemed a bit different. I suppose I didn't really need to reply to it myself though.

I saw them a couple of times in Firefox, but it seem uBlock Origin has had its definitions updated.

They already give you a big, scary warning if you try to open a .lnk file downloaded from the Internet. People do it anyway.

I'm not talking about media container formats. The MP4 container format is based directly on the MOV format and covers the most common cases, and as you mentioned, the EBML-based MKV container format deals with a few corner cases.

The Quicktime framework let you do media decoding, encoding, transcoding and playback, as well as stuff like bitmap scaling, sample rate conversion, and all sorts of other stuff. And you could use "Quicktime components" to add support for additional codecs or other functionality to every application that used the Quicktime framework. If you had a Quicktime Pro license (fairly cheap, or you could use one of the well-known Apple Sales keys if you didn't want to pay), you could use Quicktime Player to do a bunch of basic video editing tasks.

Microsoft DirectShow was probably the closest equivalent, but it never got the same market penetration and third-party support. Now there's no real replacement.

Quicktime used to be the standard framework for media playback, transcoding, etc. It had a complex API, but it held up pretty well for at least fifteen years. But Apple just lost interest in it, stopped updating it, and it sort of fell into obscurity. There's no real modern replacement that covers all the same cases.