Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> You're seriously going to defend the App Store?!

Yup, flawed as it is, I find it much more useful than apt. If I'm wearing a dev hat and were forbidden from using anything to manage software installs other than one of apt or App Store (no nix!), I'd rather have apt. But for my non dev apps (you know, even people who tweak kernel parameters have non-programming related apps they want to use from time to time ;), Appstore is obviously more useful.

> However claiming apt and yum suck when also praising the OSX App Store is just weird.

Why? Both fill different needs and App Store solves a problems that are useful to me acceptably well (making it easy to install up-to-date software I want, upgrade it and remember what I have on a per-account not per machine basis).

Yum and apt, on the other hand don't (they don't have up-to-date software I want, they don't give me what I consider a decent way to manage the same or similar setups on multiple machines etc.). I basically install everything I can with nix instead.

> So now on OSX you not only need to run the same "crufty [package manager] queries" on OSX but you also need to install the package manager itself too.

Unlike apt/yum nix offers good ways to do this – no cruftiness involved. E.g. you can just write a small file with what you want and you'll get it, on any machine.

> You only have a finite amount of system resources so you cant really complain if you intentionally over commit them.

That's not what's happened, my VMs where capped at reasonable limits. I used to run some tools for various reasons that could in some scenarios eat a lot of a ram fairly suddenly (I don't think the systems was anywhere close to overloaded CPU wise was true most of the time but I can't vouch I remember this right anymore).

Either way, I don't think the whole OS falling over because one app wants to consume too much memory and the OS has decided to never say no is reasonable. And it's not something I can recall ever happening to me with any other OS (in recent years, I don't want to think back to ancient windows days).



> they don't have up-to-date software I want

I take your multi-machine point but the above just depends on what repository you're pointing at (eg stable, testing, etc) and which Linux distro you're running. You can't really blame apt for being out of date if you're running Debian. And nor could you blame apt for delivering buggy packages if you're running the testing repos on Ubuntu.

It's the same package manager, just different end points.

> Unlike apt/yum nix offers good ways to do this – no cruftiness involved. E.g. you can just write a small file with what you want and you'll get it, on any machine.

Technically you can do that with any package manager - given that's the core point of a package manager :P

I've not used nix (read a little about it but never taken the time to try it) so I can't comment how much easier that makes the process of custom repositories than hosting your own apt or yum repo, but it's not actually hard to do in those two either. Plus you could always compile your own .deb or RPM and install it like a standalone installer (MSI et al).

I've got nothing against nix though. In fact weirdly I think your underselling nix by focusing on the points you have rather than it's major differences from traditional package management.

> That's not what's happened, my VMs where capped at reasonable limits. I used to run some tools for various reasons that could in some scenarios eat a lot of a ram fairly suddenly (I don't think the systems was anywhere close to overloaded CPU wise was true most of the time but I can't vouch I remember this right anymore).

The problem with over commiting is the limits might seem reasonable under normal workloads but when you do end up with an empty bucket you have no safe way to recover from that. Or at least not with desktop virtualisation solutions like VirtualBox. ESXi et al will handle such situations more gracefully because they're designed to over commit during off peak work loads.

That said, I don't know how long ago it was you last did this but a few years ago VirtualBox did add a CPU execution cap in the guest config. IIRC it defaults to 100% but if you're running multiple guests and/or running heavy applications on the host while also running heavy guest VMs then it's worth dropping the CPU execution cap down so the guest cannot lock up the host.

> Either way, I don't think the whole OS falling over because one app wants to consume too much memory and the OS has decided to never say no is reasonable.

I think your expectation here is a little unreasonable to be honest. You cannot drain the host of free system memory and idle CPUs then expect the host to gracefully recover. It's like trying to dowse a fire with an empty bucket. I honestly can't see how OSX would perform any different to Linux in that regard. So you were probably using different virtualisation technologies on OSX (VMWare perhaps?) that handle guests more responsibly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: