cross

7 ms·

1.
by cross 4mo ago
Xoogler here. This hits hard; right on the kidney. That is a huge problem at Google: "we're google; we know what you want and need better than you do." That and an unshakable confidence in their own infallibility. When I was
2.
by cross 1y ago
We don't. When I'm there, I see it addressed as a communal responsibility. Not to be facetious, but the way it's done is a bit of a microcosm of Oxide itself: everyone just chips in and does parts of it as needed. I even file
3.
by cross 2y ago
Linux won in large part because it was in the right place, at the right time: freely available, and rapidly improving in functionality and utility, and it ran on hardware people had access to at home. BSD was mired in legal issues, the comm
4.
by cross 2y ago
The first attempt appears to try and transfer ownership of the allocated memory from the Vec to C, so my first question is, why not allocate the returned memory using libc::malloc? But I do recognize that the code in the post was a simplifi
5.
by cross 2y ago
> If you've been doing C for five decades, it's a shame not to have noticed that it's totally fine to pass a NULL pointer to free(). Or that calling one's FFI function inside of an `assert` means it will be compiled o
6.
by cross 3y ago
I'm not Bryan, obviously, but part of the answer here is that 100 servers running at 100% capacity is an absolute upper bound, but most of the time you're nowhere near that. Most of the time few things are at full capacity, which
7.
by cross 3y ago
This is less of an issue for us at Oxide, since we control the hardware (and it is all modern hardware; just a relatively small subset of what exists out there). Part of Sun's issue was that it was tied not just to a software ecosystem
8.
by cross 3y ago
Sorry, I thought my last message did give suggestions for things to compare?
9.
by cross 3y ago
Well, you're free to study both in detail and draw your own conclusions. But the UART driver in both is pretty uninteresting, and I suspect whatever conclusions one may draw from comparing the two will be generally specious. Perhaps co
10.
by cross 3y ago
> rxv6, at least its userland, still seems to be written in C, which (correct me if i’m wrong) must be creating a lot of pressure on the rust kernel along the lines of ‘unsafe’ and ‘extern “C”’. Yes. I didn't feel the need to rewrit
11.
by cross 3y ago
xv6 was originally written for 32-bit x86; the RISC-V port is a relatively recent development. See e.g. https://github.com/mit-pdos/xv6-public for some of the earlier history. rxv64 was written for a specific purpose:
12.
by cross 3y ago
Probably true. Porting rxv64 to RISC-V probably wouldn't be that big of a lift, honestly.
13.
by cross 3y ago
In a sense yes, but also no. Plan 9 was built with the observation that high-resolution, bitmapped graphics displays were ubiquitous, and there was little motivation to keep the dated "tty" model as a basis for interaction. So you
14.
by cross 3y ago
Yeah, it's really more just a shell at the moment.
15.
by cross 5y ago
So is sed.
16.
by cross 5y ago
PL/1 definitely predates C.