I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug
mise also can manage brew
Homebrew 7.0.0
261–270 of 270 posts
Re: Homebrew 7.0.0
#262Earlier quoted context omitted.
You can use mise for install homebrew items btw so if you get a new computer you just drop the config.toml inside the mise and install. This is all you have to add to the config file: [bootstrap.packages] "brew:git" = "latest" "brew-cask:ghostty" = "latest"
Homebrew does this as well, I keep my packages synced with a Brewfile in chezmoi. Obv this only works for brewed packages though.
I've found `mise` more useful solely because it also handles things like tasks and daemons.
Re: Homebrew 7.0.0
#263Earlier quoted context omitted.
Apple was selling Intel Mac Pros in 2023, it's absurd these things are coming up on EOL already.
Check out MacPorts. It was the original package manager, still going strong, and it supports Macs going all the way back to the Leopard era. It also always used /opt instead of taking over /usr/bin like Homebrew.
I always found it much slower when compared to brew and sometimes would just hang and get stuck when installing something. Plus the lack of casks does make it less of a direct replacement.
Re: Homebrew 7.0.0
#264Earlier quoted context omitted.
Last time I checked, Mise is still a one-man show. That’s way too risky for a critical party of my supply chain for my taste.
this makes no sense to me, the reason i don't give anyone else the commit bit is only to _protect_ the supply chain. you should want as few people with that access as possible.
The bus factor makes no sense to you?
Re: Homebrew 7.0.0
#265Earlier quoted context omitted.
Thanks for the input! > I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing). Two follow-up questions on this: - How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.) - Does Aurora s…
> How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.) I don't know, and I don't want to have know, how it works. :) It just does. You can force updates by running "ujust update". It updates Homebrew, Flatpaks, the system image and all Distroboxes in one go. You can al…
Unless doing something esoteric like updating firmware that requires manual intervention, Fedora Atomic distros should never need to reboot multiple times to update, as updates are staged as side-by-side replacements of the entire base system, which includes essentially everything that would be installed through the system package manager in a traditional distro, so it's effectively like booting into an upgrade install of the OS (so preserving configuration files, user data, containers Flatpaks, etc.), except the old version remains available as a bootable option (which is possible because the atomic distros carefully separate OS and user directories, with the former typically mounted read-only).
The only times I've (very rarely) run into trouble is when adding additional RPMs to the base install, which, while frowned upon for this reason, generally poses no more problems than installing the same packages in a traditional Fedora installation, so worst-case you can simply uninstall the layered packages and re-run the update if something isn't working.
Again, without a reboot, because incompatible updates generally while staging, not after rebooting the system into the new OS, e.g., a package, possibly from an external repo, which does not exist, or depends on packages that do not exist, in the version you're updating to.
Aside from major version upgrades where packages you've layered might simply have been removed, this occasionally happens if you're installing packages from an external repo like RPM Fusion that's closely integrated with the base OS, because there are times when the base image (or even loose package mirrors) might lag a bit behind released loose packages which updates of external packages may depend on, and while you can override base image packages to resolve this, it's a bit of a hassle and probably not worth the trouble vs simply waiting until the base image catches up. Unless you have specific needs that can't be resolved by, e.g., running applications that require proprietary video codecs as Flatpaks or in containers, I'd recommend sidestepping this whole mess by not layering anything from RPM Fusion or similar (layering to pick up third-party packages that don't depend on very specific versions of distro packages works fine).
Generally speaking, nothing in the update / RPM install / RPM uninstall process touches the running OS unless you specifically request that it does, and nothing changes the on-disk copy of the running OS period. So, e.g., you can add new RPMs to the running install without rebooting, but how this works is that it first adds them to a new staged install, then creates transient filesystem overlays to activate the packages within the running OS. In other words, the on-disk copy of the current running OS remains unchanged and available in case anything goes wrong.
Re: Homebrew 7.0.0
#266Earlier quoted context omitted.
In general I agree, but recycling old power hungry gear may be better for the environment in the long term.
So discard a working and perfectly good Macbook to be replaced by a new one manufactured by the World’s #1 CO2 emitter and transported probably halfway around the world in a container ship burning dirty bunker fuel.
Per unit costs are pretty low, and old Intel gear particularly energy guzzling.
Re: Homebrew 7.0.0
#267Earlier quoted context omitted.
6 years is really not a long time at all. You can probably find heaps of open source software out there that compiles and runs perfectly on 20 year old PCs. It's not like the maintainer has to do much to retain support--they just have to not make the software dependent on new operating systems. Bits don't rot.
Bits certainly don’t rot and you’re welcome to stay on the latest stable version that runs on your architecture. And if you want new bits with the new features, those aren’t the same bits and that work isn’t free.
Exactly. That's all I'm asking for. If version X works on my system today and version Y needs an OS bump, well... that sucks and is avoidable, but whatever. I expect to be able to obtain and use version X tomorrow and into the future. That's it. I'm not asking to make version Y work for me, but it would be nice if they didn't add the OS dependency.
But increasingly, developers can't even manage to keep version X around and working, despite them having to simply not do anything to it to keep it from breaking.
Re: Homebrew 7.0.0
#268Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).
Was issue with upgrade running out of disk space fixed?
Re: Homebrew 7.0.0
#269Earlier quoted context omitted.
Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?
It's an interesting question on Linux. On macOS entire toolchains would be fair game. I just ran `brew install colima`, `brew install llvm`, etc. But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".
I use `lima` and `llvm` every day with brew. It works great there's no reason to use distro specific tooling when you can use what everyone else is using.
Re: Homebrew 7.0.0
#270Earlier quoted context omitted.
You can use mise for install homebrew items btw so if you get a new computer you just drop the config.toml inside the mise and install. This is all you have to add to the config file: [bootstrap.packages] "brew:git" = "latest" "brew-cask:ghostty" = "latest"
Homebrew does this as well, I keep my packages synced with a Brewfile in chezmoi. Obv this only works for brewed packages though.
Yeah, the combination with mise is what make this great.