pm7

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.

The second "failure" was about small flaws on display (mostly visible on white background). I didn't actually expect them to replace it, but they did.

I've also heard from friends that E7*70 had a bit higher failure rate than usual. It still seems (subjectively) to be much lower than Apple's issue with keyboard. Most importantly, they fixed it almost immediately.

Today, I don't expect things to not break. I'm still annoyed when they do, but more important is what happens after failure, how long (and how much effort) does it take to get things working again.

HPE iLO also had critical vulnerability: CVE-2017-12542.

The interesting thing about OOB on most modern servers is that its a separate, physical NIC. Not only is that easily VLAN able

On lower grade servers OOB is using main NIC. It's still possible (in all implementation I have seen, which is not too many) to have OOB in VLAN.

a more security conscious datacenter could even air-gap the out of band LAN!

1. If you air-gap remote management, you take away it's function.

2. It's not possible to truly air-gap OOB if servers with OOB are not air-gapped (it's theoretically possible to use server to get into OOB network by exploiting/flashing custom OOB from OS).

I doubt serious VPN provider are using LXC/OpenVZ containers. They don't even work with OpenVPN without special setup from provider, I don't know how about other protocols.

I guess Clodflare one is only for mobile?

Yes, unfortunately it's currently not possible to use Warp VPN on PC. Otherwise, quite good service.

https://airvpn.org/ is also worth mentioning.

Do you have any good list of such actions?

Hmm. I read the comment as saying “no cloud, because you’ll save so much by just being on-prem”. And I think an “apples-to-apples” comparison requires an N+1 setup including both compute and networking.

That is valid interpretation. I just wanted to say that is you need high availability it might be cheaper to have one colocation and cloud in standby.

Hybrid could be many different setups, but before their “zonal affinity” change it would actually be worse, right? (Egress over Direct Connect is 4x higher than Zone to Zone, while “internet” egress is 8x).

Yes, in/out traffic would be one of more problematic points of such setup, but there should be some solutions available (BGP?).

What are you assuming for the balance of Compute and Networking across at least three “sites”?

Least expensive should be zero compute in cloud unless there is issue with collocation. Depending on specific scenario, some storage/databases would have replication to cloud. I don't know how I would setup networking in such case.

@Leace

I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario.

That's completely different thing. Multi-stage builds are great for separating build environment from production environment, but if you need several layers for production environment, they won't be squashed. See here: https://github.com/docker/compose/issues/4235#issuecomment-3...

They'll send a technician to your location (typically within the week) and replace whatever parts needed for free.

My Dell Latitude had included "next business day" 3 years warranty. I used it twice (to get motherboard and display replaced) and they sent technician next working day. There were a bit more failures then I would expect, but warranty was great and I happily bought 2 more years (5 years total) for equivalent of about 200 USD plus tax.

Did you try to open T470/T480 (maybe T490)? There are awful latches which are integrated in case, so quite expensive to replace.