planede

Well, on their website they say that it's 720p right now, and you can order it. If that info is false, then it's just straight up scam.

Granted, they indeed don't write anything about brightness, apart from the class 2 classification, which they could very well meet. Just not bright enough to be very usable.

Maybe. In the article the photoshopped images look like as if it was green, but the screenshots from the demo videos look blue to me. The article says that it's cyan. Of course white balance could be way off in any of those pictures.

If this is not a scam, then they must be betting heavily on going beyond class 2 for the laser so it will be usable outdoors. 1mW is very low, and my back of the envelope calculation says that it's equivalent to a display to around 120 nits, with the generous assumptions of

1. It's a green laser (it isn't)

2. It's projected onto a white surface, (again, it isn't)

3. 9cm^2 of projected surface area (3cm x 3cm)

Maybe they can modulate the brightness by the amount of stuff present on the projected screen, and maybe even have an outdoor mode, where they use light fonts, that are displayed on a higher brightness, so the overall energy emitted still classifies the device to be class 2. Still, 1mW must be very very limiting here, a 120 nits display is nowhere near usable outdoors, let alone a 120 nits display that reflects the outdoor light just as well as the projector's.

Why on earth they aren't using a green laser if they are limited to class 2 is beyond me though.

AFAIK blaze is also somewhat heavy on templates, but maybe it uses more modern metaprogramming techniques.

Related: https://news.ycombinator.com/item?id=39355944

Taking a recording and sharing the recording are two different things. I think the intention universally is to deter from sharing the recording. Punishing taking the recording is also a way to do that, but I don't see much harm in having private recordings for personal use.

The function pointer is initialized at build time, and put into a read-only section in the executable. This is impossible for default arguments, in general. Many of them would need to be dynamically initialized.

Anyway, it's more than one way antithetical how default arguments work in C++. It's not Python, C++ doesn't have default argument objects in any shape and form. Default argument expressions are expected to be evaluated at call time, with all of its observable implications. The feature itself doesn't mesh well with virtual functions, but there is no reasonable way to resolve it. You either break the intuitions for virtual functions or to default arguments.

When would that default value be initialized?

How do you differentiate between "stretch" and "upscale"? Or how would "stretching" by exactly 2x would make the image blurry?

Upscaling exactly 2x is also an option.

I would say that they are different tools for different purposes. Sure, with pledge/unveil/seccomp you trust the process to do the right thing, it's really about restricting against threats external to the process. But it allows the process to have different privileges at different parts of the program, while external restrictions are not that flexible.

I think it makes sense to use both. Use external restrictions to only give capabilities that the process will ever need, and within the process drop capabilities when they are no longer needed.

The answer is that you retain A as a pure interface and maybe you add a convenience base below A that adds the data member, then you inherit from from the convenience base for your 70 leaf classes. You can also use CRTP for the convenience base, if it's appropriate. You can still avoid confusing interface and implementation inheritance.

Do you mean that the ferromagnetic material gets magnetized and retains some magnetization while moving away?

It's 1/r^4 for magnetic dipoles, where both have fixed a fixed dipole moment. So it's 1/r^4 between two permanent magnets.

Where one object is a permanent magnet and the other is some unmagnetized ferromagnetic/paramagnetic piece metal, then the dipole moment of that piece of metal also depends on the distance. Assuming it's proportional to the magnetic field of the other dipole (~1/r^3) then the force is going to be ~1/r^7 for this pair of objects.

Isn't SawStop patent encumbered? AFAIK the three point seat belt design's patent was made open by Volvo at the time, so the patent didn't hold back adoption.

I think the precision wouldn't compare favorably to a controller, but not only because of less travel, but also because of the lack of a stable and consistent grip that you can have with a controller.

Interesting. I kinda feel that the paint mixing model here is very simplified. Not long ago there was a submission about paint mixing[1] that used a more complex model, where (among other things) you have to consider full spectral properties of the paints getting mixed.

Compressing colors down to a 2D chart that both informs you about color perception and mixing of paints and be 100% accurate is probably impossible, but I guess you can improve on the accuracy of the existing color wheel and be useful as an approximation.

Not sure about how exactly the chart informs about aesthetics and harmonizing colors, that part of dealing with colors just feels overly subjective to me. Apart from this, it's also a third aspect separate from both pure color perception and mixing of paints, so capturing it on the same chart is an additional challenge.

[1] https://news.ycombinator.com/item?id=39515478

I think calling it a default argument object would be much more clear. "Value" can still refer to an abstract, immutable concept, even the python docs use it like that at some places.

Jail already deprives people of human rights. I'm still against the death penalty though.

Is it possible to roll the car over? I couldn't manage to do it however hard I tried. Leaving the ground is hard enough, but possible.

Is this the inverse of trickle down economics?

From https://research.swtch.com/xz-timeline :

2024-02-29: On GitHub, @teknoraver sends pull request to stop linking liblzma into libsystemd. It appears that this would have defeated the attack. Kevin Beaumont speculates that knowing this was on the way may have accelerated the attacker’s schedule. @teknoraver commented on HN that the liblzma PR was one in a series of dependency slimming changes for libsystemd; there were two mentions of it in late January.

I think that this is a plausible explanation for a rushed schedule and an actually justified deadline.

It's good that I otherwise don't click on links in my browser during my day-to-day work. /s

I suppose they won't use macs anyway.

Doh! I don't know why I went with per-byte encoding for octal. Yeah, you can do 11.1% overhead with base8, not much worse than base32, surprisingly.

> you are pretty much information-theoretically optimal

base36 with alphanumeric mode encoding has around 6.38% overhead compared to base10's 0.34% overhead in numeric mode. So numeric mode gets you closer to optimal.

For dealing with larger data I would probably split the input bits into 63 bit chunks, which can be encoded in 19 decimal digits. 63 input bits turn into 19 digits which in turn is encoded in 63.33... output bits on average. This has an overhead of 0.53% instead of 0.34% of pure base10, which I think is acceptable. But then you don't have to bring bignum libraries into the picture, as each chunk fits into a 64bit integral type.

64bit chunks are a little bit worse, with 4.16% overhead, so it might be worth dealing with the little complexity of 63 bit chunks.

I would also output the decimal digits in little-endian order.

edit: If you are willing to go for larger chunks then 93bit chunks would be my next candidate, there the overhead is 0.36%, barely more than pure base10's 0.34%. I don't think it's worth going any higher.

base10 can be awkward to work with for large data, one can also consider:

base8 in numeric mode: 8 input bits -> 3 digits -> 10 output bits, 25% overhead

base32 in alphanumeric mode: 5 input bits -> 1 character -> 5.5 output bits, 10% overhead

I would prefer base32 out of these too, but it's interesting that even base8 beats base64 here.

Response from BSI (British national standardization body): https://www.bsigroup.com/en-GB/insights-and-media/insights/b...

And an article that feels is mostly biased to paint it as a negative: https://www.raps.org/news-and-articles/news-articles/2024/3/...

I didn't find any other recent publication about it. I first read the response from BSI.

It feels like the update at the top entirely invalidates the article. At least I don't see why pinning dependency versions at the source level would be necessary for reproducible builds.