> In my opinion, this was a clear case of a programmer resisting the system approach because he wanted to spend time fixing the same problems over and over and pretend to be working hard
Which is funny when the first bullet point under "skills" in the author's resume [0] is:
// The scheduler.
//
// As the kernel supports wait/wake/swap, and no blocking in the kernel
// other than wait, any kind of more sophisticated scheduling policy
// can be implemented in the userspace (in theory; maybe tweaks are needed
// to make things perform well in practive).
//
// So the default scheduler here is rather simple, but should work
// for a lot of use cases.
//
// Priorities: see enum Priority
// Cpu affinity: a single CPU hint
// Sched groups: none: everything within a priority is round robin, so
// a process with many threads will negatively affect a process with few threads.
//
// This should be OK for most situations: if there is a need for isolation,
// just use another VM.
I've been migrating to nixos. I think it makes news in that everyone is obligated to hate it publicly for at least 6 months before resigning themselves to it.
LXD isn't an alternative to podman. Podman is meant to run 'application containers', where each container has just one running process. LXD is meant to run 'system containers' where each container is a full Linux distribution with an init system and (possibly) multiple daemons. LXD containers are like light-weight VMs. Unlike VMs, LXD containers share the host kernel.
You could run podman or other OCI containers inside LXD. I use LXD to test multi node K8s (K3s) on my desktop system.
I briefly used LXD once when I needed a full system inside a container.
But podman also supports systemd inside a container and along with macvlan networking you can pretty much build an "independent" container acting almost as a VM.
Would LXD provide any other advantages/differences to that?
Vanilla LXD containers can't run podman inside them. You need privileged LXD containers. There were quite a few settings I had to figure out before I could get K3s to run on it. I'm considering publishing an article about it.
There are a few settings to figure out before LXD containers can host K8s. It's mainly about running the LXD containers in privileged mode. I have the settings written down somewhere. I think I should publish it somewhere, considering the expressed interest in it.
I haven't read much about lxd until just now but based on that link, the differentiating feature between lxd and podman seems to be that lxd can manage full virtual machines (using qemu as backend, according to [1] which was linked elsewhere in this thread). Whatever this distinction is between application and system container, it doesn't appear to be a technical distinction nor a feature that lxd has that podman lacks, unless I'm wildly misunderstanding it. Containers you run with docker and podman are fully capable of running multiple processes (in my experience it's quite common to do so) and Red Hat has blog posts from years ago specifically discussing running systemd in podman, eg [2]. Managing VMs is indeed an additional feature though.
> the differentiating feature between lxd and podman seems to be that lxd can manage full virtual machines
LXD is a management layer over LXC and Qemu(KVM?). LXC is all about system containers. The Qemu support is a recent addition [1]. LXD supported only LXC system containers until then.
> Containers you run with docker and podman are fully capable of running multiple processes
Yes. I have done this. But it was very unwieldy - probably because docker, podman etc weren't designed to run system containers.
K8s doesn't support orchestrating LXC/LXD containers as far as I know. What I did was to use LXD containers as hosts/nodes for K8s. So, it was basically application containers/pods and K8s running inside system containers.
In addition, there are orchestrators which can run LXC containers (LXD is a management layer over LXC). Hashicorp Nomad is noteworthy.
Added later: K8s runs OCI containers. All OCI containers I have seen are application containers. I don't know if OCI specification supports system containers.
There's a bit of a Turing Tarpit here because they're both ultimately just namespaces under the hood so you can with effort get them to do equivalent things.
The original idea behind LXD was to build packages in a system equivalent to your real system but without spamming your dpkg database and filesystem with all the required -dev files. The idea behind Docker (which podman is a better implementation of and extension to) was to be able to have three different versions of Apache ephemerally on your system to match the versions used by three different projects today.
Ultimately you can do both with either (and I generally use podman to build packages, as an example) but if you do that you aren't playing to the project's strengths.
Toolbox and distrobox are sort of middle grounds that do both of them well enough to be tolerable.
LXD use case is totally different from podman, k8$ , docker.
It is like building your own digital ocean , for containers (and vms) . It can be used as a container host for docker/podman containers, virtual machine manager for qemu, it is like having your own VPS to put your servers in.
If you use LXD you don't need Podman, the main difference between LXD and Podman is LXD runs System Containers while Podman runs Application containers.
One advantage of having a system container is you can use a package manager to update your applications. With Podman, you have to replace the entire container, with LXD you can just "PATCH" the container. This results in much faster upgrade / lifecycle management.
Have you tried nixos? Its a totally different paradigm and definitely an acquired taste, but I used gentoo for ~2 years, then used Arch for ~5 and now am switching everything to nixos.
Main benefits is setting up a new machine is much easier, and updates are easier because almost all the normal configuration is managed by nixos (in the nix language) as opposed to regular files floating around etc.
That doesn't require it to be stored in the clear on the server. Extensions/apps could keep a domain list (don't see why they need full URLs) in memory after lock.
Are domains truly the only scope that matters? What if a platform site allowed hosting user web apps (which could themselves offer authentication) all on the same domain, each in their own directory/path. As long as the app was careful to set the path attribute of the session cookie appropriately, the app could be pretty well-contained. Then a password manager just decides that a password field anywhere on the whole domain is a good place to autofill your password for one of the apps on that domain? That's pretty scary!
The context here is with a locked vault so no data to auto-fill with. It's most likely purpose was to indicate "LP has the login info for this site but the vault is locked". An indicator like that can be coarse and simply use a root domain and ignore subdomains and paths, better to have some false positives than leak data in the clear.
[We might be wrong about the locked-vault but might have data scenario, but that kind of seems the only legit reason to store that stuff in the clear, so if that wasn't the reason, LP's negligence is even worse]
I cycled through dwm at one point. The thing that killed me was that on my nvidia machine, for some reason it would flash when I changed desktops, like the draw order was wrong. i3 is the only tiling window manager that didn't, I think because it uses xcb instead of xlib.
I love the magical bullshit in the description. Each line contains some face palm.
> dwm doesn't distinguish between layers: there is no floating or tiled layer. Whether or not the clients of currently selected tag(s) are in tiled layout, you can rearrange them on the fly. Popup and fixed-size windows are always floating, however.
Ok so it does have floating then?
> Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.
Ok so you can package then....?
> dwm is only a single binary, and its source code is intended to never exceed 2000 SLOC.
Strange flex but ok.
> dwm has no Lua integration, no 9P support, no shell-based configuration, no remote control, and comes without any additional tools, such as for printing the selection or warping the mouse.
It uses x, x warps the mouse.
> dwm is customized through editing its source code, which makes it extremely fast and secure - it does not process any input data which isn't known at compile time, except window titles and status text read from the root window's name.
ok so there is input that could hacked (not saying there IS, but if you process strings or floats from the user those can contain unexpected values).
All that said, suckless tools are nice, just think the mindset is hilarious.
The point is that the software that you're using to manage your computer is simple enough that you can read all of it and understand it -- not that you have to, but you could.
The official method for "extensions" to DWM is in the form of Git patches (https://dwm.suckless.org/patches/). You apply the patch and re-compile. If you had dwm through your package manager, you wouldn't be able to apply any patches, because you would just have the binary.
>Ok so it does have floating then?
What's meant by the quoted text is that you can cycle through all windows on your current workspace, including the floating ones, using only your keyboard. Yes, it does have floating.
edit: I should also say, the real power move for me is that I can just fork the dwm git repo on github, and have my exact desktop configuration available to me 24/7 from anywhere, and I can deploy it on a potato.
reply