Consti

I actually had to test this with my hardware, Win11 is atrocious. I don’t have exact numbers, but Win11 uses so much more RAM for itself that it’s really noticeable how it just gets slower so much faster when I open stuff.

I was programming in assembly for ARM (some cortex chip) and I kid you not the C program we were integrating with required 255, with just 1 it read it as false

Latvia is partly involved, yes, but it’s also part Russian and recently moved to Singapore. You may find the history section on Wikipedia interesting; it also lists the russian part-ownership as reason for many users leaving OnlyOffice (and I’ve seen quite a few posts on that at the time).

As for the open-source part, I stand corrected, thank you

From what I can tell, OnlyOffice has the best compatibility and the nicest UI (similar to MS office), same as with the regular applications. NextCloud Office is based on LibreOffice (officially Collabora, which is their name for the web product), so again same as the regular applications you’ll have some compatibility issues. That said, if you don’t need compatibility with existing documents or only documents made with LibreOffice, either is fine.

One concern many have is that OnlyOffice is closed source (edit: my bad, it’s been open-source for a long time) and russian based (edit: partially russian, see Wikipedia), while LibreOffice is open source.

A catchall solution doesn’t exist, which is why most services simply tell you to put them on a separate subdomain

Usually we don’t distinguish between many2one and one2many, since it’s the same just viewed from the other entity.

There is one more class though, which is one2one. That is, the entities have a direct relationship. Sometimes this also includes the case where you have zero or one, i.e. the relation is optional on one side. This can be accomplished with an FK plus unique constraint or by merging the tables.

streaming small commits straight into the trunk

The image even calls it like that

Some things don’t have good CI/tests, so it doesn’t make sense to include the build step, especially on a small team where we trust each other. But yes, it’s not good practice, and we don’t do this on every project, but sometimes it’s necessary to adjust the flow to the specific project

With git. Every time we start work, we pull. After every commit, we push (and pull/merge/rebase) if necessary.

We do, for two 2-3 person projects, where no code reviews are done. This is mostly because (a) it’s “just” a rewrite and (b) most new functionality is small and well-defined. For bigger features a local branch is checked out and then merged back later. Commits are always up-to-date, which makes it much easier to test integration of new featues.

Pretty sure the commenter above meant that the their RAM was advertised as X GiB but they only got X GB, substitute X with 4/8/16/your amount