You probably know this already, but the problem isn't remote desktop into a logged-in session (krdp supports this) but rather logging in remotely into a headless server without a local session running. This is slightly more complicated because the login manager has to get involved and present its UI remotely. This is what that bug is tracking.
Depends on everybody needs obviously, but say you have your dev machine that is remote, and you want to connect to it from a laptop (for real-estate reason or just for working from everywhere you want), maybe you want everything on the same (remote) machine like browser, db, IDE, etc and access to it as a remote "desktop" not just an ssh session.
Of course cli tools would be enough for somebody who likes a full TUI dev environment (and for my own use cases that would be enough) but for some people I understand the need, and I feel it is a regression for them to not have it.
The things that "start going really wrong" are listed immediately after that quote, and have nothing to do with the drop-off trajectory. Epic had problems with the ground stations they were using to communicate with their spacecraft. One of the two stations was offline because of a power failure. Then they "discover[ed] an unlikely incompatibility between their transmissions and the ground station hardware."
On a ride share mission, the primary payload determines the target orbit. If Intuitive Machines decides they want to go to a different orbit, then Epic has to deal with it. But they will be told this well before launch, with enough time to plan how many trajectory change maneuvers they need.
But even though they know beforehand how many burns they'll need, their exact parameters have to be calculated after launch once SpaceX uses the rocket's on-board guidance instruments to determine the actual insertion orbit. Usually this is within a few meters per second of the planned orbital velocity, but you need to know that last bit of error to figure out exactly how long the correction burns need to be. This doesn't change the overall maneuver plan, just the fine details.
The problem was that after launch, when SpaceX gave them the information they needed to calculate the burn parameters, they didn't have a working uplink to command their spacecraft to do the burn. So it just stayed on its original trajectory for longer than intended, getting more off-course the whole time.
Passkeys are a public/private keypair, where the service you're authenticating against has the public key and your browser has the private key. To authenticate, the browser demonstrates that it has the private key by signing and returning a challenge sent by the server.
So, unlike API keys, the actual passkey is never sent anywhere out of your device. Passkeys are more like SSH keys than API keys.
One difference between SSH and the WebAuthn protocol is that the challenge identifies which key it is expecting. So the user doesn't have to explicitly select which key to use.
It turns out the acidic environment in most beverages inverts the sucrose in cane sugar to form a 50:50 mix of fructose and glucose. In the end, the fructose/glucose ratio in cane-sugar-sweetened drinks becomes similar to high-fructose corn syrup, which is about 55:42. And the reaction is quick: about half the sucrose gets inverted in about three weeks. [1]
In this case, multiplication by any nonzero fixed element of the ring is an injection from the ring to itself. Any injection from a finite set to itself is indeed a surjection (and so also a bijection).
After watching the video I was trying to find out just how much one of those microscopes cost. Couldn’t find a price anywhere so I’m assuming it’s far out of my budget. But this kind of video is probably the greatest kind of ad there is, just genuinely showing how cool something is. Don’t have a use for it either though, but I would love to have one anyways.
This would line up with the approach talked about in the video. In very short terms, pictures were taken at various focus distances and height was defined as whichever distance was the sharpest. This would essentially make a 2D height map with all of the artifacts that would come with it
It's has 5x exaggerated height by default, so maybe that's what makes it look wonky. Looks way better by 1x.
If you really want to capture the full visual information of a painting, you'd need full PBR-style data — reflective, refractive, subsurface properties — essentially the response of the surface from any viewing angle in the hemisphere, lit from at least a few fixed directions (like in a museum light setup). Even limited to the visible spectrum, this would massively increase the amount of data needed to represent the image accurately.
The 2019 scan apparently deliberately removed reflections, even though they're an essential part of the artist's intended expression.
Are there models that simulate the actual physical properties of paintings — under artificial lighting, viewed from arbitrary angles? Seems like a worthwhile direction for preserving artworks beyond their flat 2D captures. It could also enable virtually accurate displays of art for single observers using head-tracked screens or VR.
Might also be a promising use case for NERFs or 3D Gaussian Splatting.
I've said for awhile that Pandoc is one of the very few Haskell programs that isn't exclusively used by Haskell programmers.
There are plenty of interesting Haskell programs (e.g. Xmonad, Darcs), but a lot of people explicitly use them because they're Haskell.
Pandoc, on the other hand, is useful to pretty much anyone who has ever needed to convert documents. It's one of the first things I install on most computers.
That's what C++ does because it has no way to ensure that you use the atomic reference counts in multi-threaded code. But, as the author writes in the blog post, Rust can in fact ensure this. So it lets you to use the more efficient non-atomic reference count for single-threaded use, saving the unnecessary cost of various memory access barriers.
Just because a language is designed for concurrent programming, it shouldn't make it impossible to achieve full single-threaded performance, as long as you're not compromising safety.
if you have only 1 thread, you don't atomic, and thus not using atomic reference counts is fine
but if you have more than 1 thread, you can't use a non-atomic refcount, so you can't use Rc but must use Arc.
"but that's such a simple change, just change the decl with a 1 char addition! Pluse, Rust won't let you do bad stuff if you've forgotten to change the type".
I guess I'm just old. Old enough that I've already implemented all the data structures and methods I need in C++, including safely passing around shared_ptr<T>.
And indeed you don't need to care about this, because Rust's type system is looking after this problem, if I use Jim's acrobatics crate, and Jim in turn used Sarah's tightrope crate, which happens to rely on Rc for an internal type which in turn ends up wrapped inside Jim's type which I'm using, my type knows it can't be sent across threads.
In Rust this roadblock is highlighted to Stephan. Aha, we cannot do this. Perhaps Stephan should ask the maintainer of the software they're using for a version which has the properties they desire for threaded use.
In C++ equivalent roadblocks are not sign posted. You may not even realise you're in trouble until some very strange errors begin to happen.
So for the first paragraph, this seems to be severely problematic for any software where someone you know and trust and who continues to have a good relationship with you is no longer available. How important this is will obviously vary, but predicating some important benefit of the language and saying that this benefit won't cause issues in the future because you can "ask the maintainer" is pretty unrealistic for proprietary software.
For the second paragraph, that depends a great deal on (a) what the mechanism used to "send a (shared, ref-counted reference thing) to another thread actually means and (b) what objects are used to accomplish this. Certainly simply writing the address of a shared_ptr<T> in C++ will work out as you indicate. But that's not the only way to do it. Rust's benefit comes from you being "unable" to do it an unsafe way; C++'s benefit comes from the fact that somebody has probably implemented the safe way in C++ already :)
> C++'s benefit comes from the fact that somebody has probably implemented the safe way in C++ already :)
You're an experienced C++ programmer, you already know what the "safe way" will be in C++. "Just don't make any mistakes". There's no possible way to benefit from multi-threading and yet use arbitrary non-thread-safe features magically without problems, the "genius" of C++ is finding a way to blame you for things you can't do anything about.
And then hit annoying roadblocks when you do want to pass those objects between threads?
You should write code to minimize the reference count bumps; they are waste of time whether atomic or not.
If the code spends 0.5% of its time bumping references, and you magically reduce that to zero using alien optimization technology, that only gives you a 0.5% improvement.
If the code spends 10% of its time bumping references up and down, something is wrong.
Yes, Rust also makes it quite easy to minimize reference count bumps. Rc values are moved by default, which introduces no traffic, and increments are explicit calls to `clone`. You can have both optimizations together!
It's even possible to share an Rc-managed value across threads without switching to Arc, as long as the other thread(s) never needs to change the reference count and can be "scoped" (https://doc.rust-lang.org/stable/std/thread/fn.scope.html) to some lifetime that some particular Rc outlives.
It would be very odd for such a transformation to be so difficult that it would impose a roadblock; after all, I'd think it would usually be the application deciding it only has a single thread, rather than something 10 dependencies up the line.
I remember flying VOR radials in Microsoft Flight Simulator 5.1, released in 1995. It came with a printed Pilot's Handbook [1] that included IFR procedures, explained how navaids work, and included various sectional charts.
If you're happy to use Gnome with GDM as the login manager, remote headless sessions are supported already with gnome-remote-desktop: https://gitlab.gnome.org/GNOME/gnome-remote-desktop#headless....