Yes, but the bios will still need to go to the device with the bootloader on it for you to make the choice.

In the case that the external is unplugged or had a damaged wire or something, it won’t work.

Depending on your circumstances you may be better served by just installing Linux on the external device, not writing grub (the bootloader that lets you choose) to your internal drive and instead just booting from it like a usb.

I don’t generally recommend that to people, but if you absolutely will not use partitions no matter what then it’s a less complex way of accomplishing some tasks.

E: I want to be clear that you are setting yourself up for failure and unhappiness if you try to use a usb device chain booted off grub. You will make your life incredibly complex and make it hard to get help if you try to migrate that setup to your boot device.

It is infinitely easier to move your files to the external and dual boot from partitions on one device like a normal person.

Why do you want to use a vm or boot from your usb drive in the first place?

Here’s a post explaining how dual booting works.

When you turn on your computer, the bios or bios equavalent goes down its list of devices to try and boot from. It might have usb or cd first and ssd next, so if you put a cd or usb it’ll boot that automatically.

Devices that can be booted have special instructions in the first part of their storage that can be used to operate the hardware.

When the bios finds a device that can be booted it hands the hardware off to that device and breathes a sigh of relief, most of its work is over. That devices work is just beginning though.

If it finds a windows disk, that disks bootloader will load a minimal set of hardware drivers necessary to load the rest of windows and it builds itself up towards having a functional running windows operating system and presents a login screen to the user.

If it finds a Linux disk, the disks bootloader will do the same thing but instead of loading a set of drivers, kernel and configuration that let it start a windows system it will build towards having a running Linux system. Duh.

When you dual boot, the device the bios finds to boot from doesn’t do either of those things, it runs a bootloader that presents you the user with a choice between the two, then hands the task off to one or the other based on your choice.

Setting up dual booting means clearing off space and shrinking the windows partition so you can have a Linux partition, installing Linux to it and then installing a bootloader that gives you the option to use either os.

There’s a lot of arguments for one solution or the other based on security or privacy, but let me present a different scenario:

Imagine you’re in a natural disaster. Your home based self hosted server is down because of a general rolling network outage or just irrecoverably destroyed. Your offsite on the other side of the county is in a similar state. Can your cloud hosted backup be accessed at generic, public computer in a shelter or public building?

Bitwarden can. It has specific instructions for doing so as safely as possible.

It’s a duplication of functionality in kernel/dma.

That’s why the submitter didn’t say “I didn’t submit to kernel/dma, checkmate libs!”.

The intent is to duplicate functionality in kernel/dma then get it included directly or linked to.

That’s what the r4l project is trying to do explicitly!

Before you say that kernel/dma didn’t have functional easy to use rust bindings, so the commit couldn’t have duplicated functionality: someone on kernel/dma said they didn’t want that and suggested using the c bindings instead which is what every other language has to do. Which means there was already a solution that was functional.

It’s like if there’s a community bicycle and you bring your drill and tap set so you can mount your bottle caddy and the community says “please don’t make a hole we have to tig in. Just use a pipe strap.” The right answer isn’t to start building a whole new down tube you can tap for an m5 for your bottle caddy, it’s to just use a pipe strap for your bottle caddy.

I didn’t read the linked article (or any linked article about this) because I’ve been reading the mailing list. Reporting on the kernel and people’s behavior on the list is tiring and often includes a bunch of baseless speculation.

Again, so much of the discussion around kernel mailing list exchanges excludes the context that what hellwig is talking about is not rust in the kernel at all or even r4l but a split code base.

I dealt with a c/c++ codebase once and it was beyond my meager abilities to handle both those ostensibly similar languages at the same time and I had people who were very knowledgeable in c involved with the project.

So when someone says “I think a split codebase is cancer to the Linux kernel” or “I will oppose this (split codebase) with all my energy” I’m like “yeah, that makes sense.”

I also need to clarify that I don’t think anyone is sabotaging anyone else and my intent in bringing up the simple field sabotage manual was to point out that the behaviors don’t necessarily indicate sabotage but fall into a broad category of behavior that isn’t gonna solve problems or get anywhere which is why it’s included in the manual.

I wasn’t aware it was circulating in social media recently and about fifteen years ago when I got exposed to it the main lessons to draw were not that people doing those things were active saboteurs but that those behaviors can lead to waste of energy and resources and they’re the first thing to avoid interacting with.

My exposure to and understanding of the manual was “here are some things to avoid in your own life” not “here’s how to throw a wrench into their plans!”

It’s surprising to see that statement get brought up in the news considering it’s immediately followed by a parenthetical specifically enumerating a multi language code base as the subject not rust specifically.

Iirc it’s even preceded by something to the effect of “I like rust, it’s good and there’s nothing wrong with projects that use it”.

The news coverage of kernel mailing list stuff is always so needlessly breathless.

I think I got in before they started doing that.

Actually I don’t think they require that. I just set up a new proton account on a device with a fresh wipe from a vpn endpoint I never used before and they offered to record a phone number or recovery email but didn’t require it.

Here’s hoping Apple sticks to their guns and pulls adp instead of caving.

In case you didn’t see it a few weeks ago, 3.3 million servers are doing unencrypted transport.

The way email delivery is handled also means you’re not safe just because you aren’t talking to those servers.

It’s one technique used to hide and move money all the time.

A different way is to buy some asset in the destination nation then sell it when you arrive. So like a bond or an etf share or something.

Debian, lxqt and x11.

If you can get an ssd in there then there’s some zram or something or other that can make it even better.

The barrier to entry was intended to refer to others since it’s already installed on over half their phones to start with and most people are gonna be using a messaging program on their phone.

When there’s above a 50% chance the person you’re talking to is already using a particular encrypted messaging program that’s the lowest barrier to entry.

The barrier to entry always refers to other people because the hardest part of establishing private communications has always been convincing other people to actually do it.

If you really wanted to get on imessage for the least amount of cash out of pocket possible, the bluebubble bridge application random letters person mentioned is ~$100 for an old mac, and tbh that’s a high estimate in my experience. People are just giving those things away nowadays.

Someone already linked to journalctl, but if you just quickly want to look, the command journalctl and the flag —since will get you going.

Journalctls output can be piped, so if you know what you’re looking for you can grep it easily.