j1elo

Well this is nothing but an obvious expectation given the technical level required for doing good quality contributions, no?

I felt this is kinda like there being a large number of people willing to send spam email, but a comparatively minuscule number of people willing to work on ML filters to block it.

It failed because the web browser lets the content know where the mouse cursor is, with absolute precission. It shouldn't.

So in summary:

* GitHub's backwards priorities end up causing a hack on their systems.

* Hackers use their newly gained powers to compromise other people's repos.

* GitHub dectects compromised repo, and suspends the account of its maintainer, so they cannot warn nor act against it to protect or at least warn their community of users.

"I cause a fire, and later ban you for getting burned."

No wonder people are leaving.

> the things that really need X are things you shouldn't do anyway.

I had just finished reading the link in the first post and, frankly, I'm grateful for.the insight it gives. I think we all should have more perspective than what we have around things that we take for granted. Wayland itself would be better if its own devs had done the same.

https://nocoffei.com/?p=451

At last the best option is to have the cake but not eat it too!

Not infra, but final product. I know, corporations move slow. But when there is a critical issue, and an actual desire to solve it from someone in a suit, suddenly turns out that the cogs were always able to speed up and move fast...

What is being said is that a new flag like '--minimum-release-age' would take, realistically speaking, tops 4 hours to implement (without AI assistance), plus a good 1 week of thorough testing, and maybe a 1 month period of progressive deployment. Come on, let's give it a total of 1.5 months, for good measure.

Of course this should have been started since the beginning of the major recent stream of supply chain attacks, circa 2024 or 2025... but even assuming the most backwards calendaring possible -starting after the last bug compromise (Axios, on March 31st)- that new flag should have already been shipped a couple weeks ago.

Shit does take time, but where there's a will there's a way, and nobody buys that this shit would take that much time.

Little did we know that we'd end up in an era where some people end up blindly telling an Evaluator to "Please write for me a Metacircular Evaluator, make it Secure, no mistakes"

After Stop Killing Games [0] has been doing some big steps forward lately, plus movement in the same vein has been showing up in California, we now need to start working on a more general Stop Killing Software act.

[0]: https://www.stopkillinggames.com/

I just didn't want to get into that angle in my comment. Of course there is widespread abuse. But precisely, having this practice explicitly ruled out makes a huge difference and allows calling it "abuse" instead of "just another Tuesday", which is the stepping stone on being able to defend against it.

It's surprising how Wild West it gets out there. In the EU that would strictly fall into unlawful working conditions; I kid you not, in Spain the law doesn't allow to work overtime for more than 80 total hours per year.

Talking about this specifically, yes it's difficult to think of a reason to change ranges in the future.

But bringing my post to a more general stance, I'm of the opinion that Rust is fixated a bit too much on the goal of having a minimal core and leaving the ecosystem to find its own ways forward. Maybe it wouldn't hurt that much if the language, with its current age, started opening up to providing more of the stuff that's currently deemed "inappropriate" for the stdlib. Didn't we have enough time to let the bazaar do its thing and come up with some locally optimal API designs yet? While having a consistent way to version APIs (such as the mentioned Go's /v2) solves the issue of "being stuck forever".

I guess all this to say that extremes are never healthy. The Rust Way is a good one for letting the community discover and experiment, but not even compromising on an async engine is (as always, IMHO) taking it a bit too far.

Why replace the already existing std::range in-place with the new version, and move the old one to std::range::legacy?

That's confusing and not forward thinking, what if a design improvement is found in some years and a new iteration is wanted? Will it end up as a std::range::legacy::legacier?

The other day there was some talking about Go's stdlib around here, and I truly believe they got it much better thought out. std::range should stay where it is, and the new one be introduced as std::range/v2 or std::range::v2 or whatever syntax was deemed adequate.

Solving the problem of how to iterate the stdlib in a maintainable and consistent way would also help to take away the reservations against adding actual batteries to the stdlib. The old adage against adding APIs because "once a new API enters the stdlib, it has to stay like that forever" has meant that Rust never takes a stance to pick a set of opinionated choices for the majority of the community who just want an "official" language-vetted way to get stuff done.

They are burning money to pay for AI-assisted development. Ok. But what is the ROI of it all? Was it worth the supposed increase on efficiency?

Why nobody talks about those points, which are actually the only interesting points of all this AI craze?

> you have to maintain for all eternity, with identical API

People always tout this as a huge reason for not wanting a too big std in Rust (or "too useful" either), but IMHO that's just talking about reaching theoretical optimals, while leaving the community for years without good guidance via providing a opinionated practical and pragmatic way of doing things. Which I find to be a very unhelpful stance for a tool such as a programming language.

If a design of some std package didn't pass the test of time, and a new iteration would be beneficial, the language can leave its original API version right there, and evolve with a v2, with an improved and better thought out API after learning from the mistakes of v1.

Prime example: "hey we found that math/rand had some flaws, so here is math/rand/v2". A practical solution, and zero dramas as a result of having rand be part of std.

That's very shortsighted, this pragmatism might work for a while but when enough companies do the same then some other infra provider would become the new big one, pirate sites would move to it, and La Liga would also block it, bringing everybody to square one.

You truly know that you're totally out of the loop with some topic when you read "Music discovery on the AT Protocol" and think how the heck did they manage to build such thing with just AT Commands against a GSM modem [^]

^ https://ozeki.hu/p_3653-at-command-guide-for-gsm-modem-netwo...

Pawel Jarczak could consider donating the code to an anonymous random friend who happened to upload it to a chinese code forge where development could continue.

I mean, the website is called "Rumors", so their reliability is in compliance with the letter of the contract :-)

Let me tell you a solution for the "FIX IT NOW" types:

> This is an Open Source project that gets developed at the author's discretion. We provide paid work services for urgent fixes, cost is $500 per day with a minimum of 4 days.

Put that in the README, under a header that can be linked to in bug reports from entitled people. Worst thing that could happen is that the maintainer ends up earning a couple grand.

I was like: "it should be Ctrl+Shift+H, of course, right?"

So different tastes :-)

What you describe later is "Auto-populate the find dialog with current text under cursor". VSCode has a setting for that; I guess Zed will eventually end upnadeing one too.

I'm on Firefox 150.0.1 on Windows, and Ctrl+. consistently opens up the Firefox Multi-Account Containers panel, regardless of hitting that shortcut while focusing this same text box I'm writing on right now, or not.

So this sounds like not working as expected I guess.

I wholeheartedly agree. Licensing is a complex topic of which I've read a good deal, and even within the Open Source communities there are usually a lot of misconceptions, so I like chiming in with less commonly pointed but very practical effects of it all, in case it helps someone to learn a tiny bit that day.

In this case the provider would of course have to comply with the AGPL and release their modifications as you mention, but it's important to note that No FOSS license protects at all against, for example, just offering the code as a service. It's the exact reason why Mongodb changed licenses and then a stream of commercial products started to change into "Source-Available" licenses in the recent past.

Platform providers can take (A)GPL code as-is and totally profit from it without paying.

As long as they keep releasing sources of their own modifications -if they ever do any-, the rest is fair play.

Changing the license of already existing code? You might not be able to do that without permission from other contributors, I agree.

But it's MIT license. We can open a company tomorrow, take that code, and start selling it. Further development and improvements of the code could be trivially done openly or behind closed doors. FWIW the author themselves could do that if they wanted.

Open Source has worked fine here. The author doesn't find financial support for the work, so they just want to change winds and that's a perfectly fine path forward.

If this is really much more than a personal project "for fun, on my leisure time", and it became an actually serious product-level project that provides good value in commercial environments for people, there's clearly an opportunity for a for-profit company to step in and cover that niche. But that'd require that users became customers and actually departed from their money to pay for it :)

I guess most will switch instead to asking who's the next project maintainer to work on it, to whom the new bug reports and complaints can continue to be sent for free. But if there's money to be made by using a tool, there should be money paid for using it too. We "just" need to find the new generation of FOSS Financial Sustainability solutions that actually work! Donations don't make the cut.

Then your ideal middle point is called Linux Mint

Here is a simple trick: do accept plenty of open source contributions as-is, without any kind of copyright assignment nor requiring to sign anything that grants power to relicense.

There you go, guaranteed community ownership of the code, best face and "good will" as promised by choosing a FOSS license to begin with, and future rug pulls averted.

Seeing it from the other side of the fence: if you see that all contributors are required to cede controlling power into a single hand (except certain Foundations, yadda yadda), it's not proper Open Source in spirit, only in form; and closeups are just a change of mind away.

What is the performance difference between native FFmpeg and WebAssembly-translated FFmpeg running in a web browser?

Unlike Android indeed, when you maintain a perfectly working phone that happens (by accident or force of nature) to live longer than the official lifetime some executives in a remote office had decided to grant it, the web browser cannot be updated any more. Just the single most security sensitive piece of software of any computer. Who would have guessed people were going to complain!