Yep, first instance I know of was from back in 2009, https://www.theguardian.com/technology/2009/jul/17/amazon-ki... and the kind of thing keeps happening over the years. It'll continue to happen since you aren't paying for a book. You're paying for a license to read the book for as long as the publisher/owner allows you to do so and they can revoke the permission at any time.
I still find it hilariously ironic that the first instance that was widely reported (as far as I know) was it happening to 1984.
It'll be very useful for even local setups when the data needs to be confidential. Look at the research related to medical training of llms (ignore their current lack of direct usefulness/trustworthiness, those are potentially solvable), with a homomorphically encrypted session, the large inference servers never see hipaa protected data in a way that exposes it if the server is compromised even if its an on premises setup in your doctors office processing the data, reducing risk of the data leaking anywhere.
It's more than just for cryo-freezing and attacks like that, it also helps defend against row-hammer and other DRAM refresh related issues since the scrambling means that the host kernel or application can't determine what the physical bits on the chips are going to actually be and end up determining the layout in a way to flip specific bits. It might still be possible but it's yet another layer of defense against memory related security problems.
The five command part isn't really possible but you can use custom diffs for merges, git diff, etc. pretty easily. There are projects like diffsitter ( https://github.com/afnanenayet/diffsitter ) for doing more intelligent diffs like this for supported languages.
I think its one reason ive been happy with software based epub readers where upgrading is usually reasonable to do. Either on my phone or android based eink reader. That said if they change too much then yea nobody will produce the new standard and only support the old one if it isnt carefully designed for graceful degredation.
Neat, definitely a part of history that I'm not familiar enough with myself since I was only ~6 or so around then when the article was published.
It definitely seems to reinforce the joke backronym of "People Can't Memorize Computer Industry Acronyms" for the whole thing given how badly it was all refered to. It's a lot like the whole Clippit/Clippy situation with the Microsoft Office assistants. Originally it was only named Clippit but Clippy got coined by everyone else and even Microsoft ended up giving in and using it in marketing materials not too long after the fact.
The Pi 3B doesn't have UEFI support, so it requires special support on the distro side for the boot process but for the 4 and newer you can flash (or it'll already be there, depending on luck and age of the device) the firmware on the board to support UEFI and USB boot, though installing is a bit of a pain since there's no easy images to do it with. https://wiki.debian.org/RaspberryPi4
I believe some other distros also have UEFI booting/installers setup for PI4 and newer devices because of this, though there's a good chance you'll want some of the other libraries that come with Raspberry PI OS (aka Raspbian) still for some of the hardware specific features like CSI/DSI and some of the GPIO features that might not be fully upstreamed yet.
There's also a port of Proxmox called PXVirt (Formerly Proxmox Port) that exists to use a number of similar ARM systems now as a virtualization host with a nice ui and automation around it.
For IoT myself i'm wondering if it's something that could be thrown into the Matter side of things, make the hub/border router act as an ACME server with it's own CA that gives out mTLS certs so the devices can validate the hub and the hub can validate the devices. It'd never be implemented properly by the swarms of cheap hardware out there but I can dream...
Largely management, observability, and then the way that docker mucks with firewalls. Running them this way will allow proxmox to handle all that in the same way {I assume) as the LXC and VMS so automation, and all the rest can be consistent
Sometimes, lots of companies will lock down WSL and similar because they can't as easily control what's running in it for security or policy reasons. In those cases putting would be easier to audit and deal with since it's much more single purpose
Same usecase for myself too. One of the biggest advantages for me is that it lets me setup a single and easily tested place for the users to reset passwords from too for when they inevitably forget or lose the post-it note. That, along with me using all the apps and not wanting to have to change 30 passwords for everything when something happens too.
I went a bit more complicated myself with Keycloak instead of Authentik, simply because I knew keycloak a little better but setting up SSO for all the stuff I run has definitely been worth it.
This is one reason that I'm still upset about the failure that SCTP has ended up. It really did try to create a new protocol for dealing with exactly all of these issues but support and ossification basically meant it's a non-starter. I'd have loved if it was a mandatory part of IPv6 so that it'd eventually get useful support but I'm pretty sure that would have made IPv6 adoption even worse.
> For multi-window applications you're not inside "your own window", you own many windows. Are apps not allowed to get and set properties of windows they spawn under Wayland?
Depends on what you're calling properties of the window, wayland does of course have a number of things like that but not all of them are the same as X11 used to be. I don't believe it's got a way to get the position of your own window, and does not have a way to set the position at all since that's considered a property of the compositor's handle on the surface IIRC (not exactly the same as the window, since the compositor can be putting decorations on the surface like the title bar, controls, etc.).
A lot of it is consequences of moving some security fences around as other commenters have mentioned, because over the decades a lot of applications (not necessarily on linux or X11, but it has happened there still) have used those other barrier's leakage to do nefarious things like steal passwords, pop up ads on top of what you're doing, etc.
I would definitely support an argument that they swung the pendulum further towards "secure by default, even at the expense of what people need" but I'm actually happy they did, because it's quite a bit easier to add the functionality in after you've got something that's secure, rather than design a new barrier that breaks existing things after the fact.
> EDIT: on further thought though, it's really odd that they still haven't added in optional APIs for a lot of basic window operations...
That's because like you mention, wayland doesn't look at things as "windows" like X11 used to. It's got surfaces and compositors so it's a really rather different design than the previous systems which is why there's been such an issue with transitioning some kinds of applications and why it's been so hard to get some of the window related protocols to be agreed upon. There's been a decent number of attempts at the positioning protocols that have been kiboshed because there were effective security issues because the protocol would imply that a client could take over the screen from the intended application that the user was using, if the compositor fully follows the protocol or worked the same way that X11 did. Supporting all the different use-cases like this has definitely made progress slower and harder to keep up but personally I think it's going to end up with a more comprehensive and future proofed system once it is finally getting those last couple of things that take it from an 85% solution to a 99% solution.
I still find it hilariously ironic that the first instance that was widely reported (as far as I know) was it happening to 1984.