If you look at ChromeOS, it's actually relatively mainstream.
Most of us need a locked down desktop environment more than we realize. The UNIX/POSIX shell environment works really well for our specific kind of work (writing software), but it's full of security holes and gotchas. A lot of people talk about Apple as wanting to "own" everything, but the trend in securing consumer OS environments is clearly trending in this direction. Starting with research examples like Qubes, and all the mainstream security efforts in Windows, and ChromeOS.
Working with a VM that you can torch and rebuild is ultimately the best of both worlds.
What would be really cool is a Mac OS app for managing Vagrant... Basically a competitor for Docker Desktop for Mac that used VMs instead of Docker.
This is because Google and Microsoft want to own everything, as well. It's not a coincidence that Apple, Google and Microsoft's security implementations enshrine each of them as ultimate gatekeeper and single source of truth for security on their respective operating systems.
It is interesting that you bring up Qubes OS, because its security model doesn't depend on Invisible Things Lab, the Qubes developer[1], deciding what can or can't run on Qubes OS.
In fact, if a security model that depended on a company like Red Hat authorizing what can or can't run on Linux, it would be rightly criticized as Red Hat trying to "own" everything instead of developing a secure system at the OS level. Yet Apple, Google and Microsoft are doing just that.
Do I want Firefox to have access to my Contacts? My Photos? Do I want Facebook to have that access? To all of them, or just ones that I select? Should my disk utility have the ability to send data over the network? My IDE? My IDE plugins?
This has nothing to do with "stores", and everything to do with the security model and the UI needed to make it work. e.g., when I run `grep -e "Something" -r ~/src`, I assume grep is going to read all of the files in ~/src. But in the basic POSIX environment it can access anything I can (including, say, ~/.ssh) and open up any old socket it wants and send data wherever it chooses. Have you read every line of code of every package you've installed? Rather than relying on 'trust', 2021 requires that we actually have some security model that doesn't rely on trust, but explicit permissions and grants, and workable UI for defining that. Wouldn't it be nice if bash arranged a read-only capability granted to the grep process for all files under ~/src based on the above command, and if the grep executable itself had no inherent permissions at all?
Modern security on Linux is hardly dependent on the POSIX security model.
Linux just got the Landlock feature[1] in the kernel[2] that does just this. Along with Landlock, features like cgroups, seccomp, AppArmor, Firejail and other sandboxing features go far beyond the traditional POSIX security model. Even parts of the ChromeOS security model are based on modern Linux sandboxing features, and don't rely on POSIX security.
To address your Firefox example, I use these features to sandbox Firefox so that it runs in a container, and limit its ability to run code or make certain syscalls, and it's only allowed to touch its profile and a dedicated Downloads folder. D-Bus can't even reach it.
> This has nothing to do with "stores"
I didn't say anything about stores. It has everything to do with Apple, Microsoft and (slowly) Google forgoing OS-level security for centralized control of what can and cannot run on their operating systems. This is not just enforced with "stores", but with certificate systems like Apple's Notarization and Gatekeeper programs and Microsoft's certificate program.
Instead of relying on the system to provide security, we're relying on Apple, Google and Microsoft to decide what we can run, or can't run, even though Apple is responsible for distributing 500 million copies of Xcodeghost[3], and Google's Play Store is the #1 vector for malware on Android[4].
[1] https://lwn.net/Articles/703876/
[2] https://lwn.net/Articles/700607/
[3] https://www.vice.com/en/article/n7bbmz/the-fortnite-trial-is...
[4] https://www.zdnet.com/article/play-store-identified-as-main-...
The security stuff is a huge red herring.
The security model is all about limiting self publishing and directly reaching consumers by the biggest players in IP, Disney, Netflix, Nintendo and Tencent. 90% of App Store revenue is games. Most remaining revenue is to subscription entertainment services. Security as engineers talk about it basically never affects the bottom line.
This is highly misleading. System-level hardening is complementary to cryptographic trust, not a replacement forit. Hardening features do their best to prevent arbitrary malicious processes from controlling the system, and the certificate systems make it possible to revoke the ability of specific known-malicious authors to distribute software. In macOS, you can look at the entitlements system, sandboxing, and system integrity protection for examples of hardening.
Not to mention, at least on macOS and Windows, all the certificate verification features can be turned off.
I agree, however neither of these operating systems gives the user the level of control to address these concerns:
> Do I want Firefox to have access to my Contacts? My Photos? Do I want Facebook to have that access? To all of them, or just ones that I select? Should my disk utility have the ability to send data over the network? My IDE? My IDE plugins?
A system that implemented security that empowers users would allow you to say "I want my Email App to only access certain Contacts or certain Photos", allow you to supply dummy data to apps and give you better granularity.
Instead, what we get from Google is a system whose security is convenient for advertisers first, and not users, so it doesn't offer that level of empowerment even though some AOSP forks do. You either give it all of your contacts or pictures or none of them. Making a secure system that also empowers users would mean that they and their partners can't collect user data. We're shown scary warnings about installing apps outside of the Play Store and are assured that Play Protect means that everything on the Play Store is secured.
What we get from Apple is a security model that is convenient to their bottom line, so instead of addressing that user's needs, users are told they don't have to worry about their Email App doing anything bad with their contacts or photos because Apple vets apps and its developers. Like on Android, you either give the app all of your contacts or none. Making a secure system that also empowers users goes against their marketing that insists that their App Store and certificate racket are the only things keeping users private and safe.
This literally isn't true since Android 10 and has been even more hardened in Android 11. Now the apps ONLY see the pictures you, as user, allow them to see. The same goes for file access, location access and plenty of other security model changes in last two Android versions.
So your rant about how evil Google caters to advertisers only really becomes wierd when they literally implemented the change you want.
Of course they should be doing more, but they are constantly improving, and the same can be said of any organization. Where are the Linux distros that do this stuff out of the box and don’t involve configuring these tools with the command line? SELinux and all of those other tools you mention aren’t helping users if users are forced to become sysadmins to benefit.
How does this work? When an iOS app asks for permission to view photos, the user is asked which folders to grant it access to? How does the user grant one-time access?
> Both macOS and iOS do not allow any app to have access to photos, contacts, camera, etc, without prompting the user first. But there is a trade off between usability and security, and Apple is pushing that boundary towards security and privacy about as aggressively as any vendor is. People have been complaining about all the new entitlements pop-ups in macOS and saying they shouldn’t exist!
I think security prompts, viewed as interruptions, are a consequence of the Apple-owns-everything model. If I want to share a single photo with a friend using my messaging app, I don't really want to grant permission to view photos to the app. The fact that I have to is frustrating.
Instead, a step backwards towards the desktop metaphor, where the user owns the files, is a better place to step forward from: the user owns the files, and the apps are potentially hostile tools which the user sometimes requires. The app should ask the operating system for a photo, and the operating system should allow me to select the photo I want. The app then gets read access to this file right now. The app could certainly do something malicious with the read access it has received, but at least if it doesn't do anything malicious with it now, it can't do it later.
The limitation is that each app wouldn't be able to design its own photo selector
Some apps would of course legitimately want a broader access than that, e.g. a backup app, but the broader requirement shouldn't determine the limited requirement.
The same for location, for instance: it would be a resource that the app requires and the user chooses to give the current location or the spoofed location or cancel the action. (An advanced option that could be available for that would be "automatically fulfil the request in the same way for the next day/week/month/till the next upgrade/forever".)
The cognitive load would be much less. A user doesn't need to evaluate how trustworthy the app is in general. The user doesn't need to think, "It will be much easier for me to give SMS access to this app for setup, but I don't want it general access, so which one should I chose?". The user doesn't need to deny access to any app (which is tiring, since we're typically most naturally inclined to cooperate). Every action taken is naturally limited, so the stakes are lower.
The current approach is another attempt to reduce the cognitive load by reducing gratuitous choices. But it also prevents necessary distinctions and forces people to make choices they really don't want to (I want to send this photo vs I want this app to have access to my photos). But users view permission dialogs as things that take away their control rather than as things that give them control, so this approach seems failed. As you say, making them more and more fine grained just means the user is reminded more and more often that they don't have a say.
> Where are the [free software systems] that do this stuff out of the box and don’t involve configuring these tools with the command line?
There are projects to build software in this way-ish. They are all ridiculously limited and impractical. The amount of effort it takes is incredible. It's not simply a change of configuration; operating systems and programs need to be written to operate in this way. For instance, systems would have to stop making assumptions about the global filesystem namespace - the GTK filepicker would have to return read access to a file, rather than a filepath which a program than asks to open read-only.
Can you imagine a team of three or four developers maintaining a secure fork of a web browser in their spare time? and without a web browser, everything is a toy.
What you claim about reducing gratuitous choices is pretty clearly not how Apple views these things. They have been adding more and more granular permissions with every update, in response to developers abusing the wider permissions. I also have no idea what you mean by the user being reminded they don’t have a say. The user does have a say. What irritates the people who don’t like the prompts is they think they shouldn’t have to click through anything. It’s not a complaint that the permissions are too wide, it’s that they’re too granular.
I will also note that the cryptographic verification (and App Store review) side of things makes these measures a lot stronger, because developers can’t just hack around in private APIs and system-level frameworks to circumvent the restrictions. They are forced by a contract only to access the restricted resources through approved channels. Even though Apple is not perfect with review, the evidence from other platforms and their own data is that they catch the vast majority of abuse that happens and we never see it.
No. It's a consequence of finding a balance between a usable system and the fact that people are shit.
From the start iOS was very limited as to what apps could access. Funnily enough, the Android crowd derided it for this. "What, no file system access, ahahaha".
And a user's usage scenario isn't "I open photos and and decide to share one with an app". The usage is "I open an app and want to select an unlimited random number of photos and videos to share with my friends in this app".
So the usability/permissions tradeoff was: an app sees nothing outside the sandbox, but can request access to a limited number of other system-defined sandboxes: photos, camera, microphone, location etc.
Guess what. People are shit. So they decided that unlimited access to photos is so very nice, and could be abused.
So the new permissions in iOS let you limit access even further: you select which photos an app has access to, and it only has access to those. Because what users want hasn't changed: they don't share photos with an app, they use an app to share photos.
The result is significantly more cumbersome than before and there's literally no way around it. It has nothing to do with "being Apple-owned". If you limit access, you will end up with security prompts and popups, access management dialogs etc.
> The same for location, for instance: it would be a resource that the app requires and the user chooses to give the current location or the spoofed location or cancel the action.
This is literally what iOS does. However, when iOS does it, suddenly it's "security prompts, viewed as interruptions, are a consequence of the Apple-owns-everything model"
xdg-desktop-portal [1] does something pretty close, and it is how Linux applications shipped as Flatpaks access your files (at least when the Flatpak sandbox is in enforcing mode). Every sandboxed program has its own mount namespace which cannot see your home folder. When you want to open a file in a sandboxed program, you select the file in an out-of-process file chooser, and the portal puts a handle to that file in the program's view of the filesystem.
It's a huge shame there's almost zero documentation, both in the code, and for users / developers. I've heard about this feature before, but I've no idea how to make it work.
- Deny access to photos
- Grant access to hand-picked photos\
- Grant access to all photos.
Picking the middle option opens an OS-handled photo picker where you choose which photos the application can access. The model works pretty well in balancing flexibility, security and convenience.
Something else _many_ apps support, is just pasting a photo. So if I want to post a photo on Twitter, I can just copy it from my photo app, and paste it there. Twitter has access to no photos on the system at all, it merely receives that one.
Wouldn't the POSIX way of handing this be to have Firefox run as its own "Firefox" user with different privileges?
You can do some of this with groups, but that’s difficult and runs into limitations pretty quick for even comparatively simple use-cases. And making a bunch of custom ab-hoc groups requires root access on top, when ideally a user should be able to manage fine-grained control without escalating their own privileges.
Traditional POSIX file permissions are a huge blunt hammer that don’t scale well to the fine-grained type of access that things like iOS let you configure.
SELinux sort of solves that part of the equation with additional labels given to each file, but eg. Android only uses selinux for the base of the system. Modern security requires sandboxed applications with user-controllable permissions.
To a close approximation, 99% of regular users (let's just say people who are not developers by profession) do implicitly trust their respective OS vendors. To suggest otherwise suggests a level of paranoia which would make it impossible to ever have a stable system and get anything done.
We should generally trust our primary OS vendor, because otherwise we're all going to need therapy.
But we shouldn't have to trust them. That is, the system should be designed such that we have some amount of "defense in depth" where a mistake by Apple during the review of one of the 3.5 million apps doesn't result in an exploit.
I think this is why Apple and the others are trending towards the design that they are, because a deep capability approach that's integrated into the UI helps offload some of the complexity and overhead of managing that liability at scale.
I don't think this is an accurate description of what Apple is doing at all. If anything, they're moving more towards the direction where they are implicitly trusted and if you don't trust them you don't get any security.
So even without extensive app review (which is frankly, not extensive at all) a rouge application should not be able to do much damage.
[1] https://www.vice.com/en/article/n7bbmz/the-fortnite-trial-is...
[2] https://www.zdnet.com/article/play-store-identified-as-main-...
From Wikipedia: "Security firm Palo Alto Networks surmised that because network speeds were slower in China, developers in the country looked for local copies of the Apple Xcode development environment, and encountered altered versions that had been posted on domestic web sites."
This is the next sentence after your quote[1]:
> This opened the door for the malware to be inserted into high profile apps used on iOS devices.
> Even two months after the initial reports, security firm FireEye reported that hundreds of enterprises were still using infected apps and that XcodeGhost remained "a persistent security risk". The firm also identified a new variant of the malware and dubbed it XcodeGhost S; among the apps that were infected were the popular messaging app WeChat and a Netease app Music 163.
From the same article:
> Removing malicious apps from the App Store
> On September 18, 2015 Apple admitted the existence of the malware and began asking all developers with compromised apps to compile their apps with a clean version of Xcode before submitting them for review again.
Who do you propose should shoulder this responsibility? The vast majority of users lack the expertise to take it on themselves.
Ideally, systems would be designed such that risks are minimized no matter where the app you want to run came from and no matter who signed it. Right now, that's how Apple, Google and Microsoft are dealing with security. They rely on developers signing software with certificates, and they revoke those certificates if they don't want that software to run on their operating systems. There was an incident last year the highlighted this system[1]:
> Last week, just after we covered the release of Big Sur, many macOS users around the world experienced something unprecedented on the platform: a widespread outage of an obscure Apple service caused users worldwide to be unable to launch 3rd party applications. Already being dubbed the “Apple Apocalypse” or “OCSP Apocalypse”, the cause was down to a little-known but essential service called “Online Certificate Status Protocol”
> The purpose of the OCSP call is to check whether a piece of software being launched has had its developer certificate revoked. Revoking developer certificates is one way that Apple deal with known malware. By using an OCSP responder service, Apple hope to prevent any software whose certificate has been revoked from launching on pretty much all Macs anywhere within minutes.
[1] https://www.sentinelone.com/blog/what-happened-to-my-mac-app...
It’s not security in itself. You have to configure each app to the tightest set of permissions it can run with and also have to trust said application no matter what. Apple does both of it via proper pre-configured sandboxes for apps, as well as revokable credentials. The latter is needed when eg there is a new serious vulnerability without a fix yet.
How about using the same energy to create systems and software that are more rugged, reliable and won't fall apart when a three year old mashes the buttons long enough?
Or have we already given up?
The nix model would be so much better for the latter.
I think a first-class vagrant app for Mac OS would (a) be available in the App Store for simplified VPP deployments (b) install vagrant and (c) either come with a lightweight VMM over Hypervisor.framework and/or work with other active VMMs like Fusion, Parallels or even Docker Desktop.
Vagrant was born of the CLI, but I think in 2021 it needs to embrace its role as a bridge between the GUI and CLI. Just my opinion, though...
I was using VMs to address the disaster that is the Windows Registry as a developer back in the early 2000s. Homebrew is such an amazing step backwards in that regard.
I have a feeling that Terminal.app is headed this direction on Mac OS, but Apple is taking their sweet time navigating the migration since everyone gets pissed off whenever they fix a security/reliability problem. Could you imagine the uproar if the next version of Mac OS worked the way ChromeOS does? (ps., there's nothing stopping you from running Firefox on ChromeOS, I've done it).
What do you mean?
If you run your tools, and do your testing, inside of VMs, you can quickly "restart" from a known good state.
The Windows Registry is a lot like /etc in Unix-like environments. In either case, all that configuration can get co-mingled and corrupted and you have to start over.
VMs are a great way to solve that problem for developers.
Registry corruption isn’t just about transactional integrity. It’s also about whether or not something got misconfigured along the way and now you have to go figure it out. Or end up trying to uninstall and reinstall a bunch of stuff.
I’d rather just be able to start over from scratch.
All this work to treat our servers like cattle, but we insist on treating our clients like pets. Your local client should be just as replaceable as your servers.
For example, I use the MacPorts version of Python. If I need any Python dependencies I install them either via MacPorts or pip.
In fact, I only have two Homebrew packages installed: dockutil and mas. Both are tools I use as part of ansible scripts which don't have MacPorts equivalents. All the remaining Homebrew packages are all cask apps (Firefox, Chrome, Discord, Slack, etc.). Those don't have any dependencies that would cause any conflicts.
For comparison, I have 139 MacPorts packages installed. 2 Homebrew packages, and 21 Homebrew cask apps.
For example, notice how there are 4-5 times as many results when searching the web for "configuration.nix" (which is used with NixOS) than there are when searching for "config.nix" (which is used with standalone Nix):
https://www.google.com/search?q=%22configuration.nix%22
https://www.google.com/search?q=%22config.nix%22
I got bored of wading through irrelevant search results, so I uninstalled Nix. (My experience with Guix was even worse, but in a different way.) When I want software that isn't in Debian's repos, I'll stick to installing it from source like I've been doing forever.
Otherwise, I would recommend looking at home-manager, it's essentially NixOS but for any linux distro, or even darwin with nix-darwin. https://github.com/nix-community/home-manager
Using nix as an ad hoc package manager worked for non GUI stuff, though, but that wasn't all that interesting. Except it let me have the latest Python and haskell and so forth...
The nix on its own isn't really that complex, it is really the nixpkgs that is built on top of it and then NixOS that is built on top of nixpkgs.
https://nixos.org/manual/nix/unstable/command-ref/nix-copy-c...
I've found that native Linux makes for an excellent dev environment.
Performance is pretty reasonable? APFS works fine in this setup? No gotchas with drive encryption? ... actually, if your machine does use drive encryption, which is doing it, linux or mac? I don't know enough about mac hardware to know if there is some mac boot environment that handles encryption and then hands off to the OS (be it macos or linux).
You got it.
> Performance is pretty reasonable? APFS works fine in this setup?
Works well enough for my use cases. It's certainly less slow and fragile than running Linux in a VM via macOS.
APFS works fine in the VM, but I use HFS+ just because there are more mature tools to poke at HFS+ images than APFS, right now. The APFS FUSE drivers work well and support reading and writing[1]. There's a closed source driver that supports writing and encryption, though[2].
> No gotchas with drive encryption? ... actually, if your machine does use drive encryption, which is doing it, linux or mac? I don't know enough about mac hardware to know if there is some mac boot environment that handles encryption and then hands off to the OS (be it macos or linux).
I don't use T2 disk encryption, I just let Linux handle partition encryption. Apparently there's support here[3] for it, though.
[1] https://github.com/sgan81/apfs-fuse
[2] https://www.paragon-software.com/us/business/apfs-linux/
I figured since I am passing through all this hardware anyway it might as well all directly access it.
Now with SR-IOV that would be an entirely different story.
I run Wayland, and libinput[4] gives you pretty much all of the trackpad features and gestures you get in macOS like adaptive acceleration, tapping, multitouch gestures etc. Xorg works well, as well, except its gesture support is limited compared to Wayland's.
Depending on the model, WiFi has open source and closed source driver support that both work well, and have Bluetooth support.
This is a good reference to see how well your model is supported on Linux[1]. This project will remap your keyboard shortcuts to match the ones you're familiar with from macOS[2].
I've also posted about making Linux and Plasma Desktop act like macOS on HN[3].
[1] https://github.com/Dunedan/mbp-2016-linux
[2] https://github.com/rbreaves/kinto
[3] https://news.ycombinator.com/item?id=25473702
[4] https://wayland.freedesktop.org/libinput/doc/latest/features...
In particular, I've not seen a package selection so good and so consistently up-to-date, with so very little fiddling or upkeep to add or maintain 3rd-party repos, since I was on Gentoo—and portage broke (in whole, or just had broken individual packages) a lot more than homebrew does (which is almost never). I can't think of a single thing I use that isn't available and well-maintained on it, open or closed source. Even obscure things often just install on my first guess at the package name, no muss, no fuss.
Now, what I don't use it to do is to manage project dependencies, but then I don't like using, say, the "system" PostgreSQL or Nodejs or whatever even on Debian, either, unless I'm using them directly and not making them part of a project that will need to be distributed or deployed elsewhere and worked on by others. I'm entirely fine keeping core OS parts, my personal software I use, and management of individual project dependencies, strictly separate—in fact, having worked this way, I prefer it.
I could be tempted away by a similarly-great and high-quality package selection, maybe, but that would be table-stakes before we even get into the rest of how the package manager operates.
Some people use the above for their projects themselves, for similar reasons, but I just use the now-ubiquitous env and version-manager programs for that (nvm, rvm, that kind of thing). Again: documentation, consistency, and isolation. Even if your dev set-up isn't used for deployment, if it's scripted then it's also accurately documented. As for language-specific libraries and tools, even if a few are in some package manager, I wouldn't rely on them. The language's own package manager will work everywhere, will probably be more (maybe much more) up-to-date, and you're going to need it for some stuff, inevitably, so you may as well use it for everything the project needs from that language.
[EDIT] notably, this way of working means none of my/our projects give a shit what OS or package manager anyone is using. Prefer macports to homebrew? Running Void Linux? Slackware? Probably even Windows (I dunno, who cares, it's Windows, but probably it works)? Go nuts with that, live your best life or whatever, the projects don't care. You'll likely need to manually create a Linux VM for Docker if you're on a BSD, but if you're on a BSD that will be the least inconvenience you face this week. I truly don't get why anyone would just "brew install postgresql" or "apt install postgresql" and use whatever happens to come down as an implicit project dependency in this, the year 2021. Because you actually want to directly use a local database to do database things? Sure. For a project that will be distributed or deployed elsewhere? No no no no no. Not even if you're running the same OS as your servers. Or Ruby, or Node, or even your compilers if you can help it. You have to be more specific and keep your shit tidier than that if you don't want a bunch of pain, both now and later, and almost all of that's very easy to do now.
Arch does seem to be about as good as Gentoo's portage, which is the best selection I've yet to see in a Linux package manager. I'm not interested in a rolling-release base system anymore, though, because I just don't have the time or patience for "running update broke X/Wayland/audio/wifi/boot" these days, or fiddling with whatever it takes to keep that from happening. Rolling release applications? That I like.
Arch does much better, but a quick search of ones I guessed might be missing turned up the following missing, from what I have installed on my Mac:
- rolldice
- android studio (package name android-studio in homebrew)
- tealdeer
- heroku (these are the Heroku command line tools)
- sublime text (package name: sublime)
- postman
- slack
Maybe you can add other repos to get them on there, but I usually just guess the package name and get what I want. I don't think I have a single thing on my Mac, as far as software I directly use (not project dependencies), that I didn't install with Homebrew, aside from first-party Apple software (Pages, Numbers, Safari, Xcode, Mail, and so on). And that's not bringing up all the Mac-only software I've installed with it, which obviously wouldn't be fair.
I haven't added a single extra repo. That's just with the defaults. You used to have to do a one-time invocation to enable binary-only packages (mostly closed-source stuff) and then use a different keyword for operating with them, but that's no longer the case and hasn't been for IIRC at least a year—it's all transparent. "brew install [guess at package name]" works almost every time I need it, and a "brew search" finds the rare failures. I basically never need to open a browser to find & download software, and it's all up-to-date, and it's all totally separate from my base system so is extremely unlikely to ruin my morning because I ran a blanket update-everything-to-latest and didn't pay enough attention.
PS: Debian has > 3x as many packages as Arch[1]. It would surprise me very much if that was just a matter of things being more split up in Debian, or Debian's higher count of virtual packages. When people talk about Arch's great selection of packages, they're including the AUR, which is actually massive. Imo it makes more sense, then, to include the AUR in little tests like this.
—
My main gripe is that Homebrew would regularly break my Python virtualenvs with linking errors. Meanwhile on Linux, I have virtualenvs that I created 9 years ago that still just work.
These days you might be able to sidestep that issue by not using Python from Homebrew at all, but installing and managing it with Pyenv instead.
[1] https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
but yeah, this is a constant source of pain, and I end up helping people at work fix it probably on a weekly basis (or more often). python bin-envs are such a hassle.
Virtualenvs based on Pyenv's local Python installs on Linux works well, and virtualenvs that were based on old system Python versions still work even when I upgrade the system Python. This is where I'd get linking errors with Homebrew that I don't get with Linux.
Also homebrew has so many drawbacks that I'm increasingly planning on boycotting it fully.
The issue is I got an M1 mini mac for development, and I’d rather have the superior fonts and gui of Sublime, MacVim, etc. Granted they look pretty good already on Ubuntu.
I feel like Docker container is the middle way here, you can keep the host clean from complex installs, and you can use evetything on the host to edit your code, since it’s so easy to map folders with Docker.
I don’t really see a downside, although it is super convenient as well with a graphical vm, that you can archive and backup your entire vm, along with all your os preferences, editor settings, terminal settings etc.
edit:
I guess I could also use Macvim etc. on the host with shared folders but those shared folders are slower and have all kind of permission issues afaik, I think Docker mapped folders work better.
Last time I heard Docker on Mac uses virtualization under the hood so it’s about the same as virtualbox (unlike os supported "containers" on linux host), but I don’t know if that is still true for M1?
Docker runs Linux in VMs on Intel and M1 Macs.
I’m running some Linux vms under parallels on a m1 and the graphics performance could be better..
Does it work? When I upgraded to BigSur and Fusion 12 the networking just stopped working.
VMs dont work with NAT at all. In Bridged mode, it partially works. Completely stops if I get the Mac host in to company VPN.
All of this used to work prior version of Mac OSX and Fusion 11.
Note that networking changed a ton in Big Sur because Apple doesn't allow kernel extensions anymore (or, its too user hostile for vendors to do it). The VMware networking stack switched completely to HyperVisor.framework's networking stuff, which doesn't support a bunch of "advanced" features.
I only use it for a hostonly network + NAT and this works fine.
Not GP but I'm using UTM, which is Qemu based. I need Windows to connect to my work so I've setup an ARM Windows 10 VM. Graphic performance is indeed terrible but I've found out that RDP works just fine with whatever resolution your physical computer supports.
qemu? VirtualBox? VMWare? Parallels?
[1] https://twitter.com/mitchellh/status/1346141887996915712
https://blogs.vmware.com/teamfusion/2021/04/fusion-on-apple-...
Interesting.
I could see myself using a similar setup down the line, but having two graphical environments seems like it'd be somewhat distracting or fussy.
Disclaimer: I did this 2-ish years ago, it may have changed by now.
But with native x forwarding coming soon to WSL2, you'll get the same experience soon enough (given that WSL2 is a separate VM running in Hyper-V already).
Does Calendar actually work for you?
Previously, I used Nix on Mac (as this blog post suggests) but I had enough “gotchas” with Nix on Mac that I decided to go full NixOS.
For those who ask why a VM or why I keep Mac around at all: I like macOS for everything else besides dev work. I use iMessages heavily, I like the Mac App ecosystem such as calendars, mail clients, etc. This gives me the best of both worlds.
I usually run this on an iMac Pro but also have a MacBook Pro. It runs great on either. It’s also really nice with Nix to update one machine and the other is just one command away from being equivalent.
I recognize this is a “weird” setup but wanted to point it out since it seems relevant to this post.