I selfhost for >10 years, but only for receiving, i.e. I can not send anything from my domain, because I thought that would have been to much stress to set up.
My setup: I have a root server with DNS attached to it. On there is a postfix, with a minimal config that forwards all emails to my real address on posteo.eu. And posteo has not given me any trouble with any of my emails at all.
I use this setup, so I can easily give new email-addresses to individual web services, and it gives me the option to selectively block these addresses.
Last year I brought the big abo from proton, which includes throwaway mailadresses, and I am thinking about migrating my mail setup there.
> No one buys a Porsche because they want a sensible car for their family or they need something with large storage
I know two porsche-owners personally. One sometimes uses his porsche (non SUV, but the small fast one) to go on family vacations (with the kids cramped at the too small back seats, which seems funny to me). The other has an SUV and lives in the country with bad roads; They sometimes use their porsche to commute to work and for everyday-stuff like shopping.
> The other has an SUV and lives in the country with bad roads; They sometimes use their porsche to commute to work and for everyday-stuff like shopping.
That blows my mind.
I guess its the same mindset as people who buy a mercedes "jeep" (don't know the product id) or range rover and live the middle of the city.
They kind of spoke to it. Rebasing to bring in changes from main to a feature branch which is a bit longer running keeps all your changes together.
All the commits for your feature get popped on top the commits you brought in from main. When you are putting together your PR you can more easily squash your commits together and fix up your commit history before putting it out for review.
It is a preference thing for sure but I fall into the atomic, self contained, commits camp and rebase workflows make that much cleaner in my opinion. I have worked with both on large teams and I like rebase more but each have their own tradeoffs
Yes but specifically with a rebase merge the commits aren’t interleaved with the commits brought in from mainline like they are with a merge commit.
EDIT: I may have read more into GPs post but on teams that I have been on that used merge commits we did this flow as well where we merged from main before a PR. Resolving conflicts in the feature branch. So that workflow isn’t unique to using rebase.
But using rebase to do this lets you later more easily rewrite history to cleanup the commits for the feature development.
You'll still get interleaved commits. If I work on a branch for a week, committing daily and merging daily from main, when I merge to main, git log will show one commit of mine, then 3 from someone else, then another of mine, etc. The real history of the main branch is that all my commits went in at the same time, after seven days, even if some of them were much older. Rebase tells the real story in this case, merge does not.
That's because the unannounced firedrills don't involve setting the building on fire. A "drill" equivalent would be if we all pretended the internet is down sometimes, and in some cases that still might be impossible to do without negative consequences.
I like to browse HN via "/front" and "Go back day" and then look at the couple of top posts for each day. I don't see such a day-by-day view on TPE.
What is the "official" acronym? TPE? TP? TecPeu?
What is language policy? (e.g. it would be nice if people would post any language they want, and the system shows other users what language the link is, and then offers an alternative link to a translated version. I imagine this would be hard to implement in a way that is robust way, but maybe you when user submit a link, they can set the language themselves)
> Consolidating streaming services down to a handful of offerings will make price competition more fierce because they'll have richer catalogs to do battle with.
Correct, but the current market is not working. 15+ streaming services is terrible for consumers. Catalogs are compromised. Bigger services can push prices up because they have more stuff. Clearly if there are too few players then there's less competition and no price pressure, but there's a sweet spot between what exists today and that.
Youtube, Android and Google Maps got better (and became financially viable at all) when Google bought them. Github got better and cheaper when Microsoft bought it.
I'm not necessarily talking about the product itself getting better, I'm talking about the overall consumer situation being better.
All these products were acquired very early in their lifespans, so them getting "better" was practically inevitable.
GitHub's acquisition effectively took at least one competitor off the market. Now, Microsoft doesn't have to seriously develop a competitor, they just bought their competitor and adopted it. They never had to improve Azure DevOps (VSTS) enough to be attractive, they just bought the market leader. If GitHub was never acquired, my company might be deciding between BitBucket, Gitlab, GitHub, and Azure Repos. Instead, Azure Repos is more of a niche offering where most of Microsoft's effort has focused on GitHub. Microsoft removed an option which likely raised prices or reduced user choice.
Google Maps was acquired in basically a prototype stage before it was ever a public product, so that case is irrelevant.
Android is worse in a number of ways due to Google's integration. Google Play Services APIs and other Google technologies have led to heavy Google lock-in. If Android continued as its own project, it would have been much more vendor-agnostic.
In the case of YouTube, I'd argue it's worse in a number of key ways: ads are wildly pervasive (sure, monetization would have had to happen anyway in some fashion), many of the platform changes are user-hostile (removed dislike count, background playback limited to premium subscription), content moderation more heavily influenced by Google's advertisement-based business model (e.g., if YouTube had continued on its own, it might have chosen a different monetization strategy less advertisement oriented, but Google is an advertisement company. Advertisers are more sensitive to their products being presented next to objectionable content) and competitors were snuffed out due to ecosystem integration (YouTube videos as Google search results rather than agnostic video results).
Remember the era where YouTube got extremely badly integrated in to Google+ and basically forced you to use it? That was a pretty terrible user experience.
Piracy is seeing a big uptick because streaming increasingly sucks. 10+ years ago before studios started chasing their own streaming platforms, and Netflix was the only game in town, it was an excellent deal. $10ish, as opposed to $50+ for cable (might be low on the cable subscription - I never had one).
If you wanted an equivalent catalog today, you'd need at least 3 or 4 streaming services, and you're paying $50+ or so. Netflix + WB (inc HBO) surely gets them back to roughly where they were. Will Netflix jack up their rates on the back of this acquisition? Inevitably, but I think they'll have a very hard time approaching a similar monthly rate. My gut says that they'll have a hard time getting beyond $30, with Disney and Youtube anchoring in the low teens. So, for the consumer, it's a win. For competing studios, of course, not so much.
You're assuming a free market working perfectly would bring the price down, but the free market is kneecapped by stupid and arbitrary licensing and IP games, which is the result desperate overreach of an industry hanging on by its fingernails as its business model has been upended multiple times over during the past 2 1/2 decades. But as we used to say about the music industry while happily napstering, your broken business model is not my problem.
reply