ti_ranger

Maybe AWS should put their dashboards on GCP

Then the status page would be almost entirely useless ...

Yes but only if you initiate a claim and follow their steps. Check out these onerous terms:

There's most likely a reason for this.

Like, maybe in the past AWS customers have tried claiming for SLA credits for incidents that didn't impact them, in order to reduce their bill.

It is kind of perplexing that AWS dogfoods its own status page.

You'd think they would have learned from that.

They did.

The page has been updated numerous times since the start of this incident.

instead of spending 10x on (taxpaying) staff and employees within the UK, in order to create a new technology that may be useful and solve other problems, they are spending 1x on Amazon.

You imply that Amazon/AWS doesn't employ any staff in the UK, which is wrong.

Amazon will not pay any tax within the UK

Amazon must certainly pay taxes in the UK, or at least the tax ends up being paid on Amazon share price increases from employees share vesting.

For my own startup, I built a small cluster of 17 servers for just beneath $55K, and that had a month-to-month expense of $600 placed in a co-lo. In comparison, the same setup at AWS would be $96K per month.

Why would you build exactly the same setup in AWS as for on-prem, unless your objective is to (dishonestly) show that on-prem is cheaper?

Lift-and-shift-to-the-cloud is known to be more expensive, because you aren't taking advantage of the features available to you which would allow you to reduce your costs.

When determining what to use for development of my SaaS, I did a comparison of what you actually get from providers. The full article is at https://jan.rychter.com/enblog/cloud-server-cpu-performance-...

Your results (e.g. that z1d.xlarge with 4 vCPUs is only 10% slower than z1d.2xlarge with 8 vCPUs) shows that the "performance" you were testing was disk IO throughput (probably dominated by disk latency), not vCPUs.

My takeaways were that many cloud provider offerings make no sense whatsoever, and that Xeon processors are mostly great if you are a cloud provider and want to offer overbooked "vCPUs".

I haven't tested those specific setups, but I strongly suspect a dedicated server from OVH is much faster than a 4.16xlarge from AWS.

You seem to be implying that AWS/EC2 does CPU over-provisioning on all instance types; this is incorrect, only T-family instance types use CPU over-provisioning.

Is this because ISP's can see DNS traffic? as it's in the clear over UDP...

Not necessarily.

It could very easily be done via IP address matching (think BGP communities that advertise specific subnets between one part of a network and another, as are typically used for optimal CDN routing etc.).

That's impossible.

In my country, our anti-ISP media claims that we have the most expensive internet in the world, but 10/5Mbps FTTH (in most cases with free upgrades to 20/2Mbps for the duration of COVID-19 WFH guidance mandated by the government) is quite commonly available at < $20-$25/month, and where it isn't, 10/1Mbps ADSL is available for $25-$30/month (including POTS voice service).

Thus, it is impossible that you, in the country of ~$20 1Gbps service, have worse and more expensive service.

</sarcasm>

In my opinion, there is really only one valid complaint in the article:

We need more choices for our ISPs

If you fix this, e.g. by requiring all last-mile owners to offer the last-mile access at or below their (audited, sufficiently-profitable) input cost to their retail products, most of the remaining problems would sort themselves out, without having micro-managing of ISP features.

Unless you are going to start regulating OTTs in what features/value they can provide, I think it's unfair on (non-monopoly) ISPs to prevent them from providing innovative features because of "net neutrality should trump all" opinions.

Actually, maybe it's more the fact that at a prominent tech company: * zsh is the default shell on a large proportion of servers that have read-only /home, so you can't easily change to your preferred shell * a training guide that many new developers follows states incorrectly that:

If you are using Bash and you have the option of using ZSH, you should switch to it. ZSH has additional auto-complete and history features that Bash doesn’t have (but don't worry - those features will not be relevant to this tutorial.)

oh-my-zsh seems to be recommended by a lot of developers in this company, even though: * the default mechanism to install is curl|sh (there is no Homebrew package) on developer machines which have privileged access to a lot of resources * installing it via its recommended installation procedure on dev machines would violate company policies, whereas installing bash-completion wouldn't

Sorry, but I've read too many posts that say "bash sucks, it doesn't do <thing that bash has done for years before zsh did it> like zsh does".

Also what can bash do that zsh can’t?

I have noticed that a lot of the features listed in https://www.gnu.org/software/bash/manual/bash.html#Major-Dif... aren't present in zsh, but I am not sure of all the ones that aren't in zsh.

Ones that I have used in bash that aren't in zsh (there may be many more, I stopped using zsh in many scenarios because of some of these):

* Some of https://www.gnu.org/software/bash/manual/bash.html#Shell-Par... (e.g at least ${LOGNAME^^}, `(FOO=BAR;echo ${FOO,,})`)

* -p option to read for the prompt, e.g. `read -s -p "Enter the DB password: " PW`

This is one of my primary dislikes of zsh ...

- Oh-my-zsh has a lot of plugins for auto-completion

As does bash-completion, which is available in many (but not all :-/) Linux distros and via Homebrew on MacOS and [pre-dates](https://github.com/scop/bash-completion/tree/09b07d57a7031d9...) [oh-my-zsh](https://github.com/ohmyzsh/ohmyzsh/tree/5da20b9dddb1f7a91106...) by about 6 years.

But, zsh users and oh-my-zsh fan-boys seem to be entirely ignorant of bash-completion.

For simple graph diagrams it's easy enough to open up a separate graphviz .dot file, write up a graph specification, run it through dot or neato, and include the .png in your markdown file. And then automate this with a Makefile.

Or just use zim ( https://zim-wiki.org/ ) which allows you to embed graphviz diagrams in any 'page', and many other features.

Some examples of this would be Oracle Identity Manager (which is absolutely awful but is still actually the only IdM solution really capable of scaling with massive enterprise companies)

The "massive enterprise company" I work for doesn't use Oracle IdM ...

It was used at the previous company I worked for, but it had endless problems and I think it was only bought as part of a very badly-run "buy an expensive 'enterprise content management platform and then not use it properly' initiative".

It's main feature seemed to be to import identities from LDAP servers into an Oracle database fronted by a very poorly performing non-compliant LDAP server (or, you could say, selling Oracle Database licenses).

Also added option to export a VM to the cloud using the more efficient variant "paravirtialized"

So they don't seem to be very serious about multi-tenancy?

(Spectre and Meltdown are more or less considered the nails in the coffin of Xen para-virtualisation for multi-tenant environments).

it apparently began the internal renewal process at the exact instant the cert expired (rather than 30 days in advance as is common with ACME-based renewal).

Was this some time ago?

The FAQ for ACM (https://aws.amazon.com/certificate-manager/faqs/ ) says:

Q: When does ACM renew certificates? ACM begins the renewal process up to 60 days prior to the certificate’s expiration date. The validity period for ACM certificates is currently 13 months. Refer to the ACM User Guide for more information about managed renewal.

We switched TLS termination from the load balancer to Envoy + cert-manager and the results were much better. You also get HTTP/2 out of the deal. We also wrote a thing that fetches every https host and makes sure the certificate works, and fed the expiration times in prometheus to actually be alerted when rotation is broken. Both are features Amazon should support out of the box for the $20/month + $$/gigabyte you pay them for a TLS-terminating load balancer.

You're implying that AWS doesn't support HTTP/2 on any load-balancers they offer, but ALB has supported HTTP/2 since launch ( https://aws.amazon.com/blogs/aws/new-aws-application-load-ba... ) 3 years ago.

I don't see any current load-balancer priced at $20/month (ALB, NLB and Classic ELB are all ~ $8/month), so I can't guess which one you were using here ...

A t3.large only has a "baseline performance" of 30%

Instead, I'd compare e2-std-2 to m5.large like you started to do so.

Yes, a "baseline performance" of 100% would more or less be an M-family instance, but with additional overhead to manage noisy neighbors etc. (and thus T-family is slightly more expensive for the same constant performance than M-family). T-family is specifically for non-constant workloads where CPU over-commit provides value, but without memory over-commit, which can result in highly-variable performance.

Neither T-family or M-family do "memory stealing" aka memory overcommit, like GCP's E2 seemingly does (but the pricing page doesn't explicitly state this, and your detailed comparisons omit this crucial difference).

So, apples and oranges; you shouldn't really "compare" without benchmarking ...

What is the "baseline" memory GCP E2 instances get?

This is already possible on ESXi with Linux guests for years now, so it’s certainly a solved problem in some capacity.

And has been possible on KVM (e.g. VirtManager, RHV/RHEV/Ovirt) for years too.

Xen 3 also supported online memory increases (but I don't think CPU).

Still no live VM migrations?

Based on what evidence? Statements from Google that AWS doesn't do live migration?

We take on the statistical multiplexing over the datacenter and move VMs around

You're implying here that EC2 doesn't do this.

On what basis?

I've spend 1 minute skimming some of the docs, but it's unclear whether these tools can do a better job than the docker-like tooling. The vmadm "build an image from scratch with a json file" doesn't help in building Hadoop any more than the oldest versions of docker did using a minimal image and a Dockerfile.

How does provide visibility into every dependency inside an image? Especially when using 3rd-party-maintained images that consist of significant hours of work per image to get the image to work.

(BTW., I built "live CD images" for use in physical and virtual machines since ~2001, using tools such as mklivecd, livecd-tools etc.).

Actually, the post was written by someone located outside the U.S. (a place not using any US-specific time-zone), and posted to the status page by someone else located outside the U.S.

We see numerous problems with AWS services including but not limited to being unable to create new EC2 instances in any AZ.

How were you launching? Using EC2 directly (e.g. `aws ec2` cli or RunInstances API call - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_R... ), or using e.g. ASGs?

If you were launching directly with EC2, were you doing targeted launches (e.g. specifying Placement.AvailabilityZone for classic or SubnetId for VPC)?

In the case of an AZ failure, launches which don't specify an AvailabilityZone or SubnetId may be impacted for a few minutes, whereas launches which do specify them should still succeed.

I just don't like how much power the project holds over the entire linux ecosystem ("oh hey here's systemd-logind don't mind us taking over all-things-login"-type scenarios)

That's totally not the case, all the previous solutions were slightly broken (pam_console, ConsoleKit etc.), and unmaintained.

For the record, my largest gripe with systemd is systemd-resolved too

So, uninstall it. It's not a part of systemd (the daemon), and totally optional.

Many things about Linux would be easier if we standardized on only one implementation of each thing rather than multiple competing implementations (e.g. only one desktop environment, only one text editor). But we would also lose everything that makes Linux great.

Sure, but there is nothing inherent about a text editor or desktop environment that results in you only being able to support one at a time.

It is only practical to run one system initialisation daemon on one system image at a time (unless your system initialisation daemon is too broken to support all the requirements, e.g. if you find yourself running daemontools on sysvinit).

Duplication for the sake of duplication that benefits no-one is just a waste of resources that could be spent on improving other parts of the ecosystem (addressing some of the other gripes the author has).

There are any number of major security vulnerabilities, but that's not really the point.

There are only about 2 in systemd itself.

There are any number of major security vulnerabilities, but that's not really the point.

systemd has fewer CVEs than the default syslog implementation used on most distros before systemd (rsyslog), but of course you knew I was referring to open bug reports, not resolved ones.

to a non-standardised binary logging daemon

There are pros and cons to this. I would prefer to be able to dispense with journald in some situations, but in many cases it is very convenient to have, and it solves problems that no Unix system had completely solved before it.

Most of the really obnoxious things systemd does are by design so there are no bug reports. Tight coupling to kernel and udev versions

When tight coupling is done by the BSDs, it is considered a good thing, when systemd uses features that don't exist on the BSDs, suddenly that's a bad thing ...

to a custom DNS implementation...

While a custom DNS resolver is provided as part of the systemd source, which has some advantages, it is by no means a requirement, and it a totally separate service/binary. Many distros don't install it by default (yet).

What is the situation for "reproduce a currently-installed system from a list of packages (including version/release if relevant) and a tarball/git checkout/package-deployment/puppet run etc. of configs"?

As far as I know, on most BSDs, unless you happen to have a complete source tree snapshot for said system (becoming more difficult to maintain if you build multiple systems without special tricks to retain binary artifacts), you're out of luck, you'll get today's STABLE or RELEASE, not the one from 17 days ago when your current production box was built that works perfectly unlike the one today that is broken.

This is trivial to accomplish on all Linux distros.

(I would say this kind of issue should be listed in the table in the article).

The systemd debacle is what led me down a rabbit hole toward the BSD's.

As far as I can tell (not actually using Debian or Ubuntu myself), there was only a debacle in Debian and Ubuntu, because they took too long to decide, and ended up having to rush their migration.

All the other distros, that had better-planned migrations (Arch, Fedora, SUSE, etc. etc. etc.) had basically no issues migrating to systemd, and have benefited immensely from being able to ditch the maintenance overhead of diverging init systems and init scripts, all re-implementing the same new features with slightly different implementations due to previous slightly differing implementation details.

People will currently call out OpenRC as the one non-systemd approach that works (e.g. if you acknowledge that SysvInit no longer actually works because no-one uses if for all system initialisation, instead leting it delegate lots of control to other bits and pieces), but before systemd won, there were: * SysVinit + RH-derived initscripts * Sysvinit + SUSE-style initscripts * Upstart * OpenRC * prcsys - parallel rc system (Mandrake and derivatives)

All of these had similarities, and small differences, e.g. they all tried to support dependency information in init script headers.

As a sysadmin, it was frustrating to: * Have to read every init script to see where it read its defaults from, was it /etc/sysconfig/pkgname or /etc/default/daemonname . Did it support setting limits from the defaults file, or would you have to hack the script to support your bigger-than-the-maintainer-imagined environment. * Debug where the application was logging to, if it didn't setup logging correctly by default.

As a maintainer of a package used on more than one distro, it was difficult to: * Test your init script to ensure it worked on RH-based distros and SUSE and Debian and Ubuntu. While Upstart said it supports init scripts, it fails in some random way that doesn't occur on RH and SUSE. * Setup logging correctly, as not all distros provided a helper script to setup the right logging daemon (syslogd, vs rsyslog vs syslog-ng etc.)

We won't talk about the more modern features such as cgroups etc., where only about 2 init systems support the feature adequately, and no distro or packager actually managed to support such advanced features on more than one init system, and certainly not more than one non-systemd system.

systemd mainly stays out of my way, but makes it easy to troubleshoot and customise daemon behaviour in a consistent fashion.

But trying to wrap your head around systemd in even a few hours isn't reasonable.

You don't need to wrap your head around systemd to do things with it that you would really struggle to do with any other init system. But, you've probably been too busy fighting it, or trying to prove why it's worse, rather than trying to do real things with it, or you would be able to point to valid bug reports.

The proof in the pudding for me is to look at the running processes of a default system between BSD and Linux with systemd. Yikes.

You're comparing apples and oranges here, you should rather be comparing two release of the same distro, before and after systemd became the default, and you would have seen very little difference.

What people use in those sitations is Anycast.

This requires that you blow a publicly-advertisable prefix for every unique combination of services you would want to fail-over.

E.g., if you wanted to be able to have independent fail-over between your customer-facing self-service portal and your webmail interface (each relying on specific state that you can't replicate synchronously, and can't guarantee replicate consistently with each other), you would need to /24s, one dedicated to anycast for the webmail interface, one for the self-service portal, and separate from any services which are active-active.

Whereas using DNS, you could use your other existing public /24s that you are already using for your active-active services.

In the last days of IPv4, an extra 2 /24s just for this is quite an expense.