noirscape

I decided to look into this (git gc should also be doing this), and I think I figured out why it's such a consistent issue with git in particular. Running git gc does properly pack objects together and reduce inode count to something much more manageable.

It's the same reason why the postgres autovacuum daemon tends to be borderline useless unless you retune it[0]: the defaults are barmy. git gc only runs if there's 6700 loose unpacked objects[1]. Most typical filesystem tools tend to start balking at traversing ~1000 files in a structure (depends a bit on the filesystem/OS as well, Windows tends to get slower a good bit earlier than Linux).

To fix it, running

> git config --global gc.auto 1000

should retune it and any subsequent commit to your repo's will trigger garbage collection properly when there's around 1000 loose files. Pack file management seems to be properly tuned by default; at more than 50 packs, gc will repack into a larger pack.

[0]: For anyone curious, the default postgres autovacuum setting runs only when 10% of the table consists of dead tuples (roughly: deleted+every revision of an updated row). If you're working with a beefy table, you're never hitting 10%. Either tune it down or create an external cronjob to run vacuum analyze more frequently on the tables you need to keep speedy. I'm pretty sure the defaults are tuned solely to ensure that Postgres' internal tables are fast, since those seem to only have active rows to a point where it'd warrant autovacuum.

[1]: https://git-scm.com/docs/git-gc

I can understand in theory why they wouldn't want to back up .git folders as-is. Git has a serious object count bloat problem if you have any repository with a good amount of commit history, which causes a lot of unnecessary overhead in just scanning the folder for files alone.

I don't quite understand why it's still like this; it's probably the biggest reason why git tends to play poorly with a lot of filesystem tools (not just backups). If it'd been something like an SQLite database instead (just an example really), you wouldn't get so much unnecessary inode bloat.

At the same time Backblaze is a backup solution. The need to back up everything is sort of baked in there. They promise to be the third backup solution in a three layer strategy (backup directly connected, backup in home, backup external), and that third one is probably the single most important one of them all since it's the one you're going to be touching the least in an ideal scenario. They really can't be excluding any files whatsoever.

The cloud service exclusion is similarly bad, although much worse. Imagine getting hit by a cryptoworm. Your cloud storage tool is dutifully going to sync everything encrypted, junking up your entire storage across devices and because restoring old versions is both ass and near impossible at scale, you need an actual backup solution for that situation. Backblaze excluding files in those folders feels like a complete misunderstanding of what their purpose should be.

The trick is to not overengineer your hobby if you're only doing it to prove a point.

ie. Yes, you could run a full on corporate CA, issue SSL certificates for your domains, manually rig up wireguard and run your own internal corporate VPN... or you just accept that your grand total of 1 concurrent user on an intranet is probably just better served by setting up Tailscale and a wildcard LE certificate so that the browser shuts up. (Which is still not great, but the argument over HTTPS and intranets is not for right now.)

Same with other deployment tools like Docker - yes, there's a ton of fancy ways to do persistent storage for serverless setups but get real: you're throwing the source folder in /opt/ and you have exactly one drive on that server. Save yourself the pain and just bind mount it to somewhere on your filesystem. Being able to back the folder up just with cp/rsync/rclone/scp is a lot easier than fiddling with docker's ambiguous mess of overlay2 subfolders.

Every overengineered decision of today is tomorrow's "goddammit I need to ssh into the server again for an unexpected edgecase".

The employee didn't mistreat anyone. She simply stated the procedure (which sucks!).

It was OOP that chose to escalate this to malicious compliance and ascribed a lot more to her attitude than what's actually said. OOP assumed that she was out to get him in specific, when nothing in the described call even suggests as much.

The correct response would've been to ask for the manager and if the manager chooses to stonewall in an obnoxious way (which is possible!), then you pull the frustrating fax from hell on them. At that point, you're not just speaking to someone who has no power to fix shit, you're talking to someone who does have the power to fix shit and chooses to be a stick in the mud about it. That's when being a jerk back is deserved.

Being a jerk to low paid employees in this manner is unacceptable, rude and makes me think a lot less of the person writing it.

Spoken from the pretty obvious position of never having to have worked a low-wage people facing job.

Here's the real situation: the people that pick up the phone when you call them up aren't going to be paid much above minimum wage at all. They have zero institutional power to fix anything. You're yelling at people that, themselves, almost certainly are only barely making enough money to get by either.

It is worthless to yell at these people because they can't fix shit; they don't set policies, they have no power to fix things and all your yelling is going to achieve is at best counterproductive to what you want to get done (since now the front facing employee dislikes you personally and is less inclined to try and help you out) and at worst is going to get you into further trouble when you do need something routine done. (Since now you're on the list of "people that the employees don't want to put any extra effort into since they're jerks".)

There are people that get paid to be the complaints facing entity of the organization, who are paid to withstand whatever shit you can throw at them and who have an ability to fix up whatever you needed in specific. They're not the people that pick up the phone.

What you need to do is channel the inner Karen and ask to speak to the manager. The manager can help you with this sort of thing, they are the ones that can do shit to avoid sustaining the machine, because they have a career they want to grow into and risk actual consequences for pissing people off.

Be polite (but firm; you don't need to be walked over) to the first tier support employees, even if they can't help you. Save the complaints for the manager (who you shouldn't be afraid to ask to speak to either). The managers job is to deal with the real complaints, not the routine stuff that just happens to need a human involved. They are taking a job to be the face of the machine for reasons other than "I literally need a minimum wage job to survive".

> I never understood why github became a popular place to host your site in the first place.

Easy: it was free, it was accessible to people that couldn't spend money for a hosting provider (read: high schoolers) and didn't impose arbitrary restrictions on what you were hosting.

Back then, your options as a high school student were basically to either try and reskin a closed off platform as much as you could (Tumblr could do that, but GitHub Pages also released in the time period where platforms were cracking down on all user customization larger than "what is my avatar") or to accept that the site you wanted to publish your stuff on could disappear at any moment the sketchy hosting provider that provided you a small amount of storage determined your bandwidth costs meant upselling you on the premium plan.

GitHub didn't impose those restrictions in exchange for being a bit less interactive when it came to publishing things (so no such thing as a comment section without using Disqus or something like that, and chances are you didn't need the comments anyways so win-win) That's why it got a lot more popular than just using an FTP server.

Which makes it not really a suitable replacement for GitHub, which is my entire point.

Keep in mind, I'm not saying Codeberg is bad, but it's terms of use are pretty clear in the sense that they only really want FOSS and anyone who has something other than FOSS better look elsewhere. GitHub allowed you to basically put up anything that's "yours" and the license wasn't really their concern - that isn't the case with Codeberg. It's not about price or anything either; it'd be fine if the offer was "either give us 5$ for the privilege of private repositories or only publish and contribute public FOSS code" - I'm fine paying cash for that if need be.

One of the big draws of GitHub (and what got me to properly learn git) back in the day with GitHub Pages in particular was "I can write an HTML page, do a git push and anyone can see it". Then you throw on top an SSG (GitHub had out of the box support for Jekyll, but back then you could rig Travis CI up for other page generators if you knew what you were doing), and with a bit of technical knowledge, anyone could host a blog without the full on server stack. Codeberg cannot provide that sort of experience with their current terms of service.

Even sourcehut has, from what I can tell, a more lenient approach to what they provide (and the only reason why I wouldn't recommend sourcehut as a GitHub replacement is because git-by-email isn't really workable for most people anymore). They encourage FOSS licensing, but from what I can tell don't force it in their platform policies. (The only thing they openly ban is cryptocurrency related projects, which seems fair because cryptocurrency is pretty much always associated with platform abuse.)

From their FAQ:

> If you do not contribute to free/libre software (or if it is limited to your personal homepage), and we feel like you only abuse Codeberg for storing your commercial projects or media backups, we might get unhappy about that.

Emphasis mine. This isn't about if it's technically possible (it certainly is), it's whether or not it's allowed by their platform policies.

Their page publishing feature seems more like it's meant for projects and organizations rather than individual people. The way it's described here indicates that using them to host your own blog/portfolio/what have you is considered to be abusing their services.

I don't dislike Codeberg inherently, but it's not a "true" GitHub replacement. It can handle a good chunk of GitHub repositories (namely those for well established FOSS projects looking to have everything a proper capital P project has), but if you're just looking for a generic place to put your code projects that aren't necessarily intended for public release and support (ie. random automation scripts, scraps of concepts that never really got off the ground, things not super cleaned up), they're not really for that - private repositories are discouraged according to their FAQ and are very limited (up to 100mb).

They also don't want to host your homepage, so if GitHub Pages is why you used GitHub, they are not a replacement.

Unfortunately I don't think there's really an answer to that conundrum that doesn't involve just spinning up your own git server and accepting all the operational overhead that comes with it. At least Forgejo (software behind Codeberg) is FOSS, so you can do that and it should cover most of what you need (and while you're in the realm of having a server, a Pages-esque replacement is trivial since you're configuring a webserver anyway.) Maybe Gitlab.com, although I am admittedly unfamiliar with how Gitlab's "main" instance has changed over the years wrt features.

Here's their FAQ on the matter, it's worth a read: https://docs.codeberg.org/getting-started/faq/

While the donation banner doesn't seem like an issue to me, the WMF comparison is extremely inappropriate if they want to talk about appropriate means of fundraising.

The WMF is notorious for its donation banners making wildly exaggerated claims about the state of the Foundation (it needs some money to be operational, it is however not by any real stretch of the imagination in financial trouble or losing its independence because it doesn't get enough money; they have a massive endowment that can run Wikipedia for the next 50 years or so, and major corporations already give money to the WMF to keep it in the air, making the statements those donation messages give to regular readers very deceptive), scaring people in third world countries into parting with their meager savings because they are scared of the WMF vanishing through deceptive language and in general their donation drives are extremely intrusive to the respective Wikipedias.

I understand that the Document Foundation just wants to bring donations to the attention of their users, but the WMF is the worst point to compare it to.

I think that may be the first time I've seen licensing drama over something as minor as adding another author to the copyright list.

Pretty sure those are completely standard for major changes in maintainers/hostile forks/acknowledging major contributors. I've seen a lot of abandoned MIT/BSD projects add a new line for forks/maintainers being active again in order to acknowledge that the project is currently being headed by someone else.

From my "I am not a lawyer" view, Kludex is basically correct, although I suppose to do it "properly", he might need to just duplicate the license text in order to make it clear both contributors licensed under BSD 3-clause. Probably unnecessary though, given it's not a license switch (you see that style more for ie. switching from MIT to BSD or from MIT/BSD to GPL, since that's a more substantial change); the intent of the license remains the same regardless and it's hard to imagine anyone would get confused.

I suspect (given the hammering on it in responses), that Kludex asking ChatGPT if it was correct is what actually pissed off the original developer, rather than the addition of Kludex to the list in and of itself.

Inherently, not really. An expired, self-signed or even incorrect (as in, the wrong domain is listed) certificate can be used to secure a connection just as well as a perfectly valid certificate.

Rather, the purpose of all of these systems (in theory) is to verify that the certificate belongs to the correct entity, and not some third party that happens to impersonate the original. It's not just security, but also verification: how do I know that the server that responds to example.com controls the domain name example.com (and that someone else isn't just responding to it because they hijacked my DNS.)

The expiration date mainly exists to protect against 2 kinds of attacks: the first is that, if it didn't exist, if you somehow obtained a valid certificate for example.com, it'd just be valid forever. All I'd need to do is get a certificate for example.com at some point, sell the domain to another party and then I'd be able to impersonate the party that owns example.com forever. An expiration date limits the scope of that attack to however long the issued certificate was valid for (since I wouldn't be able to re-verify the certificate.)

The second is to reduce the value of a leaked certificate. If you assume that any certificate issued will leak at some point, regardless of how it's secured (because you don't know how it's stored), then the best thing you can do is make it so that the certificate has a limited lifespan. It's not a problem if a certificate from say, a month ago, leaks if the lifespan of the certificate was only 3 days.

Those are the on paper reasons to distrust expired certificates, but in practice the discussion is a bit more nuanced in ways you can't cleanly express in technical terms. In the case of a .mil domain (where the ways it can resolve are inherently limited because the entire TLD is owned by a single entity - the US military), it's mostly just really lazy and unprofessional. The US military has a budget of "yes"; they should be able to keep enough tech support around to renew their certificates both on time and to ensure that all their devices can handle cert rotations.

Similarly, within a network you fully control, the issues with a broken certificate setup mostly just come down to really annoying warnings rather than any actual insecurity; it's hard to argue that the device is being impersonated when it's literally sitting right across from you and you see the lights on it blink when you connect to it.

Most of the issues with bad certificate handling come into play only when you're dealing with an insecure network, where there's a ton of different parties that could plausibly resolve your request... like most of the internet. (The exception being specialty domains like .gov/.mil and other such TLDs that are owned by singular entities and as a result have secondary, non-certificate ways in which you can check if the right entity owns them, such as checking which entity the responding IP belongs to, since the US government literally owns IP ranges.)

It's probably a bit of both from what I've seen of how Americans tend to react to their government doing things (online anyways).

The US's quagmire of incoherent laws and many jurisdictions seems to be a bad combination of:

* Apathetic voters that are raised on a media diet of "big government bad", which impedes any regulations on a federal level. (Note that this is irrespective on if the voters actually want a small government, it's what they're led to believe.)

* Politicians that don't like to give up power; there's an unusual desire for local/state US officials to claim responsibility and get very pissy when the federal government steps in with a standardized solution. This is very unusual compared to other countries; punting responsibilities to local officials in other countries is generally seen as a way for politicians to abdicate responsibility by letting it die in micromanagement and overworked administrative workers and isn't popular to do anymore these days. (This is also a two way street, where federal US lawmakers can abdicate making any legislation that isn't extremely popular by just punting it down to the states, even if they have legal majorities.)

* The US has a court system that overly favors case law rather than actual law. Laws in the US are permitted to be painfully underdefined since there's an assumption that the courts will work out all the finer details. It's an old system more designed around the days of bad infrastructure across large distances (like well, the British Empire, which it's copied from). It's meant to empower the judicial branch to be able to make the snap decision even if there's not directly a law on the books (yet) or if a law hasn't actually reached the judiciary in question. The result is that you end up with a bunch of different judiciaries, each with their own slightly different rules. It also encourages other bad behavior like jurisdiction shopping where people will try to find the judiciary most favorable to them, crafting "the perfect case" to get a case law on the books the way you want it to get judges to override similar cases and so on and so forth - in other countries, what the supreme court judges doesn't have nearly the same lasting impact that a decision in the US has.

* And finally, the entire system is effectively kept stuck in place because lobbyists like it this way; if they want to kill regulation, they just get some states to pass on it and then hem and haw at the notion of a federal regulation. Politicians keep it in place on their own, lobbyists provide them the grease/excuse to keep doing it. (And those lobbyists these days also have increasing amounts of ownership over the US media, so the rethoric about voters not liking big government regulations is reinforced by them as well.)

It didn't end up this way on purpose; the historical reasons for this are mostly untied from lobby interests (which is mostly just "the US is the size of a continent in width", "states didn't actually work together that much at first" and "the US copied shit from the British Empire"), but they're kept this way by lobby interests.

That does sound like there's an exploitable element there isn't it?

Statistically speaking, most people use one of the biggest email providers, which use their own models to detect spam (or even quietly drop messages). If you're doing an unpopular TOS change, why not set the mail up to still be RFC compliant but in such a way where the mail isn't going to be allowed through by any of the providers. Then you can just claim the problem is userside.

For example, the Message-ID header is technically not required (SHOULD rather than MUST), but as a spam detection measure, Gmail just drops the message entirely for workspace domains: https://news.ycombinator.com/item?id=46989217

Oh that's awesome. Finally the contradiction of buying Google to avoid Google has been resolved for GOS.

I am curious to know how Motorola intents to deal with Google's policies surrounding Android forks, but I'm sure that's a hurdle they know how to cross.

Nobody, because no company is actually pro-customer. Which is fine, the customer and the company's goals don't align beyond "want product" and "supplies product".

The problem is that Amazon abuses it's market position as being the search engine for customer products to unfairly prevent anyone from competing with them. Being "better than Amazon" as a seller in the margins is completely impossible, because Amazon demands sellers price match them.

Let's say you're a seller who wants to make 7$ from each sale as revenue (your actual margins from making the product aren't relevant to this estimate). If you list this product on the Amazon store, Amazon is going to take your listed price and apply their own price cut on top of this (although it's usually framed the other way around, so you list the final sale price and Amazon then says how much they take). For simplicity's sake, we'll go with a 30% cut, so they list it for 10$. Now let's say there's a second storefront you want to sell to, we'll call it Bamazon. Bamazon has a lower cut than Amazon does, let's say it's 10%. So the final product would then be listed for 8$ (taking into account customer psychology on price listings), making Bamazon the better seller, right? The smart customer gets a better deal, Amazon is incentivized to improve their margins if they don't want to lose market share and everybody's happy.

Wrong. What happens instead is that Bamazon will now also list the product for 10$ (because if it's listed lower, Amazon screws the seller by delisting them from Amazon, which is unacceptable for the seller because Amazon is the one with the monopoly position, so the seller then can sell absolutely nothing), making the product equally expensive for the customer and making Bamazon's deal only an improvement for the seller, who now gets higher profits from their sales, screwing the customer. Meanwhile Bamazon is rendered unable to compete with Amazon on their better margins since Amazon is the assumed default. Any benefit of a different store having better margins is fully masked by this approach, only benefiting Amazon.

It's a Most Favored Nations clause and their use on online platforms is both ubiquitous, scummy and makes things more expensive for the customer while also entrenching Amazon's monopoly position. This crap is usually couched as pro-customer rethoric, but it really isn't. It mostly serves to entrench monopolies not on their quality, but through their existing market share. (Valve also famously does this by the way.)

Well for one, Servo isn't just JavaScript, it's an entire engine. Closer to Blink & Gecko.

Secondly, Ladybird wants to be a fourth implementor in the web browsers we have today. Right now there's pretty much three browser engines: Blink, Gecko and WebKit (or alternatively, every browser is either Chrome, Firefox or Safari). Ladybird wants to be the fourth engine and browser in that list.

Servo also wants to be the fourth engine in that list, although the original goal was to remove Gecko and replace it with Servo (which effectively wouldn't change the fact there's only three browsers/three engines). Then Mozilla lost track of what it was doing[0] and discarded the entire Servo team. Nowadays Servo isn't part of Mozilla anymore, but they're clearly much more strapped for resources and don't seem to be too interested in setting up all the work to make a Servo-based browser.

The question of "why not use Servo" kinda has the same tone as "why are people contributing to BSD, can't they just use Linux?". It's a different tool that happens to be in the same category.

[0]: Or in a less positive sense, went evil.

It's not related to Chinese in specific, but in civilian air traffic, the lingua franca is specifically English[0]. The reason for this is because other languages leave too much room for interpretation. One incident not mentioned in that page that's worth bringing up is Korean Air Flight 801; the crew recognized an issue with the instruments quite a bit before the crash, but because the flight crew essentially was too polite in notifying the captain of the issue, the captain instead asserted authority with incomplete information, leading to the plane crashing[1].

Language specificity and cultural encoding in those languages can have a pretty major impact on its clarity, especially in critical situation. Speaking a secondary language instead can avoid that sort of thing simply because being a non-native speaker, you'll be a good deal more blunt in that language.

[0]: https://en.wikipedia.org/wiki/Aviation_English

[1]: https://en.wikipedia.org/wiki/Korean_Air_Flight_801

Oh that's really cool! I hope it alleviates some pressure on the DERP servers, whenever I notice the connection on tailscale is bad, it's usually because the device is connecting over DERP.

Given I don't disagree with you about GOS being the best on security, I think there's only one thing really worth mentioning:

> The attacks towards us including your libelous claims about us here are what's absurdly toxic.

I want to make this clear upfront: I have no connection to /e/, Calyx, DivestOS or whatever other projects you've had issues with over the years. If you've had trouble with them I find that very unfortunate for you, but they are entirely unrelated to this conclusion. I do not consider these claims to be libelous when they're fairly easy to check:

The reason I consider GOS' community to be extremely toxic and find official channels enabling this is for a few very simple reasons:

1. I've seen several incidents of GOS users coming into adjacent Android communities to start beef with those communities while giving off the attitude of zealots. For a concrete example, the F-Droid forums have a thread about Googles impending changes to letting users install their own software ( https://web.archive.org/web/20250903081432/https://forum.f-d... ). The original OP for this thread has a pointless attack on the F-Droid project, declaring GOS to be superior. Moderators eventually changed this to be more mild (but it's why the first replies are snarking on low-hanging fruit about GOS), but I've seen similar behavior in other places - there's a reason that a lot of Android communities generally respond with trepidation and annoyance whenever the project is brought up and it's because of this behavior from the userbase.

2. I can read the GrapheneOS forums; they're public. Nearly every issue I've seen people have with GOS on the forums is effectively met by a "you're holding it wrong". This sets a tone for the community that makes it come across as extremely hostile to potentially interested users.

3. In the same sense, it's trivial to notice that the official GrapheneOS account on this forum is a frequent participant in these discussions, generally backing up the hostility on the virtue of technical accuracy. This to me suggests endorsement of this attitude. (See a sibling to my initial comment where the official account makes a post on the GOS forums about an unrelated blog for daring to recommend a different ROM/phone combo. This to me is not indicative of healthy communications, but rather of an obsession to promote GrapheneOS at every corner.)

4. I remember, as a Bromite user, the futzing with the Vanadium license in order to prevent other Android Chromium forks from making use of it's patches for the crime of... considering a contribution from someone the GOS project has beef with. That to me is the most telling thing really. The goal with that license futzing was never to actually help advance privacy/security or anything like that. It was to try and force a different project to conform to GrapheneOS' demands over something extremely minor and GOS went ballistic and threatened license changes (which they eventually did) the moment the maintainer asked for a bit more information because "GOS doesn't like this person" isn't enough to immediately warrant kicking someone off a project. Cromite (the fork of Bromite, as Bromite's maintainer went AWOL) still doesn't include Vanadiums hardening patches because of this. It's fucking absurd.

4 is the big one for me. It is absolutely unacceptable, unbecoming and to put it plainly: toxic behavior from an official voice in the project. It's fucking rich and borderline hypocritical to talk about GOS' consistent upstreaming of Android hardening patches while making it impossible through a license change for other projects to share it's contributions.

(Here's a source for that btw; https://github.com/bromite/bromite/issues/2141 and https://github.com/bromite/bromite/pull/2102 for the original incident. csagan5 essentially got jumped with extreme hostility for something they couldn't have been aware of and was very reasonable about, and all they got in response was more threats and hostility.)

GOS creates a complete bunker of a phone that can provide defense against pretty much all but the most dedicated state level actors. If you're worried that someone would steal your phone specifically to target you, Graphene will protect against that. Securitywise it's hard to argue against them, although GOS tends to sacrifice usability in favor of security, which leads to odd decisions. Their device depreciation timeline is also pretty aggressive and really just matches that of the Pixel. (You're also buying the Google phone... to not want Google in your life; this bizarre paradox will always be strange). It's not exactly a recommendation for long-term support. Worth noting however is that usage of GOS is also seen as a signal in and of itself for the authorities that you may have something unsavory to hide, so using it stands out in that regard; some law enforcement officers (I think it was in Spain?) have said that the OS is popular with organized crime. GOS obviously denies the connection and they're probably honest in that the OS isn't deliberately designed for criminals, but it's worth noting at the very least. (Basically GOS is the paradox where someone trying their hardest to be anonymous ends up standing out way too much from the crowd and drawing attention to themselves.)

/e/OS (and similar "non-LineageOS" ROMs really) instead focus more on de-Googling. They're still generally security focused, but the priority is less "someone's after you" and more "corporate surveillance is kinda scary innit". The aim is less to avoid someone actively trying to drain your phone of data and more to prevent your phone from passively sending everything it can possibly find to the Big G's ad machine (as well as whatever other trackers get snuck into apps.) Because of this, they usually have better depreciation timelines and support a lot more devices compared to GOS who only support the Pixel line (which is an increasingly awful set of phones truth be told); their scope is much smaller.

Finally, it's worth noting that the GOS community is absurdly toxic to anyone doing anything privacy-related that isn't under the banner of GOS. It's extremely maximalist, tends to get very upset at other projects whenever they get attention (see sibling reply to this, where they pretty much melted down because an outlet dared to recommend a Fair phone+/e/OS) and the projects official channels have generally encouraged this sort of behavior. It doesn't really damage the software itself, but it's worth considering.

It should be possible to redact names from cases for that purpose.

I think a product focus does exist: Element seems to be a genuine attempt to fully assemble Matrix as one full project. The problem is that it feels like the Element devs are stuck wanting to have their cake and eat it too.

There's some design choices in Matrix that don't really "fit" with what modern messaging infrastructure looks like. (Which to summarize it pretty quickly is a Slack/Discord-esque model, where non-sysadmin users get to fully administer their own spaces, with an expectation for multiple different channels, control over user permissions and user access and so on and so forth.)

Some of these come from the fact that Matrix is pretty blatantly just designed as "what if IRC, but slightly more modern". It's main unit for non-sysadmin moderation is a single channel, with the expectation that one instance of Matrix will never have two channels named #general (as an example). Similarly, it's entirely possible to kick users from a channel... but then have that exact same channel continue independently on a different instance, but under a different label. This makes sense if you look at it as "supercharged IRC", but becomes a complete and utter mess when you factor in things like the encryption between two servers suddenly disagreeing with each other (leading to a bunch of old messages becoming unreadable), content moderation (barely an issue on IRC because message retention is expected to be almost entirely clientside) and so on and so forth.

Element/synapse's people do try to provide for these cases, but you're effectively stuck trying to prod at admin API endpoints, bots to synchronize moderation decisions and they have like 3 different "channel grouping" that's supposed to be their version of the Slack workspace/Discord guild model.

Honestly though, I'm pretty sure that once XMPP gets a proper multi-user multi-channel XEP going (there's one in draft right now which specifically tries to provide workspace-esque support; it's possible to do this already but it's a sysadmin XEP, the proposal aims to give this capability to regular users), it'll just end up blowing Matrix out of the water entirely for most usecases. Unlike Matrix, it's a far more mature protocol that's a lot easier to work with and actually has many different implementations that you can choose from.

Basically in the EU, you usually have an ID card (or a passport/driving license/visa card, they're recorded on all of those too) that has a combination of a citizen ID and a document ID. Both of these details are combined considered to be "you" for the purposes of anything to do with the government. The government has a registration of every citizen ID+document ID combination and knows as a result what documents are in circulation. They're technically not required in most of Europe, although you must be able to procure one at request for legal reasons (ie. getting your employment properly sorted, opening a bank account, or a law enforcement official asking for your identity). Revoking a combination is as easy as getting a new ID card/passport since the combination is what counts. ID documents also usually expire eventually, so there's also an inherent time limit to what a leaked combination can cause issues with.

They're also as I understand it, used to handle things like sending everyone voter IDs for elections in advance; this is how the government knows who to send the voting cards to.

Bafflingly, the US does NOT have a national identification method that works like this. There's no country-wide identity document that provides the same assurances. As a result, most US entities (government branches & corporations) have settled on a "closest possible"... which is the social security number. A number that's used to identify every person with attachment to the US in some form since social security is something every US citizen has to interact with. (It also includes a ton of non-citizens since as I understand it, social security is something foreign workers also have to interact with, but that's besides the point.) It's a 9 character long numeric string that identifies you as a person... and has almost no revocation mechanism, even if it ends up in a data breach.

Yet in spite of this, it's still used as a country-wide ID mechanism for a lot of different things and replacing it with a proper ID mechanism has as I understand it (not American) very poor support as it's a culture war issue.

Oops, yes, I meant a constant non-zero rate. It's slightly above mobile phones, where the developer is treated as the problem that needs to fix itself.

Stuff written for one version of MacOS will probably work for the next few versions, but there's just as likely a chance that Apple has decided that you need to do a full on update of all your older tools. Things like dropping Rosetta, 32-bit from the kernel and so on and so forth. There's not really any recourse, unlike Windows and Linux where you can usually finagle a workable solution without having to resort to updating everything all the time (so platform churn exists, but a user can theoretically choose to avoid it).

This is unlike phones, where there's basically no real expectations for when you need to update stuff, so it becomes a case of "you need to test every version". The lack of respect for tool stability is just one other reason why the mobile ecosystem is the user-hostile hell it is; this platform churn pretty much is one of the two roots of why mobile apps are Like That. (The other being that running your own choice of tools is treated as a privilege, not a right.)

Wrote about present day reasons to dislike systemd a few days ago on HN, which encompasses most arguments of actual substance[0] (tldr: Unix philosophy, it homogenizes distros and it may be too heavy for some low-resource environments).

Historic reasons mostly come down to systemds developers being abrasive jerks to people. Systemd has some weird behavior choices that only really make sense from the perspective where every computer is a desktop; ie. it terminates all processes spawned by a user when logging out unless they were made in a specific way with systemd-run. This makes sense on a desktop - users log out, you want everything they did to be cleaned up. On a server it makes less sense, since you probably want a tmux/screen session to keep running when you sign out of your ssh session (either by choice as a monitoring tool, or alternatively because you have an unstable connection and need a persistent shell).

Every downstream distro got surprised by this change[1] and nowadays just ships a default configuration that turns it off, because upstream systemd developers weren't interested in hearing the complaints.

Most of these footguns have been ironed out over the years though.

There's also some really dumb arguments to dislike systemd, most of which just can be summarized as "people have an axe to grind with Lennart Poettering for some reason".

[0]: https://news.ycombinator.com/item?id=46794562

[1]: It was always available, but suddenly turned on by default in an update.

There's a difference between software that's "done" (it never needs updates, ever) and software that's done (it only needs maintenance for security and platform churn).

The former is extremely rare; platform churn alone will usually demand updates, even if your code is otherwise airtight. Forces generally beyond your access will demand that your code is able to conform to platform standards. The demand this places can be very variable and depends more on the platform than you. (Windows has low platform churn since it's possible to futz with compat features, Linux is extremely variable on your codebase, MacOS is fairly constant and from what I know about mobile phones, you're basically signing up to forever maintenance duty).

The latter is much more common; sure, sudo still gets updates but most of those won't be new features. Specification wise, sudo is "done". It does what it needs to, it's interface is defined and there aren't going to be any strange surprises when I run sudo between any system made in the past 10 years or so.

The problem is that when you're selling software, demanding compensation for the former is a hard sell since it's things customers won't see or necessarily care about. Demanding compensation for the latter is much more obviously acceptable.

Still feels very relevant, since I don't think much has been systematically changed.

Structurally, SSL verification is in the same category as stuff like SELinux: most people that interact with it understand why it exists, why it's needed... but the actual process of using anything related to SSL is an exercise in frustration. So the default response is to degrade it or turn it off entirely because shit isn't working for them. (The second search suggestion for SELinux is to change it to permissive, which effectively turns it off without having your distro tools yell at you for disabling it.)

Even today, OpenSSLs interfaces are horrendously designed (if you've ever chose to mess with a proper self-signed cert setup with a custom CA and everything, you'd be aware of how bad their CLI tools are). I wouldn't be surprised if this is a case of it propagating upwards from them; OpenSSLs bad interfaces lead to bad CURL flags, which in turn leads to bad checks by more high level implementations... which goes all the way until you get the HTTP library that just does away with all the fanfare and has a function that accepts all you need for a URL and under the hood handles all those other implementations. (ie. requests for urllib3.)

It also really doesn't help that SSL errors tend to be... unhelpful at the best of times in most cases. You're usually fishing out random error codes that don't seem to have any clear relationship to what you're doing; it creates an aversion to having to engage with the process at all.

And that's for the programming side of things; the dev UX may be bad, but on the user side it tends to be way worse. This isn't about browsers, but it makes no sense that a regular HTTP connection just works, but the moment an SSL certificate is expired for a single second, you have to click through big red scare screens. It'd make more sense if both the certificate and HTTP connection threw up scare screens, but they don't. Instead you just get the strike-through lock of disappointment in your address bar. Makes zero sense.

Ignoring the more stupid reasons why people dislike systemd; there's really only three reasons.

The first is just the simple fact that most people don't want to administer their distro as a hobby. Similarly, distro maintainers primarily care about shipping a complete package that they don't need to mess around with too much. Before systemd, every distro had its own bespoke choices in tools and utilities that were wired to work together. Systemd however effectively homogenized all those choices, since almost every major distro settled on systemd. The main difference between distros now is as a result not necessarily the choices the maintainers made, but things like the package manager and the release schedule, so there's less of an incentive to use other distro's. (This isn't some sort of conspiracy, which the dumber arguments against systemd tend to assume; it's just a case where systemd winds up as the easiest choice - systemd has Red Hat backing, wires complicated things together in a way where it works on most novel PC environments that usually require config fiddling when not using systemd and it's just one upstream maintainers have to submit bugs to rather than a ton of different ones. The reasons to pick systemd as opposed to "one million tools" mostly just comes down to systemd being less of a headache for maintainers.)

The second is that systemd violates some assumptions on how Linux software is "traditionally" designed. systemd is a PID 1 process, meaning it's job is to start every other process on the system. In regular Linux software design, this would be the only thing systemd does. Systemd does this, but it also provides a massive suite of services and tools for things that, historically, have been relegated to separate tools. It's a big bulky program, that while it is modular, is essentially competing with a bunch of other Linux utilities in ways that aren't really standardized. This combines with point 1, where distro maintainers near universally settled on systemd, and what happens is that a lot of non-systemd tools that do what systemd used to do aren't really being used anymore even though the systemd implementation isn't necessarily better.

Finally there is a legitimate, albeit niche, case to avoid systemd. Because it's massive and distro maintainers tend to enable a lot of things in systemd, using it means you're getting a lot of random background processes that use up CPU/memory. If you're constrained by that sort of thing, systemd becomes a pretty inefficient hulk of a program you need to tear out.

I do think a lot of the headaches involving systemd would be simplified if the Linux space had any sort of standardization on how to wire it's tooling together, but outside of the POSIX standard (which doesn't really cover this side of things; POSIX is mainly about userspace utilities and APIs, not "how should an OS's system services behave"), there isn't any. People have rose-tinted glasses about wiring together different tiny tools, when the reality is that it was usually a pain in the ass and reliant on config flags, outdated manpages and so on. Just look at the seemingly simple question of "how do I configure DNS on Linux" and the literal 5 different ways in which it can be set since the "standard" proved to be inefficient the moment things get even a little bit more complex than a single network device handling a single connection. (Which sounds like it'd be the case, but may I introduce the concept of wifi?) Systemd being a big program avoids a lot of these issues.

The spam issue is probably one of the stronger arguments against email centered design for bug trackers, code forges and the like. It's a bit crazy that in order to professionally participate in modern software development, you're inherently agreeing that every spammer with a bridge to sell you is going to be able to send you unsollicited spam.

There's a reason most code forges offer you a fake email that will also be considered as "your identity" for the forge these days.