pm7's comments

I think in future devices are supposed to support as many popular functions as possible. Due to trend of thin devices we need smaller ports and fewer of them. Multiple possible use of same ports helps.

> As a user there is no easy way for me to tell the 12-inch Macbook's USB-C port is different than the Air/Pro unless you explicitly search for it in the tech specs

Seems like manufacturer failure.

> If you see an HDMI port on a laptop you can be sure it's going to output some kind of video signal over that.

But even HDMI/DP have versions. It's especially visible now, as we have >=4k HDR high-frequency displays.

Backup is much more important than RAID in most situations. RAID doesn't protect from user error, virus, fire, etc.

I think Windows does remind to create backup (but not very loudly and it accepts local backups to another drive which is poor solution).

Unfortunately, almost everything is cheapest possible. For example, I would prefer ECC RAM as standard. It's very cheap for production (one additional chip per RAM stick), but Intel wants to force people wanting reliability to pay for Xeon CPU and most people don't care.

I'm sorry, was my message unclear? There were no assumptions.

I'm speaking from experience that when I was using Debian testing I would usually receive security updates days after they are available for Debian stable.

Obviously security updates for stable do not go through normal release cycle.

I wasn't commenting stable security updates, but lack of timely access to security updates on testing.

Yes, there are downsides to federation, but I would argue spam is not inherent to federated communication.

There are many ideas to stop spam like proof of work.

Main reason for spam in email and PSTN is legacy protocols, which were created long time ago and cannot be significantly improved without breaking compatibility.

Let's give Facebook full control over worlds communication? And allow them to cut people off from communicating with anyone? I don't think it's great idea.

We really need federated communicator.

I used testing for many years without reinstalling.

I simplified a bit. Yes, Debian testing gets new updates, which means it gets security updates. Eventually. It can (and does) take days for critical security updates to migrate from unstable to testing after stable has access to patched version.

https://www.debian.org/security/faq.en.html#testing

> there is a minimum two-day migration delay

See this comment: https://news.ycombinator.com/item?id=21492080

Also, this: https://www.debian.org/security/faq.en.html#testing

> there is a minimum two-day migration delay

Unfortunately, Debian testing doesn't get security updates.

Or just apt install docker.io

https://packages.debian.org/search?keywords=docker.io

User should not use IP addresses. This is what we have DNS and mDNS for. In special cases, like local router if mDNS is unavailable, IPv6 address is even easier than IPv4 (compare "FE80::1" to "192.168.0.1").

Anyway, it's not like it's a choice unless you want to restrict who deserves public IP and who doesn't, because we do not have enough IPv4 for everyone.

But if services will need to use one big file, we won't have possibility to overcommit disk space (unless they implement something like TRIM).

> Keeping IPv4 alive today doesn't hinder progress

Because many users/services have only IPv4, practically all services and ISP have to provide IPv4 and do not have to provide IPv6. If we could agree to kill IPv4 at specific date, we could have truly IPv6 Internet years ago.

Really? I used bvyhe on FreeNAS and it was awful comparing to KVM or ESXi.

Professional might be different. I can personally confirm this issue on Home, version 1903-v2.

Latest 1903-v2 "Home" version does not have offline account button without being offline. I had displeasure of configuring it two days ago.

See screenshot here: https://www.extremetech.com/computing/295445-microsoft-reall...

> Even the backups where corrupt due to being backed up in encrypted images. When encrypted volumes and images are corrupted by RAM or power-failure, they are locked forever.

That sounds more like issue with backup procedure (and testing of backups), even if it was amplified by encryption.

> Of course one should never force root access, I'm saying that you can't keep out the hosting from access the server in that case.

LXC and especially OpenVZ containers seems to be replaced by KVM in hosting/cloud. Of course, it's still possible to attack VM as host has control over VM's memory. Even dedicated servers are potentially vulnerable to attacks like cold boot.

> In one incident it was using ECC RAM

Did it at least warn about issues or was it ignored?

> I mean that encryption puts the entire data-store at risk, I've seen it happen more than twice due to RAM being faulty (In one incident it was using ECC RAM) and a power-failure.

How can this cause data loss? Header containing encryption key should not change during normal work. Did it just corrupt writes?

I know, but these flags have to be set by provider of container, not user (provider of VPN). And they might require changes in kernel.

> given that all of the nginx files are not in a single directory it's my understanding that you'd need multiple COPY commands

Workaround would be to move these files to one directory on host, COPY it in one command to /tmp (or even better, /dev/shm or other ramdisk) and then use script to distribute files where needed.

> Least expensive should be zero compute in cloud unless there is issue with collocation.

One more thing: cloud can be great to scale up in peak utility without buying servers that will idle most of the time. It's just that using only cloud might be much more costly, even if it is easier.