No, concede is to admit defeat, cede is to give up something. You could concede the battle, and as a result cede land to the victor. I meant cede.

While my comment was certainly controversial, the number of up-votes from users in the Fediverse means it shouldn’t be ignored, either.

Luckily embarrassment is controlled by the person feeling it, and I seem to have a severe lack of that gene 😆

Oh yea, I just mean that all markdown characters are ASCII, and thus allowed in a plain text field. 😉

Only paid ones. Theoretically could impact Brave, for instance.

Markdown is plain text, so it’s fine to go in the field. It’s also fine for apps to allow OP’s post to look like garbage because there’s no requirement for support.

Great, thank you.

Yea your edit is the problem unfortunately. Moving across datasets would incur disk reads/writes and sending of terabytes of data.

The goal in separating them out is because I want to be able to independently zfs send folder 1 somewhere without including folder 2. Poor choice of dataset layout when I built the array.

In strict definition, true, but to those in the US cede has the connotation of giving up something after a lost battle. Just the way we’re taught.

And I don’t use them, either. I’m a contributor to multiple Fediverse projects, including Lemmy-based apps and full identity management with ActivityPub. We do not deserve to get held to lower standards if we want the Fediverse to grow, especially when it comes to features that are about things like eye comfort, which can be a mild accessibility issue for some.

Dark mode is a basic necessity in apps today. It’s not a convenience, but a necessity for adoption. There are many people who are going to open the app, then never use it again because of something that’s bog-standard in the libraries and should only take a few hours to work in, which should have been done before an announcement.

So yes, I speak up, because I want this to succeed.

Edit: And yes, I’m very excited to see the growth achieved in the other post. Fantastic news.

@corsicanguppy@lemmy.ca, @'ing you so I’m not responding in two places 😉 I appreciate the work of the team, but it doesnt change the fact that to many, this is a showstopper and I’m pretty surprised it wasn’t considered as a basic UX requirement pre-launch (see other comments in response to you).

Please update the title to the full title of the article. This is super misleading and makes it sound like the founder doesn’t want this.

IMO, a personal landlord is rarely evil unless they’ve made a job of it.

No dark mode, no use.

It never happens in ranked in Rivals.

Pretty sure that’s not what he meant in the podcast.

Wut?

123 active Software Engineering jobs listed.

Backblaze of course, but we aren’t talking about the probability of seeing a failure, but of one of your disks failing, and more importantly, data loss. A binomial probability distribution is a simplified way to see the scenario.

Let’s pretend all disks have a failure rate of 2% in year one.

If you have 2 disks, your probability of each disk failing is 2%. The first disk in that array is 2%, and the second is 2%. If 2 disks fail in Z1, you lose data. This isn’t a 1% (half) chance, because the failure rate of one disk does not impact the other, however the risk is less than 2%.

So we use a binomial probability distribution to get more accurate, which would be .02 prob in year one with 2 trials, and 2 failures making a cumulative probability of .0004 for data loss.

If you have 6 disks, your probability of each disk failing is also 2%. The first disk in that array is 2%, the second is 2%, so on and so forth. With 6 disk Z2, three must fail to lose data, reducing your risk further (not to .08%, but lower than Z1).

So with a binomial probability distribution, this would be .02 prob with 6 trials, and 3 failures making a cumulative probability of .00015 for data loss.

Thats a significantly smaller risk. The other interesting part is the difference in probability of one disk failing in a 6 disk array than a 2 disk array is not 3x, but is actually barely any difference at all, because the 2% failure rate is independent. And this doesn’t even take into account large disks have a greater failure rate to start.

I’m not saying mirroring two larger disks is a bad idea, just that there are tradeoffs and the risk is much greater.

I would do this.

And then only play Rocket League.

Hate to be that guy, but those maths aren’t mathing.

Less drives does not equal less chance of multiple failures. The statistical failure rate of one drive has no impact on another. In fact, analysis of Backblaze’s data showed that larger drives were more prone to failure (platter density vs platter count).

Thank you.

As someone who runs 3 large arrays with 8TB, 16TB, and 21TB drives respectively, know that:

• RAIDZ1 will cause tons of fear when a disk fails if you’re used to Z2. Don’t change.
• When a disk goes, the larger the disk, the slower the rebuild time, and the more taxing it is on the other disks. With Z1, if another fails during the rebiluild, you’re SOL.

Less disks is simpler, but more disks is safer. 6 disks is the perfect sized array IMO. If you don’t need more space, I’d buy a 2TB hot spare and call it a day. But if space is a concern, Z2 with 4 disks.

Edit: Those three arrays mirror each other in different locations, and the fear was still there when the Z1 had an issue. Mostly due to the headache, but still.