FreeBSD on a MacBook Pro(gist.github.com) |
FreeBSD on a MacBook Pro(gist.github.com) |
So... it's not just me. Somewhere between Snow Leopard and Mavericks I started finding building various things from source that never were a problem became an exercise in figuring out what library had been removed or moved or what Apple had done with lib/header paths or something else.
If people aren't going over to another unix, what are they doing? Homebrew? Container-ing or virtualizing another unix? Or just suffering?
I have complaints about the UI changes in OS X sometimes but it's still not as bad as half the Linux applications I'd use in place of OS X ones like Tower
And every time I try Linux i still have issues like the "sleep of death" and NVIDIA Optimus support being in poorly documented limbo (your dedicated GPU is both in use and out of use until you run a graphical benchmark and measure the current draw of your laptop)
And I prefer Homebrew to apt. I've never had Homebrew fail to install other packages because I had a package install break previously, which is always something that drove me nuts about apt.
But then again, I could never do things in tower as fast as I could on the command line, so I dropped it fairly fast. It's not super useful replacement without an interactive rebase. Nice for viewing history, though.
By the way, is it just me or have the vms better disk performance but slower graphics in Linux?
I had almost everything working (Audio, suspend on close, i3 or gnome) but never got the wifi to work, I even tethered from my android phone to the Macbook and it worked very good. But in the end it was to annoying to do often. If only FreeBSD supported that wireless chip, I'd be writing this on FreeBSD. When the wayland and updated intel drivers come to FreeBSD maybe i'll try it again, but wifi is a deal breaker.
I always wondered why there isn't wifi drivers for this macbook in FreeBSD if Fedora had them (and AFAIK Fedora only ships open drivers)
I'll probably just rebuild it instead of trying to upgrade.
It's not that far removed even now, although config is standard /etc
This flipped a set-once bit, making the rest of the article essentially unreadable due to zero confidence in the writer's technical skill. Also, the lack of "late 2011" in the title makes it pretty misleading.
Not sure if you read the rest of the article, but it didn't do much to instill technical competence after that point either.
Is it at all similar to BSD jails?
That was hard to parse.
So the author really enjoys debugging boot problems, but a custom kernel in a VM is just too tricky? Is there something I'm missing that makes that way harder than debugging dual boot?
Is there any magic I'm missing, aside from the shared memory support?
With my compulsive - but hitherto compromised - aversion to running Linux within the virtual-machine of Systemd, I have ever-since intended to try again, maybe with a Pi3 and/or laptop, or even Mac. I've wangled Debian on a Macbook, but would, considering circumstances, prefer FreeBSD. I hope there is promise here. I praise all efforts.
My Raspberry Pi 2 runs FreeBSD very well. Currently running OpenNTPD + Monit + Postgres + Node-RED + go-carbon + graphite-api + Grafana + Syncthing + Transmission — all of this with only 249 MB of RAM used. FreeBSD's memory management is excellent.
RPi 3 (native AArch64 mode) support is in progress https://wiki.freebsd.org/arm64/rpi3 for now it runs only on one CPU core, SMP is "actively being worked on".
I was using HDMI. As mentioned, I've since returned to Raspbian, where I continue to use HDMI and all works generally well. I was initially thrilled after installing FreeBSD, but for whatever reason, things changed. I remember compiling vim for a whole day before cancelling it. I could type an entire sentence or paragraph before any input would show. Bad luck perhaps. My primary use for the Pi is a surveillance camera, so I temporarily abandoned BSD for what I know works. I intend to make my next main system a BSD system. Presently I am running Debian Testing, which has been quite excellent, but as also mentioned, I am bothered by Systemd and aspire to be free of it.
The snark was really unnecessary.
/s
does close-lid-to-sleep and open-lid-to-wake work?
some might care images / screenshot, not me tho :D
Also, you can build the updated graphics drivers from https://github.com/FreeBSDDesktop/freebsd-base-graphics
$ cat /dev/sndstat | grep default pcm2: <NVIDIA (0x0042) (HDMI/DP 8ch)> (play) default
I almost never turn it off as I have to do some weird kind of dance to close the lid and type startx blind so that I don't end up with three screens in X, but I don't really care enough to fix it when I only have to do it every few weeks/months...
I use a thunderbolt Ethernet dongle thingy which does 1gbit since it doesn't ever leave the desk I've not really tried the wifi..
I use a USB DAC when I've got the cans on though because they sound much better (also works, an audioquest thing)...
I won't buy another macbook tho, XPS+Linux is going to replace my luggable very soon.
Mac/OSX stayed out of my way for a few years and was my justification for using it; who's got time to have to deal with the usual linux desktop problems when you just need a machine to do email ssh and a browser, right? I'm not sure really when, but Mac+OSX stopped being the best solution some while ago (for me at least). It's just a constant source of annoyance now (honestly, let an email password expire and see how many times it grabs focus from your editor, I get at least two full on kernel panics a week, distnoted randomly eats a core all day, I have an alias called something like "fsckoff" which does a kill on coreaudiod for when airplay stops working, I'm increasingly nervous about running prop stuff, yadda yadda). The macbook is a pretty cute little machine though, super skinny.
As for BSD? I don't think I'd bother using a BSD on a lappy that you are actually planning on lugging around, makes a nice workhorse in the home office though if you don't want to have to mess with it too much!
Is it just your model? It;s behind my desk but it's some cheapo thunderbolt->hdmi dongle made by "neeto" apparently, works well enough..
[ 131.865] (--) NVIDIA(0): BenQ GL2450H (DFP-2): connected
[ 131.865] (--) NVIDIA(0): BenQ GL2450H (DFP-2): Internal TMDS
[ 131.865] (--) NVIDIA(0): BenQ GL2450H (DFP-2): 340.0 MHz maximum pixel clock
[ 131.802] (--) NVIDIA(0): BenQ GL2450H (DFP-0): connected
[ 131.802] (--) NVIDIA(0): BenQ GL2450H (DFP-0): Internal TMDS
[ 131.802] (--) NVIDIA(0): BenQ GL2450H (DFP-0): 165.0 MHz maximum pixel clock
[ 131.865] (--) NVIDIA(0): Apple Color LCD (DFP-3): connected
[ 131.865] (--) NVIDIA(0): Apple Color LCD (DFP-3): Internal DisplayPort
[ 131.865] (--) NVIDIA(0): Apple Color LCD (DFP-3): 480.0 MHz maximum pixel clock
How do people use their laptops? For me it's almost always at a desk and if not there is always a plug nearby.
FreeBSD's hypervisor is called bhyve (and it uses vmm.ko), and xhyve is a port of bhyve to macOS (uses Apple's Hypervisor.framework). There are other things that use Hypervisor.framework too.
Still nice to know about Hypervisor.framework. If I ever get back to OS X I'll have to check it out!
Docker's macOS installer uses it rather than VirtualBox now if memory serves.
Compiling anything on ARM is horribly slow, cross-compiling from amd64 is a much better idea.
But you don't need to compile vim, there are binary packages for ARM! http://pkg.freebsd.org/FreeBSD:12:armv6/latest/ pkg should just work.
Are you intentionally ignoring the context in which I mentioned Tower?
The alternative app to tower on FreeBSD would be git itself, which had a superset of features, would it not?
Your getting hung up on the Tower example, Tower is far from the only example of OS X applications having a smoother UI than nix. I always felt it comes down to a culture issue, nix users don't mind the lack of polished GUIs if there's a command line tool (which you're so continently demonstrating)
rm -rf somedir/
rm somedir/ -rf
Tower and GitUp are a huge lock-in into macOS for me. Tower for line-by-line staging/discarding, GitUp for minor history fix-ups (editing a commit message without remembering the CLI command, etc.).