Fell

Most video games compress booleans to bitfields in the save files to save space. Depending on the game, a save file can contain thousands of objects, so it makes sense to keep it small.

At runtime, booleans are 1 byte each. The additional work of shifting and masking to get to the bit you want simply isn't worth it. When reading from memory, the CPU will read a whole cache lines of 64 bytes anyways. So unless you want to process a lot of booleans (and only booleans) at once, it's simply not worth having them 1 bit each.

Because aligned data runs faster, a single boolean sandwiched inbetween integers or pointers can even take up 4 or 8 bytes of memory.

Note: Some languages have built-in optimisations where an array of booleans is actually 1 bit each. C++'s `std::vector<bool>` is such a case and I'm sure there are more.

I've seen people advise to never use booleans, simply because a number (or enum) can convey more meaning while taking up the same amount of space.

In order to answer this question it is important to understand the fundamental difference between XMPP and Matrix.

XMPP was invented at a time, where communicating online meant sending a message from one device to another.

However, the modern expectations for messaging apps are much more than that. Sending media, using multiple devices, deleting messages, editing messages, read receipts, notifications when typing, group chats, threads, and even managing communities are all things a modern messenger app should be able to do. The fundamental operating principle has shifted from mere message passing to synchronising a common state between all participants. If you think about it, nowadays, you're not chatting anymore. You're essentially collaboratively editing a shared chat history file, where the most common action is to add a message; usually at the bottom.

This is what Matrix is at its core. It's a protocol to synchronise state, and that's part of why Matrix is so complex and hard to administrate. I personally think its the better base for the future of communication than XMPP, and I havent even mentioned encryption yet.

Moving on to the practical part: Running a Matrix Synapse server is quite a commitment, but if all you want is talk to friends and family, then there are simpler options. Conduit and Dendrite are a bit easier to set up, and of course there are plenty of public homeservers you could sign up with.

If you do commit to running Synapse however, you have the option to install bridges to almost any other messaging service. This way, your friends and family can keep using what they're used to (WhatsApp, Telegram, Discord, Facebook, ...), and you just use one single Matrix client to talk to all of them.

That's what I do.

Wayland is perfectly ready to be used for normal desktop applications, but the devil is in the details.

Lately, I struggled with: (1) a flickering bug in the NVIDIA driver only affecting Xwayland (2) streaming to my TV via SteamLink (3) reduced performance (compared to X11) on very old (2013) hardware

I fully support the idea of Wayland, but it needs to be adapted better for games.

Maybe not comparable, but $120k is still very cheap for a brand new fully enclosed aircraft.

When I was little (about 20 years ago) I found a website where you could download sheets to print out. They contained parts to cut out that would make an elaborate little glider airplane. You layered multiple layers of paper together and glued them. It included many different parts, but all of them were just paper in the end of the day.

I think the site is gone, I can't find it anymore. It had a blue background and about 10-20 designs available for download. It was either German, Swiss, Austrian, Italian or French, but I'm pretty sure it had multiple Languages.

Anyways, I found something very similar: http://www.zovirl.com/paper-airplanes/

> A couple of months ago our washing machine produced a considerable quantity of smoke when I opened its door, which I interpreted as a suggestion that a replacement was needed.

I just want to point out that what was actually needed was a repair. We're all so conditioned to think broken things must be replaced, it's easy to forget you should at least consider a repair first.

I used to love C for its simplicity. There was just no surprises, and the limited feature set enforced a certain programming style that also happens to run very well on modern CPUs.

But the C standard library is just awful. It's so inconsistent and full of quirks you just have to know. Like how some string functions allow you to specify a size, while others don't. And how strtok keeps track of an internal state and behaves differently on subsequent calls.

I wish there was a language that as simple and limited as C, but with modern (and portable) functions for things like strings, networking, graphics and so on.

And yet, VSCode cannot render at 60 FPS on my 2013 laptop. Any other program does. I don't expect Teams to perform better.

Electron is a waste of resources. A high price to pay for the convenience of easy multiplatform applications.

I think the technology might be more portable if you use a somehow-worn camera looking at the screen. The screen could display a calibration pattern and the camera could analyse it. Maybe a phone app would work. I think on phones it might be possible to retrieve the intrinsic values of the camera.

> Our job is to write programs that run well on the hardware that we are given.

I actually believe "the hardware that we are given" is the entire root of the problem.

Most programmers work and test using whatever hardware is current at the time, but this is makes them blind to possible performance issues.

Take whatever you're working on, and run it on the hardware of 5-10 years ago. If you still have a good experience, you're doing it right. If not, you should probably stop upgrading developer machines for a while.

Whatever your minimum hardware requirements are should determine your development machines. This way, you will naturally ensure your low-end customers have a good experience while your high-end customers will have an even better experience.

My game studio has been doing this for years. It saves money for expensive hardware, it prevents performance issues before they arise and it saves developer time for not having to overthink optimization.

I disagree with almost everything in this article.

Mastodon is being portrayed as a network of seperate communities, which simply isn't true. The netwotk is fully interconnected. It does not matter which instance you're on, you always receive content from the entire network.

You just don't get _everything_ because of blocks and inefficiencies. But I strongly disagree with "small reach on purpose". I've reached far more people on Mastodon (Fediverse) than on Twitter.

I see something on HN and I get inspired. It sparks many ideas in my head and I start planning a project in my mind.

But I don't write it down. Nor do I bookmark anything. I don't use bookmarks at all, frankly.

I know I don't have the time to start any new personal projects.

So I think about it, and then let it go.

I think this only reflects the jumpy disjointed nature of my brain. Things come and go, and that's okay.

I disagree.

1. Make it work 2. Make it performant (always, but within reason) 3. Clean up your mess to prevent future mistakes

I claim that "if too slow" can't be judged because you almost never have the slowest possible target device.

I'm also in the same boat. I've been trying to complete my Bachelor's degree since 2011. I've been working on a pre-thesis assignment since 2021.

However, I recently found a solution that works for me:

I commute to work for one hour every day. In May 2022 I had a car crash and wrecked my car. Not having the money for a new car left me stuck with using the train to get to work. After a few days I was already looking for something useful to do with my daily two hours I spent on trains. It was a hassle, too, because I have to change trains 2-3 times.

So, I installed Linux on my laptop and configured it for maximum battery life and, more importantly, making bootup, hibernate and resume as quick as possible.

I did that, so I can pull out my laptop even if I'm just spending 15-10 minutes on one train, and do something with my time.

So every day, before and after work, I make a little tiny progress on my thesis. And it quickly became a habit, too. I can't avoid it, because I can't avoid going to work. And there's not much else I could do with that laptop.

So, even on days when I don't feel like it, I always think: "might as well work on my thesis"

It worked so well, I even missed my stop once because I was too focused!

I spent the past 4 years at a small studio with about 6-8 programmers.

Almost all the programmers that ever joined our team came from a non gaming background.

And every time I onboarded someone new, it went about the same way. They adapted pretty quickly to our C++ codebase, even if they had a different background. But most of them were really not used to work in an environment where performance really matters. They knew how to write code, but they didn't know how to write fast code. Or what actually makes their code fast.

So if you want to prepare, take the slowest machine you can get your hands on, and program something for that hardware using C++ or Rust. It doesn't matter what it is. You'll learn a lot and have something nice to talk about at the job interview.

I don't see how this is different from a regular minimize feature, apart from the little thumbnails.

I have never used one. Was minimize hard to do before on MacOS?

If all you want is network storage in your home wifi, NFS is extremely easy to set up.

Last year, I wrote a blog post about it: https://furbasik.de/nfs-is-the-new-samba

I would not use it in an office though.

I don't think so. It would make it impossible to talk about deprecated characters ever again, even in a historical context.

Unicode contains even some ancient and long forgotten scripts so historians can keep proper records of them.

This is very interesting. I'd love to read more about all these failed and discontinued ideas of computing.

The most important stuff is backed up by version control, obviously. For everything else I use Syncthing.