Yes, everything internally has many flags (hundreds or thousands), so much so that they raise the command line size limit (ARG_MAX) in the kernel. I think it was around 2GB when I left. The internal frameworks really encourage using flags too, there's a @Flag decorator for Java that's sprinkled all over the code and sometimes nested extremely deeply down chains of classes that promote this behavior (abseil, (https://abseil.io/docs/cpp/guides/flags) has macros for this too).
We don't have any form of combined finances, each of us deposits our money directly into our own private bank accounts and has our own credit cards. While we, in theory, have access to each other's accounts for the purpose of survivorship; in practice we would never use that access and would consider it a violation of our relationship agreement should a partner chose to use that access.
We split bills though. I take large expenses, like rent and insurance and they take smaller expenses like groceries and dining out. At the start of the year we do a budget of what we project expenses to be based on the prior year (usually takes an hour or so because we both keep good financial records). We then divide that down into a monthly payment such that we're each contributing 50% of our living expenses and they transfer money to me monthly since I'm paying the larger share of the bills. At the end of the year when we budget for the next year we reconcile any differences between budget and reality so that we do in-fact each pay 50% of the living expenses (sometimes this means I give them money, sometimes they give me money). For really large one-off expenses we nominate a partner to take on that expense and the other transfers their share of the money for that expense to the partner taking on the expense. Same story for vacations or trips except we settle that after the fact not before.
It's basically made money a non-issue in our relationship. Their money is theirs and my money is mine, what we chose to do with it is up to us so long as we're contributing our fair share of the living expenses.
Edit: since others are saying this, our relationship is very close and we consider ourselves to be a team but we very explicitly decided when forming our relationship to not have combined finances even though we cohabitate because we had observed that to be a deep point of contention in relationships around us.
BoxOfficeMojo is one of the most cited sources for movie ticket sales info and has lots of interesting data and tables. They paywalled a bunch of cast data a few years back but the title data is still there. https://www.boxofficemojo.com/
I'm one of the maintainers of the cloud images and I can confirm that our goal is to release at least GCP and Azure images in addition to the AWS ones for the 3.14 release cycle. We're also looking for suggestions on other cloud providers for which people would like to see official Alpine images built.
> Interesting to see that the pricing is approximately double that of S3, for what I imagine is not much more than a thin layer on top of it.
There's a lot of necessary complexity in the backing platform. Encrypted package blobs are stored in S3 but there are a bunch of other distributed systems for doing things like package metadata tracking and indexing, upstream repository management, encryption, auditing, access control, package manager front-ends, etc... that are not immediately obvious and add cost. The platform that backs CodeArtifact is far from what I'd call a thin layer on top of S3. There is also a team of humans that operate and expand the platform.
Source: I lead the technical design for the product as well as a chunk of the implementation but left the team around mid-2018.
The back-end is largely package type agnostic and the package manager front-ends are pluggable. I'd look for AWS to expand package manager support in the near future. Nuget was on the list along with a few other popular package managers. There's a whole lot of functionality in the platform they didn't yet expose or have finished for the launch, I'd keep an eye on this as they move forward.
Source: I lead the technical design for the product as well as a chunk of the implementation but left the team mid-2018. I don't have any specific insight into their plans, not that I could really share them even if I did.
Aside from the cryptorouting concept and some convenience functions in wg-quick, Wireguard doesn't really have strong opinions on routing. It's perfectly legitimate to setup an interface with a single peer and global (0.0.0.0/0, ::/0) routes then use BGP to announce networks across it and manage the kernel route tables.
Dell XPS 13" 9370 running Fedora 29 at home 9380 running Ubuntu 18.04 at work. Formerly MacBook Pros. I'd recommend the Dell XPS 9370 and Fedora 29 combo as a decent Mac alternative.
I've run Linux systems for a little over 20 years now and have historically found the Linux laptop experience to be pretty painful, full of driver incompatabilities and other annoyances like non-functional suspend. So when Apple transitioned the Mac to Unix-like OS and Intel chips I hopped on board and was a huge Mac fan. Early on in the 10.x series Mac OS was a great Unix operating system with a nicely functional desktop environment, most stuff just worked without a bunch of hacking. Over the years, though, Apple has been gutting the core of Mac OS and replacing it with their own proprietary APIs that lack Linux compatibility (OpenSSL, OpenGL, OpenCL, etc...). Homebrew and Docker can spackle over some of this but it seems quite a hack, especially given that most production work I do runs on some variant of Linux. At the end of the day most of the tools I use heavily are open source and run on Linux and those that don't have reasonable open source alternatives (1password vs pass, for example) so I migrated.
On the work front I've been using Linux desktops since around 2006 and have been keeping tabs on the desktop experience. It's improved a ton over the past few years. As much as it pains me to say this systemd has helped a lot. In my experience Dell hardware has mostly had decent Linux compatibility because they rely heavily on Intel chips and Intel puts a lot of work into the Linux kernel. The Dell Sputnik hardware has helped even more since the whole system is Linux certified by Dell (well Ubuntu certified, but all the patches make it to upstream) which makes a huge difference for things just working. The unpatched mainline kernel just works on Sputnik hardware without any hacking in my experience.
In my recent experience Fedora is an easier distribution to run because they keep packages very up-to-date whereas Ubuntu has inherited the slower release cadence of Debian. Neither are unpleasant but Fedora has required less configuration to make it work. There are a few minor annoyances so far but nothing that can't be fixed. Suspend defaults to suspend-to-ram, which is IMO wrong but configuring it to suspend-then-hibernate (sleep to RAM for an hour of inactivity then wake up and hibernate to disk/power off) is just a config file edit. Apple accessories (can't break up with my Magic Trackpad) require really recent kernel versions (4.20+) to work reliably and then some X configuration on top of that. The Atheros wireless cards can be a little flaky around suspend/resume/unexpected device behavior (this is Atheros or the driver's fault, hopefully Dell ditches them for Intel soon). Projectors, printing, pretty much everything else has just worked without any issues at all.
