The point of mixed reality is that you can beam people into the space. So the people in the room could watch on a TV and be there in person if they wanted, while everyone else was there in VR.
I think you're missing the point Linus made. Panicking is safer from a memory safety perspective, but it's not from a kernel perspective. You'll lose all the file changes that are not saved, you'll risk having disk written in a bad state which can be catastrophic, etc.
Panic in Rust need not equate to a literal kernel panic. It can call an oops handler, which might manage to keep the system operational depending on where the failure occurred.
As far as I'm aware there's no way to reliably catch all panics. catch_unwind does not catch all panics. Handlers don't stop the program from terminating abruptly.
Panic corresponds to a potential logic bug. If you have a logic bug, you already risk its consequences even if the panic didn't happen. As long as panic can be caught (and in Rust, it's indeed the case) it is safer than the alternative.
1. As far as i'm aware there's no way to reliably catch all panics. catch_unwind does not catch all panics.
2. The whole point is that consequences of a panic are worse than the consequences of memory corruption. That's how the kernel was designed. There was an explicit design decision not to kernel panic in every situation where a logic error occurs.
There are tons of edge cases with panics, e.g. panic can trigger a destructor that can panic itself, or unwinding may cross a language boundary which may not be well defined, but to my knowledge `catch_unwind` does catch all panics as long as unwinding reliably works. That disclaimer in the `catch_unwind` documentation only describes the `panic = abort` case.
And I thought it was clear that kernel panic is different from Rust panic, which you don't seem to distinguish. Rust panic doesn't need to cause a kernel panic because it can be caught earlier.
Obviously rust panic is not the same as a kernel panic. What you're taking for granted is that just because rust can catch a panic that it will. A simple overflow can cause a panic. When this happens, the panic might be caught before the kernel panics, but by then the program is probably already in an undefined state. It also might not be caught at all, and cause an actual kernel panic.
The program is in a defined but undesirable state, both when panic occurred in Rust and when a "simple" uncontrolled overflow happened in C (provided that the compiler is configured to not treat it as an UB, otherwise it'd be worse). And anyone doing Rust-C interop already has to be conscious about the language boundary, which happens to be a perfect place to catch Rust panics.
I understand his point. I just disagree, and prefer a different tradeoff.
Yes, a kernel panic will cause disruption when it happens. But that will also give a precise error location, which makes reporting and fixing of the root cause easier. It could be harder to pinpoint of the code rolled forward in broken state.
It will cause loss of unsaved data when it happens, but OTOH it will prevent corrupted data from being persisted.
> But that will also give a precise error location, which makes reporting and fixing of the root cause easier. It could be harder to pinpoint of the code rolled forward in broken state.
I think you must have missed out on how Linux currently handles these situations. It does not silently move on past the error; it prints a stack trace and CPU state to the kernel log before moving on. So you have all of the information you'd get from a full kernel panic, plus the benefit of a system that may be able to keep running long enough to save that kernel log to disk.
On one embedded projected we had a separate debug chip could safely shutdown what might be dangerous circuits in the case of controller failure. The source code for that was much much much smaller than the controller and heavily vetted by mulitiple people. The small dedicated would initiate circuit shutdown on panic from the linux kernel on the controller. My point being is it's hard to know what happens after a panic, and logging and such is nice, but that may or may not be available, but being able to do some action as simple as sending a "panic" signal to a second dedicated processor to shut down critical systems in a controlled manner is nice. "Stop the world" can be very dangerous in some situations. There were even more independent backup failsafes on the potentially dangerous circuits as well, but redundancy is even more insurance something bad won't happen.
Linters like Splint [0] (predating Rust) can do that for C. I’m not saying that Rust’s built-in approach isn’t better, but please be careful about what exactly you claim.
Interesting that despite tools like Splint, 70% of high severity security vulns, including in well staffed projects like Chrome and Windows, are due to memory unsafety. The false negatives of security analysis tools are significant and are the very reason Rust got developed.
No, the reason Rust was developed (with regard to that aspect) was that the necessary static analysis is enforced by the compiler if it is built into the language, whereas otherwise (if not built in) it empirically doesn’t get a lot of adoption. There’s nothing Rust’s static analysis is doing that couldn’t be done with the same semantics using an external static analyzer and linter annotations.
The ideas of Rust weren’t new when Rust was developed. The actual integration into a new programming language beyond experimental status was, and the combination with ML-style functional programming.
Splint doesn't make C memory safe. What I meant is that it doesn't prevent the same problems that Rust does. Hence, you can add a linter to rust to prevent panics. You cannot add a linter to C to make it memory safe.
If you're just doing BFS why do you care who the parent is? Why not just choose the parent to be the predecessor? I.e if you visit 4 from 1, then 1 is the parent. Why do you need to check a list of potential parents?
When visiting vertices in parallel, there might be multiple potential parents that all attempt to visit the same vertex simultaneously. So, we need a way of picking which parent "wins".
Owon vds 1022I served me well for basic stuff. PC oscilloscopes are pretty decent for the $ cost. There's definitely better out there, but if you're in the market for a budget scope, I recommend that one.
Who the fuck is buying vegan meat and being like "oh I thought this was meat"? Do we seriously need to legislate that? There's no real victim here, it's just a bunch of people who are sour or feel threatened by meat alternatives. It's ridiculous.
Just this week I bought two tubs of vegan yogurt by mistake.
They were the same shape, size and color as the milk based yogurts sitting all around them on the shelf. The only clue was the word "soya" printed at the bottom edge of the tubs in small letters. The kind of letters you'd expect to tell you something like the container size or the country the milk came from.
To be fair this vegan nogurt tastes almost the same as the real thing. But I did not appreciate being tricked into buying it.
Of course I see a problem. Transparency should always be a top priority. My intention was not to disagree with you, just to provide a different lens to view this. After all, are most American consumers aware of the conditions in which the animals they eat are raised (what they are fed, how they are treated, what types of drugs they are given, how long they live, general quality of life, etc…)? I believe this is just as important as what gets printed on a label.
Do you realize that almost everyone who buys animal products is being tricked into doing so? It's critical that food companies keep people in the dark about how animal products are made.
I would love to start product line "Beyond Vegan" with tag line of "better than vegan food" with Vegan word being very big. And then have it contain lot of meat. Entirely honest and not in any way misleading marketing. And no vegan should be able to complain.
I think this is misleading in the effect is has. Omnivores still eat non-meat products, but the inverse isn't true and is in-fact pretty fucked up (if the person being deceived believes that eating beef is akin to eating dogs).
I agree that products shouldn't be deceptive, but this is a false dichotomy. More accurately the example should be "Beef Burger", then have it written in small "(dog meat)" as (at least in the West) even meat eaters don't like the idea of eating dogs.
Both beef and canine meat are from mammals. There isn't really much difference between those. Ofc reasonable labelling is reasonable to expect. But they are still meat and nearly every human including vegans can perfectly well eat either.
Same does not apply to companies that try to mislead people by calling something not meat meat or cheese or so on.
Hard disagree. I grew up vegetarian and after 18 years of such a diet I found myself in an environment where I had no choice but to eat meat in order to meet my caloric intake requirements (military basic training, so it was pretty damn low quality meat too -- and don't get me started on field rations (MREs)). I most certainly did not get sick.
Anyone getting sick is most definitely having a psychological reaction (i.e.: a choice) rather than a physiological one. As a young man out in the world on my own I quickly discovered that all the anti-meat propaganda that I was raised with was nothing other than just that. No matter what you're eating, a balanced diet is paramount. Everything in moderation.
Oh wow, every time I see these laws about how "consumers must not be tricked into thinking this liquid oat-based product is in fact not bovine titty juice", I think to myself surely there is no one actually falling for this.
The viciousness in your comment makes it clear though, that it does affect you quite a bit.
Well yeah, we opted for `milk` because it's easier and I do call it milk in my everyday usage if that comforts you. I did get caught up in the post I replied to though, so I apologize for using a degrading sounding name for milk.
My point is, milk is not as clear cut as you think it is: there is cow milk, goat milk, sheep's milk, coconut milk, in German we even have a type of cleaning product that we call a variation of milk (Scheuermilch) ... but almond milk is too much for the everyday consumer? Come on, at least be honest.
Also, yeah I'm sure I enjoyed my mother's titty juice, and I never thought I'd write that sentence. It was good enough for the time being and excellent in my development (I assume), but I have since evolved and moved on to other things without looking back. I'm sure there is a metaphor in there somewhere ...
There's intent too. All of the Almond Milk I buy has the word "Almond" on the package with pictures of almonds. The packages of meat substitutes tend not to be so explicit.
> t's just a bunch of people who are sour or feel threatened by meat alternatives
Kast, a right-wing populist politician in Chile, made a big stink during his failed presidential bid over "Not Milk." He said only milk from "happy cows" should be promoted. These so-called proponents of the free market sure do hate competition.
