> I took action as the primary on-call engineer to lock down the AWS account and prevent any actions by possible attackers.
So he suspected an attack, but did not contact his employer about it or other team members. No action taken to mitigate the attack or to identify what was going on. Just changed the AWS root account password and nothing else.
Even assuming the very best intentions, I don’t think it unreasonable that Ruby Central found that a little bit suspicious.
This is the part that strains my belief as well. If you're really the concerned responsible professional working for the greater good of the community, then pick up the (metaphorical) phone ASAP and sort it out, regardless of how pissed off and insulted you are by the boss's incompetence.
That’s my point. There’s not really a singular “Brit” unless you designate one group to decide, and various other groups may also want to be considered British or not. Since I’m from the US, I won’t say more, because I’m sure there’s more to this I’m missing.
For a political action, the blowback has been several thousand-fold larger than the support. So far I’ve seen the tailwind creator, shopify ceo, reactjs creator, creator of ladybird browser, writer of pragmatic engineer, many prominent people in the rails community, and so many others speak out against this fork.
The letter (more like a resume blacklist) has shown that the Overton window has shifted enough to where people can comfortably and publicly call out obviously dumb nonsense.
I say good luck to em ... as they say in their notes:
"We do not want to restrict DHH's freedom of speech, he can write and say what he likes. However, free speech is not "freedom from the consequences of that speech", and we as a community are completely free not to associate with people who hold views we find abhorrent."
I get it. Basically, "I don't want to associate with assholes". That's not unreasonable.
Maybe I’m just not the target audience, but looking at the front page, I don’t see what actual problems this solves. The claims sound nice, but without examples of what they mean in real world use, it’s not really compelling.
I may be wrong, but it gives me some powershell vibe. Since it seems to be targeted for macOS, I would assume it "solves" the lack of powershell equivalent on Mac ?
Powershell 7+ (a long while ago named core) is the version you should use on ALL platforms, including Windows. It's just the most recent version.
"Core" gives off a vibe that it is some limited thingy. It's not, it's full PS.
Murex works on a multitude of platforms, including Linux and Windows. But also a variety of UNIXs too.
It was actually first created before Powershell was available outside of Windows. But some of the design philosophies are fundamentally different to Powershell too. For example Murex is designed to work well with POSIX (bar the shell syntax itself), whereas Powershell reimplements most of the stack, including coreutils.
you certainly can. Omarchy doesn't appear to be anything special, just a tiling WM (of which there are plenty of on macOS: aerospace, yabai, amethyst, etc.) with some preinstalled applications + basic dotfiles. people have been running similar setups for years on macOS
Are you aware that Omarchy is just a bunch of scripts on top of a GNU/Linux distro, which has been available in one way or another for the past three decades?
This exceedingly uninformed rant makes more sense when you understand that the author has his own timestamp format he wants to push.
Counterpoints:
- UUID is not random characters, it's a 128 bit number and is stored as such in many databases. It can be presented as a hex-string with dash-separators, but it doesn't have to be.
- There are several types of UUIDs. UUIDv4 is mostly just random bits. Others have time and machine numbering, like Snowflake IDs. UUIDv7 has a combination of time and randomness.
- UUIDv7 was made to address the database index problem, rendering that point moot.
Lots of tools understand and/or support UUIDs.
You can complain about the overhead of storing and indexing 128 bit numbers if you want, but realize that a string like 2025_P5U5_326662 is likely also going to be stored as 128 bits. And the added value of having the year in front (the rest is not going to mean anything to the average user) is not that great.
I love Forgejo. I recently started a project to exit my business (and eventually personal) git from Github. Gitea was my target having ruled out GitLab based on prior experience administering an instance, but I ended up going with a Forgejo and I am glad I did. The Gitea shenanigans around the for-profit entity and its opaque ownership structure were mainly what left a bad taste in my mouth, but there were a few other more minor factors that were use case specific. Fedora recently decided to switch to Forgejo, which is quite a feather in their cap.
I also was somewhat skeptical that a git hosting platform that had a business behind it with enterprise oriented offerings wasn’t yet self-hosting in the technical sense.
Same here. Forgejo is amazing and their development velocity is soaring. And https://codeberg.org is a great host for FOSS projects, in a way I wished Sourcehut would've been except that it leaned hard into some (to me) strange workflow choices.
> The Gitea project is still community-driven and has the same yearly elections for leadership that has been around for close to a decade now :)
[1] mentions changes to the election process that mandates half of the oversight committee to be appointed by the Gitea company. Doesn't that conflict with your assertion that the "same yearly elections" have been around?
Where can one find the governance charter for the Gitea project?
> Gitea Enterprise is an offering of CommitGo, not the Technical Oversight Committee of Gitea or the Gitea project itself. CommitGo remains committed to contributing back functionality to Gitea under the MIT license.
Yup, this is the case. I'm the main author on that PR. It sadly stalled due to reviews from other maintainers requiring it to be rewritten using another library, but hopefully I'll be able to get back to it, or someone else will be able to pick it up. We've been able to get other functionality into Gitea already, and I've personally funded maintainers and others' work for the project, which goes directly into the project itself.
I'm the main author of the PR to implement SAML in Gitea, and it sadly has stalled due to reviews from maintainers requiring it to be rewritten entirely using another library. Our governance charter requires a certain process for PRs going into Gitea, and cannot be side-stepped by anyone. As for some of the others, we've been able to merge them in already.
SAML was just an example - I didn't see the PR before I made that post. That said, it feels fundamentally incompatible to a business strategy where your community edition is able to offer all of the features of the premium offering. I just can't see how that business would be able to survive if they allow that to happen.
I'm always dubious of freemium software, because the free version is always gimped in some way, be it SSO compatibility (OK, yours supports OIDC it seems so that's not _terrible_), role-based access controls, high availability, etc.
I will concede that businesses probably _should_ be paying for good software that is critical to their business to help support the vendors, but given how important cost savings are to companies these days, one can hardly blame engineers looking for cheaper offerings.
The difference between the Gitea project and the Gitea Enterprise software offering is with Gitea Enterprise we are able to include code written that was rejected by maintainers (eg. mandatory 2FA as an example) as there was still a desire for it. Luckily it was since rewritten in a way that was acceptable for the project and now it's been accepted/merged. The company has also written code that was under contract from other companies, and so they own the IP and thus cannot be accepted by the project due to not being able to be DCO compliant. Those companies are receptive to open-source, and we are working with their legal teams to be able to have them release their claim to the code so we can submit it to the project (large corpos are not known for their speed and understandably want to do their due diligence to ensure that all i's are dotted and t's crossed). There are around ~50 community maintainers that have exactly equal say over PR reviews, etc.., and that process has always been strictly adhered to.
Edit: Gitea has LDAP, OAuth2/OIDC, OpenID, SMTP, reverse proxy, and others as SSO options.
I agree with your last point, but as someone who co-owns a technology business that doesn’t have an “Enterprise” sized bank account, I still have all of those needs.
The SSO tax in particular is ridiculous.
Functionality like HA or SSO being gated behind enterprise licenses only makes it harder for smaller businesses to “get there”. My business is comprised exclusively of technology professionals. We tend to be really cheap customers to have because we typically only raise a ticket when something beyond our responsibility breaks.
And from the community side — I already have enough credentials to maintain in my personal life. It’s annoying when you can’t use SSO with a community edition product. I like having SSO at home. It makes life so much better, and it also makes me more likely to use a product in my business, which makes it more likely I’ll buy a license to backstop support.
Gitea has SSO using many different ways, such as LDAP, OAuth2/OIDC, OpenID, SMTP, etc.., and it would have SAML too (I'm the main author on the SAML PR to the Gitea project), but it's been held up by community reviews requiring esentially an entire re-write with another library. We'd love some help to get it across the finish line :) In open-source, money isn't the only thing that can be spent; we can also use our time.
> what happens when a community member wants to implement SAML for the community edition
It's surely just business model, but I was intrigued and thought that maybe there were some kind of incompatible licensing in popular libraries people use for these so-called "premium features"
Gitea would have SAML too (I'm the main author on the SAML PR to the Gitea project), but it's been held up by community reviews requiring esentially an entire re-write with another library. We'd love some help to get it across the finish line :) In open-source, money isn't the only thing that can be spent; we can also use our time.
A lot of people don't realize that all these so-called issues with TCP, like slow-start, Nagle, window sizes and congestion algorithms, are not there because TCP was badly designed, but rather that these are inherent problems you get when you want to create any reliable stream protocol on top of an unreliable datagram one. The advantage of QUIC is that it can multiplex multiple reliable streams while using only a single congestion window, which is a bit more optimal than having multiple TCP sockets.
One other advantage of QUIC is that you avoid some latency from the three-way handshake that is used in almost any TCP implementation. Although technically you can already send data in the first SYN packet, the three-way handshake is necessary to avoid confusion in some edge cases (like a previous TCP connection using the same source and destination ports).
They also tend to focus on bandwidth and underestimate the impact of latency :)
Interesting to hear that QUIC does away with the 3WHS - it always catches people by surprise that it takes at least 4 x latency to get some data on a new TCP connection. :)
Slow start is about saving small-integer-numbers of RTT times that the algorithm takes to ramp up to line speed. A 5-30 second load time is an order of magnitude off, and almost certainly due to simple asset size.
Will be interesting to see if they can make it stick. Everyone is used to Windows + Office, so there’ll be a lot of resistance to trying something else, and if their IT department is not ready for it, it can quickly become a shit-show.
This is the standard voice of someone who's never had to deal with a badly maintained or managed open source product or an asshole maintainer or had to run a fork for 6 years because no one will merge a trivial fix in. Or had a LibreOffice bug open for a decade.
Yeah I can really get in there and spend 2 years ripping the horrible UI out, then have to run a fork because it's not of interest to the maintainers and will never be merged.
At that point I'll just use MS office. Costs me 10 minutes salary a month.
I don't understand these stories: Do people talk to the maintainer before they work on the change? If not, why not? It seems necessary and obvious to get people on board before you invest in something.
If you can get a discussion going with the maintainer, which is not a guarantee (cant speak to libre maintainers, but I know other projects like this), then you have to convince them that your change is both valuable and reasonable for them to maintain. The latter part there is key - they are _maintain_ers. You write the code once and then run off. If you write some new UI in some fancy framework then they have to live with it forever and learn a new framework to support it. Its a big cost for them, so on smaller projects maintainers can get defensive/grumpy
Man, I hate how excel behave a lot of times but I thank God everyday that it exists.
On the backend while writing macros you discover a lot of...interesting choices
Like how sometimes my macros failed because it does not interface with the regional formatting of the system (had to take 0.34 and convert it to 0,34 by converting it to string). The reverse is not necessary.
How value and value2 exists as property of a cell (I will bet whatever you want that it was a temporary name) and how the "value" behavior is dogshit.
How stuff is hyper advanced but stuff that SHOULD work does not....
Not everyone has an extra 20 hours a week to contribute to open source, and I'm assuming a project as big as LibreOffice has a lot of non-technical hurdles in place for anyone new. It's perfectly reasonable to donate to people already working on it tho.
He didn't want to do work himself, he wanted to contribute monetarily and have the desired outcome provided to him. That's the not-nice thing about Open Source.
The comment said 'organizing this', not doing the development work. That could mean crowdfunding to fund development of the desired outcome.
A faff, of course, but perhaps a better deal than contributing monetarily to Microsoft to have Copilot shoved in your face instead of the features you actually want.
The converse of this is the bad thing about open source. Although seemingly nothing's stopping people sometimes, somehow stuff still tend not to get done.
So he suspected an attack, but did not contact his employer about it or other team members. No action taken to mitigate the attack or to identify what was going on. Just changed the AWS root account password and nothing else.
Even assuming the very best intentions, I don’t think it unreasonable that Ruby Central found that a little bit suspicious.