1. 3

    Both Xming and XvSrv will also work with basically the same procedure, except when you start them you will want to disable access control if you are using WSL2. Every X server I’ve used on Windows has somewhat blurry text. YMMV.

    Also–and this is admittedly a nitpick–can I take a moment to point out this

    export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0
    

    is way more pipelining than you possibly need? You can do all this with the basic features of awk.

    export DISPLAY=$(awk '/^nameserver / {print $2; exit;}' /etc/resolv.conf 2>/dev/null):0.0
    
    1. 2

      I use XvSrv on a hidpi monitor and have had success starting Emacs (and other GUI apps using GTK widgets) with some tweaked GDK_SCALE and GDK_DPI_SCALE settings. (See https://developer.gnome.org/gtk3/stable/gtk-x11.html)

      I can’t recall, but I think I had to tell Windows to not try to scale the XvSrv application itself as well. I’ve been using this setup long enough that I can’t remember. I haven’t had blurry text or had to crank the font like @bbatsov mentions.

      1. 1

        The standard GDK settings didn’t do anything for me for some reason. I’ll probably take a closer look at this down the road, especially if I get to use more GUI apps over X.

    1. 1

      Dang. No official FVWM3 releases yet, and nary a screenshot to be found. I’d be curious to try FVWM3 when it’s packaged for Fedora, not sure I have the patience these days for compiling my own desktop / window manager.

      1. 2
      1. 4

        This is pretty good, but I recommend going one step further and moving all subpackages from reporoot/cmd/.../ to reporoot — and each command main itself should be limited to stitching together logic from another subpackage, either below reporootor below reporoot/internal. The reasons are basically the same: above the level of a small script-like command, my team finds that separating the command orchestration (e.g. flag handling, output & error reporting) from the actual logic helps encourage more reusable code. This also involves writing deployment-environment–neutral code in the main logic packages: what I mean is writing logic which works on e.g. a channel of domain objects rather than an AWS SQS queue, or which fetches domain objects from an interface passed in (and created) by main rather than commingling internal logic and database or filesystem reads.

        I fully understand that this may feel like a YAGNI violation to a lot of folks, but we have found repeatedly that we have needed it and that the resulting code is cleaner, and easier to use & modify.

        1. 1

          Are you saying to change @cadey’s example of:

          repo-root
          ├── cmd
          │   ├── paperwork
          │   │   ├── create
          │   │   │   └── create.go
          │   │   └── main.go
          

          To something like the following where create is split out from being in the repo-root/cmd/paperwork namespace?

          repo-root
          ├── cmd
          │   ├── paperwork
          │   └──── main.go
          ├── create
                └── create.go
          
          1. 1

            I like this pattern, with all packages that could be reused being in the repo-root. There are times, however, when a package could be so specific to the cmd that it should be grouped under the cmd, but then it should most likely go in an internal package in the cmd repo-root/cmd/paperwork/internal/create.

            1. 1

              Yup. It is possible that orchestrating-the-create-package-within-an-executable command would logically be a package, too, but that is pretty unlikely. Our main packages are really lightweight, generally a single file and a few screens of text.

              We would also probably have lots of files at the repo-root level, implementing whatever the repo does.

          1. 58

            my partner submitted a patch to OpenBSD a few weeks ago, and he had to set up an entirely new mail client which didn’t mangle his email message to HTML-ise or do other things to it, so he could even make that one patch. That’s a barrier to entry that’s pretty high for somebody who may want to be a first-time contributor.

            I think it was actually Gmail that was a barrier. And he also couldn’t do it from Apple Mail. It is just that the modern mail client has intentionally moved towards HTML

            I am flabbergasted someone is able to send a patch to OpenBSD but is not able to set the web interface of GMail to sent plain-text emails. Or install Thunderbird, which might have been the solution, in that particular case.

            I also never used git send-email, but I don’t think it is the barrier to become a kernel maintainer.

            Actually, that might work as an efficient sieve to select the ones who want to be active contributors from those who are just superficial or ephemeral contributors.

            In my opinion, although Github supposedly decreases the barrier of first-time contribution, it increases the load on the maintainers, which has to interact with a lot of low-quality implementation, reckless hacks and a torrent of issues which might not even be. That is my experience in the repositories I visit or contributed.

            1. 41

              Patching some component or other of OpenBSD is not a skill that transfers well to making some random application do what you want.

              1. 40

                I agree with you.

                On the other hand, if someone knows how to install OpenBSD, use cvs (or git), program in C and navigate the kernel’s souce-code, I supposed they are capable of going to any search engine and find the answer on how to send plain-text email via the GMail interface.

                1. 16

                  GMail mangles your “plain-text” messages with hard-wraps and by playing with your indentation. You’d have to install and configure thunderbird or something.

                  1. 3

                    One of the many reasons why I use Mutt.

                2. 14

                  Note that this is anecdotal hearsay. This person is saying their partner had to set things up… they may have misunderstood their partner or not realized their partner was exaggerating.

                  Also, one might expect the amount of patience and general debugging skill necessary to transfer rather well to the domain of email configuration.

                  It’s also possible that guiraldelli is assuming it was an excepted OpenBSD kernel patch, wheras we don’t know if the patch was accepted and we don’t know if it was a userland patch. It doesn’t take much skill to get a userland patch rejected.

                3. 30

                  I am flabbergasted someone is able to send a patch to OpenBSD but is not able to set the web interface of GMail to sent plain-text emails.

                  You can’t send patches, or indeed any formatted plain text emails through the gmail web interface. If you set gmail to plain text, gmail will mangle your emails. It will remove tabs and hardwrap the text. It’s hopeless.

                  1. 26

                    Think about impediments in terms of probabilities and ease of access.

                    You wouldn’t believe how many people stop contributing because of tiny papercuts. There is a non-trivial amount of people who have the skills to make meaningful contributions, but lack the time.

                    1. 18

                      Lobsters requires an invite. That’s a barrier to entry, so those who make it are more likely to make good contributions, and have already extended effort to comply with the social norms.

                      1. 8

                        You may be willing to jump a barrier of entry for entertainment (that is lobsters) but not for free work for the benefit of others (because you have already done that work for yourself).

                        1. 4

                          If you want to save yourself compiling and patching your kernel every time there’s an update, you might want to submit it to the project maintainer.

                          1. 18

                            If the project wants to have contributors in the future it might want to consider using modern, user friendly technologies for contribution.

                            Linux is considering it, a discussion is started, which is positive (for the future of the project) in my opinion. It is a sign or responsive project management, where its conservatism does not hinder progress, only slows it to not jump for quickly fading fads.

                            Other communities are closing their microverse on themselves, where it is not enough to format your contribution in N<80 column plain text email without attachments with your contribution added to it via come custom non-standard inline encoding (like pasting the patch to the end of the line), but you may even need to be ceremonially accepted for contribution by the elders. Also some such projects still don’t use CI, or automated QA. These communities will die soon, actually are already dead, especially as they don’t have large corporations backing them, as someone getting paid usually accepts quite a few papercuts a job demands. This is why Linux could actually allow itself to be more retrograde than the BSD projects for example, which I think are even more contributor-unfriendly (especially ergonomically).

                            1. 2

                              I tend to agree, however that discussion was started by someone with a very striking conflict of interest and therefore their opinion should be questioned and considered to be insincere at best and maleficent at worst.

                              1. 5

                                That doesn’t matter, the discussion can be done despite that. I think a forge-style solution is the key.

                                Despite Microsoft having 2 “forge” type solutions in its offering (both quite usable in my experience, github being a de-facto standard) I still cannot see a conflict of interest in this topic. There are other software forges available. The current process is simply outdated.A custom solution could also be developed, if deemed necessary, as it was the case with git.

                      2. 14

                        Pay attention my comment talks about maintainers, active contributors and superficial or ephemeral contributors.

                        From the article:

                        a problem recently raised by Linux kernel creator Linus Torvalds, that “it’s really hard to find maintainers.” Maintainers are the gatekeepers who determine what code ends up in the widely used open-source kernel, and who ensure its quality. It is part of a wider discussion about who will oversee Linux when the current team moves on.

                        And later on…

                        “We need to set up a better or a different or an additional way to view tools and the work that’s being done in the Linux project as we’re trying to bring in new contributors and maintain and sustain Linux in the future,” she told us.

                        Picking her words carefully, she said work is being done towards “moving from a more text-based, email-based, or not even moving from, but having a text-based, email-based patch system that can then also be represented in a way that developers who have grown up in the last five or ten years are more familiar with.

                        “Having that ability and that perspective into Linux is one of the ways we hope we can help bring newer developers into the kernel track.”

                        So I understood Sarah Novotny is addressing the problem of new contributors, not the one Linus Torvalds see, of new maintainers.

                        So, your comment that

                        how many people stop contributing because of tiny papercuts. There is a non-trivial amount of people who have the skills to make meaningful contributions, but lack the time

                        is not the problem the Linux Foundation has, but the one that Microsoft’s Sarah Novotny wants to solve. Those are two different problems, with two different solutions. On the surface, they might seem the same, but they are not. They might be correlated, but the solution for one problem does not necessarily mean it is the solution for the other.

                        Therefore, my argument still stands:

                        [having a plain-text email list as central communication and collaboration to the Linux’s kernel] might work as an efficient sieve to select the ones who want to be active contributors [i.e., maintainers] from those who are just superficial or ephemeral contributors.

                        If we are going to address, though, that it might hinder new contributors, then I tend to agree with you. :)

                        1. 21

                          Let’s not let Microsoft decide how Linux is developed.

                          The waning popularity of their own, proprietary kernel is no excuse for telling other projects how they need to be run.

                          1. 5

                            This is just my opinion but I think that while she’s totally missing the mark on finding Linux kernel module maintainers having anything at all to do with plain text email patch submission systems, the general issue she’s speaking to is one that has generated a lot of discussion recently and should probably not be ignored.

                            Also, in the spirit of the open source meritocracy, I’d prefer to let people’s actions and track records speak more loudly than which company they happen to work for, but then, lots of people consider my employer to be the new evil empire, so my objectivity in this matter could be suspect :)

                          2. 8

                            So I understood Sarah Novotny is addressing the problem of new contributors, not the one Linus Torvalds see, of new maintainers.

                            Bingo!

                            My first thought after reading this was “Does this person ACTUALLY think that having to use plaintext E-mail is even statistically relevant to the problem of finding module maintainers for the Linux kernel?”

                            In a general sense I believe that the open source community’s reliance on venerable tools that are widely rejected by younger potential contributors is a huge problem.

                            Martin Wimpress of Ubuntu Desktop fame has spoken about this a lot recently, and has been advocating a new perspective for open source to increase engagement by embracing the communications technologies where the people are not where we would like them to be.

                            So he streams his project sessions on Youtube and runs a Discord, despite the fact that these platforms are inherently proprietary, and has reported substantial success at attracting an entirely new audience that would otherwise never have engaged.

                            1. 5

                              is not the problem the Linux Foundation has, but the one that Microsoft’s Sarah Novotny wants to solve. Those are two different problems, with two different solutions. On the surface, they might seem the same, but they are not. They might be correlated, but the solution for one problem does not necessarily mean it is the solution for the other.

                              GKH even said that there are more than enough contributors in his last ama, so having contributors is “a priori” not a problem right now.

                              1. 2

                                So I understood Sarah Novotny is addressing the problem of new contributors, not the one Linus Torvalds see, of new maintainers.

                                Every maintainer was a new contributor at a point! Also better tooling would be beneficial for everyone.

                                1. 1

                                  Every maintainer was a new contributor at a point!

                                  That is true, but it is not the current problem: see /u/rmpr’s reply and his link to the Reddit’s AMA to verify that.

                                  Also better tooling would be beneficial for everyone.

                                  That is not necessarily true: the introduction of a tool requires a change of mindset and workflow of every single person already involved in the current process, as well as update of the current instructions and creation of new references.

                                  I saw projects that took months to change simply a continuous integration tool (I have GHC in mind, except the ones in the companies I worked for). Here, we are talking about the workflow of many (hundreds for sure, but I estimate even thousands) maintainers and contributors.

                                  As I already told before, RTFM [1] [2] does not take long for a single individual that wants to become a new contributor; in [1], there is even a session specially about the GMail’s Web GUI problem.

                                  If the problem is retrievability of the manual or specific information, than I think that should be addressed first. But that topic is not brought up in the article.

                            2. 19

                              I am able to deal with email patches, but I hate doing it. I would not enjoying maintaining a project which accepts only email patches.

                              Actually, that might work as an efficient sieve to select the ones who want to be active contributors from those who are just superficial or ephemeral contributors.

                              Ephemeral contributors evolve to maintainers, but if that initial step is never made this doesn’t happen. I don’t know if this will increase the number of maintainers by 1%, 10%, or more, but I’m reasonably sure there will be some increase down the line.

                              Finding reliable maintainers is always hard by the way, for pretty much any project. I did some git author stats on various popular large open source projects, and almost all of them have quite a small group of regular maintainers and a long tail of ephemeral contributors. There’s nothing wrong with that as such, but if you’re really strapped for maintainers I think it’s a good idea to treat every contributor as a potential maintainer.

                              But like I said, just because you can deal with email patches doesn’t mean you like it.

                              1. 14

                                GMail, even in plain-text mode, tends to mangle inline patches since it has no way of only auto-wrapping some lines and not others.

                                Not a major issue as you can attach a diff, but from a review-perspective I’ve personally found folks more inclined to even look at my patches if they’re small enough to be inlined into the message. I say this as someone having both submitted patches to OpenBSD for userland components in base as well as having had those patches reviewed and accepted.

                                I personally gave up fighting the oddities of GMail and shifted to using Emacs for sending/receiving to the OpenBSD lists. I agree with Novotny’s statement that “GMail [is] the barrier.” The whole point of inlining patches like this is the email body or eml file or whatever can be direct input to patch(1)…if GMail wraps lines of the diff, it’s broken the patch. Text mode or not.

                                Obviously, this doesn’t mean if the Linux kernel maintainers want to change their process that I don’t think they shouldn’t. (Especially if they take a lot of funding from the Foundation…and as a result, Microsoft/GitHub.) OpenBSD is probably always going to take the stance that contributions need to be accessible to those using just the base system…which means even users of mail(1) in my interpretation.

                                1. 5

                                  You can’t attach a diff – nearly all mailing lists remove attachments!

                                  OpenBSD is probably always going to take the stance that contributions need to be accessible to those using just the base system

                                  Heh, if you add arc to the base system, you can adopt Phabricator without violating that principle :)

                                  1. 2

                                    Good point…so basically GMail (the client) doesn’t really work with an email-only contribution system. It’s Gmail SMTP via mutt/emacs/thunderbird/etc. or bust.

                                2. 5

                                  I have found several Linux subtle kernel bugs related to PCIe/sysfs/vfio/NVMe hotplug. I fixed them locally in our builds, which will ultimately get published somewhere. I don’t know where, but it’s unlikely to ever get pushed out to the real maintainers.

                                  The reason I don’t try to push them out properly? The damn email process.

                                  I did jump through the hoops many years ago to configure everything. I tried it with gmail, and eventually got some Linux email program working well enough that I was able to complete some tutorial. It took me some non-negligible amount of time and frustration. But that was on an older system and I don’t have things set up properly anymore.

                                  I don’t want to go through that again. I have too many things on my plate to figure out how to reconfigure everything and relearn the process. And then I won’t use it again for several months to a year and I’ll have to go through it all again. Sometimes I can get a coworker to push things out for me - and those have been accepted into the kernel successfully. But that means getting him to jump through the hoops for me and takes time away from what he should be doing.

                                  So for now, the patches/fixes get pulled along with our local branch until they’re no longer needed.

                                  1. 4

                                    I have no idea how dense they need to be to not be able to send text-only email from Apple Mail. It must be anecdotal, because I cannot believe that someone is smart enough to code anything, but dumb enough to be able to click Format > Change to text in the menu bar.

                                  1. 2

                                    One barrier to entry is that I had no idea how to install it on my desktop

                                    I use Emacs via Cygwin

                                    GNU Emacs 26.3 (build 1, x86_64-pc-cygwin) of 2019-08-30

                                    There are pre-compiled binaries for Windows (native):

                                    http://ftp.acc.umu.se/mirror/gnu.org/gnu/emacs/windows/

                                    The Emacs wiki has a bunch of info

                                    https://www.emacswiki.org/emacs/MsWindowsInstallation

                                    In my previous job I used Emacs extensively to plan my workday and to read email. I had a Windows desktop and used the native build (from memory, it’s been a long time). It worked fine.

                                    1. 3

                                      And don’t forget the real bleeding edge Windows pre-compiled binaries: https://alpha.gnu.org/gnu/emacs/pretest/windows/

                                      As a pretty dedicated Emacs user for the past 5 years, I’ll admit to having fought with Emacs on Windows (which I run on my work laptop). Most of my past work had been Linux-native so I was primarily using TRAMP and working on a remote system or local vm under hyper-v.

                                      I’ve been too chicken to turn on the Insiders channel to get WSL2, so I’m curious how the ergonomics are using native Emacs + TRAMP (into the WSL2 instance) vs. Emacs over X11.

                                      1. 1

                                        While I’m not sure what TRAMP is, I know that sometimes inputs can get lost when using terminal Emacs, depending on your terminal of course. Windows Terminal for example, treats Ctrl and Ctrl + Shift as the same thing so trying to do eg; C-c C-S-l to remove a link in org mode will actually fire C-c C-l (which inserts one). It also has some system bindings for keys like Ctrl + (zoom in) which can interfere with terminal Emacs. I’m sure any other regular terminal wouldn’t have the C-l / C-S-l issue though.

                                        1. 2

                                          From the official docs: TRAMP stands for “Transparent Remote (file) Access, Multiple Protocol.”

                                          TRAMP is the original “remote editing” before VS Code had it. It effectively lets you work with files on a remote machine via ssh/scp as if they were local (in most cases). Most Emacs modes just work without even knowing it’s a remote file. You can run the native Windows Emacs and still work within a WSL2 instance without mucking about with X11 etc. (There are some caveats, but even eshell supports it and I believe magit.)

                                          https://www.gnu.org/software/emacs/manual/html_node/tramp/Quick-Start-Guide.html

                                          1. 1

                                            Ah! I totally misunderstood your comment then.

                                            This seems like a really interesting alternative, and if it works, I’d probably opt for a native Windows binary in that case. I might see if I can get it running on the weekend. Let me know if you end up experimenting yourself as well.

                                      2. 2

                                        Oh yeah, that is definitely true and I could do that for sure.

                                        Originally, I did have my development files on my C drive and kind of fumbled my way around with Powershell. When WSL came about, it was a lot more attractive being able to use regular unix tools and just apt-get install things.

                                        I believe it’s still the recommended case that you keep everything within the WSL environment for performance reasons? Either way, having to navigate to /mnt/c/code/ was a bit more tedious than being able to just do ~/code for example

                                        That was sort of the logical steps that lead me to keep everything inside WSL and hence why I opted to get emacs in there, rather than out in Windows land.

                                        On a similar note, I’ve found it much nicer running the WSL2 Docker Preview (docker daemon + kube inside WSL2) than having it run in Windowsland so it’s basically another reason for keeping my dev environment inside WSL, at least at work anyway.

                                        That said, maybe someday I’ll give the pre-compiled binaries a spin! Thanks for the heads up

                                        1. 2

                                          I should give WSL a closer look. I think it’s a bit sad Cygwin seems to be forgotten. It has served me well for many years, even as you say that dicking around with /cygdrive is a bit of a pain.

                                          Performance-wise I find it much faster to parse large log files using Perl in Cygwin than using pure PowerShell!

                                      1. 12

                                        “I also wish they debloated packages; maybe I’ve just been spoilt by KISS. I now have D-Bus on my system thanks to Firefox. :(”

                                        …why is D-Bus bad, exactly?

                                        Also, this guy reminds me of the time I spent in my early high-school years distro-hopping. That’s not a good thing or a bad thing, just an observation… That time’s also when I discovered my love of OpenBSD, so I’m glad they’ve gone down a similar path.

                                        1. 11

                                          Hi, I’m “this guy”.

                                          …why is D-Bus bad, exactly?

                                          I just don’t like how GNOME-y it is. It uses glib types, instead of just C ones, when it has nothing to do with GNOME. Many apps that shouldn’t need D-Bus hard-depend on it, which is annoying. I think it’s just my general disdain for anything freedesktop.org.

                                          Also, this guy reminds me of the time I spent in my early high-school years distro-hopping.

                                          I only hop once or twice a year, at max. Besides, I’m holed up at home with nothing better to do, so why not?

                                          That said, I didn’t even want to post this here. These are just my opinions. You can have your own, I won’t stop you. My previous post here got some pretty… interesting responses. I didn’t think people would be this annoyed at my choices. Anyway…

                                          1. 4

                                            Nice writeup.

                                            Did you check out using ifconfig join in lieu of ifconfig nwid? (http://man.openbsd.org/ifconfig#join) You can even put it in your /etc/hostname.iwm0 and list a few networks and their wpakey’s so when you take your laptop to other known networks it should automatically detect and join them.

                                            1. 2

                                              It’s a great feature. My life got significantly better when it landed. Thanks, @phessler!

                                            2. 3

                                              I didn’t think people would be this annoyed at my choices. Anyway…

                                              :trollhat: – you do realize that this is the Internet and people need validation that they are in the 95th percentile of “smart,” right?

                                              1. 2

                                                Good to see you here. Thanks for writing that up. I haven’t looked at openBSD for quite some time. A post like this, informs people like me that there is actually good support on recent laptops. That’s a good thing.

                                                Also, Nice window mgr screen/rice. Very clean.

                                                1. 2

                                                  Hi, I posted it, sorry about that.

                                                  While I was slightly concerned about the responses that would come up due to what was said in your previous post, I thought that this article was interesting and relevant while not being quite so divisive - like Plan 9, OpenBSD seems to be one of those things that people can’t help but approve of. So far the discussion seems to be quite civil and cover various facets of the post, so I think it’s been a success.

                                                  I enjoy your blog, thanks a lot.

                                                  1. 2

                                                    Hi, I posted it, sorry about that.

                                                    Hey! No apologies needed. Thanks for reading, and posting. :)

                                                  2. 2

                                                    Again, not saying hopping’s a bad thing at all! I found it to be a good way to learn about different systems. I took a similar path to yours, actually, but with CRUX instead of KISS [since KISS didn’t exist].

                                                    1. 2

                                                      [D-Bus] uses glib types, instead of just C ones, when it has nothing to do with GNOME.

                                                      GLib is used by (and developed by) GNOME, but it does not have any GNOME-ism in it. It is just another library meant to make dealing with C more tolerable on a variety of systems.

                                                      «GLib is the low-level core library that forms the basis for projects such as GTK and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system.»

                                                      Should projects really implement yet another base64 conversion function?

                                                      Many apps that shouldn’t need D-Bus hard-depend on it, which is annoying.

                                                      D-Bus is a serialization and messaging library with a central broker. If an application needs to talk with another application, it needs to speak the (de)serialization format used by the daemon. How is having a standardized (de)serialization format a bad thing?

                                                      Similarly, if an application does not want to send messages synchronously with this other (possibly slow) application, it needs to implement some sort of dispatching mechanism and a dispatching thread. How is having a standardized dispatch mechanism and daemon a bad thing?

                                                      I doubt that nowadays there are many interactive apps that 1) do not need to talk with another application and 2) don’t need to do that asynchronously and reliably.

                                                      That said, D-Bus could be improved or provided by the kernel. But something like or with the role of D-Bus is a necessary piece of every dynamic operating system.

                                                      I think it’s just my general disdain for anything freedesktop.org.

                                                      Again, freedesktop.org is just a consortium of people working hard on desktop environments. Every now and then these experts sit together and harmonize/standardize things that are, up to that point, wildly incompatible with each other. https://www.freedesktop.org/wiki/Specifications/ How is that a bad thing?

                                                      Is, for example, having a drag-n-drop standard spoken by GTK, Qt and all other GUI toolkits such a bad thing?

                                                      1. 1

                                                        Running linux in vmm(4) has been on my todo list as well - I know it’s possible, I’ve just used vmm for OpenBSD on OpenBSD :~)

                                                        I’m also a lazy and my qemu linux and windows xp installs both still work on OpenBSD, so I’ve not ventured down the vmm for everything else path yet. I would be interested reading about in your experiements with running linux in vmm.

                                                        1. 2

                                                          I was considering building a laptop with NetBSD Xen, for the sole purpose of running VMs that I’d selectively share hardware with. Something like a cheap and (probably) ineffective QubesOS… The “beauty” in the idea was that I could run a small linux distro and get a better driver for my wireless card, then bridge other VMs that need the network to it, etc.

                                                          But, now that that machine is my 3rd grader’s primary way to do school work, and runs Ubuntu, I guess the other plans I had for linux based VMs could probably be achieved via vmm(4), or even qemu as you point out–thanks for the reminder! :)