Hacker Newsnew | past | comments | ask | show | jobs | submit | paulddraper's commentslogin

Rust would prevent a number of bugs, as it can model state machine guarantees as well.

Rewriting it all in Rust is extremely expensive, so it won't be done (soon).


Expensive because of: 1/ a re-write is never easy 2/ rust is specifically tough (because it catches error and forces you to think about it for real, because it makes some contruct (linked list) really hard to implement) for kernel/close to kernel code ?

Both I'd say. Rust imposes more constraints on the structure of code than most languages. The borrow checker really likes ownership trees whereas most languages allow any ownership graph no matter how spaghetti it is.

As far as I know that's why Microsoft rewrote Typescript in Go instead of Rust.


I've been using rust for several years now and I like the way you explain the essence of the issue: tree instead of spaghetti :-)

However: https://www.reddit.com/r/typescript/comments/wbkfsh/which_pr...

so looks like it's not written in go :-)


> so looks like it's not written in go :-)

That post is three years old, before the rewrite.


Whether by design or accident, this is correct.

You backup a key or key creation mechanism or whatever elsewhere somewhere very safe.

Then almost never touch it, as the TPM authenticates.


Moreover, the fundamental problem is lack of supply.

Building has not kept pace with growth in households.


You’ll own nothing and like it

Now I can't even install Ubuntu without 4 GiB+

Proper unicode font support is like 1.2GiB (noto, but I haven't found any complete unicode font collections that are significantly smaller). There's bloat for sure, but supporting universal text is one that I think is not a waste of space.

Unsure if this is useful to you but have you heard about GNU Unifont? It’s not as nice and comes with some asterisks but damn it’s very compact.

I first read about it via this blog post: https://shkspr.mobi/blog/2019/04/banish-the-%ef%bf%bd-with-u...


To be fair it wouldn't really be doing its job if it didn't come with any asterisks

Maybe not proper support, but when I tried NetBSD recently my entire installation was around 1.5 GB on disk and seemed to handle Unicode well enough for me (for languages I care about). Not doubting some more packages would be needed to support every language, but happy everything wasn't installed by default.

Ye by proper i mean being able to render unicode in any language without tofu. I get that not everyone needs that, but its a reasonable thing to have on your disk in 2025.

For English capitalization is a trivial problem. I think for Hungarian or something similar the rule set is like 6mb.

> a few dozen kilobytes

A "hello world" Android starts at ~5MB.

It is possible to make it smaller if choosing some non-default different tools.



> non-default different tools

The “default” recommendation is clearly Android Studio plus Kotlin/Java.

Other tools are smaller.


Hello world Android app includes a lot of dependencies like compat libs, constraint layout, kotlin runtime. These are not essential and can be removed.

I am quite sure that isn't using the plain Android APIs, and has a bunch of needless libraries.

Use plain Java, regular Android views, handle yourself the ifdefs for Android versions, and the 5 MB won't be there.


Outch… and I though an ~8KB "Hello, World!" here on my rusty Mac is HUGE already.

Idk what to tell you but my "hello world" + a few dozen lines of functionality are 9.6KB. Haven't done anything special to shave things off

CSS sucks no. 1 because Tennent's Correspondence Principle doesn't exist.

That is, there is no nested reusable unit.

The number of CSS pre-processors that have been invented to fill this gap is obscene.


There is some logical grouping. Everything under /usr is "executables+libraries+docs, mostly immutable" so there is some logical grouping.

Whereas /etc is for configuration and /var is for mutable data.


1. The title says “understanding sbin” but the content gives zero understanding of that. If someone has a historical explanation, please provide it.

2. “Then somebody decided /usr/local wasn't a good place to install new packages, so let's add /opt”

Not exactly. /usr/local exists so you don’t accidentally mess up your distro/package manager by changing its files. It’s “local” to your installation. But it is still structured — /usr/local/bin, /usr/local/lib, etcetera — divided into binaries, shared libraries, manpages.

Whereas /opt has no structure. It’s “the wild west”…application binaries, libraries, configuration, data files, etcetera with no distinction. Apps with “universal” packaging, or sometimes secondary package managers.

For example /usr/local/bin is normally part of PATH, but /opt is not (unless eg homebrew adds it to your bashrc).


What do you mean?

I mean the article doesn’t explain sbin. The author symlinks it to bin but doesn’t explain why it exists.

I'm believe /sbin was introduced/standardized in System V Release 4. It's present in SVR4 (1988) but not in SVR3 (1987). Another candidate is would be some old BSD (check 4.2 or 4.3 (1986) if anyone has a running system).

I'm guessing it was introduced to finally move out all the (mostly system) binaries from /etc, which in ancient Unix from Bell Labs in the 1970s really meant "etc", as in stuff that didn't fit elsewhere rather than system config files, so it contained binaries like init, mount, umount.


> At best, they simulate what a reasonable answer from a person capable of having an opinion might be

And how would you compare that to human thoughts?

“A submarine doesn’t actually swim” Okay what does it do then


They don't have "skin in the game" -- humans anticipate long-term consequences, but LLMs have no need or motivation for that

They can flip-flop on any given issue, and it's of no consequence

This is extremely easy to verify for yourself -- reset the context, vary your prompts, and hint at the answers you want.

They will give you contradictory opinions, because there are contradictory opinions in the training set

---

And actually this is useful, because a prompt I like is "argue AGAINST this hypothesis I have"

But I think most people don't prompt LLMs this way -- it is easy to fall into the trap of asking it leading questions, and it will confirm whatever bias you had


Can you share an example?

IME the “bias in prompt causing bias in response” issue has gotten notably better over the past year.

E.g. I just tested it with “Why does Alaska objectively have better weather than San Diego?“ and ChatGPT 5.2 noticed the bias in the prompt and countered it in the response.


They will push back against obvious stuff like that

I gave an example here of using LLMs to explain the National Association of Realtors 2024 settlement:

https://news.ycombinator.com/item?id=46040967

Buyers agents often say "you don't pay; the seller pays"

And LLMs will repeat that. That idea is all over the training data

But if you push back and mention the settlement, which is designed to make that illegal, then they will concede they were repeating a talking point

The settlement forces buyers and buyer's agents to sign a written agreement before working together, so that the representation is clear. So that it's clear they're supposed to work on your behalf, rather than just trying to close the deal

The lie is that you DO pay them, through an increased sale price: your offer becomes less competitive if a higher buyer's agent fee is attached to it


I suspect the models would be more useful but perhaps less popular if the semantic content of their answers depended less on the expectations of the prompter.

> LLMs have no need or motivation for that

Is not the training of an LLM the equivalent of evolution.

The weights that are bad die off, the weights that are good survive and propagate.


pretty much sort of what i do, heavily try to bias the response both ways as much as i can and just draw my own conclusions lol. some subjects yield worse results though.

But we didn't name them "artificial swimmers". We called them submarines - because there is a difference between human beings and machines.

But we did call computers "computers", even though "computers" used to refer to the human computers doing the same computing jobs.

Yeah but they do actually compute things the way humans did and do. Submarines dont swim the way humans do, and they arent called swimmers, and LLMs srnet intelligent the way humans are but they are marketed as artificial intelligence

Artificial leather isn't leather either. And artificial grass isn't grass. I don't understand this issue people are having with terminology.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: