brunoborges

bingo

The point is not how much it made, it is how to transfer that wealth (whether 6B or 60B) out of a non-profit into someone else's account without looking like, or literally being, a criminal.

Infantino clearly wants to see FIFA making billions so he and many others can pocket millions legally. But the only way for this to happen in a non-corrupt way, given that FIFA is non-profit and therefore requires a lot of questionable operations, is to turn FIFA into a business like NFL / MLS.

The problem with that is that it then it is no longer a sport, rather a... business.

UEFA letter is spot on.

Note: I meant [newest]

Nah, this has way more to do with karma points than with "anything that gratifies one's intellectual curiosity".

I've seen submissions by original authors not trending, but then someone with enough karma points booming the same article in a second submission, and then folks having to adjust or point to the original submission to give the proper credit (and karma points) to the author.

Visiting [newest] always has a handful of entries that are genuinely interesting, but never trend. At all.

I challenge HN team to bring one to three random entries from [newest] into the [news] (trending) page as an exercise.

Amazing how an article from Wikipedia easily trends on HN for no good reason, while many posts go unseen under the [new] tab.

Choosing to do an app is quite often less about the capabilities (of an app on the phone, versus a website in a mobile browser) and more about discoverability and market reach. App Stores serve a "store window" purpose, where it is easy to search, easy to discover, easy to access new tools/solutions.

What annoys me is not that "this app could've been a webpage". It is that "this app should also have a web version".

TripIt comes to mind as the opposite way: they started as a website only, and quickly the need to have an app was obvious: GPS integration, offline access, contact list for sharing, and more.

> price is usually purely determined by the net inflows and outflows as decided by humans.

"as decided by humans", more than 90% of trades are led by bots, so no, price is not being determined by humans.

In fact, we have seen time and again how some weird companies get a huge inflow of purchases simply because of bots misinterpreting news articles.

It's time to forbid bots and HFT.

Want to buy/sell a stock?

Humans need to manually submit in the system.

"Help me help you" stands.

This is how tickets for sports and concerts should always be sold.

Entertainment tends to compare with airline tickets, except that with air travel, there are regular flights and competition. There is no such thing as a single flight from Paris to New York on one Saturday at 9pm on a window of a few years.

> Founding cannot be a commodity. If it is, you have no moat or point, meaning you instantly collapse again, because you are an interchangeable commodity.

With the recent AMD announcement [1], local models are likely the future indeed. Cloud will be the place for remote sessions, remote agents, continuous agents. But I foresee a place where phones, laptops, PCs, and even perhaps dedicated hardware just for AI, will be the place for most AI-related workloads.

If you get caught with illegal guns and illegal chemicals, well... there are consequences. Bad actors will always find a way, at the risk of getting caught.

However, the vast majority of people will rely on commercial AI models.

> But I think mostly it will be used to serve ads.

If only...

I do believe that access to commercial AI should be regulated, heavily taxed, and controlled just as much as access to dangerous chemicals and weapons. Only this way the best AI models are more likely to indeed be used for frugal purposes (sadly, however, including ads).

I wonder if there are discussions about POSIX standards on this.

Go to a store that sells fly fishing equipment and talk to a customer or a staff. You may as well end up with a new friend.

Give me the modern interior design with a vintage exterior design.

Sonatype allows "io.github.<username>" as a valid groupId and has a process to verify ownership. I am sure other providers like GitLab can work on this.

That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype.

But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they are generally avoided because they hurt reproducible builds. That means a malicious new release does not automatically flow into most consumers’ builds just because it was published.

I'd go as far to say that NPM should:

1. Enforce scope (namespace) requirement, and require external verification (reverse DNS for example).

2. Disable version range support out of the box. User must --enable this setting from the command line at all times.

3. Remove support for install scripts completely. If someone wants to publish a ready-to-run software, there are plenty of other mechanisms.

It is 100% up to the package manager's steward to control how ownership of packages and namespaces are granted.

Maven Central exists for decades the amount of incidents of people stealing namespaces is minimal.

One can't simply publish a package under the groupId "com.ycombinator" without having some way to verify that they own the domain ycombinator.com. Then, once a package is published, it is 100% immutable, even if it has malicious code in it. Certainly, that library is flagged everywhere as vulnerable.

It baffles me that NPM for so long couldn't replicate the same guardrails as Maven Central.

> Claude Code is really good at stuff like this.

A lot of "Claude Code is best at X" claims are probably user-selection bias.

The people saying it are often exclusively Claude Code users, not people who are actively benchmarking Claude Code against Gemini CLI, OpenAI Codex, GitHub Copilot, and other agent harnesses on the same tasks.

The claim may still be true for certain scenarios, but the evidence is usually anecdotal, not comparative.

Indeed, the fact that maintainers didn't have until only recently the control for disabling Pull Requests tab in a GitHub repo, is what drove a lot of issues in FOSS collaboration over the past decade.

FOSS and open source licenses never ever granted entitlement for contributors to have their proposals reviewed/merged by maintainers. Neither it ever offered entitlement for users to ask for free support.

FOSS is about giving people access to source code so they can do with it whatever they want, and maintainers/authors should have always had the ability to "publish and forget" the source code, without having to deal with those "entitlements".

AI not finding a security issue on cURL has more to do with lack of widespread security issues than the model's capacity of finding them.

Cool... why?

I wonder if a model that does not know anything about a hypothetical programming language X, could write code once given said language X specification, APIs, and SDK tools and their documentation.

Meaning: the model has no idea, no access to examples, no previous codebase trained on, nothing, for language X. But it knows English, it knows how to program in general (training data does contain other programming languages), and everything we expect from LLMs today. It just doesn't know jack about language X.

> Far too often people think productivity is the point. Maybe the point is developer's understanding of the product IS the product?

This is an interesting take.

100%... that's why I say code review became unbearable!

Before AI, shipping code to production used to be a two-person task: one writes the code, another one reviews the code. Now with AI writing the code, the developer that was supposed to write the code, only has to review it. And this is because they are responsible for the code they ship.

Code review has become unbearable because before AI, developers were reviewing code as they went writing it in the first place. Granted, never perfect and why a second person reviewing code was (is?) a best practice. But effectively there was always some level of code review happening as developers wrote code.

I fear it is way more boring to review financial and medical documents completely written by AI than it is to write (and at the same time review) by yourself. And way more dangerous to ship mistakes than in most software.

Makes sense but doesn't explain why open sourcing it, therefore doesn't directly answer the question.

The other cool thing is Copilot SDK, so you can build agentic capabilities into apps, or build tools, that leverage the agent harness of the Copilot CLI:

https://github.com/github/copilot-sdk/