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".

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.

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/

https://docs.codeberg.org/codeberg-pages/

> 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.

All it shows the world is why there needs to be a VAT like tax against US digital services to help drive a public option for developers.

There's no reason why the people can't make our own solutions rather than be confined to abusive private US tech platforms.

A better alternative would be to create the incentives so that companies like these can be born in Europe.

I am not sure how someone should be entitled to prevent others from enjoying thr benefits of better technology.

If you do not like it, just skip it, as I do.

Just fix the right things, not the wrong ones.

You are against democracy, I am not. Democracy has led to some of the best advances of civilization, all oligarchies have done is introduce mass poverty, mass misery, and mass death.

At least with democracy we went to the moon for mankind, not shareholders.

Your definition of not letting people choose goes more against democracy that what I mean IMHO.

Just do not let these people collude with the power. Fewer politicians would mean fewer people doing business to influence others through politics.

That is what my experience tells me.

My 2 cents.

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.)

I mean, it is arguably much easier to just write the HTML page and upload it with FTP and everyone can see it. 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.

1) Passive mode. What is it and why do I need it? Well, you see, back in the old days, .... It took way too long for this critical "option" to become well supported and used by default.

2) Text mode. No, I don't want you to corrupt some of my files based on half-baked heuristics about what is and isn't a text file, and it doesn't make any sense to rewrite line endings anymore anyway.

3) Transport security. FTPS should have become the standard decades ago, but it still isn't to this day. If you want to actually transfer files using an FTP-like interface today, you use SFTP, which is a totally different protocol built on SSH.

And if you already knew how to write/make HTML you'd for sure already know all of that too.

I don't always have a server available to host an HTTP+FTP server on. Or want to pay for one, or spend time setting one up. I can trust that Github Pages will have reasonable uptime, and I won't have to monitor it at all.

> And if you already knew how to write/make HTML you'd for sure already know all of that too.

This seems unnecessarily aggressive, and I don't really understand where it's coming from.

BTW, you can absolutely host plain HTML with Github Pages. No SSG required.

That's a completely false statement. My kid took very basic programming classes in school which covered HTML so they could build webpages, which is a fantastic instant-results method. Hooray, now the class is finished, he wants to put it on the web. Just like millions of other kids who couldn't even spell FTP.

No it wasn't. Seriously, where?

a) git pull & push for updates

b) good enough CDN distribution, sometimes interactive examples/project page loads tons of files

c) good enough security promises of the entire platform/infra

d) good enough serviceable time, we do not need 99.9999SLA but better not down often

e) have generous free tier

f) great DX & UX, this one is small but small headache adds up quickly

Sounds like they're cool with a little personal website.

Hey, I’m building Monohub - as a GitHub alternative, and having private repositories is perhaps a key feature - it started as a place for me to host my own random stuff. Monohub [dot] dev is the URL. It’s quite early in development, so it’s quite rough around the edges. It has PR support though.

Hosted in EU, incorporated in EU.

Would be happy if you tried it out — maybe it’s something for you.

Edit: you can have a look at a public repository I have to see what it looks like now: https://monohub.dev/@tbayramov/efcore-audit-timestamps

   ipinfo monohub.dev
  Core
  - IP           188.114.96.1
  - Anycast      true
  - Hostname     
  - City         San Francisco
  - Region       California
  - Country      United States (US)
  - Currency     USD ($)
  - Location     37.7621,-122.3971
  - Organization AS13335 Cloudflare, Inc.
  - Postal       94107
  - Timezone     America/Los_Angeles

Domain whois: https://monohub.dev.whoswho

(Yes, I'm still salty google broke our localhost .dev sites.)

(Yes, I know it was never a reserved TLD.)

Hmm all that operational overhead... Of an ssh server? If you literally just want a place to push some code, then that really isn't that hard.

And no, its not that hard once you learn. Except, now its a never ending chore when it was an appliance. Instead of a car you have a project car.

Can confirm.

Also, not everyone who wants to share content publicly has a domain name with which to do so, or the kind of Internet connection that allows running a server. If you include "hosting" by using a hosting provider... it's perfectly possible (raises hand) to not even have any experience with that after decades of writing code and being on the Internet. (Unless you count things like, well, GitHub and its services, anyway.)

And I believe GP was talking about the only thing you need is:

  ssh user@remotehost git init --bare repo.git

  git remote add origin user@remotehost:repo.git

  git push origin branch_name

then do above.

then troubleshoot.

set vm backup policy.

save myriad passwords and secret to bitwarden.

get ubuntu to stay up to date.

    # locally
    ssh git@example.com
    
    # server
    mkdir repo.git  
    cd repo.git  
    git --bare init
    
    # locally
    git remote add origin ssh://git@example.com/home/git/repo.git  
    git push origin master

Just store the repo and access it with your account.

The whole git@ thing is because most "forge" software is built around a single dedicated user doing everything, rather than taking advantage of the OS users, permissions and acl system.

For a single user it's pointless. For anyone who knows how to setup filesystem permissions it's not necessary.

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).

You don't need a one size fits all solution...

Until the AI scrapers[1] come for you at 5k requests per second and you're doing operations in hard-mode.

1. Most forges have http pages for discoverability. I suppose one could hypothetically setup an ssh-only forge and statically generate a html site periodically, but this is already advanced ops for the average Github user

1: https://code.storage/

Also gitlab has cves like every other week... You're going to be on that upgrade train, unless you keep access locked down (no internet access!!) and accept the admittedly lower risk of a vulnerable gitlab server on your LAN/VPN network.

Even if gitlab is updated fully, you're fighting bot crawlers 24/7.

Step 1.) Stay on GitHub

I think the internet has "GitHub Derangement Syndrome" right now. It's an outlet for people's frustration.

The current trend reminds me a lot of the couple years we had where Game Developers were that outlet. They needed to "Wake up" and not "Go woke, go broke". An incredible amount of online discourse around gaming was hijacked by toxic negativity.

I'm sure every individual has their really good logical reasons, but zooming out I think there is definitely a similar social pathology at play.

I would argue that the open source people aren't the only ones paying attention right now.

If you are hosting proprietary code on Github, it has become clear that Microsoft is going to feed that into their AI training set. If you don't want that, you don't have a choice but to leave Github.

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.

They have been breeding bad will and it is overflowing onto others.

That said, the failure of this post to recognise the problem of the WMF approach does not build confidence in the ability to recognise when users might have a legitimate complaint. That leads them to wonder where LibreOffice is headed.

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.

The original author said they were “the license holder”, specifically with a “the”, in discussions around both Starlette and MkDocs, which yes, just isn’t true even after rounding the phrase to the nearest meaningful, “the copyright holder”. This appears to be an honest misconception of theirs, so, not the end of the world, except they seem to be failing at communication hard enough to not realize they might be wrong to begin with.

Note though that with respect to Starlette this ended up being essentially a (successful and by all appearances not intentionally hostile?) project takeover, so the emotional weight of the drama should be measured with respect to that, not just an additional copyright line.

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.)

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.

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

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.

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.)

Just think about that.

Ironically, a large part of Amazon's rise was on the back of their very pro-consumer policies. Not many companies would tolerate large scale GPU return fraud (among other items) for those many years for example.

Some companies have good intent. Public benefit corporations are a thing. They aren't really relevant, because unscrupulous companies outcompete them.

Your assertion that pro-consumer companies would outcompete unscrupulous ones depends on consumers and regulators holding them accountable. So why are you arguing against being suspicious of companies?

Obviously the best strategy for companies is to appear to be pro-consumer, but "cheat" (meaning price fixing but also things like advertising and buying up competitors) as much as possible. In that context, "all companies are anti-consumer" is a decent shorthand for "you should assume every company is anti-consumer because the regulatory environment favors it, even if there are exceptions."

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.

Notably Servo doesn't have it's own JS engine at all. It uses Rust bindings to SpiderMonkey.