I run into this issue when building against different environments, each with a
1. A library depends on a system package. To test against the different versions of the system package, the library is compiled within a container.
2. To minimize the incremental rebuild time, the `build` directory is mounted into the build container. Even when using a different version of the system package, this allows re-use of system-independent portions of the build.
3. When switching to a build container with a different version of the system package, the mtime of the system package is that of its compilation, not that of the build container's initialization. Therefore, the library is erroneously considered up-to-date.
Because the mtime is the only field checked to see if the library is up to date, I need to choose between having larger disk footprint (separate `build` directory for each build container), slower builds (touch the system package on entering the container, forcing a rebuild), or less safe incremental builds (shared `build` directory, manually touch files when necessary).
I looked into it at one point, as I was disgusted by the unskippable advertisements when paying for an ad-free tier on one of the myriad streaming platforms. Apparently, they distinguish between "advertisements" for a product or service and "promotions" for themselves. I get why that would be a reasonable internal distinction, as the former would require sign-off from the business paying for the advertisement, while the latter would only need internal approval, but it's a pointless distinction after that.
The distinction is likely a claw back to give themselves just that ability to freely advertise to you after telling you it was ad free. Like what’s the difference advertising a subsidiary like Disney parks to me or a new car? Just that they own the former.
I particularly love how they will periodically choose to only use the selected Bluetooth device for audio output, and will instead switch back to the builtin microphone. The builtin microphone may be in my pocket or across the room, and so the only indication I get is when the person on the other end of the line says that I’ve dropped off.
Nothing changes in the UI to indicate this, nor could I find any setting to change this. Sometimes swapping the audio away from the headset and back to it helps, but it it at best a temporary fix.
> Emacs is not primarily a TUI program (although it does have a TUI with the -nw). The TUI version of emacs lacks visual customizability and introduces unnecessary overhead (terminal!). Use the GUI.
Can you elaborate on this? I tend to use emacs exclusively in the terminal, since I'm often using them on remote workstations. For remote workstations, I can (a) open files using TRAMP, (b) open a remote GUI with X11 forwarding over SSH, or (c) open a remote TUI. TRAMP doesn't always play nicely with LSP servers, and remote TUIs are much, much more responsive than X11 forwarding.
Locally, the performance of emacs depends far more on the packages I load than on the GUI vs TUI, so I'm interested in hearing what overhead there would be.
Yes, emacs is equally performant in GUI and TUI. And frames can be opened in both GUI and TUI on the same socket.
For me, TUI is a dealbreaker because:
- No mixed-pitch support: I use mixed-pitch fonts in org-mode buffers and in outline faces in prog-mode buffers. And fonts are just plain nicer on the GUI, and it's much better to look at.
- No SVG support: (I might be wrong about this) I have a custom modeline with SVG artifacts and the artifacts fail silently on the TUI
- Keybind conflicts: I am not used to accounting for the terminal's keybinds. Also, I use xfce4-terminal, which does not support the Hyper modifier (which I use extensively).
> Making these extra stops causes the bus to 'miss' the light cycle at almost every stop.
This would be a much bigger change, but it's also possible for the lights to give priority to buses. When a bus approaches a light, that should trigger the lights to advance to the part of the cycle that gives the bus the green light. That way, you prioritize the 20 people in the bus rather than the 10 people each in their own car.
This happens with trams in the German city I live in. The other advantage is energy efficiency, apparently - if you can keep them traveling at a consistent speed, then they can maintain momentum, as opposed to if they're constantly stopping and starting and need to spend more energy getting up to speed.
It's slightly irritating as a pedestrian when you're waiting to cross the road to get to a tram stop, and you see that the tram is coming in less than a minute, and you know you're not going to be able to cross in time. But that's the sort of slight irritation I'm okay with for better fuel efficiency and faster trams.
> Oh man. The infinite loops of impossible verification by large companies that should know better are massive pain peeve of mine.
I got hit by this from google.
1. Gmail added requirement for 2FA on my primary email address. Since I had no phone number on file, it instead used my recovery email address. Thankfully, I still had the password for my recovery email address, and could continue to (2).
2. Gmail added requirement for 2FA on my recovery email address. Since I had no phone number on file, it instead used by recovery's recovery email address. Thankfully, I still had the password for my recovery's recovery email address, and could continue to (3).
3. SBC Communications no longer exists, as it merged with AT&T in 2005. Email addresses at `sbcglobal.net` were maintained up until around 2021-ish, when they started purging any mailboxes that had been idle for more than 12 months.
Fundamentally, this was google's fault for misusing a recovery email for 2FA. Unfortunately, the only way to fix it would be to contact AT&T, asking them to pretty please update the email settings for somebody who hadn't been a paying customer for two decades.
Google made it very clear years ago that they shouldn't be trusted with anything irreplaceable/that would cause major problems if you lost access.
Once it became clear that they'd shifted from "crappy customer service" to (IMNSHO) "we fetishize the complete absence of customer service" it became dangerous to depend on them. Really, what's the worst that could happen? Maybe someone spams emojis in live chat on a game livestream at the request of the streamer on a personal account, it gets banned for abuse, Google recognizes that it's linked to other services and locks down everything? But that's so unrealistic I'm sure it could never happen.
It's not like they also have the ability to identify links between multiple accounts accessed by the same person and have automated processes that might stomp the associated accounts as well. Why, that would probably require something like allowing poorly-understood automated agents to take actions on their own!
> Fundamentally, this was google's fault for misusing a recovery email for 2FA.
While this would absolutely suck and I sympathise with anyone getting hit by this out of the blue, it's pretty clearly your fault, not Google's. What should they have done? Just permit everyone to avoid upgrading to 2FA indefinitely? That would result in relatively more account hacks overall, for which they would inevitably be roasted in the court of public opinion.
I'm tired of 2FA. Absolutely the worst when setting up a new phone after losing the old one. A whole bunch of mixed methods, in 2 hours between installing all the apps again, getting text messages, installing authenticators, scanning IDs, taking selfies, receiving phone calls with spoken codes, grabbing another device that still somehow has access, twenty emails about new suspicious activity, grabbing recovery codes, or scrambling to find the Yubikey I used when registering for the simplest and most benign services that have no connections to my personal data or payment.
Google will insist on sending a notification to a phone you have no longer access to, and regaining access always feels like hacking yourself. I dread the day I lose a phone together with my SIM card and ID during travel. I will never be able to go back and will have to start a new life as an illegal immigrant, living as a hermit in some deep forest.
> What should they have done? Just permit everyone to avoid upgrading to 2FA indefinitely?
Yes. I've had online accounts for nearly as long as there's been an "online". The only time I've ever lost control of an account was due to 2FA.
2FA should always be optional for one's personal accounts. [0] People who can securely manage passwords simply don't need it. And if Organized Crime or Mossad wants access to my accounts, 2FA is not going to stop them.
[0] Corporate accounts and hardware are a different matter. You manage those however your employer commands you to manage them.
The only reason Google does that 2FA dance is to get your phone number 'cuz it tends to be a very strong persistent marker which is very useful for... advertisement.
2FA isn't an upgrade, it's an annoyance. If your organization needs secure authentication, it's useful, but as an individual I have only ever been enraged. Making me check my email and phone to log in is a great way to ensure I never use your service again.
I think it's similar to, say, serving raw HTTP instead of HTTPS. If, say, Facebook still served HTTP and people were getting their passwords swiped, Meta would be in the crosshairs.
Even though you could say a person getting their 1FA account details phished is technically "their own fault", certainly to a greater extent than my HTTP example, spending the time understanding the issue well enough to realise that it was their own fault and not BigRichCompany's fault is not high on most people's list of fun things to do.
Or yours, for not caring about 2FA. It's been a common practice for many years, and strongly recommended by most identity services, as well as OWASP and NIST recommendations.
I have the same issue. At the time I created the account that I'm locked out of, Google said nothing about these "recovery" email addresses as 2FA. Years passed without any notice that maybe they were going to lock me out of an account I have the password for. No notice that I had better have access to that "recovery" email address that I hadn't bothered to keep up to date because I never thought I'd need to "recover" the account from Google. (In my case, it's an old .edu email address that I was promised "for life".)
If Google wanted to lock me out of my account for my own good until I enabled 2FA, fine. But as GP stated, they abused the recovery email addresses to force 2FA on people and ended up locking some people out of their accounts.
> No notice that I had better have access to that "recovery" email address that I hadn't bothered to keep up to date
The rest of your complaints make sense but this one is bizarre. It's a recovery email, isn't having access to it the entire point? Like what else did you think it was supposed to be there for beside being accessible?
Google clearly misused it for something else, and you have a strong argument they shouldn't have. This one sentence just needlessly weakens the argument.
I never expected to need to recover the account because I used a strong password stored in a password manager that I had adequately secured and backed up.
It was pretty sobering when Google demonstrated to me a new and novel way that made them the actual threat to my account security. I thought that by carefully refusing to publish anything with their add-ons (YouTube, Docs, Android Store, etc, etc) that I'd avoid getting swept up in an autoomated account-wide bannination, but, nope. A perfectly ordinary login to the account I'd had for years from the exact same location and IP address I'd used the day before was "suspicious" and required "recovery".
Why is 2FA so critical it’s worth proactively breaking the user? What’s the even more bad thing that would (not could) happen to the user if 2FA was not enabled?
Not force nonconsensual authentication methods onto users.
Google is one of the rare places I actually see positive value to 2FA. Compare with say banks, where it being demanded actually decreases my security. But regardless, it should not be forced.
As for the banks I doubt it decreases security. Even SMS 2FA actually reduces fraud by 90%+ percent.
Yes, some banks implement it silly, like SVB requiring biometric login in order to scan one-time QR 2FA code from their app (biometric login is less secure), but you don't have to use the QR code, can use regular 2FA without biometrics.
But even then having 2FA is 42 times better than not having it.
For US banks, the most important thing you can do to prevent fraud is to check your account transactions every 30 days so that you can report fraudulent transactions in a timely manner and have them reversed. Anything that increases friction of logging into your account thus decreases your security.
They certainly did a proper thing forcing people to use 2FA AFTER multiple emails over the years recommending to turn it on, and warning that they will enforce it, which they did.
nonsense. any feature should have acceptable failure modes. blaming the customer for a fault they have no control over is not acceptable. many people know nothing about 2FA. it is not their responsibility. 2FA is a symptom of shitty designed systems which are inherently insecure and companies who dont give a shit about that and let their customers shoulder the burden by shoving complexity down their throats.
if you make an app it is not your customers responsibility to secure it with additional actions from their side..if it is, you need to make it mandatory and guide them step by step.
you cant after a while enable some toggle.and tell people to fuck off and its the fault of their ignorance to not know some technical details.
most consumers of these services dont know shit about IT and they should not be burdened with it..any product that demands it is either only meant for tech savy people or more likely lazily and badly engineered by money hungry people who see opportunity to make more money in user's issues.
Provide a way to resolve the issue in the very foreseeable situation where someone doesn't read the emails an add it.
Is it possible that you use email differently than most people? I virtually never actually check my inbox. I'm either reading an email that I knew was coming (e.g. an order confirmation with a shipping link) or I'm searching for something specific. So no matter how many emails Google sends I'm unlikely to read them.
2FA falls under the same criteria as mandatory password rotation, and "has to have special characters". Those were NIST recommended for a long time too.
> There are always weird systems with old drivers (looking at Ubuntu 22 LTS)
While I agree with your general point, RHEL stands out way, way more to me. Ubuntu 22.04 and RHEL 9 were both released in 2022. Where Ubuntu 22.04 has general support until mid-2027 and security support until mid-2032, RHEL 9 has "production" support through mid-2032 and extended support until mid-2034.
Google will lock you out of an account even if you remember your password. This happened to me, when Google decided to use the recovery email address for 2FA, locking me out of my primary account. And the exact same change was made to my recovery account, at the same time. As for the recovery email of my recovery emails address, it was with a company that hadn't existed for over a decade, and no longer existed.
I'll admit that I've done that type of bugfix in the past. Though, usually it's because the bug is caused by an underlying design flaw, and the 10-line fix would have only papered over a single instance of the bug, and wouldn't actually solve the underlying cause.
Last time I needed to install Windows 11, avoiding making a Microsoft account required (1) opening a command line to run `oobe/bypassnro`, and (2) skipping past the wifi config screen. While these are quick steps, neither of those are at all "easy", since they require a user to first know that it is an option in the first place.
And newer builds of Windows 11 are removing these methods, to force use of a Microsoft account. [0]
1. A library depends on a system package. To test against the different versions of the system package, the library is compiled within a container.
2. To minimize the incremental rebuild time, the `build` directory is mounted into the build container. Even when using a different version of the system package, this allows re-use of system-independent portions of the build.
3. When switching to a build container with a different version of the system package, the mtime of the system package is that of its compilation, not that of the build container's initialization. Therefore, the library is erroneously considered up-to-date.
Because the mtime is the only field checked to see if the library is up to date, I need to choose between having larger disk footprint (separate `build` directory for each build container), slower builds (touch the system package on entering the container, forcing a rebuild), or less safe incremental builds (shared `build` directory, manually touch files when necessary).
reply