LPThinker

I would think an Astrophotographer needs to know which distant objects in the night sky are going to be illuminated and/or washed out when, so maybe that's what it's referring to? I.e. the joke is not that he knows where the sun is pointing on Earth, but that he knows where in the observable galaxy the light will be best for his needs?

Local Privilege Escalation - i.e. someone who is already a non-admin user (whether through other hacks or normally) on your computer getting admin privileges.

My understanding is that they're withholding part of their source code (which is forbidden by AGPLv3 as described in the article) so that they can keep lock people with their devices into their cloud services (and of course corresponding subscription fees, privacy nightmares, etc.), rather than having the printers able to receive files and print them themselves.

Does the livestock figure include the water being used to grow their feed? Probably not because of course there's no guarantee that their feed is Texas sourced. But there are just SO many examples of already too dry places having astronomical amounts of water given (read: stolen legally) to farm stupidly water intensive crops that are only good for feeding livestock like alfalfa.

For what it's worth, the Popover documentation is very explicit that <dialog> is the only right tool for the job when you want a modal:

• modal, meaning that while a popover is being shown, the rest of the page is rendered non-interactive until the popover is actioned in some way (for example an important choice is made).

• non-modal, meaning that the rest of the page can be interacted with while the popover is being shown.

Popovers created using the Popover API are always non-modal. If you want to create a modal popover, a <dialog> element is the right way to go.

One reason you may not have known this is that these (iterator methods, not the Iterator itself) are newish additions to Javascript and only available in all the big browsers for just over 1 year.

This is such an exciting proposal for the web. From what I understand, this would be one of the final hurdles to having WASM "just work" in browsers the way people always expected it to (i.e. having standardized support for directly interacting with Web APIs/the DOM, without any janky glue code and skipping the huge inefficiencies of intermediary JS).

The end result would be developers having a much easier path to implementing huge parts of their applications with native-like speeds in any language they want. Some people will want to do their whole application this way, and others will have specific modules that can benefit hugely from this while still making considered use of the rest of the web platform.

As they say in the article, the current status quo is that this is possible but that ad-hoc/custom WASM modules are out of reach for all but the largest developers because of the cliff of complexity involved in moving beyond the most well-trod paths.

What RCE are you talking about?

To add two numbers, for example, it constructs the midpoint between them, then doubles the distance from the origin.

It's basically a self-defined system of arithmetic, with no actual numbers. e.g. rather than 1 + 2 = 3, you have [radius of unit circle A] + [radius of 2 unit circle B] = [length of 3 unit line C]. I'll confess I don't totally understand how you can extend that to the point that it can correctly implement RSA, but I believe it can be done based on other achievements with unquantified geometry I've witnessed in the past.

For example, this excellent video about constructing flags using only the shape drawing tools of PowerPoint without ever applying external measurements to the shapes.

Servo has been picked back up by a community of devs outside of Mozilla (currently housed in the Linux Foundation Europe) and has been gaining momentum since 2023, to the point it seems to be moving faster now than when Mozilla was funding it.

https://servo.org/about/

The number of times I've seen people link to this thread while completely misunderstanding the context of it drives me nuts. The issue isn't being able to export keys, it's that KeepassXC was making it trivial to export keys in plaintext with no user warning/verification, which fundamentally undermines the biggest security advantage of passkeys - phishing resistance. In other words, if users can be easily talked through exporting their keys via a simple in-app flow that gives them no warning about the danger of what they're doing, then they will do that and be scammed horribly by it.

The person who raised the issue was asking KeepasXC to come up with a better solution for exporting keys - originally he asked them to wait for the now standardized process that every passkey provider uses, but then they settled on showing the user an explicit warning about the danger of plaintext exports in the meantime.

If you choose to read the most hostile and uncharitable subtext into every word a person writes in public, you can misunderstand what he's saying. Otherwise, this is a pretty cut-and-dry example of a person genuinely trying to support the interests of end users.

Hell yeah nushell! Truly a life-changing upgrade.