Termination without notice in Germany? That's a major challenge even in situations that warrant it.

It's not flawed. Nobody should get rewarded or encouraged by story points. It's solely a planning metric and not a metric of productivity.

Extremely cheap per kilowatt? Every statistic out there that I've seen and that includes government funding, as well as construction and deconstruction costs, paints a different picture. Nuclear is only competitive with coal or the relatively underdeveloped solar thermal.

In 2017 the US EIA published figures for the average levelized costs per unit of output (LCOE) for generating technologies to be brought online in 2022, as modelled for its Annual Energy Outlook. These show: advanced nuclear, 9.9 ¢/kWh; natural gas, 5.7-10.9 ¢/kWh (depending on technology); and coal with 90% carbon sequestration, 12.3 ¢/kWh (rising to 14 ¢/kWh at 30%). Among the non-dispatchable technologies, LCOE estimates vary widely: wind onshore, 5.2 ¢/kWh; solar PV, 6.7 ¢/kWh; offshore wind, 14.6 ¢/kWh; and solar thermal, 18.4 ¢/kWh.

Emphasis mine, source: https://world-nuclear.org/information-library/economic-aspects/economics-of-nuclear-power

You can implement public or semi public ledgers without Blockchain. That's what banks are doing already by sending huge CSV files internally and externally. Blockchain is not a technology of zero trust. It's close to the opposite. You trust a few peers and blindly trust everyone they trust. That way you trust a network that you know nothing about and if the network decides on a common truth that you are convinced is incorrect, there is nothing you can do about it. The consensus always wins and there is no single entity to complain to and get it fixed. This is great for making sure that many actors need to be bad actors in order to have the whole system fail. It's bad if you don't trust anyone and want to make sure that your standards are always observed. From a technology standpoint I love the concept of Blockchain. But use cases that are not forced are few and far apart. Too few for the amount of hype it receives.

While this is true, the airline could have sold the direct flight that you actually took for more money. You had to pay less because the flight was seemingly inconvenient for you. So in the end you didn't pay for your illegally obtained convenience. You rascal!

Also, Kanban was invented in the 40s as a process for automotive production lines. That's why it aligns so well with maintenance and operations projects in IT. It's ridiculous how more and more people claim it comes from software development and would not fit hardware projects, when that's the core use case of the methodology.

This video might give you a good idea of what's going on behind the scenes and why things are not trivial to get right: https://youtu.be/yGhfUcPjXuE

Two things can be true at the same time.

Too little, too late. This has been ignored for far too long.

Postgres handles NoSQL better than many dedicated NoSQL database management systems. I kept telling another team to at least evaluate it for that purpose - but they knew better and now they are stuck with managing the MongoDB stack because they are the only ones that use it. Postgres is able to do everything they use out of the box. It just doesn't sound as fancy and hip.

It turns out there's still plenty I don't know, and I spend much more of my time confused and frustrated than I did before. The cool part is that I'm now confused and frustrated by really interesting problems.

This is spot on. Your whole response ist just a trove of insight, I wouldn't have been able to articulate so eloquently.

Windows 11 has some niche features that set it apart in amazing ways. One of them is that it natively supports Linux GUI applications almost the same way as native Windows applications. No need to have a dedicated remote desktop window. Just intermingle Linux and windows applications through WSLg. Granted, it won't mean much to many users but as it stands, Windows is becoming the top multi-platform OS. Who would have thought?

The Tesla truck is already there and just needs to be built at scale.

Full self driving has been fully achieved in 2017 and will reach end consumers next year (as claimed by Tesla every single year since then).

It is desirable that SpaceX rockets fail hard instead of succeeding in their missions.

Musk has truly mastered this principle and only now are people getting impatient. Most investors still regard him as too big to fail. Either Elon will be able to present sufficient success in the next few years or that bubble will burst very violently. He has almost used up the good will he has built up over years (earned our not).

There are different versions of Outlook depending on your subscription. Companies that do things properly, never see the problematic, "free version" of Outlook. They have very fine control over the features and data collections they enable.

Very well written. I'd only change something about this paragraph:

• Operated without production interruption even with frequent team member exit during critical phases of operation

Sounds like people were quitting on you because of terrible work conditions you fostered. An alternative could be:

• Operated without production interruption even with occasional unexpected or planned team member absences during critical phases of operation

Teslas were the "best", as in the only option for what they did. They were never the "best", as in better than existing products for what they did.

Being first to market for such a long time was an incredible feat and it speaks volumes that their position isn't much, much stronger at the end of it.

I guess they mean person hours since they are referring to a team. An initial brainstorming session, another review session or two and 16 hours are quickly gone.

Everyone keeps saying that but I just can't see it. The only time my mails were rejected was because I didn't know what I was doing at the beginning of my journey. Now, whenever I changed my stack or did some major updates the past 20 years or so, I just go to 2-3 sites that analyze my mail server from the outside and tell me if there is anything wrong. The free tier is always more than enough. Just make sure there is at least one service in the list where you send an email to a generated mailbox and have it analyzed. Just looking at the mail server is not enough to find all potential configuration issues.

I aim at a100% score. It's time consuming the first time around but later it's just a breeze.

[...] and velocity is often used to compare developers against each other.

Wow, that's messed up. Luckily I've never had such a team/such leadership.

My laptop was somewhat high end around 11 years ago and is still working solidly. I love the Thinkpad series btw. The only thing I had to do was upgrade to SSD and larger memory many years ago. I was an early adopter of windows 11 and after forcing the installation, it ran even better than windows 10 on the same hardware. The lock out felt extremely artificial and arbitrary.

Flatpak with Fedora 39 must have come a long way. Almost every tutorial with workarounds or discussion of broken features you can find online is now obsolete. It just works out of the box, especially under KDE. Mostly. That makes searching for actual issues extremely hard because I find myself chasing down paths of issues that have long been resolved.

The Lenovo business models (ThinkPad series) are amazing value. My 11 year old laptop is still going strong.

Just stay far away from any Lenovo non-business models.

Sure, there were electric cars. But if I remember correctly, Tesla was the first to deliver the whole next-gen package with an every day, everywhere car, plus charging stations plus the whole automation. If you wanted that, there was no way around Tesla for quite a while.

Most of your points seem to be spot on from what I understand as well. However, I believe that the GDPR requirements can and should be baked into Lemmy itself. This would prevent the fragmentation you mentioned. A guarantee of removing user data as requested while federated plus a guarantee to remove stale user data while defederated since requests won't get through in that case. That would "just" leave the list of processors. This one can be very tricky because you are not just sharing data with your home instance and their federated instances but also with the federated instances of those federated instances. The home instance has no way of learning about the 2nd degree federation. I have no idea how to get the network of data sharing GDPR compliant and I think this is the mich more complicated part that your proposal also suffers from.

HP has decent enterprise models. So office drones will have a positive image of HP. Also old people who have been out of touch with the market for 20 years or so.

If you use feature flags, don't forget to remove them after some grace period. Almost everything bad about feature flags that you can read online is related to long-lived feature flags and all the dead code and complexity involved. Adding a feature flags without a commitment and plan to remove them (the flag, not the feature), is asking for trouble down the line.

You have to go out of your way to even find Tesla charging stations in Germany. They are comparatively rare and far in between.

1Password can't fail that hard easily. They've done great write-ups to compare their architecture to that of LastPass. Long story short: it's the secret key that protects you: https://blog.1password.com/what-the-secret-key-does/

The original author of git flow begs to differ. But hindsight is always 20/20 https://nvie.com/posts/a-successful-git-branching-model/

It depends. Some hardware degrades gracefully while my current desktop system won't even boot and throws error codes on an empty battery. It took me hours to figure out what was wrong the first time it happened.

I was hoping the silly "you rascal" made the sarcasm obvious.

When I installed Kinoite to start using Linux as my primary daily driver, the first thing I did was setting up Ansible, creating a new playbook and all Linux configurations I made from that point on, are only ever done through that playbook, which is backed up in my Forgejo instance. One command and everything is being set up exactly the way I want. It feels extremely liberating.

Yeah, it's the same for me. The content is awesome but requires a lot of concentration.

I'm running MediaWiki for a role playing group in docker. The difficult part was getting everything set up to get certificates from letsencrypt and offering https without leaving docker compose. The great thing about this is that creating a backup or moving servers has become trivial now. As long as you don't expect your users to perform dozens or even hundreds of operations per second, I'd strongly advise sticking with SQLite to make your admin life that much easier. If you want, I'll look up my full stack and post it here once I'm not on mobile any more.

Trouble with those tests is, that they become unreliable or even meaningless, when you have done then once before, let alone daily.

Ansible playbook is perfect for this. All your configuration is repeatable, whether on a running system or a new one. Plus you can start with a completely fresh newest version image and apply from there, instead of starting from a soon-to-be outdated custom image.

Linux, browsers, and hardware accelerated videos on the web don't go along well out of the box. Which is a total shame.

FAQs are just a format of writing. They are usually what developers/managers want to communicate and not necessarily what happens in support.

Sure thing.

So there are two parts to all of this:

1. Getting MediaWiki set up , properly configured and running.
2. Having it securely accessible from the Internet (if needed), including SSL certificates.

Part 1 is well covered my the MediaWiki release already. You only need to worry about the correct configuration. When you download the current version from the official MediaWiki page, you'll notice that there is already a docker-compose.yml file in there. This gets you most of the way to your destination.

Read the file and set the values of all variables you wish to override in a separate ".env" file in the same folder. It could look something like this: MW_SCRIPT_PATH=/w MW_SERVER=https://your-url.com MW_DOCKER_PORT=80 MEDIAWIKI_USER=Admin MEDIAWIKI_PASSWORD=some_password XDEBUG_CONFIG= XDEBUG_ENABLE=true XHPROF_ENABLE=true MW_DOCKER_UID=1000 MW_DOCKER_GID=1000

Now you can just docker-compose up and everything will be set up when visiting your site for the first time, it should hold your hand, guide you through configuration options and finally offer you to download the LocalSettings.php file, that contains all the decisions you've made. You can review and adjust it futher and finally save it to the same folder as your docker-compose.yml file. Refresh the site and it should be accessible right away. I would say for a closed audience, these are the most important options to set:

# The following permissions were set based on your choice in the installer
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;

These options will prevent people from creating their own accounts (you will have to create one for them from the UI) and it will block people from viewing any pages without being logged in.

If you do not wish to use SQlite but rather a dedicated DBMS (I strongle discourage you from getting into that trouble for smaller or even medium user bases), you will find more information on the page for alternative configuration recipes.

If you would like to go into part 2, just ask and I'll give you an overview of my setup here as well. I'm using docker-letsencrypt-nginx-proxy-companion.

I specifically picked the statistic that claimed to have included the full cost of installing something new. Most other statistics only include prolonging the life of existing plants, thus ignoring the installation costs completely. You can just quote the paragraphs that prove your point the same way I have and then we can discuss further. Maybe I made a mistake, who knows.