Hacker News Reader

Comment by ekianjo | Hacker News Reader

For developers OSX will almost always be worse than a Linux distro, if only because of package management.

As a developer I work with text all day, a task made thoroughly more pleasant with good font rendering and proper HiDPI support, neither of which are available on Linux. I'll take my 13 inches of Retina display over a pair of 27-inch externals any day.

SSH and rsync for remote editing work just fine from an rMBP.

It's possible to use HiDPI on Linux, but I guess it depends on what software you use. I've used it for almost a year. I set my DPI in X and GTK. I believe GNOME understands DPI, but I just use ratpoison so I don't know. After turning off hunting, fonts look very nice.

Don't bother trying to connect an external monitor with a different DPI though, hehe. I've heard that problem is unsolvable with the X11 paradigm but will be fixed in Wayland (whatever that is).

I want you to re-read the first paragraph you wrote. That's exactly why I don't use Linux. I don't mean this to be a condescending comment, but really, the contents of your entire first paragraph are just things that I don't want to deal with. It's all just bullshit, and I don't have time to deal with bullshit like that. I really just don't want to even think about stuff like that. Not even a tiny bit, not even for a second.

Sure, that's fine with me, you can choose to spend your time however you want.

Someone said proper HiDPI support is not available on Linux. So I replied that I have used HiDPI on Linux for a long time without major issues.

That's not an advocacy argument for anyone to choose Linux. So I might ask you to re-read my paragraph—unless you're so allergic to Linux "bullshit" that mere anecdotes cause you pain, in which case I'm sorry. (That's meant to be just slightly condescending...)

> It's all just bullshit, and I don't have time to deal with bullshit like that

It's bullshit to you, but it doesn't make Linux bullshit - others prioritise different aspects.

You care about HiDPI - perhaps you are a designer, so it's important. But, you're not everyone. For example, I have no need for HiDPI and I personally have much more focus on the power and control Linux gives me. I wouldn't want HiDPI if I had to give up a proper Window Manager.

Your choice is fair enough, but it's no more than a personal preference.

He might not "be everyone" but his priorities are relevant to more people than your priorities by a factor of perhaps 100:1 or more.

I haven't met a single person that didn't immediately appreciate the benefits of HiDPI when they saw it.

Well you sure convinced me with your accurate statistics. You talk of benefits as if higher dpi cures cancer, it looks better and that's it. I really don't know what the big deal is, I have a HiDPI screen, works fine under linux as most of my work is done in terminals all I've had to "configure" was turning off hinting for my emulators and that was that. But they are waay more important things I would like from my machine so there's no need to be condescending just because you and your friends were impressed by the high res screens.

You seriously think more than 1% of computer users care about some esoteric configuration flexibility of a Linux window manager? How insular is your view of the world?

Oh, and higher DPI cures cancer.

I honestly don't care what "hinting for my emulators" means or why it matters that it's off.

This is exactly what I'm talking about. I just want to get work done in a sane way. Linux is insane to any normal human being.

Since when is this a forum for normal human beings?

It's certainly not a forum for one single particular type of computer enthusiast.

Right... which makes it kind of ridiculous to claim that any mention of configuring Linux to work with HiDPI is "bullshit." Because there are a lot of Linux enthusiasts here.

Far be it for me to defend somebody else's words, but I happen to entirely agree with askafriend when he described the manual tinkering required to get HiDPI functioning well as "things that I don't want to deal with. It's all just bullshit, and I don't have time to deal with bullshit like that. I really just don't want to even think about stuff like that. Not even a tiny bit, not even for a second."

There are indeed a lot of Linux enthusiasts here, myself included, but being a Linux enthusiast doesn't mean we all want to act as systems integrator all the time.

This was a pointless squabble to begin with. I just reacted to "askafriend"'s way of arguing against my non-argumentative semi-helpful anecdote... because I think it's really tedious that mere mentions of Linux configurations can turn into a flame war... it also struck me as a little odd to be so ferociously reluctant to engage in any kind of computer configuration, "for even a second", on a forum about hacking.

I happen to see a lot of value in the availability of a free and open operating system, so I take offense when people rail against it in this sweeping way. Yeah, it's not polished perfect like Apple's products (let's imagine that they don't have any tedious bullshit problems), but it's free software and a community effort.

So when people say it's "insane for any normal human being" to use it... eh, that pushes my buttons.

If you install Postgres, you have to mess around with some configuration files. Some people might consider that tedious, painful, horrible bullshit. I just see it as a necessary reality, and I don't whine condescendingly at people who offer advice or anecdotes.

Well if the tradeoff is to use a lesser OS or desktop environment compared to for example Fluxbox then it could be worth it ?

Wow the word bullshit get thrown very easily by people who use OSX and dont want other people to disagree.

Use Linux Mint with Cinnamon - HiDPI is awesome there, Linux finally looks good! I switched development over there from OS X & Win, on three 4k monitors and a notebook with 3200x1800 resolution.

You should check out the Infinality[1] patch sets. Installation is extremely simple when using your distro's package manager. The improvement made on rendering text is astronomical.

[1]http://www.infinality.net/blog/

Or just enabling subpixel-hinting and font-smoothing. I didn't bother with infinality after that.

I feel the same way. Every few months I will have a moment where I think, "I really shouldn't be using this small screen 14 hours a day, lets hook up my 22 inch monitor" and I use it for all of 8 minutes before I switch back. The text rendering is absolutely beautiful.

BULLSHIT

I live in the command line and use a modern toolchain. Package management has no bearing on my development. mvn, npm, composer, gem, and pip all work just fine. Home brew gets you the OS packages and I've yet to run into an even remotely popular package not in a Homebrew repo somewhere.

On top of all that- with Vagrant and (or even just) Virtualbox you have whatever flavor of Linux you want running on your desktop.

I have found OSX to be the best combination of just works enough OS with all the command line power I need. I can't effing stand Windows anymore and all the Linux desktop distros, though may have some appealing niche characteristics over OS X, there are way more rough edges. I could see one day leaving OS X for a Linux distro, but it won't be any time soon.

I've been on HN for years now and I've never seen someone write "BULLSHIT" in all caps here.

Can we not do that?

That's fair enough. I can see how the response starts significantly more aggressive than I meant it to be as a quick response.

Trash talking laptops and OS choices seem to be a pressure point for HN users, considering how civilised discussion is normally.

Hmm, I guess the tone of the actual content wasn't abusive or inflammatory so I didn't think about it. OS flame wars are still burning.

We've just given up on OS X for developers at my workplace. There are just too many little incompatibilities. Especially around clang replacing gcc messing with our C++ code, but also different revisions of various gems - especially browser testing - that cause hiccups. And then there's setting up all the ancillary services like databases etc. - not just once, but repeatedly, and reconfiguration when the arrangement changes. We can reuse many of our actual deployment Puppet scripts for setting up developer Linux machines; not so much for Mac.

Various utility scripts need to be written more defensively to run correctly in OS X with its ancient shell and BSD tools.

Overall it's just not worth the hassle, particularly when you need to ramp up new developer machines in minimal time.

We use Vagrant and Chef to provision everything, and where possible, I like to keep my OS relatively clean- so I don't have any databases or anything installed in OS X anymore. We have a number of Vagrant and Chef scripts that will take developers from zero to fully running development environment with a simple vagrant init command followed by a few steps for hooking up whatever must be hooked up in the IDE for remote debugging where necessary. It's been fantastic, but we're mostly JVM based.

I could definitely see how clang would screw things up. I don't have experience as a C/C++ developer in OS X for anything other than personal electronics projects.

My personal and professional experience with significant development time in Java, PHP, Python, and Node has been that only Linux could do it as well, but the trade offs for daily desktop use simply aren't worth it. Being able to pump my development environments into a VM of the same flavor as the target environment has given me the best of all worlds. But I've genuinely never run into anything that just refused to work on OSX. I will say that Python and Python env are sometimes a PITA, but not any constant issues.

> I live in the command line and use a modern toolchain. Package management has no bearing on my development. mvn, npm, composer, gem, and pip all work just fine. Home brew gets you the OS packages and I've yet to run into an even remotely popular package not in a Homebrew repo somewhere.

When you're building for a managed runtime it's fine. When you're building native code not so much.

I would say that the same does apply for native code as well.

Developing native code means writing code, reading code and documentation, and interacting with the build system / debugger. Those tasks need to happen directly on the developer's workstation, but not the actual building and execution/testing of that native code.

This is better done in an environment with known state, i.e. either an isolated local or remote VM that will have the environment set up as required for production, and likely multiple different, incompatible environments, or some external hardware for many use cases of native code. Best practices and a modern toolchain would imply things like reproducible builds which you can't really have if you're building and running C or C++ code directly with whatever setup and libraries each developer has on their own workstation, no matter if they're on linux, windows or mac.

You need both a reproducible build environment and an environment that your IDE is tightly integrated with - at present IDE-VM integration isn't quite good enough for the same environment to act as both. The closer together those two environments are, the less common bugs that can't be reproduced in the dev environment will be, and such bugs are the hardest to deal with. (You still have to be capable of dealing with them - you'll get them even when running the same OS in both cases - but the lower the rate, the better).

> mvn, npm, composer, gem, and pip all work just fine

...for you.

There are many developers who value high several OS X features, such as well-implemented HiDPI mode with custom resolutions, super-easy backup solution, solid energy saving & suspend & resume functionalities (no conflicts with crappy 3D drivers), etc, etc. Those features wouldn't mean much without the possibility to easily¹ run FOSS on unix-like system.

¹) The differences between various package management systems are not significant in this context.

eh? I have a both and I far prefer developing on the MBP just because the computer is so great and I can use it anywhere hassle free. My ubuntu machine is hard to tab around the windows and generally has a bad UI and the fonts are terrible. I actually had an ubuntu machine before I ever used a mac computer, so if anything I should be bias towards the more familiar linux setup. The MBP totally blew me away. Linux package managers may be superior, but I don't actually spend most of my development time installing system packages thankfully. npm, maven, pip are identical experiences on both.

Maybe, but only marginally so. In an age of cheap virtual environments of many flavors, this objection seems minor to me.

This is certainly not true. You can basically get any package with Homebrew that you can on Linux, (assuming it's on GitHub, you can get all of them) in fact there's even a port of it to Linux for people that love it on Mac.

Homebrew is certainly not as good as a regular package manager you get in Linux. I'm not sure how you can argue otherwise.

Decade old heavy Linux user who got his first Macbook a few months ago. I agree that Homebrew is not as good as most package managers. However, it's good enough and doesn't get in the way. It does what it needs to do and because of that, I don't think it's fair to use that as a reason to claim that OS X is worse than Linux for developers.

Oh just wait. It will, I promise. It's nowhere near yum or apt.

Tbh, yum and apt both get in the way for other reasons. Homebrew is nice and straightforward. Very much depends on what development you do though - anything web-related, and you're absolutely fine on a Mac.

Homebrew is really, really good about about giving you guidance to fix failed installs.

"Homebrew failed to do thing...here's exactly the commands you can run to make this thing work now though if you are so inclined."

apt fails? Good luck

This is somewhat untruthful. If apt fails, it tends to leave detailed error reports, and does its best to leave things in a sane state. However, if you're using apt, you're doing it wrong - aptitude is where it's at.

Home brew, when things go wrong, goes wrong disastrously in my experience. You're never quite sure where you're left, and you have to spend a fair bit of time picking through what actually failed.

If APT fails catastrophically, your complete system could be in limbo. If Homebrew fails catastrophically (which never happened to me), the rest of your system is fine, you wipe out /usr/local and are up and running again in a couple of minutes (since most large packages are bottled).

By the way, aptitude does not really help you in the typical error case: a package (continuously) fails in dpkg-reconfigure, which causes the complete install/upgrade to fail.

apt is not the only package manager on Linux. At least you have abundant choices as to what you can use. As always on Linux, for about everything, there are tons of ways to do it.

And homebrew isn't the only package manager on OSX.

I actually see this as an argument in favour of OSX, as it is much more straightforward to change package manager than on Linux, where the sane way to change package manager is to change your distribution.

Homebrew is certainly not as good as a regular package manager you get in Linux.

It's actually better, for three reasons:

- If a library is not in Homebrew (which happens frequently when you are a developer ;)), you just install it into /usr/local/Cellar/<name>/<version> and you can use all the regular Homebrew tools (brew link <name>, brew unlink <name>), etc.

- It's much easier to build and distribute your own stuff in Homebrew, by providing a repository of formulae. I have packaged both Debian packages (distributed via Launchpad's PPA) and created Homebrew formulae. Packaging for Homebrew is much easier.

- Homebrew is packaging is decoupled from OS packaging/updates. This means that you can update a new application without having to upgrade half of your system. In Linux, you usually have the choice of: stable OS, outdated software. Up to date software, in-flux OS.

> This means that you can update a new application without having to upgrade half of your system. In Linux, you usually have the choice of: stable OS, outdated software. Up to date software, in-flux OS.

I've never seen an application on Linux asking to update half of my system libraries or something. Please stop using hyperbole, this is not useful for the sake of conversation.

On top of that, you can install recent software in many ways (OpenSUSE has specific, updated repositories that can be triggered with one-click on their website, Ubuntu has pretty much the same thing with PPAs) or you can even build everything from source on Arch with AUR and just ensure you have updated libraries as required (which is not half of your system).

And if you don't want to update ANY of your system libraries, it's fairly straightforward symlink local versions of libraries instead of system ones.

It might be for a package maintainer or if you aspire to be. As a develop I have no aspiration for that.

Homebrew frequently requires you to manually perform steps or edit files. While it might not be directly homebrews fault, that 100% disqualifies it for the label "It's actually better".

How is it not as good? I'm genuinely curious because I've used apt on debian derivatives and rpm on red hat and I prefer brew to both of them.

My favorite is actually Nix/Guix but I haven't bothered to set it up on my daily driver.

A few reasons:

- you have way more packages on any Linux package manager.

- Linux package managers do not mess with /usr/local as expected in a UNIX compatible OS. Homebrew does. Linux package managers run as root, not in user-space.

- Apparently Homebrew gets broken by Apple software/OS updates.

- Linux package managers are an integral part of the OS environment and update process - it's structured this way even for critical system and kernel patches.

- Aptitude, for example, gets rid of older versions of packages, while Homebrew keeps all previous versions and simply changes the symlink. Cleanup is also automated in Linux package managers, not Homebrew as far as I know.

- Homebrew sometimes pulls up sources to compile software locally, while Linux distros usually pull up binaries (except AUR on Arch or Portage on Gentoo, or Sbopkg on Slackware). While compiling from source is nothing wrong, it can take a lot of time depending on what you are building.

- you have way more packages on any Linux package manager.

And Homebrew tends to be more up to date then most distribution repositories. Especially if I want to have a stable OS.

Linux package managers do not mess with /usr/local as expected in a UNIX compatible OS. Homebrew does.

You can install Homebrew in another directory, it works fine.

Linux package managers are an integral part of the OS environment and update process

Which is bad. Application updates are typically tied to base system package updates. Either you use some stable branch (like Debian) stable and you are stuck with old software. Or you use some rolling release, but then your kernel, X11, Gtk+, or whatever could break.

Decoupling the installation of applications from the base operating system is a good thing.

- Aptitude, for example, gets rid of older versions of packages, while Homebrew keeps all previous versions and simply changes the symlink.

    brew cleanup

...and old versions are removed and downloads are cleared. Also, you can add the --cleanup flag to upgrade and it will remove old versions. I prefer Homebrew's approach here, because it's easier to rollback.

While compiling from source is nothing wrong, it can take a lot of time depending on what you are building.

Luckily, Homebrew bottles most software that has long compile times. I have a MacBook with a Core M processor and install times have never been a problem (and I have installed Boost, Rust, and ghc, to name just a few larger things).

> Decoupling the installation of applications from the base operating system is a good thing.

How is that a good thing if an application needs some core OS features that are not available in its current state? Newer libraries become available for all software and benefit from the upgrades. And yeah, sometimes some things break, but it's easy enough to roll back to a previous library version if you need to, instead of bloating the system with multiple versions of different libraries.

> You can install Homebrew in another directory, it works fine.

But it's not its default. How many users change its directory ?

> And Homebrew tends to be more up to date then most distribution repositories. Especially if I want to have a stable OS.

Honestly you can't compete with AUR (Arch) on that level.

I went from Windows to using Ubuntu for years then to Mac only a few years ago. I really disliked the packaged management as well. Homebrew and seeing individual apps give me "an update is available!" pop-ups felt like such a step backwards.

However...what specifically are you wanting to install and update on Mac that a better package manager would significantly help with? I find on Mac I'm rarely installing or updating new packages so it doesn't bother me as much as I thought it would. As long as I can easily install and update Python, Node, Vagrant, Chrome and a few other things I'm happy.

I'd love a laptop that had a long life battery, good screen, good build, was light, ran an open source OS that supported all the software I need etc. but you have to compromise unfortunately and I can compromise on package management.

Most of these things are considered features of homebrew, not bugs.

Nonsense. Absolute rubbish.

Being broken is a feature? Changing /usr/local instead of being sane? Leaving old versions of packages lying about instead of cleaning them up? Breaking when the Apple devs wonder if it would be fun to switch things up a bit under the hood without telling anyone?

The one thing I can think of that's a "feature" is that brew compiles locally, instead of pulling down a binary, but even that has some draw backs.

I'm all for product loyalty, but a spade's a spade.

What exactly is wrong with writing to /usr/local? It seems to fall in line with the FHS standard, at least as far as I can tell.

Sometimes older versions of different packages may be dependencies of newer packages. This is a thing that happens with software. When it's not a problem, `brew cleanup` gets rid of old versions.

Most of the time brew does install binaries, they're called Bottles. When it can't find a binary, it compiles locally. Yes this is sometimes annoying but it's not a deal breaker, at least not for me.

I'm not sure what you mean by "Breaking when the Apple devs wonder if it would be fun to switch things up a bit under the hood without telling anyone." This has never happened to me or anyone I know and furthermore Brew is a Unix compliant tool and OS X is a SUS compliant operating system.

Sorry if I'm sounding harsh, it just sounds a little like you're a Linux user who doesn't or possibly hasn't ever used OS X. Brew is not a panacea but it's honestly pretty good. There's also MacPorts if you're used to more old-style tools and a couple other package managers as well. You can even use Nix on OS X.

> Changing /usr/local instead of being sane?

Better than most OS X programs, which seem to have paths like /Applications/Something.app/Contents/Resources/SomethingElse.app/Contents/Developer/Frameworks/Resources/Something.dylib/Contents/Resources/MacOS/Resources/Frameworks/Something.dylib/Contents/Developer

Case in point, an excerpt from the program Lipo's usage text:

fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo [input_file]

I'm not understanding what is "insane" about installing to /usr/local/Cellar and dropping a symlink in /usr/local/bin. This is the convention on OS X. All tools I have ever seen install to /usr/local.

Not being a part of the OS is a major issue, though.

Maybe not as good, but definitely good enough. (My personal laptop runs Archlinux, my work laptop runs OS X).

Which developers?

Not everyone is writing POSIX only code.

Of course, Darwin is a perfectly cromulent POSIX system.

My point being that human beings writing native desktop and mobile applications, device drivers, games, vertical integrations, plugins for commercial software are developers as well.

UNIX having a cli doesn't do anything to help us.

Homebrew is pretty good.

Reply on news.ycombinator.com