- simcop2387Pretty reasonable place to start. I'm curious how it would fare in an emc/rf test.
- 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
- Likely due to areas that still have only 2g coverage. Still a lot of that in rural usa
- 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.
- Listen, there are Top Men in charge of keeping these things safe. Top Men.
- 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.
- What about the late Earl Warren? https://youtu.be/FUw9Eo9QqmM
That's the one I remember from the simpsond back then
- I think they're referring to this, https://linux.die.net/man/5/magic given the notation. That said I don't really see how it'd be all that relevant to the discussion so maybe i'm missing something else.
- that entity extraction is where it actually gets really really difficult, even for LLMs since people will use 10 different names for the same thing and you'll have to know them ahead of time to handle them all properly. For either BERT based or llm based there's a bit of a need for the system to try to correct and learn those new names unless you require users to put them all in ahead of time. That said i've seen LLMs handle this a lot better with a list of aliases in the prompt for each room and then type of device when playing with home assistant + llm.
- Yea it seems like it's something to act like ACPI and DMI but on ARM, right now this is being "solved" in linux with the whole Device Tree subsystem where there's a config file that's passed to the kernel on boot that gives all this data about the memory map, peripherals, etc. I'm hoping that this does work out to completely replace the whole device tree idea since then kernel support will be a lot simpler for a user, esp since UEFI has also been starting to be adopted on more ARM based systems now too.
- If anyone wants to look up why this might work, it's a Whitening transform [0]. I can't find the name of the algorithm itself being describe in the parent but there's more than just that for accomplishing the same thing.
- Probably not dolable on planetary scale but ii imagine it'd help in space, esp if combined with some other mods like fiximg the vitamin c gene to remove scurvy. If we could use light to suppliment our metabolism it'd mean fewer physical resources to bring alon.
- The application side of it is more for things like the multi-window setup of things like GIMP so that windows that are "docked" next to each other will stay that way past restarts. That's one of the reasons that the newer proposals are doing things with relative positioning between a zone or main window rather than allowing applications to place themselves randomly on whatever monitor or space that they want, interrupting whatever workflow is going on (which actually allows for security issues, i.e. a window pretending to be a password prompt putting itself on top of a browser or something to confuse the user). This also allows for new windows from the application to request that they're positioned next to any others so that related things stay together. This also apparently helps in a few cases where a single "application" to the user is actually multiple separate programs that get run by a main interface. Not as common in new software today but it used to be one of the ways that a lot of older software worked and there's still a decent amount out there apparently that are maintained that way.
Keep in mind that this is also a request by the application, not a requirement of the compositor to obey it. If there's not sufficient space where the application requests things then the compositor can just ignore it and do what it believes makes sense.
- > Also with this new partitioning of responsibility is my main annoyance: The DE needs to remember window placement for all my apps, since they are not allowed to know their environment under Wayland (for good reasons).
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
This might eventually get fixed, above is what I believe is the current proposal for handling this issue and letting apps do some amount of positioning without exposing things that a program shouldn't know about. That said this has had multiple proposals over the past 5-6 years at least and none have managed to make it all the way through. If you go through the previous ones (ext-placement and i forget the others) and ignore the angry messages involved it turns out that it's a very difficult problem to deal with in a way that isn't just a free-for-all with apps either not knowing about monitor placement, or having to handle so much detail about the displays that nothing will ever act consistently.
That said, recent discussion on that latest one does look promising so maybe it'll finally happen.
- Honestly it reminds me a bit of the macguffin used to amplify a signal to insterstellar distances used in The Three Body Problem book. Which given the rest of the novels makes me a little scared
- > That is what is so important about it RISC-V is that it being an open ISA creates a commodity with true competition instead of competing oligopolies.
Not just that, but also by being fairly vanilla/boring about a lot of things in the ISA too. Thus letting the ISA itself be less an impediment to being compatible with ARM and x86_64 as far as behavior for memory ordering and such.