Cool idea, but supporting homebrew is a big yikes!
I hope no serious developers on linux ever use homebrew, it's the worst package manager by far.
Most package managers support versioning and keeping old versions of installs around, but not homebrew. That's why I'm boycotting it at this point, got burnt by it too many times.
I'd rather use pacman or apt-get or pkgsrc or nix or any other package manager than homebrew.
I don't use Homebrew because it installs to /home/linuxbrew/.linuxbrew. It makes absolutely no sense to use a whole new user, and then use non-standard directories.
If you change where Homebrew installs, then you are on your own because they don't support changing the install path.
Personally, I would love to not use homebrew, but I'm practically forced to. The package management story in Linux is horrible, far worse than the general fans lead me to believe. Most tools I need are missing or ancient, even in the Fedora repos. That's one of the reasons so many modern tools will give you a shell script to pipe to bash for installation. It's the only way to make things installable in a simple, uniform way.
While homebrew isn't perfect, it's still a lot better than manually compiling every new version of a tool until the distros repo gets the update, or following custom install instructions for every tool (and then manually managing updates).
But I'm new to having Linux as a daily dev driver (only servers before), so if I'm missing an obvious fix to get 99% of tools in their up-to-date version installed and managed on Fedora (or ideally, anywhere), please let me know.
while I use Homebrew on macOS for the errant command line utility or library, I share your concern. I use the Universal Blue Silverblue variant for it's integrated Nvidia support with either mise-en-place[0], or the native toolbx[1] utility for isolated environments.
I've also been very happy with Silverblue (an alternate flavor of Universal Blue, the same guts as Bluefin). It took a bit of an adjustment period to get used to using an immutable distro, but given that I run this as the sole OS on my daily driver, reliability is paramount. It gives the same feeling of running a highly stable OS like MacOS, but with the power, ergonomics and customizability of Linux - and anything I need that isn't easy to fit into the immutable model is just a simple Distrobox invocation away.
It's "Container-driven development" done right - containerized applications and shells _feel_ native via Distrobox (which gives them access to the host FS, network, hardware, etc by default) but without the risks of native development causing dependency conflicts. And if I screw something up, I can just spin up a new container.
Silverblue is a Fedora project. The Universal Blue and its flavors (Bluefin, Bazzite, Aurora) are based on its image. They are basically community maintained versions of silverblue because Fedora is very cautious (and stubborn) in including QoL things.
I really appreciate that he included a video with great narration. So much better than the animated gifs that provide too little context and go too fast.
Ok, so I checked it out slightly more and noticed that the omarchy installation script enables the chaotix.cx repo, which contains packages automatically built from AUR. I.e. packages contributed by practically anyone. So you'll be trusting not just one unknown set of people (AUR) but a completely second one too (chaotic.cx).
Omarchy enables all this silently with pacman -U --noconfirm.
This is probably fine for a hobbyist, and this is what people in the Linux world generally do, but also constitutes a pretty bad supply side attack vector. Then again, not significantly worse than what things like npm/node do.
On a positive note, using the concept of migrations in a tool like this is neat.
I've been using this on a mini pc I bought and I'm really digging it. I could see myself using it as my daily driver instead of macOS one day. I also am floored by how low the resource consumption is on it
I've been following his journey here since Omakub. I plan on refurbishing a 2015 MBP that had its HDD die to run Omarchy this weekend. I've heard it runs well on old hardware. Will be nice to have a mobile dev machine again.
I used the one he put together for Ubuntu. My setup had become old and clunky. My dotfiles had become a mass. It was nice to go from 0 to something useful without effort. Now I just make changes as I see fit.
Crunchbang was such a good distro! I ran linux for about seven years. Ubuntu and then Crunchbang. Had my 2012 MacBook Pro dual boot into Crunchbang. Battery life was awful. It had no automatic fan control, so the laptop got so hot I could barely touch it. I ended up writing a bash script to manually control the fans using function keys https://gist.github.com/nwjlyons/b29ee6f7e26595f55a2a
As cool as it was, I can't be bothered with any of that these days. Just give me a Macbook Pro, as I know it will work and have amazing battery life!
Readit News
https://projectbluefin.io/
I hope no serious developers on linux ever use homebrew, it's the worst package manager by far.
Most package managers support versioning and keeping old versions of installs around, but not homebrew. That's why I'm boycotting it at this point, got burnt by it too many times.
I'd rather use pacman or apt-get or pkgsrc or nix or any other package manager than homebrew.
If you change where Homebrew installs, then you are on your own because they don't support changing the install path.
While homebrew isn't perfect, it's still a lot better than manually compiling every new version of a tool until the distros repo gets the update, or following custom install instructions for every tool (and then manually managing updates).
But I'm new to having Linux as a daily dev driver (only servers before), so if I'm missing an obvious fix to get 99% of tools in their up-to-date version installed and managed on Fedora (or ideally, anywhere), please let me know.
[0]https://mise.jdx.dev [1]https://containertoolbx.org
You can't use pacman, apt or pkgsrc on image based distros. And nix is a big headache.
Of course anything that can easily run in a container is better, but I use brew for the stuff that doesn't and have few problems.
It's "Container-driven development" done right - containerized applications and shells _feel_ native via Distrobox (which gives them access to the host FS, network, hardware, etc by default) but without the risks of native development causing dependency conflicts. And if I screw something up, I can just spin up a new container.
[1]: https://fedoraproject.org/atomic-desktops/silverblue/
Nearly 20 years later and it's surprising that more people don't do this.
Omarchy enables all this silently with pacman -U --noconfirm.
This is probably fine for a hobbyist, and this is what people in the Linux world generally do, but also constitutes a pretty bad supply side attack vector. Then again, not significantly worse than what things like npm/node do.
On a positive note, using the concept of migrations in a tool like this is neat.
I flagged this post for the misleading title. Although this is kind of interesting it's nowhere near as interesting as a new distribution.
As cool as it was, I can't be bothered with any of that these days. Just give me a Macbook Pro, as I know it will work and have amazing battery life!