mustache_kimono

4 ms·

1.
Court shines a further light on who was at fault in SVB implosion(ft.com)
11 points by mustache_kimono 18d ago|1 comments
2.
by mustache_kimono 29d ago
> C being a low-level language is not a myth if, as normal people do, you consider assembly languages to be low-level languages. I'd suggest you're holding that stick too tight! > If you want to argue that there are no low-l
3.
by mustache_kimono 29d ago
> nonetheless intentionally misleads readers 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 s
4.
by mustache_kimono 29d ago
> The article explicitly states 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 asse
5.
by mustache_kimono 29d ago
> You could attempt to make the claim that assembly is no longer a low-level language, but the article explicitly does not do this, instead listing assembly as the low-level extreme that C is being compared against. The article mentions
6.
Bun 1.4: Zig vs. Rust Compile Times(twitter.com)
4 points by mustache_kimono 2mo ago|2 comments
7.
by mustache_kimono 3mo ago
Wow, yeah, really hate this.
8.
by mustache_kimono 5mo ago
> Now it needs to be put into shape so that all the unsafe blocks are eliminated All the unsafe seems to be FFI? https://github.com/search?q=repo%3Aoven-sh%2Fbun+unsafe+lang... > and the code is turned into maintaina
9.
by mustache_kimono 7mo ago
> Why not use a struct of arrays? 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 O
10.
by mustache_kimono 9mo ago
> The two obvious examples 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 wou
11.
by mustache_kimono 9mo ago
> Two examples that I can find 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 ju
12.
by mustache_kimono 9mo ago
> There's been several instances. 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
13.
by mustache_kimono 9mo ago
> Scrubs check hashes, not structure. 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 w
14.
by mustache_kimono 9mo ago
> Imagine that a directory ZAP has an entry that points to a bogus object ID. That would be an example. The ZAP block is intact but its content is inconsistent. The above is interesting and fair enough, but a few points: First, I'm
15.
by mustache_kimono 9mo ago
> Imagine a race condition that writes a file node where a directory node should be. You have a valid object with a valid checksum, but it's hooked into the wrong place in your data structure. A few things: 1) Is this an actual ZFS
16.
by mustache_kimono 9mo ago
"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 ot
17.
by mustache_kimono 9mo ago
> That will also put it on the unfortunate position of being the place that breaks every time somebody adds a bug to the C code. Can someone explain charitably what the poster is getting at? To me, the above makes zero sense. If the Ru
18.
by mustache_kimono 9mo ago
> Why would I use it for s3? 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
19.
by mustache_kimono 9mo ago
> I think that companies like Oracle, SAP, and Broadcom begin to resemble specialized private equity firms This is an entirely fair/accurate. I suppose what I am getting at is that these are just 2 different business models, and, t
20.
by mustache_kimono 9mo ago
The next sentence is more defensible: >> 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
21.
by mustache_kimono 9mo ago
> Page management isn't really a thing we can do well "in user space". But it is the thing most high performance OLTP DBMSs, most of us are aware of, do? I'm also not sure your cite is relevant here. Or it is at lea
22.
by mustache_kimono 9mo ago
> On performance: ... In particular I am thinking how there's a whole body of research of database buffer pool management Why? The solution thus far has been to turn off what the kernel does, and, do those things in userspace, not
23.
by mustache_kimono 9mo ago
> there are many of us who are very thankful for them. Why? Can you explain, in light of the article, and for those of us who may not be familiar with qubes-mirage-firewall, why?
24.
by mustache_kimono 9mo ago
Bryan Cantrill, "Unikernels are unfit for production". [0] [0]: https://www.tritondatacenter.com/blog/unikernels-are-unfit-f...
25.
by mustache_kimono 10mo ago
> I think Rust is more unsafe than C due to supply chain issues in the Rust ecosystem This is such an incredibly cheap shot. First, the supply chain issues referenced have nothing to do with Rust, the language, itself. Second, Rust&#x2
26.
by mustache_kimono 10mo ago
> I'm more interested in the % of rust code that is marked unsafe. I think you should less interested in % unsafe as what the unsafe is used to do, that is, it's likelihood to cause UB, etc. If it's unsafe to interface wi
27.
by mustache_kimono 10mo ago
> Your sense seems more than a little unrigorous. 1/160 = 0.00625. So, several orders of magnitude fewer CVEs per line of code. This is incorrect. Chalk it up to the flu and fever! Sorry. 0.00625 == .625%. or about twice the instan
28.
by mustache_kimono 10mo ago
> Github says 0.3% of the kernel code is Rust. But even normalized to lines of code, I think counting CVEs would not measure anything meaningful. Your sense seems more than a little unrigorous. 1/160 = 0.00625. So, several orders
29.
by mustache_kimono 10mo ago
> So the prediction that incautious and unverified unsafe {} blocks would cause CVEs seems entirely accurate. This is one/the first CVE caused by a mistake made using unsafe Rust. But it was revealed along with 159 new kernel CVEs
30.
by mustache_kimono 10mo ago
> You don't generally need specific versions of GCC or Clang to build it I'm pretty sure. You need a C11 compiler these days with loads of non-standard extensions. Note, for a very long time, one couldn't compile the Linu

More ›