HN user

brunoborges

291 karma

[ my public key: https://keybase.io/brunoborges; my proof: https://keybase.io/brunoborges/sigs/rvxf5NFG9aAHhOB8JL4wlPVEeTcCCMGq53Ej4k-HLNI ]

Posts16
Comments145
View on HN
github.com 5mo ago

Exploring Solutions to Tackle Low-Quality Contributions on GitHub

brunoborges
4pts0
github.com 10mo ago

Jcd: Rust-based CLI tool for enhanced directory navigatio

brunoborges
5pts0
devblogs.microsoft.com 4y ago

Microsoft Joins the Java Community Process (JCP)

brunoborges
2pts0
github.com 6y ago

Stack Allocation in Java's OpenJDK HotSpot C2 Compiler

brunoborges
1pts0
devblogs.microsoft.com 6y ago

OpenJDK for Windows on ARM

brunoborges
10pts0
blogs.oracle.com 8y ago

Open Sourcing Bare Metal Cloud Services CLI

brunoborges
1pts0
sdtimes.com 9y ago

Oracle open sources new tools focused on containers

brunoborges
4pts0
blogs.oracle.com 9y ago

Getting Started with Microservices, Part 2: Containers and Microservices

brunoborges
1pts0
blogs.oracle.com 9y ago

Getting Started with Microservices, Part 1: Advantages and Considerations

brunoborges
4pts0
blogs.oracle.com 9y ago

Three New Open Source Container Utilities (build/run/debug)

brunoborges
4pts0
blogs.oracle.com 9y ago

Oracle to commit engineers to work on Kubernetes

brunoborges
1pts0
github.com 9y ago

Solaris IPS: Image Packaging System (GitHub)

brunoborges
1pts0
blogs.oracle.com 9y ago

Getting Started with Microservices, Part 3: Basic Patterns and Best Practices

brunoborges
1pts0
www.youtube.com 9y ago

[video] Douglas Crockford Keynote about JavaScript at Oracle Code

brunoborges
3pts0
blogs.oracle.com 9y ago

Getting Started with Microservices, Part 1: Advantages and Considerations

brunoborges
1pts0
blogs.oracle.com 9y ago

Oracle Database Python Driver Cx_Oracle Now on GitHub

brunoborges
3pts0

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.

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.

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

Please Use AI 2 months ago

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.

Ferrari Luce 2 months ago

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

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

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.

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.

The more someone is making at their solo business, the less they want to blab about it and attract competitors.

Exactly! And this is why every time I see someone selling a course while bragging about making a lot of money, I know for sure they are _not_ making money.

Yes, but today a 16-year-old building a unicorn is about as likely as winning the lottery.

In today's world, a new digital service is more likely to be successful when attached to celebrities than from pure PLG / Marketing.

I remember a story of an Oracle Database customer who had production broken for days until an Oracle support escalation led to identifying the problem as mere "No disk space left".