Hacker News Reader

Comment by ecoffey | Hacker News Reader

What I've liked about switching fulltime to a mac laptop is the polish. It's a unix install that quickly sleeps when I close the lid :-P

View on HN

The sleep comment is apt. Having run linux on laptops many times in the past, the regular incompatibilities and inconsistencies are hard to get past. From power management features, to wifi quirks there is always something that just doesn't work right.

I've spent the better part of my life, from age 6 onwards tinkering with computers, installing and reinstalling OSes and I can honestly, say I'm over it. Now I just want the damn thing to work like every other user. I think being burnt out on tinkering makes me a better developer though. At least as far as creating a good UX goes.

When I finally got it working on my asus, it still took a healthy 2 - 5 minutes to sleep and about the same to wake

Full hibernation on my AMD 'netbook' is that way (or was before I shoved an SSD in it), but sleep/wake is usually pretty quick. When it works. But it rarely works.

Don't get me started on what the WiFi switch does in Linux. (I could swear it sticks a random value in the CS and IP registers.)

Package management is not a minor part of the "unix install". When I get a just works Mac equivalent of pacman -S whatever, I'll consider using OSX for more than testing.

The homebrew comment (which I can't reply to for some reason) is good, but not totally fair. Homebrew has to compile everything, while this isn't a huge problem with todays machines it is still a bit of a time sink. Homebrew regularly has packages that fail to build. There are over 400 open pull requests for the project at the present time to illustrate this problem.

Homebrew != apt-get or any other linux package manager.

"compile everything" is an approach to package management. BSD Ports (as well as Gentoo's Portage) use it. It does a pretty decent job at helping packaged programs build off/work with unpackaged installs. You also get some marvelous compile environment debugging adventures. ;)

Not saying it isn't an approach, I'm just saying,it's apples and oranges. When someone suggests that OSX doesn't have a linux style package management, they are technically correct.

What does "linux style" even mean? Linux is a kernel, it doesn't define how a package manager is supposed to work. Gentoo has been source compiling from ages, and is a linux distribution. If you're looking for technical correctness, your initial comment[1] is wrong in the context of Portage.

If you're looking for a reason to dislike a project like homebrew, bring up that it's nowhere close to complete system management. There's huge parts of OS X that I have to have already installed through other means just to get it up and running, and plenty more that I simply cannot install through it. That's a lot more important than wether or not you have to wait for package compilation.

[1]"Homebrew != apt-get or any other linux package manager."

Well, hang on there. I'm not here to become Mr. Homebrew Defender, but saying 'this project has 400 pull requests, that's a problem' isn't fair at all. The majority of those pull requests represent users updating formulas to new versions of things, or adding new formulas, not fixing problems that prevent things from compiling.

Like any solution, particularly a 100% opensource solution, it's not perfect, but it does do the job, the majority of the time. YMMV, but I have 24 Homebrew formulas installed and have had zero problems with any of them.

I think the point was more that in comparison to the package systems deployed for Fedora or Ubuntu or OpenSUSE (also "100% open source"), Homebrew looks, well, pathetically primitive. Seriously, look at the way launchpad or koji or OBS work sometime.

Sorry, I use and love homebrew, I'm just saying I understand the parents issue with the lack of a compiled binary package manager for OSX. Arguably I can't see anything that is preventing one from being created though. Perhaps compile-on-demand is just the way of the future.

Moreover, homebrew doesn't provide complete package management for the entire system. Sure, it can keep track (sort of) of the packages that it installs, but it's not by any stretch a one-stop destination for anything installed on your system.

By contrast, I know that I can use exactly one tool (pacman)[1] to handle any installation, upgrade, query, removal, dependency tracking, versioning, etc, even for things like Python libraries. I don't need to futz around and try and remember how I originally installed it.

Compare that with OS X, which gave me absolute hell when I tried to do something so utterly basic as upgrade the system version of Python from 2.6 to 2.6.1, just so that I could install matplotlib (or something along those lines). In the end, I had to do some manual rm-ing and symlinking in /usr/bin/System_Python (or whatever it was) just to get everything to line up properly while at the same time not borking everything else on my system. Manual deletion of root-access files? Just to upgrade a single library? Come on, this is 2012, not 1992.... and even if it were, we still had better tools back then!

[1] Okay, technically you'll need a wrapper for the AUR like packer if you want exactly one tool; but my point still stands.

Upgrading the system Python on Mac OS X isn't easy because it's not something you should do. See http://stackoverflow.com/a/1541850 for something of an explanation about this.

My point exactly. A well-designed OS shouldn't require you to keep multiple versions installed on a machine like that. I have exactly two versions of Python on my box (a 2.7.x and a 3.x), and since I don't need to do development testing of libraries against multiple versions, that's all I should need. (And we're just talking about development tools and installation here - what about all of the other aspects of package management, which OS X completely neglects?)

In this case the problem is that libraries may not detect the alternative versions of Python if System Python is still installed. But the prepackaged versions of Python won't always install properly if you already have a Python on your system, so you're in a catch-22.

I mean take a look at the installation instructions for Matplotlib[1]. It takes about two lines to explain how to install it on Windows, and more than half the page to explain different things you have to try to get it to work on OS X. And that's not counting the copious other errors and hacks that you'll find if you try Googling the OS X installation issues.

Let's face it: if it's orders of magnitude easier to install a well-designed library on Windows than your OS, you have a problem with your OS.

[1] http://matplotlib.sourceforge.net/faq/installing_faq.html

> A well-designed OS shouldn't require you to keep multiple versions installed on a machine like that.

A well-designed OS should require you to install a separate version of Python if the version it provides does not suit your needs. Replacing the system version of Python means that any system components that use Python are now running in an untested configuration and may break in mysterious ways. Installing your new version elsewhere removes that concern.

> prepackaged versions of Python won't always install properly if you already have a Python on your system.

If a prepackaged version of Python for Mac OS X won't install if you already have Python on your system, then it's broken. It's that simple. Mac OS X has shipped with Python installed for years, so such a package would not install on any modern Mac OS X installation.

> I mean take a look at the installation instructions for Matplotlib.

I don't know that using Matplotlib as an example really supports your argument.

The installation notes about Mac OS X are a mess, but from my reading of that page it says as much about Matplotlib as it does about the state of Python on Mac OS X. On that page they recommend a third-party distribution of Python named EPD, but then go on to talk about how EPD has issues building Matplotlib on some versions of Mac OS X. Why would they recommend a version of Python that can't build their software? The page also spends a bunch of time talking about older versions of Matplotlib, and about packaging mechanisms that they no longer use. Neither of those things are relevant to the average person that is getting up and running with Matplotlib on Mac OS X.

As far as I can see Matplotlib only distributes binaries for Mac OS X that require the Python.org version of Python to be installed. With such a version of Python installed, the process for installing Matplotlib appears to be as simple as: 1) Install NumPy from http://sourceforge.net/projects/numpy/files/NumPy/1.6.1/ 2) Install Matplotlib from http://sourceforge.net/projects/matplotlib/files/matplotlib/....

As far as I can tell, this is exactly the same process as for Matplotlib on Windows. Right down to installing a version of Python from python.org. I'm not even sure that's strictly necessary. The hand-wavy mention of problems with the system version of Python on the installation page are so void of context and detail that they're impossible to evaluate.

http://mxcl.github.com/homebrew/

See you in the Apple Store.

So does my Linux pc; it also wakes up when I open the lid, equally instantly.

Would you mind sharing some information on your setup? What make/model laptop do you have and what distro are you using? Did you have to do anything specific to get the power management to work properly? Cheers

<Shameless Plug> I'm using a System76 laptop (http://www.system76.com/laptops/model/gazelle) and the power management works quite well. The System76 team partnered with Ubuntu to provide enhanced drivers to support all of their hardware with zero configuration to the end-user. I wish the multi-touch hardware was a bit better, but otherwise, I can't say enough good things about my new laptop.

Thanks for the reply. Have you tried any other distros on it? Specifically I am interested in Arch. Thanks.

Assuming Arch is still based on Slackware: Slackware 13.37 on my Compaq Presario (C700 series) works great.

It never used to, back in the 12.0 Slackware days, and then I gave up and forgot about it. A few months ago I decided to try again and it just worked.

Check out your scripts in /etc/acpi and try `acpi_listen` to see what event is triggered.

My setup is Arch at Toshiba R830, with toshiba_acpi and uswsusp.

Nice! Although that was never my experience, after futzing with it for a while.

I don't want my laptop to go to sleep when I close the lid, especially if it's plugged in. Is there a setting on Macs for that yet or do you still have to run a 3rd party app?

That behavior is one of the most annoying defaults ever, in my opinion.

As far as I am concerned, sleeping is only annoying if it takes time. My MacBook basically wakes up instantly, so I have no issue whatsoever with it. Why do you think sleeping is a annoying?

If he's like me he'll leave some long running process going and close the lid to save power. I do that a lot for compiles or downloads.

If I have a game running I don't want my laptop to suspend, if I have an ssh, RDP, or IRC session open I don't want my laptop to suspend, if I have audio or video playing I don't want my laptop to suspend, if I just started a compile I don't want my laptop to suspend, if I just copied files to my dropbox folder I don't want my laptop to suspend.

Well, if you don't want your laptop to suspend while it is open, use Caffeine. Awesome App!

I was really asking why you would ever want your laptop to not suspend when you do close your lid. Watching a video or game is not possible with a closed lid anyway. Downloading something would be, but then I just leave the lid open if I want to do something like that…

If I have any of the above, I also don't want to CLOSE the lid.

What's with you people? What's next?

"If I have an ssh session running, I don't want the machine to stop when I remove the battery and the charge plug"?

You don't want to close the lid when you have an ssh session running or IRC? That is non-sensical.

Really? Are you doing something over IRC or SSH with the lid closed? I normally don't talk to irc with the lid closed, because I can't reach the keyboard that easily...

If you want something on the other side of the SSH to continue, use sleep or tmux.

If you want to keep your session, well, keep your lid open...

Except if you want to use your laptop as a server, churning on with the lid closed...

Then you might have to wonder if yours is maybe not the typical use case.

Just sayin...

If you have an external monitor and USB keyboard/mouse plugged in your mac shouldn't sleep.

Reply on news.ycombinator.com