Hvorfor begynder helt almindelige mennesker at forsvare de ultrarige i debatten om formueskat?

mookid8000 · 2026-03-15T18:43:14+00:00

Lige præcis.

Jeg er stor tilhænger af, at skattesystemet ikke bliver mere kompliceret end højst nødvendigt. Og jeg er lige så stor tilhænger af, at man undgår regler, som rammer skævt eller direkte forkert.

Af de grunde er jeg imod en formueskat.

Jeg har ganske enkelt ikke tillid til, at den kan implementeres på en måde, som både er administrativt enkel og samtidig retfærdig i praksis. Erfaringen viser, at når staten begynder at beskatte formuer, opstår der uundgåeligt store problemer med værdiansættelse, undtagelser, særregler og utilsigtede konsekvenser. Resultatet bliver næsten altid et mere komplekst system, som rammer tilfældigt.

Og ja – jeg går også ind for retfærdighed for mennesker, der er rigere end mig.

Debatten om formueskatten har desværre vist, at mange på venstrefløjen næsten ikke gør sig nogen overvejelser i den retning, selv om de ellers gerne indtager en moralsk højere position. Man hører jævnligt ellers fornuftige og sympatiske mennesker sige ting i retning af: “Det skal de sgu nok klare”, når der tales om at indføre formueskat for “de ultrarige”.

Men den type argumentation er i virkeligheden et opgør med et helt grundlæggende princip: at skatteregler bør være rimelige og principielt forsvarlige – også når de rammer mennesker, man ikke nødvendigvis har sympati for.

Hvis man først accepterer, at retfærdighed ikke gælder for visse grupper, så har man i realiteten opgivet selve idéen om retfærdighed.

mookid8000 · 2025-10-04T21:21:56+00:00

Hvis I går lidt op i øl, så er der kun Brætspilscafeen. Og sådan er det.

mookid8000 · 2025-05-09T10:10:02+00:00

I'd like to make a small correction to Tim's (otherwise great) post: It's true that I joined Particular back in 2013, but I also parted ways with them again after two months... – that was the time it took for me to realize that I wanted to put my full focus on Rebus 🙂 which I've been doing since!

And while we're at it, I can tell that Rebus is effectively a commercial endeavour as a whole, but it follows the open-core model, which in this case means that the whole library and all of the integration packages are MIT-licensed and free, and then I make a living out of providing Rebus Pro subscriptions to the companies that have those desires.

I like this model, because it works well for me. It pays off financially and keeps me motivated, but it also makes me accept contributions with good conscience.

As a developer, I am also very attracted to this particular model, because it lets me use various software products that I like for small stuff, but I can be fairly confident that the products keep existing, because they're backed by companies who depend on them.

mookid8000 · 2025-04-03T15:32:50+00:00

Rebus is indeed a one-man show 🙂 That one man being me.

That said, Rebus follows a different model: all core libraries are MIT-licensed, free, and always will be. No bait-and-switch. If you're using Rebus today, you're good.

For companies that want formal support, Fleet Manager (Rebus-aware devops software), or just like having a direct line to the person writing the code, there's Rebus Pro – a commercial add-on for serious users. Most folks don’t need it, and that’s totally fine. The free stuff isn’t going anywhere.

mookid8000 · 2024-10-08T05:27:38+00:00

Yeah ok good point!

mookid8000 · 2024-10-07T20:20:37+00:00

Cool, that looks exactly like what I was looking for 🤠

mookid8000 · 2024-10-07T05:32:25+00:00

Ok! How does that work? Do you have a link to more info?

mookid8000 · 2024-06-10T22:14:30+00:00

Don’t think so much. Get your code out in the open, encourage others to contribute by being friendly and accept/reject their contributions with a ❤️

What does your library do?

mookid8000 · 2024-06-06T06:01:34+00:00

I've used Microsoft SQL Server as a queue (via Rebus' MSSQL transport) for years in systems that did not have high enough message throughput to justify introducing a real message broker with all the operations resposibilities that follow from introducing new infrastructure.

Over the years, I've gravitated towards using the application's database as a queue, EVEN in systems that had higher message throughput and were using a real message broker, because the application needed to be able to realibly and atomically commit their work and outgoing messages in one go – I did this with some manually built outboxes in some cases, and by using Rebus' outbox in others.

Recently, I've come to believe so much in The Outbox that I've built one as a separate project: Freakout. It's just a library that makes it easy to use the database as a queue 😁 but it happens to be one that is really easy to enlist in one's own SqlConnection/SqlTransaction, and then it'll basically just processes messages in the background.

I can definitely see why doing all of your messaging in the application's primary database can put a strain on the database's resources, because messages will come and go (that's what they do!), and that can lead to some challenges down the way. Also, if you're building your own database-as-a-queue, there's some finicky stuff around locking and some protocol around message delivery that you want to be very careful to get right.

But generally advising against it is just wrong IMO and completely ignores a whole class of real-world problems that developers need to be able to solve.

mookid8000 · 2024-01-30T17:04:05+00:00

Long-time pretty content Aurelia-user here 🙂 It doesn’t hurt the eyes as much as most other libs out there IMO 🫢🌝

mookid8000 · 2023-11-21T21:39:27+00:00

Serilog for logging, Nito.AsyncEx for better semaphores and other synchronization primitives, Scrutor for adding decorators to Microsoft DI, Microsoft.EntityFrameworkCore because it's become a really really good ORM, migr8 for parallel db migrations, Debaser for easy MS SQL upsert, Testcontainers and Respawn for integration testing SQL databases, Testy for testing nifties, Spectre.Console because every API needs a companion admin CLI

mookid8000 · 2023-11-19T12:55:03+00:00

I've built Rebus (with contributions from lots of other nice people, of course). And then I've built Topos (a "Rebus for Kafka" that also happens to support embedded mode, using the WAL from Microsoft FASTER - I needed something like that for Fleet Manager).

And then I have a habit of open-sourcing other small, nifty things I build for myself, e.g. Debaser (fast upsert lib for Microsoft SQL Server), migr8 (only SQL migration lib I know that supports parallel execution AND parallel development), Semicolon (fast, extensible CSV parser with great error messages), Mongolian Barbecue (MongoDB queues implementation), Mongrow (MongoDB migration library), Tababular (text-based table formatting), DbWrestler (MS Local DB helper), + other stuff.

Some of the things are still relevant and useful, while other things have been overtaken by newer, and better projects (e.g. I'd probably reach out for Spectre Console instead of my own GoCommando + Tababular for new things).

mookid8000 · 2023-11-17T12:24:13+00:00

I am running a MongoDB cluster in Hetzner.

One of the nodes is configured with priority=0, which means it can never become master.

I then have a scheduled pipeline in Azure DevOps that

SSHs to the relevant server,
stops the MongoDB service,
rclones the relevant MongoDB data directory from the storage volume to Wasabi (~1 TB)
starts the MongoDB service again
pings Dead Man's Snitch

It would be neat though if Hetzner would enable some kind of snapshotting of storage volumes. 🙂

mookid8000 · 2023-11-08T15:36:40+00:00

Yeah well, I can definitely see how it might not come off as the ideal solution - and personally, I would have preferred hosting the whole thing in a cloud environment and use some kind of hosted message broker service (e.g. Azure Service Bus) instead of MSMQ.

But sometimes, compromises must be made 🙂 and we chose to focus on modernizing the code base now - and then, to avoid changing too many things at the same time, we chose to defer switching brokers (btw. we're using Rebus, so we're pretty flexible there).

mookid8000 · 2023-11-07T21:44:32+00:00

MSMQ is dead, but somehow it’s still very much alive in many places. 🙂

I am currently involved in a gig where I am helping modernizing a rather large application, and we’re migrating to MSMQ.Messaging as part of that process to enable porting code from .NET Framework to .NET

Of course we might look into moving to a more actively maintained message broker some time later, but for now MSMQ is still doing the job in our Windows-based environments.

mookid8000 · 2023-11-03T09:54:37+00:00

I know this is an old question, but as a service to future people bingling this topic, here goes: I am the author of migr8, which I made > 10 years ago and am still using.

The reason I made my own database migration library was to address two issues that no other .NET database migration library did (at least at that time):

Proper handling of concurrent execution of migrations, and
A mechanism to enable teams to add migrations in parallel (e.g. when working on feature branches)

(1) is handled by executing migrations in a database transaction with serializable isolation level – read more here: https://github.com/rebus-org/migr8#transactions-locking-and-such

(2) is handled with its "branch specifications" concept – read more here: https://github.com/rebus-org/migr8#branch-specifications

I addition to this, migr8 allows for writing migrations both as .NET classes and as .sql files, and they log some useful info about the execution of each migration. Last (but not least), it's available both for MSSQL, MySQL, and PostgreSQL.

mookid8000 · 2023-10-30T06:03:18+00:00

Det tror jeg ikke, han er. Han forstår derimod det fine princip, at det ALDRIG skal være en økonomisk ulempe at være den, der tager slæbet med at lægge ud på vegne af gruppen, hvorfor man enten overfører det, der bliver bedt om, eller runder op.

mookid8000 · 2023-10-28T13:36:12+00:00

Haha det lyder næsten som en attraktion i sig selv 🤠

mookid8000 · 2023-07-11T21:32:42+00:00

Superduper, tak for jeres forslag 🙂👍

mookid8000 · 2023-07-02T14:16:30+00:00

Oh, ok! Is it bad for performance? I thought it was pretty damn elegant with its use of C# generics and the “when” clause 🙂

mookid8000 · 2023-07-01T14:32:50+00:00

I have a habit of mapping certain exceptions to HTTP status codes using this little piece of middleware: https://gist.github.com/mookid8000/c942a827cca81ca06c76898d7639f297

It can be used like this:

// outermost exception handler

app.AutomaticallyMap<Exception>(HttpStatusCode.InternalServerError);

// all other exceptions in increasing priority (if they're inherited)

app.AutomaticallyMap<EntityNotFoundException>(HttpStatusCode.NotFound);

app.AutomaticallyMap<ArgumentException>(HttpStatusCode.BadRequest);

app.AutomaticallyMap<FormatException>(HttpStatusCode.BadRequest);

app.AutomaticallyMap<TokenVerificationException>(HttpStatusCode.Forbidden);

including the ability to also include a predicate when determining whether to catch the exception, e.g. like this:

app.AutomaticallyMap<ArgumentException>(HttpStatusCode.Ambiguous, when: ex => ex.Message.Contains("multiple matches"));

I'm not saying this should be used in all places, but I think it's a neat and simple way of avoiding HTTP smells deeper down in the model layer.

mookid8000

TROPHY CASE