If you run qemu from CLI you get a window which grabs keyboard and mouse automatically. Ctrl+Alt+G (from the top of my head) releases the input devices so you can again navigate the host. The window is otherwise a default window for you display server.

I find qemu from CLI way more transparent then these GUI-Applications since each vm is a readable, single script. So I recommend this.

Regarding installation on iMac bare metal: If the kernel supporta virtualization you can expect to work flawlessly. If you have a dedicated graphics card you can only pass this (as well as dedicated devices like hdd’s) if you main board supports IOMMU.

If it does all you need is the qemu man page to setup your vm.

Why I prefer a qemu script to any GUI alternative:

The entire script for passing RAM, GPU and a HDD is about 10 lines max. A default vm with tcg-emulation e.g. via libvirt etc. can pass 50 lines of xml easily.

I recommend giving it a try. My workflow is: Place the install script in some directory. The default run script is placed in my ~/.bin/ You can combine these scripts but I find it way simpler to separate them (you would need more elaborate options mounting devices).

Modularity of software ranked way too low.

Adding a terminal multiplexer. Now I understand why UNIX is an IDE.

It is bearable but feature complete. Every month linaro and the community add functionality. The most recent things include a custom power-domain mapper implementation and apparently camera support.

If you are running wayland you can simply install any os and its working oob.

The laptops weight and heat production is awesome. Very practical. Also the body is exceptional sturdy and worth mentioning (even in comparsion to a T14, e.g.).

But:

• external monitors are not detected at boot
• no hibernation
• battery time is very depended on the task. It ranges from 4 to 13 hours.
• no virtualization support, so one is stuck with tiny code generator runtime when using kvm
• audio is pretty quiet, so depending on the environment an external source is required.

I followed almost all patches on the lkml. It appears to me that the upcoming chip can benefit from the sc8280xp hugely. It sufficies for my use cases but I promised myself a little better, yet.

Man. I bought Lenovo ARM. I wanted to buy a tuxedo so badly. Now I’m stuck with this thinkpad.

The Debian community not already maintains a Chromium fork. How much does that cost?

I honestly can’t and wouldn’t judge: Time, Resources, implicit know-how etc. are unknown to me.

The human time needed should grow with the number of patches that need to be applied to the upstream code base, …

jupp

… because some will fail now and then.

Forks are done due to different reasons. Therefore it depends why to fork. It could be possible that one feature diverges so much that applying patches isn’t enough. Especially patches in a debian sense, neither .diff/.patch-patches.

This is what I refer to as “fatness” of the fork. The more patches, the fatter. It should be possible to build, packege and publish a fork with zero patches without human intervention, after the initial automation work.

For a brief period, until something rattles on the build system. Debian patches are often applied to remove binary blobs due to licensing - Imagine upstream chooses to include M$ Recall into the render engine. You would need to apply extraordinary amounts of work. Maybe even maintaining a complete separate implementation. This would also imply changes on the build systems, which needs to get aligned continiously between both upstreams, now.

Maybe I’m missing something obvious. 😅

With each version you have to very carefully review every commit if you want to maintain compatability with upstream, in order to merge patches into your fork.

When there are 50 devs working on upstream and you need to review every commit to assure requirement X, this alone is a hard path. If you need to also apply workarounds compatible with future versions of upstream, you need PROFESSIONALS. Luckily these are found in the FOSS community; But they are underpaid and worse: underappreciated.

// plus I could imagine that things like chrome may even not be coming with the full test suite. The test suite of a browser are surely so huge I can’t even comprehend the effort put into it. And then bug tickets… Upstream says: Not in my version. Now the fork has to address these themselves! :)

It does not depend in how fat the fork is. You provide some reasons on your own.

Your assumption appears to be that open source software can be maintained with minimal costs by the community and sofware-aid assures an ongoing bug prevention of some sort.

In the end you still need at least a few full-time devs on it. It would be fair to pay them accordingly if they are maintaining behemoths of software.

Funfact: Infrastructure costs are x-times higher then IT Personel in my organization. A big chunk of it is energy and space; But its less then licensing costs…

At least the EU restricts this directly to your communication and make examples for its usages.

Your awesome for correcting me (I use vim BTW)

Plus emacs and lisp are superior. But I didn’t managed to jump ships.

One could point to the inclusive or environmental aspect to this approach.

How goes the saying? 32 MB of RAM and always swapping?

This should get their slogan. Any linux should have this slogan :) Have fun on your endeavors!!

You can use LFS to… Install targeted-kernel Setup AUR/pacman as package manager Use a minimal DE if needed. Otherwise just use the x.org kiosk to start your applications without any de.

Corporate rated this strategy viable

Rehire obv.

:!w /etc/fstab first!

deleted by creator

I assume truth social has this feature!

Open up ticket first, please. Thanks Codemonkey.

OpenAI is just a mask of Satan. Apple is just a contender for hell and doesn’t run things there. Yet.