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.
Bit fields are also common in live service network communication and other large data arrays like graphics calls in video games. Depending on what is being done, packets may not be inflated into proper data structures and left as raw bits to remove processing overhead. That’s my experience with actual 1 bit booleans, but yeah the vast majority of the time the “higher level” byte abstraction is just fine.
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.
> 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.
XMPP provides all of these features and manages to keep up with commercial products really well. Everything Slack or Discord offer is there in the XMPP protocol. And if it wasn't, it could be relatively easily added, thanks to it being extensible.
However, navigating the protocol and software supporting it requires a little bit of know-how. If the OP is interested in building a product incorporating instant messaging and the satellite features, I'd suggest partnering up with somebody with this know-how. Scalable servers would be MongooseIM or ejabberd, polished clients are Conversations or Movim.
If it's a question about which protocol to use for a homeserver, then maybe something focused on ease of setup would work best, like Prosody.
> The fundamental operating principle has shifted from mere message passing to synchronising a common state between all participants.
So it should all be based on blockchain, shouldn't it? ;)
I was an xmpp user back in the early 2000s and hosted a few instances myself. I think it would be an interesting experiment to leave xml behind and start using something like yaml to reduce message overhead. Never got far enough to implement it myself, though.
For those who still like the classic style of messengers, Psi [1] offers an old-school, extremely customisable interface, and is still actively maintained. It integrates nicely with all the desktop platforms as well.
Kinda. The normal version hasn’t seen a release in 4 years, only the experimental psi+ version is maintained, and it is unclear which features it actually supports as all (at least in the wiki in English) information is heavily outdated.
Modern XMPP clients have all of those: Sending media, using multiple devices, deleting messages, editing messages, read receipts, notifications when typing, group chats.
A lot of the features you mention were already there in XMPP 20 years ago. I've lost track of the standard a long time ago but I assume the rest have been added through extensions.
Synapse isn't as heavy as it used to be.
It's quite lite and very stable, I would pick it over any other server, matrix has issues as it is, you don't want to add compatibility issues to the mix.
Maybe it’s gotten a ton better but a couple years back setting up and managing the whole stack had a “shitty on purpose so you pay for hosting” vibe. I noped out in a hurry—and I’ve built and managed some comms-related stuff that ought to be an order of magnitude more fiddly than just running a Matrix server.
Dealing with stuff like running a state compressor regularly, manually removing records it bails on. Also having fast enough resources to handle situations like someone joining the Matrix HQ channel (it's the biggest one) and pulling in like 70GB of database bloat. I hit a bug a month or two back where sliding-sync (the new protocol Element X uses) was causing huge amounts of database bloat, they fixed it but my instance was running something like 200GB on a server with less than 10 people.
EDIT: I run it on a hetzner dedi, I have run it on Apple fusion drives in the past and consumer SSD's and it was a terrible time. Need high IOPS so things don't grind to a halt on intensive db operations (like joining HQ channel lol)
I should have omitted the "I found it fairly easily to set it up with a domain of my own." part, because I do like the answers to the question, those are the sort of answers I was hoping for, so thank you.
the matrix server where i have my account, run by a small tech community with one admin recently had to switch from a blacklist to a whitelist approach in order to curb the amount of fake accounts and spam they were getting. as a side effect since that change i had to bother the admin multiple times because one of the groups i was participating in was not reachable. the amount of work the admin has in order to keep the server im shape is much more than i would be willing to tolerate.
on top of that not a month goes by where something doesn't break.
a security conscious friend who joined matrix because of me (well, he was interested before, but i finally gave him a reason)
just deleted his matrix clients in disgust after some messages randomly could not be decrypted.
i suspect that there is still a problem on the server i am using, therefore more potential work for its already overworked admin.
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.
* Recently tried to run an Electron application, in particular Element. It failed completely to show UI even with the extra options to do it.
Even with Xwayland
* Interesting handling of drag was spotted in GNOME on Wayland with touchscreens, as in events are discontiguous breaking apps. The one we spotted it in is Blender.
* Multiple important use cases have no replacement or equivalent, especially remote desktop access is weak, and software KVM like Barrier doesn't seem to exist.
* Issue with 3D also messes up timings on video playback at high frame rates.
Issue (1) has been a long-standing issue and a prolonged back and forth [0,1] between NVIDIA and Xorg/Wayland devs about implicit and explicit synchronisation protocols. It looks like the explicit sync protocol is in the process of getting merged upstream and the 555 series driver [1] will take advantage of this so hopefully things are looking better. Problem with wayland is that all of the driver, xwayland and every compositor must support the new protocol but it looks like mutter, kwin and wlr will eventually support it. That being said there are constantly new paper-cuts appearing with the NVIDIA driver and Wayland support so who knows what will break with the new driver. Definitely not a pleasant experience. I'm not saying that AMD is smooth sailing but at least you don't have to fight the driver at every new release.
I'm afraid (2) will probably never work properly :-(
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.
> 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.
In case one has full time job, the time and money to disassemble, investigate, diagnose, order parts and fix an appliance is comparable with simply purchasing a new one. Make them take away the old one and blame the environmental disaster on plastic straws and cutlery. Producers will dismiss any requests with "hire an authorized technician co come over onsite" so fixing will also increase your adrenaline level. Luckily you found some blueprints on the internet! oh bummer... they're in Cyrilic and French...
30+ years ago my parents washing machine broke, my dad got his hands on a replacement control module thingy which was an electro mechanical cylinder that had the selection knob on the outside. The inside had 30+ wires (memory may be exaggerating) and he tasked me with labeling them, removing the push fit connectors and connecting them to the new controller. I don't think my 13 year old self ever felt such pressure but it was a great sense of achievement when it worked.
Today they’ll be in Chinese. In China, you might actually have a chance of cost effective repair, except the units they generally sell there are so cheap that replace is still more economical.
In most locations I lived in these repair places ranged from "they are the same clueless as me" to pure scam. One week and 60 EUR to learn what's wrong with this thing? By then I'll be using a new one and will not have to take half day off.
Very generally on a washing machine the first thing to go will be the carbon brushes/bushes - these are usually relatively easy (and cheap) to replace.
If it isn't the brushes then it is likely the control module - this is often so expensive to source new (and can be pricey 2nd hand) that there isn't much point in replacing.
My dishwasher needed a new board, and despite only being 5 years old, the manufacturer wanted 80% of the cost of a new machine. Even on the grey market I couldn't find a good price, and going 2nd hand didn't turn up the parts I needed. Was very sad to scrap such a new piece of hardware.
Regulating prices produces situations that are rife with unintended consequences. Choose a different brand instead (unless that brand has a monopoly, which is only the case in a few industries.)
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.
This is very painfully true, but one 'killer feature' of C is that it is useful without ever using stdlib functions (except basics like memset, memcpy, ... which can be considered compiler builtins anyway).
In more recent languages (even C++) there is no such clear distinction between the language and stdlib any more, which IMHO is a real problem (e.g. most of C++'s problems are actually stdlib problems, not language problems).
Because it was designed with UNIX API surface in mind, and also the reason why outside embedded and Windows everyone with a C compiler does POSIX, even crufty mainframes that are still being sold.
It is as much the case that modern cpus have been designed to facilitate c semantics. C was designed for the cpu initially, but a lot of generations have happened since then, and there have been attempts to try other things, and by now the cpu is designed for c to run well on it.
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 don't think the "job description" is accurate though. Most programmer's jobs is to write code that runs well _enough_ on the hardware that we are given. What "well enough" means depends heavily on whether you are working on firmware, a game engine or a web application. If performance isn't important, you end up with slow software.
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.