Don't think any game has the same support doom has. Doom has become a benchmark of sorts so gets ported to the strangest of places. Not normally places you would bother to port any game. It is done for the challenge of the port rather than any practical reason.

There are tonnes of games that could run in the same places as doom, many could run in far more places. But doom is complex enough to be an interesting challenge while being simple enough to run on very limited hardware. And has been open sourced while being a classic icon which makes it attractive to be a benchmark for getting to run in the weirdest of places.

Restrictive tech never works when you apply it from the start. You need to capture the market first before you can start to apply that. And that is the road Bamboo labs looks to be heading down. It is the classic playbook:

1. have some true disruptive innovation in some product that people will actually want to use your products for ✅
2. mass market your product and get loads of people singing parse about how innovate it is ✅
3. slowly start to lock down your product, typically behind the guise of safety and security ✅
4. start to squeeze your customers for as much money as you can with DRM or subscriptions You wont succeed if you skip straight to step 4. But Bamboo have been slowly working their way up to it. It might take a few more years but I can see them eventually wanting DRM filament.

By far the most important thing is consistency

This is not true. The most important thing is correctness. The code should do what you expect/want it to do. This is followed closely by maintainability. The code should be easy to read and modify. These are the two most important aspects and I believe all other rules or methodologies out there are in service of these two things. Normally the maintainability side of things as correctness is not that hard to achieve with any system of rules out there.

You must resist the urge to make your little corner of the code base nicer than the rest of it.

Uhg. I really don't like these words. I agree with their sentiment, to a degree, but they make it sound like you should not try to improve anything at all. Just leave it as it is and write your new code in the same old crappy way that it always has been. Which is terrible advice. But I get what they are trying to say - you should not jump into a area swinging a wrecking ball around trying to make the code as locally nice as possible at the expense of the rest of the code base and other developmental practices around.

In reality there is a middle ground. You should strive to make your corner of the code base as nice as possible but you should also take into account the rest of the code base and current practices as well. Sometimes having a little bit better local maintainability is not worth the cost of making the code base as a whole less maintainable. Sometimes a big improvement to local maintainability is worth a minor inconvenience to the code base as a whole - especially for fast moving parts of the code base. You don't want something that no one has touched in 10 years to drastically slow down current features you are working on just to keep things consistent.

Yes consistency is important. But things are far more nuanced than that statement alone. You should strive for consistency of a code base - it does after all have a big effect on the maintainability of the code base. But there are times that it hampers maintainability as well. And in those situations always go for maintainability over consistency.

Say for instance some new library or an update to a library introduces a new much better way of working. Your code base is full of the old way though. Should you stick to the old way just to keep up with consistency? If the improvement is good enough then it might be worthwhile. Ideally if you can you would go though and update the whole code base to the new way of working. That way you improve things overall and keep consistency of the code base. But that is not always practical to do. It might be better to decide that the new way is worth switching to for new code, and worth refactoring old code when you are working in that area anyway but not worth the effort of converting the whole code base at once. This makes maintainability of the new code better, at the expense of old less used code.

But the new way might not be a big enough jump in maintainability of new code that it is worth sacrificing the maintainability of the code base as a whole. Every situation like this needs to be discussed with your team and you need to decide on what makes most sense for your project. But the answer is not always that consistency is the most important aspect. Even if it is an important aspect.

That is a bit more expensive and complex. Looks like this is configured with a couple of resistors for 5v from USB which is simple to get and a voltage reg to drop down to 3v3 optionally. Full PD requires a chip and active negotiation for higher voltage levels. Though there are chips that do that it does increase the complexity and cost and soldering skills a bit. Might not be worth it if all you work on is 5v or 3v3.

becoming production capable and ready for prime-time use from Linux gamers to workstation customers and data centers.

I would bet on it being the boom in AI increasing demands for Nvidia GPUs in data centers which largely run Linux wanting better support. Bet they don't care at all about workstation users and Wayland support is a by product of making it work better with the kernel overall.

But it applies to features, not coding practices

I disagree. It applies to everything. I would argue it applies to SOLID most of all. I do not find SOLID principals to be good ones to follow most of the time. Situational they can be useful but I have seen so many projects that strictly follow SOLID that becomes an unmaintainable mess.

If you struggle to understand the SOLID principles or think they are too general, then I would suggest you follow my SOLID Training Wheels until you understand them better.

I hate this excuse. If the answer to the problem is you are just not doing it right then it is a terrible answer. But lets look at some of this advice:

Summary: 1 piece of code has 1 responsibility. The inverse: 1 responsibility of code has 1 piece of code

Training Wheels:
Follow the 10/100 Principle
Do not write methods over 10 lines
Do not write classes over 100 lines

No. Just no. Making everything as small as possible is exactly what is wrong with the single responsibility principal. I agree that everything should have one responsibility, but that responsibility might be complex and require a lot of code. Hiding the code behind other functions does not make it easier to read, only means you need to jump around a lot in order to understand what it is doing which IMO makes things harder to read. Every time I jump location it gets harder to remember where you came from or what the wider context is. Keeping related code together is more important then creating small function.

Just take a look at the stdlib of almost any mainstream language. Like the ArrayList in Java, or Vec in rust. These classes are thousands of lines long with many methods being 10-20 lines of code with some even longer then that. Is this code bad or hard to read? Not for what it is doing. And code like this is not atypical in stdlibs, you can jump to almost any class/struct in a language of your choice and see similarly structured code. And in all cases the classes represent one thing and its methods do one thing on that object regardless of how many lines of code they contain.

If you have to change a class that already breaks the 10/100 Principle:
take your code out of that class and put it in a new class first so the original class is smaller
Check-in this refactor without your new code
make your changes in the new class
Check-in your new code

IMO this breaks the single responsibility rule. If new code is mostly related to a single class then it should be added to that class as that is what the class is responsible for. Adding a new class for every bit of logic just splits up the responsibility and makes it far harder to find what is responsible for something.

I could go on about the rest of that training guide - which this whole post seems to be an advert for.

YAGNI, will ruin your code base if you apply it to how you code.

It applies just as much to how you code as to what you are coding. If you added every programming paradigm and principal to your code base it would be a unreadable mess. Not to mention impossible to do as loads of these conflict with each other.

Pick the right tools for the right job. Don't blindly apply anything to every situation. There are times when the SOLID principals can help but there are also times where they make code worst. Instead always ask yourself if there is a simpler way you could be doing something and if when applying a principal if it actually made the code easier to read (ask someone else as well as it can be hard to tell yourself). Don't be afraid to break a principal if it is not helping.

And the basket will be upside down.

It also tells you nothing about the data flow or the data at all. What do these functions do? What data to they act on? It is all just pure side effects and they could be doing anything at all. That is far from what I consider clean.

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

saying they are “arbitrary, capricious (and) an abuse of discretion.”

They would know, all the tricks they use for their advertising and pricing tactics...

developers, i.e. people who are supposed to be good at looking up online how stuff works.

How I wish this were true.

That abstract is full of oh won't anyone think of the profits vibes.

This thumbnail does not inspire confidence in the quality of the content. It is a pure clickbait title screen.

So is just about every video created over the last few years. This is the new norm and can no longer be used to judge a bit of content. For ~~better or~~ worst.

The video itself is a good overview of what data brokers are and what they collect on you with some ways to help mitigate this. Honestly not very big news for anyone that is already into data privacy, but it will be very eye opening for anyone that is not already aware of what they collect.