Comments URL: https://news.ycombinator.com/item?id=49756250

Points: 11

# Comments: 1

I'd suggest you're holding that stick too tight!

> If you want to argue that there are no low-level languages when it comes to programming modern CPUs, you are free to do so, but that is a different argument.

Not if you read the whole article?

> And it is arguably not a fruitful one because then the terminology loses all meaning. Okay, you've defined assembly as a high-level language.

Again, what if the terminology isn't very important? I'd argue the distinction between high and low level languages is not an important distinction, because it is so crude. For example, C/C++/Rust have all been described as high level languages at one time or another. C people seem to be the only ones that take real offense to this.

I'm really not certain that's the idea, and it certainly does not feel very charitable. Perhaps you are holding on a little too tightly to this high vs. low level distinction (the simple mental model being attacked)? I compared the author's argument to a reductio. A reductio is not intentionally misleading?

This paper reminds me of "It's Time for Operating Systems to Rediscover Hardware". See: https://www.youtube.com/watch?v=36myc8wQhLo

There, an argument is made that our simple model of "the machine" is also wrong. There, the speaker points out much of the software that is running on our complex SoCs, with multiple cores, is firmware. To which, I'd imagine you might argue: "But that firmware is not the OS?! This talk is misleading!"

> If the author knew this, and his central premise were that no low-level programming language existed anymore, the article would be titled differently and he wouldn't be making the arguments against C specifically.

I am not sure. I believe the reason C is targeted specifically is because C communities are where this myth, and its religiosity (!), is the strongest.

> But this is essentially packaged as clickbait

I'd agree that the article is provocative, but it would seem to have good reason to be. Lots and lots of people think both C and our processors must work one way. That there is or was some level of naturalism/determinism at play. The author is simply pointing out -- not so much.

> After writing out my charitable interpretation of the author's capabilities, this interpretation only leaves me more disgusted with the article as a writing output.

Yes, it was designed to make you mad. But if you were forced to write a rebuttal to the entire article, from a charitable POV, I think you'd see there is some value to the reader in realizing this tight coupling (C and processor design) is not a necessary condition.

Again -- I think your impression is the result of the contentious tone of the article. Yes, the article explicitly states:

    "Think of programming languages as belonging on a continuum, with assembly at one end and the interface to the Starship Enterprise’s computer at the other. Low-level languages are “close to the metal,” whereas high-level languages are closer to how humans think."

See the very next section "FAST PDP-11 EMULATORS"

    "The root cause of the Spectre and Meltdown vulnerabilities was that processor architects were trying to build not just fast processors, but fast processors that expose the same abstract machine as a PDP-11. This is essential because it allows C programmers to continue in the belief that their language is close to the underlying hardware."

See also the section "IMAGINING A NON-C PROCESSOR", where the author explicitly discusses alternative processor designs (which would of course require new assembly languages!).

The author is actually trying something like a reductio on your mental model. When the author states "Think of programming languages as belonging on a continuum", the author is really saying "This is everyone's impression, but ... when you look a little deeper you see the cracks (which are actually contradictions)."

The article mentions assembly once. But it's not an argument about how assembly is "low level" and C isn't, although it may sound like that, upon a first reading, given the article's contentious tone.

The article is really an argument about how C programmers believe, and constantly state, that they are programming "close to the metal", but what they are really programming is a very fast PDP-11 emulator with lots of implicit behavior.

Implicit behavior like speculative execution and asynchronous execution and lots and lots of caching.

Comments URL: https://news.ycombinator.com/item?id=49382812

Points: 4

# Comments: 2

All the unsafe seems to be FFI?

https://github.com/search?q=repo%3Aoven-sh%2Fbun+unsafe+lang...

> and the code is turned into maintainable, readable, reasonably idiomatic Rust. I wonder how long is it going to take.

This isn't a c2rust rewrite?

I would assume because then the shape of the data would be too different? SOAs is super effective when it suits the shape of the data. Here, the difference would be the difference between an OLTP and OLAP DB. And you wouldn't use an OLAP for an OLTP workload?

Appreciate this rincebrain. Know that you know better than most and this certainly covers my 2nd point. I don't imagine these cases cover my first point though? These are not bugs of the type a fsck would catch?

I think you may be misreading my point above. I am not arguing ZFS doesn't have bugs. That's nuts. I am arguing that the bug the parent says he has would be an extraordinary bug.

This is not just a bug that a scrub wouldn't find, but also it is a bug which an fsck would find. And it is not just a bug in the spacemaps or other metadata, but the parent's claim is this is a bug which a scrub, which is just a read, wouldn't see, but a subsequent read would reveal.

I think you're missing the 2nd feature to the parent's point that I take issue with, which is this is not just a bug that a scrub wouldn't find, but it must also be a bug which an fsck would find.

The parent's point is -- ZFS should have an fsck tool because an fsck does something ZFS cannot do by other means. I disagree. Yes, ZFS has bugs like any filesystem. However, I'm not sure an fsck tool would make that situation better?

How is the structure not valid here? Can you explain to us how an fsck would discover this bug (show an example where an fsck fixed a similar bug) but ZFS could never? The point I take contention with is that missing an fsck is a problem for ZFS, so more specifically can you answer my 4th Q:

>> 4) If so, wouldn't this just be a bug, like (a bug in) fsck, not some fundamental limitation of the system?

So -- is it possible an fsck might discover an inconsistency ZFS couldn't? Sure. Would this be a fundamental flaw of ZFS, which requires an fsck, instead of merely a bug? I'm less sure.

You do seem to at least understand my general contention with the parent's point. However, the parent is also making a specific claim about a bug which would be extraordinary. Parent's claim is this is a bug which a scrub, which is just a read, wouldn't see, but a subsequent read would reveal.

So -- is it possible an fsck might discover this specific kind of extraordinary bug in ZFS, after a scrub had already read back the data? Of that I'm highly dubious.

The above is interesting and fair enough, but a few points:

First, I'm not sure that makes what seems to be the parent's point -- that scrub is an inadequate replacement for an fsck.

Second, I'm really unsure if your case is the situation the parent is referring to. Parent seems to be indicating actual data loss is occurring. Not leaking objects or space or bogus object IDs. Parent seems to be saying she/he scrubs with no errors and then when she/he tries to read back a file, oops, ZFS can't.

A few things: 1) Is this an actual ZFS issue you encountered or is this a hypothetical? 2) And -- you don't imagine this would be discovered during a scrub? Why not? 3) But -- you do imagine it would be discovered and repaired by an fsck instead? Why so? 4) If so, wouldn't this just be a bug, like a fsck, not some fundamental limitation of the system?

FWIW I've never seen anything like this. I have seen Linux plus a flaky ALPM implementation drop reads and writes. I have seen ZFS notice at the very same moment when the power dropped via errors in `zpool status`. I do wonder if ext4's fsck or XFS's fsck does the same when someone who didn't know any better (like me!) sets the power management policy to "min_power" or "med_power_with_dipm".

    "Scrubs differ significantly from traditional filesystem checks. Tools such as fsck or chkdsk examine logical structures and attempt to repair inconsistencies related to directory trees, allocation maps, reference counts, and other metadata relationships. ZFS does not need to perform these operations during normal scrubs because its transactional design ensures metadata consistency. Every transaction group moves the filesystem from one valid state to another. The scrub verifies the correctness of the data and metadata at the block level, not logical relationships."

A scrub literally reads the object from disk. And, for each block, the checksums are read up the tree. The object is therefore guaranteed to be correct and consistent at least re: the tree of blocks written.

> Unfortunately it's possible for ZFS bugs and issues to give you filesystem objects that have problems

Can you give a more concrete example of what you mean? It sounds like you have some experience with ZFS, but "ZFS doesn't have an fsck" is also some truly ancient FUD, so you will forgive my skepticism.

I'm willing to believe that you request an object and ZFS cannot return that object because of ... a checksum error or a read error in a single disk configuration, but what I have never seen is a scrub that indicates everything is fine, and then reads which don't return an object (because scrubs are just reads themselves?).

Now, are things like pool metadata corruption possible in ZFS? Yes, certainly. I'm just not sure fsck would or could help you out of the same jam if you were using XFS or ext4. AFAIK fsck may repair inconsistencies but I'm not sure it can repair metadata any better than ZFS can?

Can someone explain charitably what the poster is getting at? To me, the above makes zero sense. If the Rust code is what is implemented correctly, and has the well-defined semantics, then, when the C code breaks, it's obviously the C code's problem?

You have it the wrong way around. Here, ZFS uses many small S3 objects as the storage substrate, rather than physical disks. The value proposition is that this should be definitely cheaper and perhaps more durable than EBS.

See s3backer, a FUSE implementation of similar: https://github.com/archiecobbs/s3backer

See prior in kernel ZFS work by Delphix which AFAIK was closed by Delphix management: https://www.youtube.com/watch?v=opW9KhjOQ3Q

BTW this appears to be closed too!

This is an entirely fair/accurate. I suppose what I am getting at is that these are just 2 different business models, and, the world can sustain a multitude of business models. There need not be only one (har har).

It's also fair to believe there is a moral dimension to one's own model which doesn't extract maximum value from the customer. Because IMHO "let's kick them in the dicks again" isn't an especially likable model, even if it is successful, and it's fair to avoid doing business with such people.

Imagine trying to sell your partners on doing business with Broadcom. If your core principle is "Broadcom needs to be around in 10 years", maybe the persistence/"kick them in the dicks" model is appealing, but otherwise, its fair for their competitors/Oxide to point out how awful dealing with a corporate sociopath might be.

>> Certainly, these companies not endure as innovators: when coercion is your business model, innovation is not merely unnecessary but actively antithetical.

Oracle and VMware do seem like just rent seekers. I'm sure those rents do pay for plenty of nice things, but it's really hard for me to ever understand Oracle or VMware as an "innovator", beyond their initial innovations (their flagship DB, x86 virtualization).

> Oracle has endured nearly 50 years. Sun did not endure.

IMHO it's perfectly fine for companies to live well, and then be sold. AFAIAC persistence is only proof of persistence. Sun created plenty of wealth/millionaires too. And, by Bryan's lights, it did so mostly ethically. That's a good life.