The default actually works pretty well these days.
Messing with the EFI partition, for instance by attempting to have two of those on separate disks, will probably cause you more pain than Windows will. As far as I understand, only one EFI partition can be configured in BIOS as the boot partition, so you will have to change the configuration in BIOS whenever you want to boot to the other OS.
Windows does have a history of changing the default EFI bootloader once in a while; however your chosen bootloader is still there, just not marked as the default anymore. A Windows app like EasyUEFI will let you change the default back.
The ONE time in half a decade I take a trip to Seattle...
"Possible cyberattack" plus "no threat actors or ransomware group has taken responsibility" sounds to me like someone fucked up and is timid about owning up.
She's pretty and deserves neck scritches. :) Also needs to see a farrier.
Yup, that's a giant house spider. No kidding, that's the vernacular name of the species, see https://en.wikipedia.org/wiki/Giant_house_spider. Formerly filed under the tegenaria genus, now its own genus.
They're comically large and terror-inducing, but not aggressive. And they keep out more aggressive species too.
Was this a mistake?
Clarifying: are you asking if downloading the Proton Mail app through the Google Play Store gives Google access to your Proton account? If so, the answer is no.
Hey, friend. This sounds super stressful, and I hope things will not take too long to be sorted out. I hope you'll manage to make room to take care of yourself too until you get to the other side of this. I'm rooting for you!
All labels are imperfect, I guess. That's the nature of labels: a shorthand for a complex reality.
I don't know if the "trans" label is or isn't a good shorthand for the complex reality of your identity. But the important thing is: your identity is valid and yours, regardless of what labels you stick on it.
If you feel that you are a woman, be that partially or completely, then congratulations, girl, there you go. Or maybe what you feel like switches back and forth depending on your mood, or maybe you exist somewhere in the middle. That's valid too. There are other labels worth exploring in that space, non-binary, genderfluid... I suppose the only really useful thing here is to work out which ones resonate with you as a suitable shorthand for who you are.
Oh and who you are attracted to is irrelevant. Lots of trans gals are lesbians. Doesn't make them any less trans.
Firefox's stance on privacy, like Apple's, is to some extent branding. Arguably it always was. You should still use Firefox (or any other third party browser) if it works for you. Ecosystem diversity matters.
They didn't drop the don't be evil thing. It's still right there in the code of conduct where it always was, they just moved it to the conclusion of the document so it's the last thing that remains with you. See for yourself: https://abc.xyz/investor/google-code-of-conduct/
The supposed removal is a perfect example of the outrage-bait headlines I'm discussing in another comment.
It's not the company it once was, but there are also a lot of outrage-bait headlines about it that don't hold up well to scrutiny.
For instance, there have been a lot of Lemmy posts about Chrome supposedly removing the APIs used by adblockers. I figured I'd validate that on my own by switching to the version of uBlock that is based on the new API. Well... As it turns out, it works fine. It's also faster.
Mind you, figuring out the actual facts behind each post gets exhausting, and people just shutting down and avoiding the problem space entirely makes some sort of sense. That, and it is healthy for an ecosystem to have alternatives, so I'd keep encouraging usage of Firefox and such if only on that basis alone.
This is actually an excellent question.
And for all the discussions on the topic in the last 24h, the answer is: until a postmortem is published, we don't actually know.
There are a lot of possible explanations for the observed events. Of course, one simple and very easy to believe explanation would be that the software quality processes and reliability engineering at CrowdStrike are simply below industry standards -- if we're going to be speculating for entertainment purposes, you can in fact imagine them to be as comically bad as you please, no one can stop you.
But as a general rule of thumb, I'd be leery of simple and easy to believe explanations. Of all the (non-CrowdStrike!) headline-making Internet infrastructure outages I've been personally privy to, and that were speculated about on such places as Reddit or Lemmy, not one of the commenter speculations came close to the actual, and often fantastically complex chain of events involved in the outage. (Which, for mysterious reasons, did not seem to keep the commenters from speaking with unwavering confidence.)
Regarding testing: testing buys you a certain necessary degree of confidence in the robustness of the software. But this degree of confidence will never be 100%, because in all sufficiently complex systems there will be unknown unknowns. Even if your test coverage is 100% -- every single instruction of the code is exercised by at least one test -- you can't be certain that every test accurately models the production environments that the software will be encountering. Furthermore, even exercising every single instruction is not sufficient protection on its own: the code might for instance fail in rare circumstances not covered by the test's inputs.
For these reasons, one common best practice is to assume that the software will sooner or later ship with an undetected fault, and to therefore only deploy updates -- both of software and of configuration data -- in a staggered manner. The process looks something like this: a small subset of endpoints are selected for the update, the update is left to run in these endpoints for a certain amount of time, and the selected endpoints' metrics are then assessed for unexpected behavior. Then you repeat this process for a larger subset of endpoints, and so on until the update has been deployed globally. The early subsets are sometimes called "canary", as in the expression "canary in a coal mine".
Why such a staggered deployment did not appear to occur in the CrowdStrike outage is the unanswered question I'm most curious about. But, to give you an idea of the sort of stuff that may happen in general, here is a selection of plausible scenarios, some of which have been known to occur in the wild in some shape or form:
- The update is considered low-risk (for instance, it's a minor configuration change without any code change) and there's an imperious reason to expedite the deployment, for instance if it addresses a zero-day vulnerability under active exploitation by adversaries.
- The update activates a feature that an important customer wants now, the customer phoned a VP to express such, and the VP then asks the engineers, arbitrarily loudly, to expedite the deployment.
- The staggered deployment did in fact occur, but the issue takes the form of what is colloquially called a time bomb, where it is only triggered later on by a change in the state of production environments, such as, typically, the passage of time. Time bomb issues are the nightmare of reliability engineers, and difficult to defend against. They are also, thankfully, fairly rare.
- A chain of events resulting in a misconfiguration where all the endpoints, instead of only those selected as canaries, pull the update.
- Reliabilty engineering not being up to industry standards.
Of course, not all of the above fit the currently known (or, really, believed-known) details of the CrowdStrike outage. It is, in fact, unlikely that the chain of events that resulted in the CrowdStrike outage will be found in a random comment on Reddit or Lemmy. But hopefully this sheds a small amount of light on your excellent question.
One funny thing about humans is that they aren't just gloriously fallible: they also get quite upset when that's pointed out. :)
Unfortunately, that's also how you end up with blameful company cultures that actively make reliability worse, because then your humans make just the same amounts of mistakes, but they hide them -- and you never get a chance to evolve your systems with the safeguards that would have prevented these.
You won't find the incompetence in the software no matter what.
If you fail to assume that the software contains issues -- if you fail to understand that your software is made by humans and humans make mistakes, not because they're bad but because they're human -- and if you fail to implement mechanisms to feel gracefully with inevitable failures, THAT is the incompetence.
Failures are systemic.
I had no idea DF had macros but it makes so much sense.
For serious. I wish they hired remote.
Multiple cursors are fantastic for certain use cases, but will not help you when each line needs a different input -- if you're swapping arguments in function calls, if you're replacing one bracket type with another around contents of arbitrary length, etc.
Mind you, if your objective here is to not learn a new thing, then you can just go ahead and do that, you don't need an excuse.
Where editors usually have editing shortcuts, vim has an editing grammar.
So you can copy (or select, or replace, or delete, or any other editing verb) N arguments or blocks or lines or functions or any entity for which vim has an editing noun, or around or inside either of these, and you only need to remember a few such editing verbs and nouns and adjectives in order to immediately become much more effective.
It's so effective that switching back to a regular editor feels annoyingly clunky. (I guess that's why many offer vim plugins these days.)
Better: you can record entire editing sentences and replay them. Ever had to make the same change on dozens of lines? Now you can do it in seconds.
Now of course, replaying a sentence, or several sentences, is also a sentence of its own that you can replay in another file if you want.
It's neat. :)
Where editors usually have editing shortcuts, vim has an editing grammar.
So you can copy (or select, or replace, or delete, or any other editing verb) N arguments or blocks or lines or functions or any entity for which vim has an editing noun, or around or inside either of these, and you only need to remember a few such editing verbs and nouns and adjectives in order to immediately become much more effective.
It's so effective that switching back to a regular editor feels annoyingly clunky. (I guess that's why many offer vim plugins these days.)
Better: you can record entire editing sentences and replay them. Ever had to make the same change on dozens of lines? Now you can do it in seconds.
Now of course, replaying a sentence, or several sentences, is also a sentence of its own that you can replay in another file if you want.
It's neat. :)