but you present your “wide populace” fact without giving sources too

my statement is not that many people are using passkeys today. but that if there comes a time when many people will use passkeys, they will be as careless and convenient as they are with everything else today, accepting any restrictions, because “why would anyone not use Google Passkeys? It’s the most convenient thing!”.

and not only that. I was talking about device locking but that’s only part of the problem. isn’t it that passkey receiving services can identify the client software, and decide they will only accept passkeys from x and y clients?

wait, did Godot enshittify?

what were the questions to which they gave those responses? It’s really not clear. link the source.

element was very buggy a few years ago. the new clients are just now starting to get feature parity, and in my experience calls are still quite unstable, requiring your server to have some specific additional setup (which most public registration instances don’t have), besides that not a lot of clients have implemented yet MatrixRTC calls. even the client list on matrix.org is only showing whether a client supports the former calling system.

so for the layman it’s definitely not production ready yet. and even for new tech literate users some of the things are still challenging to figure out.

but it’s so much easier to grab torches and pitchforks than to read an announcement

except when the wide populace starts accepting it being device locked, and your opinion does not matter anymore to those making the decisions

namely the VC funding and the huge resource hungry clients to me

wasn’t there a DB conversion document?

the debian cve tracker also links to that page, but they have written 7.0-rc7 besides it.

https://security-tracker.debian.org/tracker/CVE-2026-31431

the openwall link has some comments that talk about the delayed patches, Greg KH also commented.

and the patch to the kernel was commited on 1th of April.

are you sure? what I have seen in git patch dates is 11th for the unreleased 7.0, and yesterday for the LTS versions

tbh they could have boasted even less bytes by just having everything in a zlib.decompress()

I think they mentioned issues and pull requests

last year when Serinus changed the moderation policy that the “narrative” that trans people are not real or are mentally ill or whatever to not be considered hate speech and thus not to be removed automatically, following the similar change at Facebook.

wow, that’s wild. they do have quite a few highly questionable decisions, to put it gently. maybe we should treat them like we do .ml, and encourage people to move to other instances, while generally not participating in their communities

this defense edit does not make sense. no, volunteer foss engineers don’t need to stay clear of popular projects. if the allegations in the replies are true, I’m genuinely sorry for that, but that’s not a risk of being a foss developer, that is a risk of discussing on the internet.

if people are harassing you, you should report them to the admins.

this shit stirrer ex-googler really does not understand the signals people are giving… apparently the community response is “hilarious”, the moderators removing their toots at both instances are “overzealous” for acting upon multiple reports and giving a proper hilarious removal reason.

“everyone is dumb but me!” lol… (not a quote)

this person is really butthurt that people are telling them they have acted very irresponsibly.

or didn’t have a defense against a 0 day.

firewalls are not for defending against 0 days. it is about access control, and reducing, sometimes even minimizing access to potentially vulnerable services. firewalls are not an infallible security tool, but there is no such thing either. the reason to use it is to restrict access such that fewer attackers can take advantage of a potential vulnerability.

there are intrusion detection/prevention systems that could do more, but it’s unlikely they will protect against 0 days, because 0 days are undiscovered and unknown issues.

So the vlan doesn’t do anything either way.

it does. its useful to force traffic through a firewall. its for limiting what has access to what. if you wouldn’t use vlans, hosts on the network would not care about your firewall because they can just go straight to the destination.

I’m not sure I understand your argument, but I think what you say is, firewalls are not infallible so they are useless

Then I was not sure what you meant by this:

I don’t actually know if this is the right way to calculate it, but if for each disk you count the time separately, and add it together for a combined MTBF, then that is 20 out of the 136 MTBF years.

5 years of drive runtime for one drive. 20 “years” for 4 drives, 40 “years” for 8 drives. I say “years” because the way I mean it is like this: running 4 drives for 10 minutes is 40 minutes of combined drive runtime. running 4 drives for 5 years is 20 years of drive runtime. I think calculating it like this can be compared to MTBF. but again, I’m not totally confident that it really works this way.

All in all, I am at this point only trying to track down and relay what I’m seeing about SAS vs SATA.

I think it might be because SATA drives you normally run across, especially in laptops, are not the enterprise kind, but consumer drives built from cheaper components and simpler designs. and those are lower quality. while SAS drives are always enterprise grade.

but still, in my experience SATA drives can have a long life too. but it may be more unpredictable than enterprise SATA/SAS drives

HP says that SAS is more reliable

could be controller chips and cable quality. but also, SFF-8644 type SAS connector can be used to attach a drive to multiple HBA cards as I heard, maybe even multiple machines, for redundancy

if you allowed that to happen you either did not set firewall rules strict enough, or if the client doing the compromise absolutely had to have access to the vulnerable service then you did everything you could to limit the chance of it happening.

usually the solution to that is to limit who can access what more strictly. dont allow user devices like smartphones on the iot vlan, as any app running on the phone could be doing nefarious things. only allow the iot devices and the home assistant service on the iot vlan, and user devices will only talk to home assistant, something supposedly more secure than whatever iot devices there are.
similarly, don’t allow user devices to access the ip cameras. put the ip cameras on a network where only the NVR software can access them, and user devices will only access the NVR. if you can, don’t put the whole operating system of these services on the iot and ipcam vlans either. this is possible when the services run in containers, because you can pass in only vlan specific interfaces to the containers. if not using containers, you can still use the operating systems firewall to filter incoming traffic.

if you set up proper network filtering, the “if” in “If your firewall couldn’t stop it” will become a pretty big “if”

I’m a repair depot I typically didn’t see drives that live much longer than 17k hours (just under 2 years).

I have a bunch of working drives with 2+ years, and in my area almost everyone still has their system installed on old hard drives

that it would be difficult to project an average lifetime of 20 years

I did not mean an average timeline of 20 years

that when Backblaze mentions consumer vs enterprise drives they are possibly discussing SATA vs SAS.

there are plenty of enterprise SATA drives

This comes from the realization that enterprise workstation drives are still just consumer drives with a part number label on them (seen in Dell and HP Enterprise equipment).

that’s workstation drives. Obviously if your work buys 2 TB wd blue drives they won’t become enterprise drives. enterprise drives include like that of wd red pro, ultrastars, etc, which do use the SATA interface.

The security reason generally doesn’t exist for home labs because most need to setup bridging or you can’t access the devices on the secure vlan at all.

bridging can be set up in a limited fashion. it could happen with a firewall doing routing and filtering