For low-cost I have been using RamNode. They are a pretty established company and provide HDD options which are great if you want lots of storage at a reasonable price:
This seems unlikely since it boots with a monitor attached. From past experience most laptops that refuse to boot while closed don’t boot even if an HDMI display is connected.
It may still be nice to have a reference implementation. For example maybe they can see if there are extra hardening options that they can enable or adopt the more seamless update flow.
Back in the day X was a great protocol that reflected the needs of the time.
Applications asked it to draw some lines and text.
It sent input events to applications.
People also wanted to customize how their windows were laid out more flexibly. So the window manager appeared. This would move all of your windows around for you and provide some global shortcuts for things.
Then graphics got more complicated. All of a sudden the simple drawing primitives of X weren’t sufficient. Other than lines, text and rectangles applications wanted gradients, rounded corners and to display rich graphics. So now instead of using all of these fancy drawing APIs they were just uploading big bitmaps to the X server. At this point 1/3 of what the X server was previously doing became obsolete.
Next people wanted fancy effects and transparency (like drop shadows). So window managers started compositing the display. This is great but now they need more control than just moving windows around on the display in case they are warped, rendered somewhere slightly differently or on a different workspace. So now all input events go first from X to the window manager, then back to X, then to the application. Also output needs to be processed by the window manager, so it is sent from the client to X, then to the window manager, then the composited output is sent to X. So another 1/3 of what X was doing became obsolete.
So now what is the X server doing:
Outputting the composited image to the display.
Receiving input from input devices.
Shuffling messages and graphics between the window manager and applications.
It turns out that 1 and 2 have got vastly simpler over the years, and can now basically be solved by a few libraries. 3 is just overhead (especially if you are trying to use X over a network because input and output need to make multiple round-trips each).
So 1 and 2 turned into libraries and 3 was just removed. Basically this made the X server disappear. Now the window manager just directly read input and displayed output usually using some common libraries.
Now removing the X server is a breaking change, so it was a great time to rethink a lot of decisions. Some of the highlights are:
Accessing other applications information (output and input capture) requires explicit permission. This is a key piece to sandboxing applications.
Organize the system around frames to avoid tearing except for when desired (X doesn’t really have the concept of a frame).
Remove lots of basically unused APIs like fonts, drawing and many others.
So the future is great. Simpler, faster, more secure and more extensible. However getting there takes time.
This was also slowed down by some people trying to resist some features that X had (such as applications being able to position themselves). And with a few examples like that it can be impossible to make a nice port of an application to Wayland. However over time these features are being added and these days most applications have good Wayland support.
Also window managers started compositing which moved 1/3 of what X was doing to the window manager. Then applications started doing their own rendering which moved another 1/3 of what X was doing to the applications. All that is left over is basically the low-level IO which had gotten greatly simpler over the years and could basically be packaged into a few libraries (mesa and libinput primarily) and some complex mutli-hop IPC which was completely unnecessary.
I think yes. In general if you have good setup instructions (preferably automated) then it will be easier to start from scratch. This is because when starting from scratch you need to worry about the new setup. But when upgrading you need to worry about the new setup as well as any cruft that has been carried over from the previous setup. Basically starting clean has some advantages.
However it is important to make sure that you can go back to the old working state if required. Either via backups or leaving the old machine around working until the new one has been proven to be operational.
I also really like NixOS for this reason. It means that you can upgrade your system with very little cruft carrying over. Basically it behaves like a clean install every update. But it is easier to roll back if you need to.
I can’t way I have tried. But Wayland uses a socket, so many you can set file permissions to let other users access it?
I don’t know what your exact use case is but if you just want programs to have different “profiles” you can probably do something like setting $HOME to point somewhere else or otherwise configure their data directory.
I don’t really have a source. It is just me thinking logically about the system and many offhand comments I have read over time. Other than the privacy policy which I have linked.
The difference is that the popup is optional on X. They can also just access the window data directly. On Wayland they have no way to access other windows without asking for permission via the “Portal” popup.
If I run these as an unprivileged user via xhost, they don’t really work well.
This is not a strong security boundary and in this case is basically doing the opposite of what you want. Giving access to an X session is basically giving the app full access to your user account. As an example they can inject keystrokes to open a terminal and do whatever they want. X also gives every program access to every other program.
Running as a different user will prevent direct access to other resources of your user account which may block some generic malware/spyware that tries to gobble up random files, but keyloggers and screen captures will just work as expected because they use X anyways.
As mentioned in other comments the best solution to this is Wayland. Under Wayland apps don’t have direct access to each other. These apps use “Portals” which are trusted permission prompts. So if you try to share the screen under Wayland you will get a trusted prompt that list all windows, and if you select one the app only gets access to that one selected window.
Although it is worth noting that most apps running under your user account will have pretty broad access. This can be mitigated by sandboxing tools like Flatpak but many available Flatpaks don’t provide much isolation. Carefully check the permissions if isolation is important to you.
And for the truly paranoid anything running under the same kernel is not strongly isolated. It is likely good enough for these partially trusted apps like Zoom or Teams (they are not likely to actually try to exploit your system, just suck up more data than you would like them to) but not strong enough for running completely untrusted programs that may be malicious. You would at least want a VM boundary (see Qubes OS) or ideally different physical hardware.
Another good option is running these in a browser. Browsers are designed from the ground up to run untrusted software safely. Google Meet works perfectly in the browser and Zoom has all of the core functionality available. (I don’t use MS Teams so can’t vouch for it.) This is my main approach to isolating proprietary software as it is reliable and I also value features such as cross-platform usage. Half of these programs just run Electron anyways so running in my main browser will use less resources and be faster than running 7 different Chromium processes.
IIUC it is mostly to avoid placing huge load on the original package host when people download the same package hundreds of times a day in their CI workflow. It also means that Google can take control over the user experience rather than huge issues coming up every time some smaller host goes down or someone deletes an existing package version.
Overall I doubt that this proxy was added as a source of tracking. And the privacy policy on the service is pretty strict: proxy.golang.org/privacy. So even though I am pretty wary of Google overall I think this is actually a fairly reasonable decision by them to have enabled by default.
For sure. Lots of people here are enthusiasts that like trying out different things and different distros. Most people will just find something they like and stick with it for years. Don’t get me wrong, it can be fun to jump around, but don’t feel compelled to. Fedora will likely serve you well for many years.