4 ms·

* Package management isn't a train-wreck (I always have troubles with brew whenever I have to move to a mac that I never have with linux). * There are substant

* Package management isn't a train-wreck (I always have troubles with brew whenever I have to move to a mac that I never have with linux). * There are substantial subtle differences between Mac and Linux that will eventually trip you up when leaping the divide between development and deployment. * The Mac often has ridiculously old versions of tools because of its GPL allergy. But hey, Macs are shiny and popular.

mugsie 10y ago
++. I will say their screens are a step above 90% of other laptops, not that it makes a huge difference when you are reading text.
- walshemj 10y ago
  so? most development should be done on desktop pcs with dual or triple monitor set ups.
  - mugsie 10y ago
    Yeap, and 90% of mine is - but sometimes you are at a conference, doing something over the weekend, or on a plane, and an external monitor is not possible.
    - walshemj 10y ago
      And your point is? spending the premium for a mac for this use case is a waste of your or the share holders money
      - mugsie 10y ago
        not really actually. the 2 systems on offer were similar price range, and there was other factors that pushed towards a mac.
        walshemj 10y ago
        For the same performance/$ I doubt that
OJFord 10y ago
> Package management isn't a train-wreck (I always have > troubles with brew Really? What? > The Mac often has ridiculously old versions of tools > because of its GPL allergy. Brew! :) I would actually love to ditch macOS - I used Arch on my MBA for some time, but in the end it was better drivers and brew that brought me back. I seriously miss i3wm though. Brew is the best package manager I've ever used - so simple to add your own or edit existing formulae if what you want isn't available.
- draven 10y ago
  I find Arch with AUR offers much more than Homebrew for my needs. There are even specialized repositories for specific uses like ArchStrike for "security professionals and enthusiasts". Using a tool like pacaur makes AUR even easier to use. And PKGBUILDs are not that hard to write!
- crdoconnor 10y ago
  >Really? What? * Conflicts with other software installed causing all sorts of weirdness. * Numerous packages not in the main repo that weirdly have to be installed by some other mechanism (pip, cask, etc.). * Dependency on XCode. There's like a 5 step installation process to get it up and running! * brew install rsync -> rsync [xyz] -> why isn't this working? -> oh wait, the version of rsync on the PATH is still the ancient system one for some reason. * whatever brew doctor does. the fact that command even exists is a big red flag to me. ^^ This is just the stuff I've run into recently when I've had to debug stuff that was working just fine on linux but somehow broke on a somebody's mac.
  - OJFord 10y ago
    > Conflicts with other software installed causing all > sorts of weirdness. Can't say I've had that, but I can imagine it happening - more of a `$PATH` issue than brew's fault though, surely. > Numerous packages not in the main repo that weirdly have > to be installed by some other mechanism (pip, cask, > etc.) There are 'taps' just like there's AUR, apt repos, et al. Cask is a tap away (and this is prompted if you try to run `brew cask <cmd>` without it), and pip is just `brew install python[version]`. > Dependency on XCode. There's like a 5 step installation > process to get it up and running! That is annoying, but you can condense it to a single command (`softwareupdate` piped to some nonsense) for a 'fresh install' script. I think the only way around this would be for brew to ship a compiled binary, and then mandate that you install either XCode Command-Line Tools, or gcc. (Some formulae will need to compile.) > brew install rsync -> rsync [xyz] -> why isn't this > working? -> oh wait, the version of rsync on the PATH is > still the ancient system one for some reason. Well that's just a broken `$PATH`. > whatever brew doctor does. the fact that command even > exists is a big red flag to me. It's a badly named debugging utility. It should just be `brew debug`. It even says when you run it: > Please note that these warnings are just used to help > the Homebrew maintainers with debugging if you file an > issue. If everything you use Homebrew for is working > fine: please don't worry and just ignore them. Thanks!

mugsie 10y ago

++. I will say their screens are a step above 90% of other laptops, not that it makes a huge difference when you are reading text.

walshemj 10y ago
so? most development should be done on desktop pcs with dual or triple monitor set ups.
- mugsie 10y ago
  Yeap, and 90% of mine is - but sometimes you are at a conference, doing something over the weekend, or on a plane, and an external monitor is not possible.
  - walshemj 10y ago
    And your point is? spending the premium for a mac for this use case is a waste of your or the share holders money
    - mugsie 10y ago
      not really actually. the 2 systems on offer were similar price range, and there was other factors that pushed towards a mac.
      - walshemj 10y ago
        For the same performance/$ I doubt that

OJFord 10y ago

> Package management isn't a train-wreck (I always have > troubles with brew Really? What? > The Mac often has ridiculously old versions of tools > because of its GPL allergy. Brew! :) I would actually love to ditch macOS - I used Arch on my MBA for some time, but in the end it was better drivers and brew that brought me back. I seriously miss i3wm though. Brew is the best package manager I've ever used - so simple to add your own or edit existing formulae if what you want isn't available.

draven 10y ago
I find Arch with AUR offers much more than Homebrew for my needs. There are even specialized repositories for specific uses like ArchStrike for "security professionals and enthusiasts". Using a tool like pacaur makes AUR even easier to use. And PKGBUILDs are not that hard to write!
crdoconnor 10y ago
>Really? What? * Conflicts with other software installed causing all sorts of weirdness. * Numerous packages not in the main repo that weirdly have to be installed by some other mechanism (pip, cask, etc.). * Dependency on XCode. There's like a 5 step installation process to get it up and running! * brew install rsync -> rsync [xyz] -> why isn't this working? -> oh wait, the version of rsync on the PATH is still the ancient system one for some reason. * whatever brew doctor does. the fact that command even exists is a big red flag to me. ^^ This is just the stuff I've run into recently when I've had to debug stuff that was working just fine on linux but somehow broke on a somebody's mac.
- OJFord 10y ago
  > Conflicts with other software installed causing all > sorts of weirdness. Can't say I've had that, but I can imagine it happening - more of a `$PATH` issue than brew's fault though, surely. > Numerous packages not in the main repo that weirdly have > to be installed by some other mechanism (pip, cask, > etc.) There are 'taps' just like there's AUR, apt repos, et al. Cask is a tap away (and this is prompted if you try to run `brew cask <cmd>` without it), and pip is just `brew install python[version]`. > Dependency on XCode. There's like a 5 step installation > process to get it up and running! That is annoying, but you can condense it to a single command (`softwareupdate` piped to some nonsense) for a 'fresh install' script. I think the only way around this would be for brew to ship a compiled binary, and then mandate that you install either XCode Command-Line Tools, or gcc. (Some formulae will need to compile.) > brew install rsync -> rsync [xyz] -> why isn't this > working? -> oh wait, the version of rsync on the PATH is > still the ancient system one for some reason. Well that's just a broken `$PATH`. > whatever brew doctor does. the fact that command even > exists is a big red flag to me. It's a badly named debugging utility. It should just be `brew debug`. It even says when you run it: > Please note that these warnings are just used to help > the Homebrew maintainers with debugging if you file an > issue. If everything you use Homebrew for is working > fine: please don't worry and just ignore them. Thanks!