I'd be interested to see what the upcoming Btrfs performance improvements in linux 7.3 do for these benchmarks.
1,088 karma · joined January 1, 2013
> It is our collective assessment that the jury verdict against Greenpeace in North Dakota reflects a deeply flawed trial with multiple due process violations that denied Greenpeace the ability to present anything close to a full defense.
https://www.trialmonitors.org/statement-of-independent-trial...
Commons can fail, but the whole point of Hardin calling commons a "tragedy" is to suggest it necessarily fails.
Compare it to, say, driving. It can fail too, but you wouldn't call it "the tragedy of driving".
We'd be much better off if people didn't throw around this zombie term decades after it's been shown to be unfounded.
The "tragedy", if you absolutely need to find one, is only for unrestricted, free-for-all commons, which is obviously a bad idea.
Unfortunately, the amount of work you need to just maintain the build across language and bazel version upgrades is incredibly high. Let alone adding new build steps, or going even slightly off the well-trodded path.
I feel like Bazel would need at least 5 more full-time engineers to eventually turn it into an actually usable build tool outside Big Tech. Right now many critical open source Bazel rules get a random PR every now and then from people who don't actually (have time to) care about the open source community.
My go-to now is to use mise + just to glue together build artifacts from every language's standard build tools. It's not great but at least I get to spend time on programming instead of fixing the build.
I wanted to make this point here explicitly because lately I've seen this complete erasure of the moral dimension from AI and tech, and to me that's a very scary development.
Notice the phrase "from a moral standpoint". You can't argue against a moral stance by stating solely what is, because the question for them is what ought to be.
I agree it would have been nicer if the message was more polite. But if you compare that to having the backbone follow through with meaningful long-term changes against a corporation you don't trust or respect, there shouldn't even be a discussion.
And don't even get me started with the people who come in here just to point out that Codeberg isn't perfect either.
No, not really: https://news.ycombinator.com/item?id=45232159
> This isn’t selling your soul;
There is a plethora of ethical reasons to reject AI even if it was useful.
Also: productivity is for machines, not for people.
That's what's valuable to you. For me the zero to one part is the most rewarding and fun part, because that's when the possibilities are near endless, and you get to create something truly original and new. I feel I'd lose a lot of that if I let an AI model prime me into one direction.
I'm in the same boat (granted, 10 years less) but can't really relate with this. By the time any part becomes boring, I start to automate/generalize it, which is very challenging to do well. That leaves me so little boring work that I speed run through it faster by typing it myself than I could prompt it.
The parts in the middle – non-trivial but not big picture – in my experience are the parts where writing the code myself constantly uncovers better ways to improve both the big picture and the automation/generalization. Because of that, there are almost no lines of code that I write that I feel I want to offload. Almost every line of code either improves the future of the software or my skills as a developer.
But perhaps I've been lucky enough to work in the same place for long. If I couldn't bring my code with me and had to constantly start from scratch, I might have a different opinion.
Even worse: because it makes it seem like the EU law is just meritless pestering of people, they are actually fighting for the right for worse sites to spy on their visitors.
It's baffling.
They need to be stored, but do they technically have to be stored by just one AppView? I get that it's a 100x easier to implement it like that, but I don't think a distributed search would've been technically impossible (although, granted, necessarily it would have had worse UX).
Choosing this feature and then implementing it like they did was a technical choice. Technical choices have consequences and this, I think, was the one which will prevent BlueSky from reaching any meaningful decentralization.
And saying "you can create an inferior UX with affordable costs" is not a real answer. Any meaningful decentralization IMO can only happen if it's affordable to create feature identical nodes. That can only happen if you refuse to implement features in ways that need centralization to scale.
A clarifying question: the blog post [0] I found about zeppelin.social which I think is a full AppView, the author said this:
"The cost to run this is about US $200/mo, primarily due to the 16 terabytes of storage it currrently uses"
Last I heard the amount of storage was just a couple of terabytes so the growth seems to be very fast.
If and when the primary cost is the storage, IMO the crucial question is: what's the expected future cost of running community AppViews?
Because unless storage cost drops as fast as the BlueSky data grows (unlikely?), to me this architecture looks like it will very soon kick out smaller players and leave only BlueSky with enough money to keep the AppView running.
I didn't know about these recent attempts, they're impressive for sure. However they write[1] about zeppelin:
"The cost to run this is about US $200/mo, primarily due to the 16 terabytes of storage it currrently uses"
So when you here give that $200/mo cost as a price point for "organized groups", you are forecasting that the cost of storage will go down as fast as the BlueSky data size grows? At what rate right now is the data size growing? Because the last numbers I saw were something like 2TB, so it being already 16TB sounds like $200/mo is not going to be enough very soon.
Users can move their follows, followers and posts to zeppelin.social fron BlueSky transparently?
Now you can of course debate on what "decenttalized" means, but in a social network easy migration between servers is the crucial feature that would allow the decentralized network to emerge.
Edit. Does the network actually work over at zeppelin.social alone if Bluesky servers go down?
AFAIK actual decentralization needs still a big engineering effort.
I personally can't even imagine a world where their VC investors would ever sign off a "let's make it possible, easy and risk free the users to exit our silo" project, over the many ways they try to squeeze profit out of their users.
I understand how it happens, but I'd hope people understood that Trump's USA is not the world. Just like people in general know not to extrapolate what Putin's administration is doing in Russia, they need to be able to do the same for the USA. At the moment, in my opinion, both administrations are lost causes, and you can just choose to follow, support and advocate many other positive signals around the world.
But I should've never attempted anything that complicated with MS. They can barely manage simple cases, groups of users is way too hard.
"Each time zone is defined by a standard offset from Coordinated Universal Time (UTC)." (https://en.m.wikipedia.org/wiki/Time_zone)
So the offset is the timezone.
That's why I stand with my original point: if you want to support "clock on the wall" future dates, a geolocation is needed. And given that Germany was two countries in the recent past and Frankfurt and Berlin were in different countries, I wouldn't solve this by picking a city from the help text that's currently closest to the timezone, but instead use the actual geolocation of the event.
P.s. All this is, of course, for 99.99% of the cases a complete overkill, and as said, I haven't had issues in using unix epoch for all dates. But just wanted to say that timestamps aren't as simple as I felt was suggested in the first comment.
Note that I'm not arguing against storing the numeric part in a consistent format, of course you should. My point is that right mow in 2025 you don't know the timezone.
E.g. if you write that as the zones are now, it would be "2029-07-26T11:00:00.000Z", but if the timezones change, then when a person is looking at their calendar in 2029, they will be an hour early or late to the meeting.
So it's not about presentation of the timestamp, it's that the timestamp does not match what the user meant.
> In the same way, place names are localized.
I beg to disagree. All spellings refer to the same phyysical place, but you can't guarantee my example timestamp description and a simple ISO time representation without a geolocation will refer to the same singular point in time.
If by "timestamp" you mean past dates and deterministic future dates, then agreed. (Although I prefer unix epoch in ms for those, to be able to use integers and skip string parsing steps completely.)
But if your unlucky enough to need to handle future dates, especially "clock on the wall" ("let's meet in Frankfurt on July 26th 2029 at 1pm"), then you just can't know the timezone. The reasons can be many political ones, but especially in this case there's a high probability that EU will remove daylight saving time by then.
So in those cases, if you want to be correct, you'd need to include the geolocation in the stored timestamp.
As a counterpoint: isn't popularity of a library more a metric of API convemience than actual code quality?
And isn't popularity of an essay more about how it conforms to existing beliefs than the quality of the thinking?