Oh yeah, it also did that for me recently when I asked how I would go about designing a PCB that takes M.2 daughterboards. It recommended stems and threads I should buy. Unfortunately all the product links were dead.
> Slotted pages are composed of three components: a header (containing metadata about the page), cells (variable-sized “slots” for data to be stored in), and offset pointers (an array of pointers to those cells). The benefit of this layout is that you can store variable sized data, since the cells can be of variable size, and you don’t need to move that data to logically reorder it. Reordering the positions of the pointers in the pointer array is sufficient. This is inexpensive since the pointers are small, and in a well-known position at the beginning of the page. In other words, as long as the offset pointers are ordered in key-sorted order, it doesn’t matter where in the actual page the keys are stored.
Does that really make a difference if we have to re-write the entire tree node anyway, even if it's just for reordering the pointers (because node == page)?
> Does that really make a difference if we have to re-write the entire tree node
The I/O write is a fixed cost, but sorting the data to match the pointers would require additional CPU cycles for an outcome that wouldn't really make a difference for subsequent operations.
I think the first three items are "add effects, and do it right":
Capabilities to IO can be done by letting IO functions interrupt and call an effect handler, and the caller can specify the effect handler and do access control in there.
The whole Pin situation only exists because async/await was an afterthought and didn't work well with the existing language. async/await is an instance of effects.
I'm excited to start playing with a language that has a good effect system. I am hoping on Ante, but would also like to try Roc at some point.
I general I agree, but we are also in the paradoxical situation that generic associated constants in traits are stable, but you can't actually use them as constants. You can't use them as const generics for other types, and you can't use them for array lengths.
I'd argue that this makes them pretty useless: if you just want a value that you can use like any other, then you can define a function that returns it and be done with it. Now we have another way to do it, and in theory it could do more, but that RFC has been stale for several years, nobody seems to be working on it, and I believe it's not even in nightly.
If the support would actually be good, we could just get rid of all the support crates we have in cryptography libraries (like the generic_array and typenum crates).
That said, I agree that the Rust team should be careful about adding features.
> Now we have another way to do it, and in theory it could do more, but that RFC has been stale for several years, nobody seems to be working on it, and I believe it's not even in nightly.
What is this way? I have been fighting with this problem for quite some time recently.
> The system that derives truth from experiments - the actual scientific system...
Yes!
> ... is the competitive dynamic between scientists who are trying to tarnish each others' legacies and bolster their own.
Hm. To some degree, sure, that is one dynamic, but (a) this leads to/presupposes a truckload of perverse incentives and (b) this is not inherent in the system if we rearrange incentives
Do you have an idea for a better one? It is pretty darn close to natural selection, which while ugly, does produce surprisingly good results in many domains.
Of course the implementation is far from perfect. For example, the interaction between impact factor and grant funding produces pressure toward ideological conformity and excessive analytical “creativity”. But the underlying principle of competitive scrutiny is probably a desirable one.
> Do you have an idea for a better one? It is pretty darn close to natural selection, which while ugly, does produce surprisingly good results in many domains.
Cooperation is also an extremely fit behavior in natural selection.
Not by itself it’s not. The “selection” part of natural selection is inherently competitive, even if some things cooperate as a competitive strategy. Obviously scientists can and do cooperate within the broader framework of competition.
> “every man hates women” (literally in the second paragraph!)
(from parent)
In case anybody wondered, the article says nothing of the sorts:
> Kate defines misogyny as the enforcement branch of the patriarchy. While sexism is a set of beliefs, misogyny is a set of actions. As such, it is much more damaging to women. Worse, misogyny enforces a patriarchical worldview that the majority of the world holds as the morally correct one. Thus, when women break this norm (i.e., by demanding authority, recognition, space and not providing goods that men feel entitled to like domestic, emotional and mental labor), they are in the wrong. The men are seen as the victims, while the women enduring the misogyny are the bad actors. This viewpoint leads to justification of a number of vile behaviors perpetuated by men – even those men that claim to support and love women.
Just to be clear what happened here, he made the point that if such sweeping negative stereotypes of other groups were thrown about it would be shocking and unacceptable, and your rebuttal(?) is that his examples are shocking and unacceptable and so you won't respond..? QED, I guess.
Well domestic, emotional and mental labor aren't goods, they're services. And I didn't know what emotional labor was supposed to mean, so I read the linked blog post, and it seems to be saying that women who are angry because men won't listen to them have no duty to listen to men who are angry because women were angry at them; also that the author is in principle prepared to have a reasonable and constructive discussion about this under theoretical circumstances. So, I don't know, that's probably true, but the whole business is rotten from start to finish and I'm going to the park now to feed peanuts to squirrels and crows, until some angry human tells me I shouldn't.
Emotional labor, per the feminist that originally coined the term, is actual paid work (“labor” in the traditional sense) that involves presenting or maintaining certain emotions: think a customer service rep, or a waitress.
It has been repurposed by the radfem movement to mean something else. That something else is not super well defined but it has something to do with the coddling that unstable men presumably require to not retaliate against women.
> drop virtual memory mapping support from CPUs, making them faster.
In the video, his argument was that the browsers are single-process anyway, and if everything runs in that process, we don't need that separation. However, since then, we've learned that single-process browsers are a security nightmare, so these days browsers are actually not single-process anymore to provide proper sandboxing.
But I love how close to correct that video is, and it's interesting to see in what ways it turned out to be wrong.
Defense-in-depth is always best practice in security. The more layers the attacker has to break and the harder each layer is, the better. All layers can and will be broken.
Apple has spent a long time hardening the JavaScriptCore web sandbox to run untrusted code. We’ve come a long way since JailbreakMe’s web-based jailbreak, but ultimately memory safety requires participation from all parts of the stack and JavaScriptCore and V8 are still both written in C++. You can trigger memory-safety vulnerabilities in the host VM using guest code.
wasmtime is supposedly a hardened WebAssembly runtime written in Rust, but it’s also a JIT, and I have no idea if anyone has put it through its paces security-wise yet. The idea is that WebAssembly can have JIT-like performance without JIT-like security concerns thanks to a simpler translation layer and minimal runtime.
I could see an argument for dropping some layers if the VM isolation become stronger
> The more layers the attacker has to break and the harder each layer is, the better.
No its not, when it comes to end-user app performance, experience or privacy.
Sure, by adding security we can have another reason to let developers end up with golang app compiled to wasm running within electron sandboxed through API redirection (OS + antimalware/antivirus/BPF based EDR) and use it for, like, listening music in a very secure way..
With all these layers happily streaming all kinds of telemetry to knows where, with owning nothing but a bunch of numbers behind a ton of DRM layers, and with no ability to change things to the point where we can't have an app's theme matching system colors because crossplatform compatibility/security reasons.
I don't want to accept developer's assumption that these have to be enabled by default.
Case 2, Windows: can't even do a build of a trusted codebase under IntelliJ without antimalware adding up, like, +150% to build time. While IntelliJ (or some of its extensions or plugins that creep up during development) is happily reporting that performance issue back to its masters. Ugly.
This may change if you're using a bunch of wasm sandboxes. Browser would split its memory up into multiple sandboxes with a process like interface, but one that doesn't need virtual memory
Amen. Single address OSs would be cool to run trusted code with minimal overhead in-kernel while avoiding crashing the machine because of a bug. But I want more sandboxing, not less, when running untrusted code.
Not really. Godwin's law points to inadequate comparisons to Hitler and the "classic Nazis", whereas your parent points out that he supports real, alive Nazis today.
It's a not a Nazi comparison, it's stating facts. Just two days ago he recommended voting for the German fascist party AfD, in the process regurgitating white supremacist conspiracy theories.
Yes, yes, anyone you disagree with and is more right wing than 20008 Obama is a Nazi. They said the same about Meloni in Italy but that has proved to be very much not the case.
> So if you're ever doing this for a UART or network stream or something, always do the delimiter approach!
I'm confused. I mean for UART, sure. But network streams is usually sent over a protocol that recovers lost data. Am I reckless for sending length-prefixed data chunks over TCP?
No, you're right that this approach is ok for TCP streams. I shouldn't have thrown that in there without clarification that I meant something more generic.
I actually use SLIP for packetisation over TCP anyway, because then syncing for any other logging or diagnostic thing that joins halfway through is easy. Basically I find it to just be a more robust system.
TCP is a stream with no packet boundaries. If you want to separate that stream into a series of messages then you need to do packetisation. The SLIP delimiter approach is a pretty good one.
You're right that it was originally for segmenting a serial link to send separate IP packets (so you could theoretically have SLIP over TCP over IP over SLIP), but it works just as well in other contexts.
reply