m11a

Graphite seems cool, it’s just unfortunately quite expensive and sometimes hard to convince procurement/etc to invest in when it has a noticeable cost involved.

So I’m really hoping something like Graphite becomes open-source, or integrated into GitHub.

I don't know enough about networking as I should, so to plug for my gap in knowledge, I generally prefer to use more comprehensible (to me) forms of security. And a feature like this:

> Speaking of SSH, Tailscale has special support for it whereby it handles any incoming connection to port 22 from the Tailscale network, and deals with authentication itself. No public keys or passwords: if you’re logged into Tailscale you can be logged into the machine.

kinda worries me (given also IP spoofing is possible?), compared to SSH keys whose mechanism is more obvious and thus easier to trust.

I definitely like the idea of Tailscale as an extra layer of protection, but I'm not sure I'd loosen existing protections while using it, whereas many Tailscale articles often present it as a panacea for internal-network-over-the-internet security. Are my concerns misplaced?

Agree, for now.

But the foundation models will eventually hit a limit, and the open-source ecosystem, which trails by around a year or two, will catch up.

I tried these models half-sceptically.

I ended up blown away. via Cerebras/Groq, you're looking at around 1000 tok/sec for the 120B model. For gentic code generation, I found the abilities to exceed gpt-4.1. Tool calling was surprisingly good, albeit not as good as Qwen3 Coder for me.

It's a very capable model, and a very good release. The high throughput is a game changer.

Email is pretty difficult to reliably self-host though, and typically a PITA to manage. And you really don’t ever want to lose your email address or the associated data. Fewer people could say they properly secure, manage and administer a VPS on which they can host the email server they eventually setup, over say a 10yr period.

Most people I saw offer self-hosted emails for groups (student groups etc), it ended up a mess. Compare all that to say ollama, which makes self-hosting LLMs trivial, and they’re stateless.

So I’m not sure email is a good example of commodity not bringing price to the floor.

At the end of the day, a big part of a good CEO's job is to make sure their company is well-funded and well-marketed to achieve its mid and long term goals.

No AI/tech CEO is going to achieve that by selling AI for what it is currently. What raises more capital, promotes more hype, and markets better? What they say (which incidentally we're discussing right now, which sets the narrative), or the reality, which is probably such a mundane statement that we forget its contents and don't discuss it on HN, at dinner, or in the boardroom?

A CEO's words isn't the place to look if you want a realistic opinion on where we are and where we're going.

Yeah, I feel like I’m missing the point of this. The original purpose of the WAL was for recovery, so WAL entries are supposed to be flushed to disk.

Seems like OP’s async approach removes that, so there’s no durability guarantee, so why even maintain a WAL to begin with?

I think that notion is very specific to Rust's design.

Golang for example doesn't have that trait, where the user (or their runtime) must drive a future towards completion by polling.

I'd agree. There's so many footguns involved in multi-master setups, that most organisations should avoid this until they're big enough to hire distributed systems engineers to design a proper solution for the company. I personally don't love any of the Postgres multi-master solutions.

You can scale surprisingly far on a single-master Postgres with read replicas.

Yes, but async Rust is basically built on tokio's runtime, which is what most the big async libraries depend on, like hyper/axum/tokio etc. And tokio is a thread-per-core work-stealing architecture, which requires Send + Sync bounds everywhere. You can avoid them if you depend on tokio-proper, but it's more icky when building on something like axum, where your application handlers also require these bounds.

A good article on this: https://emschwartz.me/async-rust-can-be-a-pleasure-to-work-w...

That would be ASI I think.

But consider: technically AlphaTensor found new algorithms no human did before (https://en.wikipedia.org/wiki/Matrix_multiplication_algorith...). So isn't it AGI by your definition of answering a question no human could before: how to do 4x4 matrix multiplication in 47 steps?

Barring breakthroughs in robotics, it seems AGI will mainly act through a computer interface, which would primarily benefit countries with a large services economy via productivity improvements. Industrialised Western countries stand out in this regard.

The products and services they develop, and global problems companies in these countries solve, would likely be exported to the rest of the world (probably at some premium).

That's a weak form of lock-in though, because you can switch to another platform going forward, and access your previous Steam purchases for free. No ads, no subscription fee. Stay signed out of Steam Chat and the social stuff, and you've basically just got a heavy application launcher.

Compared to PS+ and Xbox Live, which charge subscription fees to continue accessing online content, it's a pretty sweet deal for the consumer.

It's not clear to me that these approaches aren't already being tried.

Firstly, by some researchers in the big labs (some of which I'm sure are funded to try random moonshot bets like the above), at non-product labs working on hard problems (eg World Labs), and especially within academia where researchers have taken inspiration from biology before, and today are even better funded and hungry for new discoveries.

Certainly at my university, some researchers are slightly detached from the hype cycle of NeurIPS publications and are trying interdisciplinary approaches to bigger problems. Though, admittedly less than I'd have hoped for). I do think the pressure to be a paper machine limits people from trying bets that are realistically very likely to fail.

Use the human brain as an example then. We don't really know how it works. I mean, we know there's neurotransmitters and neural pathways etc (much like nodes in a transformer), but we don't know how exactly intelligence or our thinking process works.

We're also pretty good at working around human 'hallucinations' and other inaccuracies. Whether it be someone having a bad day, a brain fart, or individual clumsiness. eg in a (bad) organisation, sometimes we do it with layers of reviews and committees, much like layers of LLMs judging each other.

I think too much is attached to the notion of "we don't understand how the LLM works". We don't understand how any complicated intelligence works, and potentially won't for the forseeable future.

More generally, a lot of society is built up from empirical understanding of black box systems. I'd claim the field of physics is a prime example. And we've built reliable systems from unreliable components (see the field of distributed systems).

C syntactically is straight forward, but conceptually may be harder than Rust. You’re exposed to the bare computer (memory management, etc) far more than with a GC language or even Rust arguably, at least for simple programs.

Towards deployment is even harder. You can very easily end up writing exploitable, unsafe code in C.

If I were a Python programmer with little knowledge about how a computer works, I’d much prefer Go or Rust (in that order) to C.

Well, the apps often come bundled with a bunch of other stuff. Automatic updates, background workers, telemetry …

All of which sucks up your compute resources and battery. Repeat for every such little utility app you have on your Mac. Some may implement that random stuff inefficiently (eg very frequent telemetry), which sucks even more. Some of it may even be wrong, vibe coded, or copy pasted.

Personally, puts me off installing random utility apps, even if the single utility would be useful.

The solution is kagi.com imo.

Before AI generated results, the first page of Google was SEO-optimised crap blogs. The internet has been hard to search for a while.

Indeed. And aside from that, LLMs cannot generalise OOD. There's relatively little training data of complex higher order constructs in straight assembly, compared to say Python code. Plus, the assembly will be target architecture specific.

I feel like they’re trying to increase switching costs. eg was huge reluctance to adopt MCP and each had their own tool framework, until it seemed too big to ignore and everyone was just building MCP tools not OpenAI SDK tools.

> Do we suppose they will just create a backdoor to allow _some_ bots in?

That, and maybe they will as CF seem quite big on MCP.[0] Or people just bypass the bot detection. It's already not terribly difficult to do; people in the sneaker bot and ticket scalping communities have long had bypasses for all the major companies.

I mean, we can all imagine bad use-cases of bots, but there's also the pros: the internet wastes loads of human time. I still remember needing to browse marketplaces real estate listings with terrible search and notification functionality to find a flat... shudders. Unbelievable amount of hours wasted.

If fewer people are able to build bots that can index a larger number of sites and give better searching capabilities, for instance, where sites are unable to provide this, I'm personally all for it. For many sites, it's that they lack the in-house development expertise and probably they wouldn't even mind.

[0]: https://developers.cloudflare.com/agents/model-context-proto... etc

Neither, my categories only cover "services" (at least as Wikipedia would categorise things into this bracket: https://en.wikipedia.org/wiki/Service_economy).

I agree with you on construction and physical work.

You'll be happy with either. Bishop's approach is historically more mathematical (cf his 2006 PRML text), and you see that in the preliminaries chapters of Deep Learning, but there's less of this as the book goes on.

I've read chapters from both. Much overlaps, but sometimes one book or the other explains a concept better or provides different perspectives or details.

Most ML is disjoint from the current NN trends, IMO. Compare Bishop's PRML to his Deep Learning textbook. First couple chapters are copy+paste preliminaries (probability, statistics, Gaussians, other maths background), and then they completely diverge. I'm not sure how useful classical ML is for understanding NNs.

If so, then it seems the solution is for HN to upvote the random qualified engineer with AI predictions?

"stuck" is a bit strong of a term. 6 months ago I remember preferring to write even Python code myself because Copilot would get most things wrong. My most successful usage of Copilot was getting it to write CRUD and tests. These days, I can give Claude Sonnet in Cursor's agent mode a high-level Rust programming task (e.g. write a certain macro that would allow a user to define X) and it'll modify across my codebase, and generally the thing just works.

At current rate of progress, I really do think in another 6 months they'll be pretty good at tackling technical debt and overcomplication, at least in codebases that have good unit/integration test coverage or are written in very strongly typed languages with a type-friendly structure. (Of course, those usually aren't the codebases needing significant refactoring, but I think AIs are decent at writing unit tests against existing code too.)

> that's not what _humanity_ is about

I've not spent too long thinking on the following, so I'm prepared for someone to say I'm totally wrong, but:

I feel like the services economy can be broadly broken down into: pleasure, progress and chores. Pleasure being poetry/literature, movies, hospitality, etc; progress being the examples you gave like science/engineering, mathematics; and chore being things humans need to coordinate or satisfy an obligation (accountants, lawyers, salesmen).

In this case, if we assume AI can deal with things not in the grey zone, then it can deal with 'progress' and many 'chores', which are massive chunks of human output. There's not much grey zone to them. (Well, there is, but there are many correct solutions; equivalent pieces of code that are acceptable, multiple versions of a tax return, each claiming different deductions, that would fly by the IRS, etc)

Syntactically it's a pretty nice language, with a nice and sane ecosystem (crates, etc), and it's fun to write (which is a pro especially for unpaid hobby projects). If you get used to it, it's nice to write various things in it. I'd probably use it for CLI tools at this point.

You do pay a bit in syntactic overhead (lifetimes, borrow checking perplexities), though you get used to it. I'd still not use it for a standard product-y web app. For CLI tools though, it's pretty good.

I mean, if it was solely about renting machines, we’d all just use DigitalOcean, or EC2 on AWS.

People use things like RDS and EKS/GKE to avoid all the administrative overhead that comes with running these things in prod. The database or its underlying hardware has a problem at 1am? It’s Amazon engineers getting paged, not you (hopefully… assuming the fault hasnt materialised to operational impact yet)

I’d like to see some thoughts on where we go from here. Is there a way we can keep end users protected even despite potential compromise of services like ToDesktop?

(eg: companies still hosting some kind of integrity checking service themselves and the download is verified against that… likely there’s smarter ideas)

The user experience of auto-update is great, but having a single fatal link in the chain seems worrying. Can we secure it better?