Hacker Newsnew | past | comments | ask | show | jobs | submit | loeg's commentslogin

License plates have always been required to be legible; that's the whole point. Obscuring them is clearly against the spirit of the law, whether or not that particular method is specifically codified.

Yeah. License plate frames started out with a legitimate purpose--plates bend a lot more easily than plates in frames. But they've gotten crazy.

The streams for some halls from day 1 seem to be here: https://www.youtube.com/@LinuxPlumbersConference/streams but I don't see Main Hall A from yesterday.

https://lpc.events/event/19/contributions/2159/


It might have better abstractions over the current popular operating systems (Windows, Mac, Linux). Obviously not more portable in general.

The existing regulations here might be insufficient. There is definitely risk if the devices are not carefully designed to be safe.

To date I can't think of any existing lasers which you are intended to look at during daily use. Most consumer facing lasers are either class 1 but hidden (CD-ROM), or class 2 but basically not shined into your eye (barcode reader).

There was another discussion a week back https://news.ycombinator.com/item?id=46126780

The lack of accessible certification/testing docs for the lidars is also worrying. Where is the proof that it was even tested? Was it tested just via simulation, via a dummy eye stand-in, or with a real biological substitute?

What if there are biological concerns other than simply peak power involved with shining NIR into the eye? (For instance, it seems deep red light has some (beneficial) biological effects on mitochondria. How do we know that a pulsed NIR laser won't have similar but negative effects, even if it doesn't burn a hole in your retina.)


If it's like everything else, it's "move fast, break things". I'm sure if it turns out to be harmful, we'll find out decades before regulation catches up

> class 2 but basically not shined into your eye (barcode reader)

TIL barcode readers can cause serious eye damage when misused. You'd think they'd have warning labels on these things given how common self-checkout is nowadays and how curious/stupid children can be


They're not always class 2, some are class 1. I'd maybe suspect the self-checkout ones are class 1 since the object is pressed right against it, while handheld barcode scanners are class 2.

>I can't think of any existing lasers which you are intended to look at during daily use

Iphone face unlock users lidar to scan your face when you look at it.


This is a common argument about Rust. Unlike pointer confusion, with index confusion, you still get bounds checking in the containing collection, and you also avoid type confusion (the wrong index element will still have the same type as the object you intended to access). So there are still some benefits.

> This is a common argument about Rust.

Because it is a correct one. std::vector can do this in debug mode, Zig and a bunch of other languages do as well. But that's not the point of why memory safety's important. You opt out of all aliasing and lifetime checks this way, which means an easy off-by one indexing bug (which would be a compiler error otherwise), silently propagates through the system, and you can reference wrong nodes, invalid nodes, uninitalized nodex.

It's even worse in some aspects that a dangling pointer, because you can quickly tell a dangling pointer contains garbage data, but here, the stuff looks plausible.

I am not sure this is a critique of Rust - this certainly goes against the grain of how the language has been designed - which in the case of Rust, might make things easier, since lifetimes are not checked for individual elements, but also less safe.


I don't think this argument is useful to rehash here. That said:

> you can reference wrong nodes, invalid nodes, uninitalized nodex.

No, you cannot access uninitialized nodes in safe Rust.


Sure, though it is very easy to visually identify drivers looking at their phones. (Unless they have illegal tint.)

Only if you're driving next to the car. Speeding obviously can be detected from a distance. Driving under the influence also can be seen from a distance.

I could see having a cop and a camera stationed in a place working as a spotter that then radios to other cops up ahead to pull over in an old school speed trap set up. However, that would take a lot of man power and coordination that I doubt most departments would care to do. We've seen plenty of YT videos of people trying to make a point of catching distracted drivers. The cops just need to give a shit, and want to do something about it.


It doesn’t take a targeted trap or driving next to. It’s like 1 in 6 drivers at any time; it’s super easy to spot if you’re looking. One cop could pick off drivers no problem without any coordination.

As they say, "Hitler drank water."

What about this representation is hostile to humans and ad-hoc traversals? Don't convenience "getters" basically solve usability?

(author here) If you run the parser under a debugger like lldb, then attempt to inspect the AST of a program, it appears as an array of u64. Not very useful, unless you work on special support for debuggers (such as a python script to unpack it in lldb). Compare that to a tree of pointers, you can "expand" nodes without any extra effort.

I guess that makes sense. But I don't ever look at AST in a debugger, and if I needed to, I'd just write some python helpers.

FWIW I think Clang IR does something like this in a lot of places. It is relatively common to see child nodes stored inline following parent nodes. The APIs more or less abstract this away from consumers like static analysis tools, though.

E.g., https://github.com/llvm/llvm-project/blob/62e00a03fba029f82d...

and

https://github.com/llvm/llvm-project/blob/62e00a03fba029f82d...


There are a number of oddball platforms LLVM doesn't support, yeah.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: