Windows Management Framework 5.0 Preview [1] contains early versions of Microsoft's OneGet and PowerShellGet.
OneGet can install applications from repositories, using any number of providers. The preview version comes with a version of Chocolatey [2] built in managed code (C#) instead of PowerShell, but it supports the same Chocolatey gallery (a repository of software packages) and protocol.
PowerShellGet [3] can install PowerShell modules (e.g. make new Cmdlets available on the PowerShell command line). The modules can be delivered as scripts or as compiled .NET assemblies. By default PowerShellGet is configured to use a (closed preview) repository [4], which makes it not very usable, but it's interesting to know what direction it is headed.
As a more practical alternative to PowerShellGet, have a look at PSGet [4], a PowerShell module for installing PowerShell modules, with its own dedicated repository. Hopefully Microsoft's PowerShellGet will support PSGet as a provider in the future as well, the names are certainly confusing.
Desired State Configuration (DSC) [6] is a new (Windows 8.1) capability to configure Windows using a declarative syntax extension of PowerShell v4. It can set registry keys, create files and directories, enable Windows Features, and more. DSC 'resources' are PowerShell modules, so DSC's capabilities can be extended, see this GitHub repository [5] for examples.
Alternatively, have a look at Boxstarter [7]. It can do installation and configuration, and you can host your 'starter script' online and launch it with a single command. Boxstarter will take care of all Windows restarts that might be necessary along the way.
Be aware that, although most modern package solutions for Windows are using NuGet as a packaging format, using NuGet.exe directly (the application) and with nuget.org (the website) is meant for managing software development dependencies, not installing/updating end-user applications or command-line utilities.
On windows I'm forced to do some nasty tricks (i.e.: reloading the script with admin user, and if any exception happens I output the stacktrace on a tkinter textarea, since the terminal is not available anymore)
(to actually install software, I use chocolatey, but it's really hit and miss...)
It worked pretty well on my macbook air once I figured out the marvell ata errors (the sata controller behaves poorly) and the backlight (magical recompilation every boot on a new kernel with dkms solved it).
I get the joke, and it was the first thing that popped in my head too. But in all seriousness, OS X is Unix as well, and can do pretty much any Unix based task that GNU/Linux can. Sometimes the best tool for the job is the one you already own.
BSD differs from Linux in some important ways. If one of those differences affect your works, than Mac OS X is useless, even if it is Unix (and Linux, some would say, isn't)
"Useless" a strong word for a simple difference between two Unices that affects your work. You could just as well say Linux is useless because sysvinit and upstart aren't the same as launchd.
I get that, and I wasn't trying to say that GNU/Linux is Unix, either. In fact, what with systemd on most major distros these days, GNU/Linux is less Unix-y than ever (I'm not saying that's good or bad; I have my reservations about systemd but they are irrelevant to this discussion and I'm not being biased either way about it here).
That said, for just about any project I've ever worked on within a GNU/Linux ecosystem, I could have easily adapted it to Mac if that was my chosen platform. HTML is HTML, JavaScript is JavaScript, so for today's web-centric projects the OS you're running doesn't matter as much. Even languages like Python don't really care what's under the hood.
Of course, if you're doing Linux kernel development, or targeting a GNU/Linux deployment, then a Mac isn't the best idea. :)
In general, I don't think I'd ever give up Linux. It's a hacker's OS, by and for hackers. Being able to pick apart and fiddle with any portion of, from the kernel on up, is a wonderful, empowering feeling, and something that has proved useful both personally and professionally over the years.
Indeed, when I'm on GNU/Linux I always set the WM to focus-follows-mouse, click-to-raise. But strictly speaking, that's an X11 thing, not a Mac/BSD/Unix/Linux thing.
I didn't mean any slight against GNU/Linux; I use it every day (and I don't mean on a phone or tablet either). But I also have used Macs for stuff that works better on a Mac, and Windows for stuff that works better on Windows. There isn't a "Best OS" period, because every use case is different. There's only "best for the job at hand".
As the other commenter stated, it's an X11 thing. Despite the prevalence of applications that run under X11 and the XQuartz availability, the native UI under OSX is Quartz which handles everything under OpenGL I believe....?
iOS may be Unix underneath, but on the top it has a terrible WM that simply cannot be changed to behave like anyhting else. I'm using xmonad and while I may come off as pretentious, I do see that my colleagues that use mac constantly fight against the WM, searching for windows, moving them around, resizing etc.
The biggest problem I had with Mac OS X was it's user space unix tools. Everything GNU is ancient from before GPL3, everything BSD is crazy ancient from FreeBSD 5.. it's pretty awful.
Thus why macports for me was king. HomeBrew tried to hard to not replace your user space, though I haven't looked at it in a long while. I'm on Linux everywhere now.
I've never gotten CPAN to work reliably with any OS's included copy of Perl. As with Python and Ruby, if you want to use things not available via the OS's package manager, you're best off installing a separate copy.
So, I've satisfied your request, "Try using cpan to install basic modules like MySQL". I guess that means you admit OS X "can do pretty much any Unix based task that GNU/Linux can"?
That's a larger problem I have with the Mac (and Windows, although less so) platform as a developer environment: all the cool tools are closed-source and paid. That's a serious barrier to innovation.
"Cool tools"? Needing ext#fs write support on OS X is a pretty niche application and I'm honestly surprised it's continued to be a viable business for Paragon all these years, especially with the rise of mainstream virtualization. I wasn't expecting to find them still selling it at all.
It probably wouldn't be there except I'm sure most of the expertise and code had to be developed for their imaging and partitioning products.
I think the only things I run frequently for development that don't come with OS X and aren't free or open source are Sublime Text and Paw. You can certainly use vim/emacs/TM2 and curl scripts if you want.
Were I using Linux, I'd be using Sublime Text, and, well, curl scripts again. I'd also be jumping off a cliff after about two days of dealing with desktop Linux's horrific regressions over the past decade.
OS X's native development tools (Xcode, llvm/clang) are free, and most of the tools you use in Linux are either already there, or a "brew install" away.
The UX is amazing if you ignore gnome/kde etc, which are just imitations of windows and mac. I'd say the true linux UX is in tiling window managers. Just like the terminal and vim/emacs, tiling WMs have a steep learning curve and an amazing payoff where the computer becomes an extension of your will, rather than something you fight. I really recommend you try them.
That being said, they don't look pretty, but they make me so productive I just can't go back to anything else.
I disagree that tiling WMs necessarily have a steep learning curve. From experience I claim: Anybody can learn to use a WM like xmonad in its stock configuration in about 30 minutes, and be proficient enough to have a significant boost in productivity in a day or two.
You're right that it's not necessarily steep if you're used to using keyboard commands. But if you're used to doing everything with a mouse it might take some adjusting
It's just, look at all this fighting you have to do to get linux tools on your mac. It's not a hacker OS by default, it's a pretty, user-friendly OS by default, and you can use homebrew and these other tools to replicate many of the features you'd get on the actual hacker OS: linux. Unless you're developing for Mac, I just don't get why it's so popular with developers.
(OK, that's not true, I get it. It's very cool looking. But I'd think more developers would get past that and see how hard they're working to turn their cool looking OS into a poor linux imitation).
It's popular because it's Unixy without all the bullshit. I stopped running desktop Linux/FreeBSD years ago because the UI and system management tools in that world were such a clusterfuck. Now I can run commercial applications and not have to deal with all that configuration file nonsense.
Honestly, it's quite insulting when you presume that people who use OS X haven't considered the alternatives, or are unfamiliar with Linux.
Why try to get Linux tools on your Mac in the first place? You don't see guys fighting to get Mac tools on Linux, so why does it happen the other way around? Perhaps they picked the wrong hardware and OS?
I don't understand what you mean by "hacker OS" though? If you mean an OS that I can write code on, all mainstream OSes apply. If you mean an OS that I can constantly fight to get hardware working on and where the windowing paradigm shifts according to the whims of the incoming teenage developers (see the CADT model), then OSX doesn't fit in. (I use Linux, just not any recent WM thanks).
But I agree with you otherwise; not trying to pick a fight.
My stumbling block is always that I start with macports, which requires Xcode, which requires logging into apple, app store, long download, long install ...
Do I understand that brew does not require xcode and I can jump straight from a new machine to `brew install git` (for instance) ?
i personally think Boxen is the easiest way to setup a brand new machine. it can also easily be distributed and updated
the only downside is that it requires Xcode + command line tools.
https://boxen.github.com/
Boxen always seemed pretty heavy-handed to me for a single developer as opposed to an IT team managing workstations for a team of developers. Is this not the case? A dotfiles repository always seemed like enough to me.
Just curious, what's wrong with Homebrew? I'm just a student, not a full-time developer, but I've never had problems with it and find it pretty pleasant to use.
It's slow and it has to build the packages most of the time. pkgin will install a precompiled packages very quickly. It is also a whole C program and Homebrew is just ruby scripts.
So the opaque pre-compiled blob that installs other pre-compiled blobs is somehow better than a collection of scripts that lets you build from source? I don't think so... As an update is something that is done occasionally and in the background "slow" is not exactly a reason to change.
> It is also a whole C program and Homebrew is just ruby scripts.
And that's a problem?
I would argue that it's a feature. Due to Homebrew being written in Ruby, it has easily allowed over 4,000 contributors [1]. Recipes are easy to read and inspect for verification purposes.
I use a macbook for the battery life and the no-hassle experience (which is getting worse everyday, but that's a different discussion). Homebrew works against these two principles in multiple ways. Compiling software takes massive amounts of time; if I need to install something I want it now, dammit. In principle, there are some binary packages too, but when I tried homebrew there were not for anything that I needed.
Apart from time, compiling software consumes energy, decreasing the autonomy of my laptop.
But those are not the main reasons I dislike homebrew so much. My main gripe is that the packages are of extremely poor quality. When I needed something, it was not compiled with the options I needed. E.g. packages were missing DTrace integration, QEMU was missing the one target I cared about etc.
I am a Go developer; you have no idea how many problems people have had with the homebrew package. It is garbage. And Go is quite trivial to package compared to other stuff. I simply gave up on helping anyone reporting a problem if he is using homebrew. I ask them to recompile Go from official source first.
And then there's the whole curl into bash things, gah I'll just stop now.
The biggest advantage of pkgsrc (apart from quality binary packages) is that I can use the same package versions, compiled exactly the same (to the extent possible) on OS X, Linux, and Solaris; and these are production-ready releases used in production by Joyent (and others) vetted by actual release engineers.
And with pkgsrc it is trivial to install from source when you need to modify a package locally (unlike, say, with apt).
(On a sidenote, I got into Arch because I heard hype, but did not even like it until I recognized the BSD outlook, with ports and pkgsrc style tools. This is very cool, and now I know what to use if I deal with OSX again!)
This "cool hacker settings for your Mac" script turns off your laptop's power saving features (sleep, display dimming, hibernation even though sleep was off(?)), removes at least three kinds of backups for data loss (MobileTimeMachine, Resume, hibernation file), and changes AppKit settings in a way your customers will never be using (by turning off Automatic Termination, which is pretty harmless).
Please don't run scripts like this, unless you promise not to post about how your untested configuration is so unstable and has such bad battery life after an OS X update.
That's a common problem with all of these OS X setup helpers. I recall one floating around with a big batch of defaults settings, many of which I would never use.
That said, these projects are useful for showing off strategies for others to adopt. I treat them much like someone's heavily customized emacs or vim setups: a good reference for ideas, but only ever to be cherry picked into my own setup, and only after I understand the piece I'm picking.
Completely agree, you should definitely closely inspect any script you run, before running it. These settings have been working well for me, but I may tweak them in the future.
That's a little hyperbolic. Sure, that script stops your Mac from automatically going to sleep, but it's not like it changes the CPU usage or power usage (and it will still sleep when you close the lid).
Most of the settings in that script appear to be disabling automatic or "smart" things that average users don't want to think about and power users want done a specific way (e.g. backups, screenshots). Basically if you read that script and don't understand what it's doing then you shouldn't be running it.
Actually, I was going to check if those commands changed the lid-closed behavior and edit the post, but guess they don't.
Still, it does turn off display dimming and automatic termination - those can both affect the leaving laptop on a table unplugged case, one much more than the other.
I agree, I seriously don't understand why anyone would ever want to run this script. Getting 8+ hours of battery life is the entire reason I use a Macbook.
Just like PC's, Macs have entered the world of, what I call, "car guys." Car guys are always fiddling with things for a tiny performance or perceived security boosts without really thinking things through. In the Windows world you'll hear them tell you how you must disable the UAC, must install registry 'cleaners', must use $av_vendor_x because $av_vendor_y sucks, fiddle with some obscure registry change, use drivers or utilities from sites laden with malware, etc, etc. As a sysadmin, these guys drive me crazy. Often, they're the dominant voice in PC or gaming forums and their advice is not only terrible, but actually makes things worse for the end user looking to solve an issue.
At least in the Windows world we have ugly GUIs and other roadblocks to making these changes easy. With OSX's scripting, you could have one single script make all these changes. Its interesting to think how terrible some random person's advice on the internet can be to your machine if you decide to type in what they say. Worse, I'm seeing a lot of FOSS/Linux stuff that more or less asks you to wget a random file on a random server into your shell and run it as root. Umm, no thanks.
The above wouldn't be so bad if they all came with well written undo scripts, but I think the "car guys" aren't even considering scenarios where their half-cooked advice would be wrong. If they did, they probably wouldn't be putting this stuff out there like this.
Huawei even builds this nonsense into the OS! The Mate 2 (which is neat because I get 30+hours battery) has this stupid easy-to-hit button on the app switch page that terminates everything. Despite my usage never going below a GB free, it gleefully proclaims "XXX MB freed!" Well shit, I can go buy a 1GB SODIMM and leave it on my desk and always have 1GB free.
"Automatic"? Or do you mean an application that makes killing tasks fewer taps?
Because the latter isn't that bad ... I have apps misbehave about twice a week; chrome, skype, yelp, google voice - they all need an occasional fresh start - a convenient way to do that I don't understand the objections against.
"Haxies are a source of controversy among Macintosh software developers. Because haxies make changes to Mac OS X that Apple did not intend, they complicate the operating environment for other developers' applications, and are frequently the cause of system instability and unexpected crashes.[1] Applications by Bare Bones software display a dialog after crashing (or are force quit by the user) if haxies are detected on the system. The Omni Group routinely asks users to remove Application Enhancer modules before contacting customer support for help with their applications.
According to a post by an Apple employee on an Apple mailing list, Apple ignores all crash reports submitted by users if they show that APE is installed."
"Reports abound regarding users suffering from a “blue screen” after upgrading to Leopard: they upgrade, reboot, and get stuck at a blank blue screen.
But, as far as I can tell, there is no mystery involved. There is one and only one known cause for this problem: old versions of Unsanity’s Application Enhancer, a.k.a. APE. Versions 2.0.2 and 2.0.3 of APE are apparently inert but harmless on Leopard. But at least some, if not all, versions of APE preceding version 2.0.2 are incompatible, and will render the system unbootable if left in place during an upgrade."
This is a great analogy. In high school and college, I believe I was a Windows and then Linux "car guy". One of the things I liked when I (mostly) switched to OSX from Linux was that I no longer had to spend any time fiddling with stuff. I used to find it fun, now it just feels like there's way too many interesting things to be learning about and doing to spend any time tweaking crap on my computer!
I feel there's two levels of the constant fiddler, one where their fiddling is fruitful, one where the fiddling is not. The difference, I feel, basically comes down to how much you document, test, and automate what you do.
If treated like science instead of voodoo, messing with your computer becomes one of those "interesting things to be learning."
That's how I used to feel, and then (documentation and automation or not) it totally lost its interest for me! Creating software is just so much more interesting than configuring somebody else's. YMMV.
Programming is very interesting and enjoyable, but it's also quite hard. The road from idea to implementation is often long and filled with obstacles. It's well worth it to spend some time "fiddling" to remove some of them. In truth, I personally am not very interested in tinkering with config files - it's boring and frustrating at times - but I still do it. I feel it's my duty as a professional as well as a pride as a craftsman to keep my tools sharp.
People who refuse to do this scare me a little. They got something somebody else told them works and they learned to live with it even if it has flaws. Now I have to wonder: how many refactors weren't done, how much technical debt piled up just because they did the same when writing code?
Interesting perspective! I think the analogy to refactoring is also apt. Keeping tools sharp is good, but (quickly, in my opinion) hits a point of diminishing returns. Refactoring is even better but also eventually hits that point (much less quickly).
> but (quickly, in my opinion) hits a point of diminishing returns.
That's certainly true - it depends on the tools you use and problems you use them to solve, but sooner or later you'll see your "sharpening" stop giving you any advantage. That's the moment you should just stop :) And maybe try other tools: but that's always a non-trivial time investment and should be done only after making sure there actually is something to be gained from the switch.
This is true in most other areas as well. For example, I'm collecting knives as a hobby. I had to learn how to care for them and sharpen them. It's incredible how sharp you can make a knife given proper tools - whetstones ans stropping - you can get an edge which is sharper than any scalpel or razor. It's also a complete waste of time to do so: it takes hours to make a knife that sharp and it takes one or two cuts to dull it. Granted, my "dulled" edge is probably still sharper than anything you ever saw ;) but in the end I get the same edge I'd get without those extra hours spent on polishing it. It then stays that way for quite a long time. It took me years to learn how much sharpening is "good enough". Now, for my primary pocket folding knife, I spend 15-30 minutes sharpening it per week and get an edge I can trust.
It's the same in programming. Both sharpening knives and tinkering with programming tools can be pleasant by itself. It takes practice to recognize that "good enough" is actually really ok and that anything more than that is a waste of time. Still, I can't imagine not sharpening my knives at all. Or giving them to someone else for sharpening. The very idea seems crazy to me.
Your story about the knives is interesting, because it sounds like all you really need is one (or maybe even zero - I'm not sure what you're doing with them) "good enough" knife, but you enjoy having a bunch and tinkering with them. That's great, and sounds pretty fun. My point in this thread has just been that at some point I realized all I really need is a simple development setup, and that I don't particularly enjoy tinkering with it.
Took me a moment to realize what you were talking about then visions of my game boot disks came flooding back. They're probably still in my parents' computer desk.
I think one of the things that the author forgot to mention is that you don't have to install these as `sudo` basically, homebrew does that already but with other things there no really need for it. As of the FOSS/Linux stuff you are seeing, these aren't random files, these are mac apps see: https://github.com/caskroom/homebrew-cask
It turns off hybrid sleep (where memory is written to disk when sleeping so it could eventually resume even if the battery died), as well as automatic sleep (when the lid is open). These are things I turn off 100% of the time on all of my machines.
I'm a bit dubious about the display dimming thing - I'll probably leave that on in my fork of this script.
As for Automatic Termination, I need to read more about that before I turn it _on_, not before I turn it off. :)
I agree with you 100%. I bought a new mac book pro 2 weeks ago and it took me about 2 hours to get up and running.
Because OS X is linux based (BSD but the difference is not relevant here), a lot already exists to make these kind of things work out of the box.
Personally, I need two things to have my setup working:
- Homebrew (OS X only but it's a given to anyone used to ruby)
- dotfiles
My dotfiles are on github and git can be installed via homebrew. I am using vim so my setup depend on both homebrew (git) & dotfiles (settings/plugins).
I have no idea why I would need anything more than that to get started. But this is personal, your company needs may be different. But don't think you need some kind of automation, linux has powerful tools. Use them.
I always got the feeling that installing Homebrew and running the associated apps that run under X but not natively under Quartz was a broken way to get apps on Mac OSX (unless it runs under Quartz now...?)
It feels like the "dirtying" of the native system in the same way that installing cygwin and a mingw and GNUWin32 on Windows does, just in order to get it more like Windows. Rather, I'd use the native utilities on the system and native compilers.
Is it just me who feels this way? Does any Linux user feel compelled to install Linux and then run software ONLY under Wine?
Oh dear...
Its not even BSD-based...
Its Mach based(http://en.wikipedia.org/wiki/Mach_(kernel)) with a BSD userland. (Read BSD-API). So its "BSD-based" in the same way as Windows is Posix-based (as it too can have a Posix userland API).
You're missing the rather well placed claim that people should not run the script blindly but indeed read the comments of the script, and only use the parts that they want to. This is an Administrators' script - most admins worth their salt read the scripts they're about to run, especially if bold claims are being made about their efficacy.
There are lots of great things to learn in the settings being tweaked in this script ..
No, you change your user shell to the shell you want. You can do this in the "Accounts" preference pane by control-clicking a user, selecting "Advanced Options" from the context menu, and changing the "Login shell" setting to your preferred shell.
That should be #!/usr/bin/env bash, particularly for BSD which does not install bash in /bin. Nothing new about absolute executable paths being non-portable, #!/bin/bash is as bad as #!/usr/bin/python.
Right....but your user shell has nothing to do with shellshock. Shellshock involves things like Apache invoking system calls that need a shell, and those system calls don't care what your user shell is. They care what /bin/sh and /bin/bash are (or wherever your system shells live, it's /bin for OSX).
This guide is claiming that updating your login shell to bash via Homebrew will mitigate shellshock, which is flat-out wrong, and dangerous to boot.
OK, but nothing in your comment implied that you were talking about the "Shellshock" vulnerability. I believe that a very recent OSX update patched this vulnerability, anyhow.
Oops, a very good point. I should have mentioned that right off the bat: my issue was with calling this a "hacker's guide", when it contains a pretty blatant security issue.
I think the parent poster is talking about eliminating all known-vulnerable bash shells from his machine, not just having the default user shell change.
The next thing you should do is update the unix tools you already have on your mac. This is more relevant than ever since the recent "Shellshock" debacle.
How many developers are launching bash scripts with environment variables defined by third parties?
After installing Mackup, the Mac backup tool mentioned in this guide, I noticed that it backed up my entire ~/.ssh directory to Dropbox. This included my id_rsa private key, which I would prefer not to have on Dropbox, even with a key passphrase.
I do not wants to flame, but is there a reason people dislike Macports so much. I tried Homebrew when it was 1-2 years old, but stuck with ports bc it was so stable, compiles from source, and I never heard a serious problem.
I heard the opposite complaint on the net, but almost all Macports hate was from many years before.
I am the only one who chose not to rely on Homebrew!?
I am absolutely no kind of programmer but I prefer to compile from source on my own, when I can. For example, the first thing I did yesterday after clean installing Yosemite Beta 4 was to compile Scrypt.
For example, I like running the latest version of Vim (OS X is often behind). Compiling from the source, I can control what the binary is named (to avoid a name collision with the built in Vim), I can control the features (--with-features), and I can have it install to a directory of my choosing (~/Applications, where I also have scrypt install).I also install Lame and FLAC this way.
Nope, I'm a Macports guy as well, never had any serious problems with it. I wish it was possible to run both though because there are packages exclusive to either that I would like to run.
No, MacPorts is actually more sane in this regard because it build it's own set of dependencies instead of relying on anything the system provides. This makes it a more soundly designed tool, IMO.
Homebrew also recommends using /usr/local as the root which I think is just plain bad advice, but it is simple enough to change it to something else.
Because /usr/local doesn't belong to homebrew and is not appropriate for homebrew to commandeer.
MacPorts was originally written by the BSD team at Apple; if /usr/local was where a packaging system was supposed to stuff itself on OS X, they would have used it -- instead of /opt/local.
The co-opting of /use/local breaks all kinds of stuff -- for instance, /usr/local/lib is in the default linker search path and can't be removed, which means that trying to not link against homebrew libraries requires some pretty evil hacks -- such as library symbol interposing to hide /usr/local from stat(), etc.
I disagree. / is where the stuff needed for single-user mode gets installed. /usr is where the OS's userland stuff gets installed. On Linux systems this includes everything that you get from your package manager, because this is considered to be part of your system. /usr/local is wher you install your own packages. For example, if I'm installing something from source, that's where I'm going to install it. Or if I'm building my own project, I would also install it there.
On a Mac, there is no system-blessed pacakage manager - the official packages are pre-installed on your Mac and only change when you get an OS update. They tend to be installed in /Library or ~/Library. All of the add-on package managers therefore play a role much closer to that of hand-installed source. It's logical that they install to /ur/local. In particular, one of my main use case for package managers is when I want to try out a package that has a whole bunch of dependencies. I might want to compile the package that interests me by hand, as I need to tweak the config, but I don't want to have to do the configure-make-make install dance for the 30 packages that it has as dependencies. That's where homebrew / MacPorts comes into the picture, they save me that work. But they should be installed into the same hierachy as the package that does interest me, as they are at the same level of "officialness".
One last thing. I know Fedora, Gentoo and MacOSX fairly well, and I have also worked a fair bit on a hand-rolled linux distribution. None of them ever had /usr/local/lib in their LD_LIBRARY_PATH by default, I've always had to configure that in my .bash_profile. This is exactly what you would expect, by default the directory should be empty, so why add it to the default LD_LIBRARY_PATH, that doesn't make any sense.
Well, it usually installs from source, but that's not really the point. It's a package manager, it is trivial to give it it's own home, (and thankfully they made that an easy thing to do), but to throw it in that /usr/local bucket by default? It seems like a decision that requires real justification and the reasons I have seen seem pretty weak.
I mean, in the end it seems like almost nobody cares, but it's always been a pet peeve of mine.
I get what you're saying, but /usr/local is where I install stuff. I'm happy with having the thing that does little more than untangle my dependencies before running `make` for me with sane defaults use it too.
I expect to find system-specific applications in /usr/local. I get the argument otherwise, and it has merit, but not enough to not do it, if you get me.
Can I ask what you use your package manager for? My experience on the Mac is that it's mostly used by developers that want to install a package and don't want to have to manually install the 30 other dependencies by hand. For that use case, installing the dependencies along side the module that you actually wanted seems like an eminently reasonable thing to do, and certainly in my case it's pretty much exactly what I want from a package manager on the Mac. I assume if it bugs you that you have a different use case from mine. I would be interested to hear what it is (have I been missing opportunities on my Mac all this time???)
> On a Mac, there is no system-blessed pacakage manager ...
Which is one very big reason why commandeering /usr/local for a single package manager is inappropriate; it means that your 3rd-party package manager cannot share the system with any other 3rd-party package manager.
To re-iterate -- the BSD team, who maintained hier(7), very intentionally didn't put MacPorts in /usr/local.
I would think you can't find recent Macports complaints because nobody uses Macports. I didn't even realize it was still being updated at all. I stopped using it many years ago because it was frequently long out of date and broke in ways that I found impossible to fix without wiping everything and starting over.
I switched to Fink, which broke occasionally but I was usually able to rescue it without too much hassle.
Eventually I stopped using Fink maybe a year (or two?) ago in favor of homebrew, and have not had any serious problems since. brew's structure combined with 'brew doctor' and a vast and frequently-updated array of available packages seem to have done a pretty good job of avoiding the "can't get there from here" problems I had with fink and macports.
Huh. I had no idea. I've been using MacPorts for what must be a decade, or close to it. Tried Fink a few times, never had any luck -- but never had a reason to find anything new (brew). I guess the Ports versions of everything I use are "good enough". If it ain't broke, and all that.
Homebrew was new 5 years ago when a whole new generation of Mac-using front end developers discovered the command-line (and git, and tmux…). MacPorts worked perfectly well but hey! how can an old tcl-based, svn-using package manager compete with a new ruby-based package manager that's on GitHub?
I prefer Homebrew over Macports, because the Homebrew default is to use the stuff your system already has. Macports always wants to pull in (newer versions) a bunch of stuff that's already in OSX.
There's benefits to both approaches. However, I really only need a few extras on my OSX laptop, and I don't really want to end up compiling dozens of extra stuff just to get the latest version. Sometimes I want to force that new version, but only if there's specific functionality I'm after. Others really want to get the latest and greatest of everything constantly...
I use MacPorts. I tried Homebrew about a year ago, it worked fine, but I could not see the benefit. The current MacPorts is pretty up to date, at least for my needs. Pretty trouble free…
I think homebrew is much easier to contribute to. I started using it when I wanted something that neither Macports nor homebrew had at the time, and it was very simple to add it to homebrew. It seems like things are generally more up to date and comprehensive in homebrew, and I think it's because of how easy it is to add things.
I stopped using Macports for two reasons. First, it was taking a long time for some of the ports to get up to date. That doesn't seem to be a problem now, but it was. The second reason is that it insists on using its own versions of tools that OS X already has. I'd prefer not to install new versions if I don't have to. I understand their reasoning, but that's why I don't use Macports.
I don't use either. I build my stuff manually, and that way I also contribute upstream if there is a problem with some software not building on Mac OS X out of the box.
Macports was perhaps necessary a while back, when most people didn't realize Mac OS X was just another BSD based UNIX. Now that the word is out, most software builds without a hitch.
And honestly if you can't download a source tar archive and compile it yourself with your own customizations, then don't call yourself a hacker.
I like Macports a lot more. I've never had an issue with any of the packages really besides a few esoteric ones that failed to build or hadn't been updated in a while (and they are usually easy to by updating the portfile). I prefer the segregated environment of macports too, you won't overwrite any system stuff. I got the impression that homebrew wasn't a terribly well thought out tool and was a bit lazy. There's a lot of 'github' culture there which I'm wary of (and by github culture I mean half finished stuff and fancy looking projects lacking rigor). Case in point, it annoys me that their slogan is 'the missing package manager for OSX'. Macports had been around long before they were. I only sometimes wish that Macports had better binary package support.
Assuming you have uBar installed, is there anything about it that makes it feel like an add-on? Or does it feel like it's really a part of the desktop environment? (I'm not talking about design aesthetic or anything like that, just wondering if it gets wonky sometimes)
Hi there, I'm the developer of uBar:) uBar is made to totally feel like part of the system. Please feel free to check out the 4 week trial, and take advantage of the The Talk Show coupon! And if you have any suggestions or feedback, you can send them via Twitter or email using the Send Feedback item in the uBar menu. Just see the release notes to see how much user feedback gets incorporated into updates:) Regards, Edward
A taskbar like Windows is useful to know what are your alt-tab targets, of if you need to open a new app. But good idea, I'm going to try the empty dock.
I use the empty dock too - well, nearly. I have emacs, terminal and browser on there permanently, for quick access to my 3 most-used programs. For quick access to everything else, I've got a shortcut to the Applications folder too. (Sort by Name, Display as Stack, View Content as Automatic.) To reduce clutter, you could alternatively make yourself a ~Applications folder with a reduced set of shortcuts in it, and add a shortcut to that instead.
I'm certain OS X was set up this way when I first got my computer, but I've used some people's Macs and they don't have it. So... maybe it wasn't? But anyway, default or not, it works well.
Years ago I thought DragThing (http://www.dragthing.com/) was the coolest thing around. I went around making all sorts of clicky things to litter my desktop with. It's apparently still developed though I don't think I've seen any screenshots of it from this decade, so it might be wishful thinking that it would've kept up with OS X UI styling. uBar looks interesting though and it's nice to see people working on this kind of tool.
I think the developer spends more time working on PCalc, and even then, I think the iOS version gets the most attention.
I last used DragThing back in the OS 9 days. With the OS X dock, it didn't seem as necessary. Couple that with LaunchBar (or Alfred/Quicksilver) and I have basically my launch needs met.
Thanks for linking to this, I just picked up a copy. I switched to a MBP retina two months ago, and have made an effort to keep it fairly vanilla and figure out how to do things in OS X... without diving into OSXvsWIN, let's just say I'm super glad to have found this add on. It'd be even better if it updated to mimic Windows 8's taskbar (popup previews of windows, mostly), but I'll take what I can get for now. Easily worth the $20 it normally sells for to me, but I could only pay the $10 sale price. Sold!
On one hand, I feel so much more aware of what's currently running on my computer, but on the other hand, I feel a bit like the kid I mocked in the 2000s who would move his Windows task bar to the top of his screen because he missed using his Mac.
You might also be interested in Witch [0] which lets you switch between windows of different apps as opposed to only switching between single apps or between windows of a single app.
I love Witch, but after upgrading to Mavericks I found that it was weirdly sluggish and tended to overshoot what I was aiming at. It also doesn't function with a lot of fullscreen apps (primarily games) and iBooks does ridiculous stuff with its windows that no app switcher seems to know how to work around. All that said, I'm still glad I bought it and I end up switching back and forth to the default app switcher because it's so much better in every way but those bugs. I'm sure the iBooks thing will get resolved and I think the sluggishness thing is eventually going to get cleared up in patch.
FYI: The grep in homebrew/dupes is not a newer version of the grep provided by OSX. OSX grep is the BSD variant, hb/dupes provides GNU grep. I am always shocked by how poorly BSD grep performs compared to GNU grep. I think you need to provide the `--default-names` option in order to use GNU grep in place of BSD grep.
> What is the difference between the cask installation suggested in the link and the cask installation procedure suggested on the cask home page?
Two differences. One is that we moved to an org repo, so the first form is relying on the github redirect from the move. The other is that the second form relies on the semi-recently introduced "auto-tap" syntax in homebrew.
Functionally they will get you to the same place (we've got code to notice that your remote is pointing to the old repo location and update it), but the second form is newer and cooler. ;)
Last year I was thinking about creating a service for this built on top of Hubot. The core idea is that you would go to a website and configure your profile. When you get a new Mac, you would just ssh install your profile, go way, come back and your Mac would be setup (Similar to GitHub's new employee setup).
I didn't do much research into whether or not anyone would pay for the service or how many users they might be. But it sounds like this is a stab at helping individual users set up something personal.
Definitely, but after reading some of the responses (e.g. "I ran this script but now my spotlight is missing"), I think too many people skip the learning part.
What do you guys think of http://bowery.io/? It looks like you can have your dev environment for a specific project in the cloud without dealing with all this junk locally.
266 comments
[ 2.8 ms ] story [ 242 ms ] thread[1]: https://ninite.com/
OneGet can install applications from repositories, using any number of providers. The preview version comes with a version of Chocolatey [2] built in managed code (C#) instead of PowerShell, but it supports the same Chocolatey gallery (a repository of software packages) and protocol.
PowerShellGet [3] can install PowerShell modules (e.g. make new Cmdlets available on the PowerShell command line). The modules can be delivered as scripts or as compiled .NET assemblies. By default PowerShellGet is configured to use a (closed preview) repository [4], which makes it not very usable, but it's interesting to know what direction it is headed.
As a more practical alternative to PowerShellGet, have a look at PSGet [4], a PowerShell module for installing PowerShell modules, with its own dedicated repository. Hopefully Microsoft's PowerShellGet will support PSGet as a provider in the future as well, the names are certainly confusing.
Desired State Configuration (DSC) [6] is a new (Windows 8.1) capability to configure Windows using a declarative syntax extension of PowerShell v4. It can set registry keys, create files and directories, enable Windows Features, and more. DSC 'resources' are PowerShell modules, so DSC's capabilities can be extended, see this GitHub repository [5] for examples.
Alternatively, have a look at Boxstarter [7]. It can do installation and configuration, and you can host your 'starter script' online and launch it with a single command. Boxstarter will take care of all Windows restarts that might be necessary along the way.
[1]: http://www.microsoft.com/en-us/download/details.aspx?id=4407...
[2]: https://chocolatey.org/
[3]: http://blogs.msdn.com/b/powershell/archive/2014/05/20/settin...
[4]: https://msconfiggallery.cloudapp.net/
[5]: http://psget.net/
[6]: https://github.com/powershellorg/dsc
[7]: http://blogs.technet.com/b/privatecloud/archive/2013/08/30/i...
[8]: http://boxstarter.org/
Be aware that, although most modern package solutions for Windows are using NuGet as a packaging format, using NuGet.exe directly (the application) and with nuget.org (the website) is meant for managing software development dependencies, not installing/updating end-user applications or command-line utilities.
https://github.com/berdario/dotfiles/blob/master/deploy.py
On windows I'm forced to do some nasty tricks (i.e.: reloading the script with admin user, and if any exception happens I output the stacktrace on a tkinter textarea, since the terminal is not available anymore)
(to actually install software, I use chocolatey, but it's really hit and miss...)
That said, for just about any project I've ever worked on within a GNU/Linux ecosystem, I could have easily adapted it to Mac if that was my chosen platform. HTML is HTML, JavaScript is JavaScript, so for today's web-centric projects the OS you're running doesn't matter as much. Even languages like Python don't really care what's under the hood.
Of course, if you're doing Linux kernel development, or targeting a GNU/Linux deployment, then a Mac isn't the best idea. :)
http://steve-yegge.blogspot.it/2008/04/settling-osx-focus-fo...
In general, I don't think I'd ever give up Linux. It's a hacker's OS, by and for hackers. Being able to pick apart and fiddle with any portion of, from the kernel on up, is a wonderful, empowering feeling, and something that has proved useful both personally and professionally over the years.
I didn't mean any slight against GNU/Linux; I use it every day (and I don't mean on a phone or tablet either). But I also have used Macs for stuff that works better on a Mac, and Windows for stuff that works better on Windows. There isn't a "Best OS" period, because every use case is different. There's only "best for the job at hand".
As the other commenter stated, it's an X11 thing. Despite the prevalence of applications that run under X11 and the XQuartz availability, the native UI under OSX is Quartz which handles everything under OpenGL I believe....?
Thus why macports for me was king. HomeBrew tried to hard to not replace your user space, though I haven't looked at it in a long while. I'm on Linux everywhere now.
Well, that's one I can personally tell you I've had problems with in the past.
> even worked back in 2000 on Cygwin out of the box on win2k
And also this one. That's even back around the timeframe I was actively doing Perl development while using win2k.
In the end after seeing the complex work arounds and all the warnings about buggering up your mac OS install I gave up and run a VM.
After all the nice people that employ me want me to do some nifty Machine learning tools to save a week a month running single adwords account.
https://gist.github.com/anonymous/d69f5b0cee13102a9167
So, I've satisfied your request, "Try using cpan to install basic modules like MySQL". I guess that means you admit OS X "can do pretty much any Unix based task that GNU/Linux can"?
Edit: Seems it's still read-only. If you need write support that badly (why?), there's always Paragon: http://www.paragon-software.com/home/extfs-mac/
It probably wouldn't be there except I'm sure most of the expertise and code had to be developed for their imaging and partitioning products.
I think the only things I run frequently for development that don't come with OS X and aren't free or open source are Sublime Text and Paw. You can certainly use vim/emacs/TM2 and curl scripts if you want.
Were I using Linux, I'd be using Sublime Text, and, well, curl scripts again. I'd also be jumping off a cliff after about two days of dealing with desktop Linux's horrific regressions over the past decade.
OS X's native development tools (Xcode, llvm/clang) are free, and most of the tools you use in Linux are either already there, or a "brew install" away.
I'm hoping the year of the linux desktop will come eventually however.
That being said, they don't look pretty, but they make me so productive I just can't go back to anything else.
(OK, that's not true, I get it. It's very cool looking. But I'd think more developers would get past that and see how hard they're working to turn their cool looking OS into a poor linux imitation).
1. Excellent laptop displays (16:10, high-DPI that actually works). 2. Reliable networking and graphics drivers. 3. Battery life.
Honestly, it's quite insulting when you presume that people who use OS X haven't considered the alternatives, or are unfamiliar with Linux.
I don't understand what you mean by "hacker OS" though? If you mean an OS that I can write code on, all mainstream OSes apply. If you mean an OS that I can constantly fight to get hardware working on and where the windowing paradigm shifts according to the whims of the incoming teenage developers (see the CADT model), then OSX doesn't fit in. (I use Linux, just not any recent WM thanks).
But I agree with you otherwise; not trying to pick a fight.
;) Just kidding of course, yours is way better. Time to think of another silly name for my dotfiles...
[1]: http://robots.thoughtbot.com/brewfile-a-gemfile-but-for-home...
http://curl.haxx.se/mail/archive-2013-10/0036.html
Do I understand that brew does not require xcode and I can jump straight from a new machine to `brew install git` (for instance) ?
If so, why does anyone use macports over brew ?
I suspect macports might also be able to cope with just these tools? Or does it still have X11 ports?
`xcode-select --install`
More info here: http://saveosx.org/
It's great. It really is. I never understood why it's not used by more people. Homebrew is simply awful.
Why use OSX, then? Shouldn't you be using Gentoo?
Give it a try, you might like it (because it rocks!)
And that's a problem?
I would argue that it's a feature. Due to Homebrew being written in Ruby, it has easily allowed over 4,000 contributors [1]. Recipes are easy to read and inspect for verification purposes.
What is the advantage of C over Ruby?
[1](https://github.com/Homebrew/homebrew/graphs/contributors)
At least, not using /usr/local myself, I see a lot of packages building because they have detected I changed the base directory.
Apart from time, compiling software consumes energy, decreasing the autonomy of my laptop.
But those are not the main reasons I dislike homebrew so much. My main gripe is that the packages are of extremely poor quality. When I needed something, it was not compiled with the options I needed. E.g. packages were missing DTrace integration, QEMU was missing the one target I cared about etc.
I am a Go developer; you have no idea how many problems people have had with the homebrew package. It is garbage. And Go is quite trivial to package compared to other stuff. I simply gave up on helping anyone reporting a problem if he is using homebrew. I ask them to recompile Go from official source first.
And then there's the whole curl into bash things, gah I'll just stop now.
The biggest advantage of pkgsrc (apart from quality binary packages) is that I can use the same package versions, compiled exactly the same (to the extent possible) on OS X, Linux, and Solaris; and these are production-ready releases used in production by Joyent (and others) vetted by actual release engineers.
And with pkgsrc it is trivial to install from source when you need to modify a package locally (unlike, say, with apt).
Hence, trying to get such libraries installed with homebrew results in dependency hell, as the package manager won't handle those dependencies.
Source : http://www.netbsd.org/docs/pkgsrc/pkgsrc.pdf
(On a sidenote, I got into Arch because I heard hype, but did not even like it until I recognized the BSD outlook, with ports and pkgsrc style tools. This is very cool, and now I know what to use if I deal with OSX again!)
Please don't run scripts like this, unless you promise not to post about how your untested configuration is so unstable and has such bad battery life after an OS X update.
That said, these projects are useful for showing off strategies for others to adopt. I treat them much like someone's heavily customized emacs or vim setups: a good reference for ideas, but only ever to be cherry picked into my own setup, and only after I understand the piece I'm picking.
Most of the settings in that script appear to be disabling automatic or "smart" things that average users don't want to think about and power users want done a specific way (e.g. backups, screenshots). Basically if you read that script and don't understand what it's doing then you shouldn't be running it.
Still, it does turn off display dimming and automatic termination - those can both affect the leaving laptop on a table unplugged case, one much more than the other.
At least in the Windows world we have ugly GUIs and other roadblocks to making these changes easy. With OSX's scripting, you could have one single script make all these changes. Its interesting to think how terrible some random person's advice on the internet can be to your machine if you decide to type in what they say. Worse, I'm seeing a lot of FOSS/Linux stuff that more or less asks you to wget a random file on a random server into your shell and run it as root. Umm, no thanks.
The above wouldn't be so bad if they all came with well written undo scripts, but I think the "car guys" aren't even considering scenarios where their half-cooked advice would be wrong. If they did, they probably wouldn't be putting this stuff out there like this.
Because the latter isn't that bad ... I have apps misbehave about twice a week; chrome, skype, yelp, google voice - they all need an occasional fresh start - a convenient way to do that I don't understand the objections against.
The biggest one in Mac OS X history I remember is haxies:
http://en.wikipedia.org/wiki/Haxie
"Haxies are a source of controversy among Macintosh software developers. Because haxies make changes to Mac OS X that Apple did not intend, they complicate the operating environment for other developers' applications, and are frequently the cause of system instability and unexpected crashes.[1] Applications by Bare Bones software display a dialog after crashing (or are force quit by the user) if haxies are detected on the system. The Omni Group routinely asks users to remove Application Enhancer modules before contacting customer support for help with their applications.
According to a post by an Apple employee on an Apple mailing list, Apple ignores all crash reports submitted by users if they show that APE is installed."
http://daringfireball.net/2007/10/blue_in_the_face
"Reports abound regarding users suffering from a “blue screen” after upgrading to Leopard: they upgrade, reboot, and get stuck at a blank blue screen.
But, as far as I can tell, there is no mystery involved. There is one and only one known cause for this problem: old versions of Unsanity’s Application Enhancer, a.k.a. APE. Versions 2.0.2 and 2.0.3 of APE are apparently inert but harmless on Leopard. But at least some, if not all, versions of APE preceding version 2.0.2 are incompatible, and will render the system unbootable if left in place during an upgrade."
Ubuntu has even more powerful window managing key bindings by default (on OSX I need Spectacle).
For all other things I just don't care.
If treated like science instead of voodoo, messing with your computer becomes one of those "interesting things to be learning."
People who refuse to do this scare me a little. They got something somebody else told them works and they learned to live with it even if it has flaws. Now I have to wonder: how many refactors weren't done, how much technical debt piled up just because they did the same when writing code?
That's certainly true - it depends on the tools you use and problems you use them to solve, but sooner or later you'll see your "sharpening" stop giving you any advantage. That's the moment you should just stop :) And maybe try other tools: but that's always a non-trivial time investment and should be done only after making sure there actually is something to be gained from the switch.
This is true in most other areas as well. For example, I'm collecting knives as a hobby. I had to learn how to care for them and sharpen them. It's incredible how sharp you can make a knife given proper tools - whetstones ans stropping - you can get an edge which is sharper than any scalpel or razor. It's also a complete waste of time to do so: it takes hours to make a knife that sharp and it takes one or two cuts to dull it. Granted, my "dulled" edge is probably still sharper than anything you ever saw ;) but in the end I get the same edge I'd get without those extra hours spent on polishing it. It then stays that way for quite a long time. It took me years to learn how much sharpening is "good enough". Now, for my primary pocket folding knife, I spend 15-30 minutes sharpening it per week and get an edge I can trust.
It's the same in programming. Both sharpening knives and tinkering with programming tools can be pleasant by itself. It takes practice to recognize that "good enough" is actually really ok and that anything more than that is a waste of time. Still, I can't imagine not sharpening my knives at all. Or giving them to someone else for sharpening. The very idea seems crazy to me.
Just use esxi and run a hypervisor running boot mac os and what ever your production environed if you must have the mc os shiny
> This script should not be run without prior examination. It's quite opinionated and intended to be modified.
I'm a bit dubious about the display dimming thing - I'll probably leave that on in my fork of this script.
As for Automatic Termination, I need to read more about that before I turn it _on_, not before I turn it off. :)
Because OS X is linux based (BSD but the difference is not relevant here), a lot already exists to make these kind of things work out of the box.
Personally, I need two things to have my setup working:
My dotfiles are on github and git can be installed via homebrew. I am using vim so my setup depend on both homebrew (git) & dotfiles (settings/plugins).I have no idea why I would need anything more than that to get started. But this is personal, your company needs may be different. But don't think you need some kind of automation, linux has powerful tools. Use them.
Wait... what?
> (BSD but the difference is not relevant here)
Still, "Linux-based" is a funny way of saying "Unix-like". Is HP-UX also "Linux-based (System V but the difference is not relevant here)"? ;)
It feels like the "dirtying" of the native system in the same way that installing cygwin and a mingw and GNUWin32 on Windows does, just in order to get it more like Windows. Rather, I'd use the native utilities on the system and native compilers.
Is it just me who feels this way? Does any Linux user feel compelled to install Linux and then run software ONLY under Wine?
Linux != UNIX. BSD != OSX
There are lots of great things to learn in the settings being tweaked in this script ..
...right? `brew install bash` will just give you /usr/local/bin/bash, and then use that as your interactive shell.
This guide is claiming that updating your login shell to bash via Homebrew will mitigate shellshock, which is flat-out wrong, and dangerous to boot.
http://support.apple.com/downloads/
I don't know if it fixes the more recently found bash vulnerabilities, but I know it fixes the first one that was reported.
You can find versions for Lion and Mountain Lion if you search.
How many developers are launching bash scripts with environment variables defined by third parties?
I heard the opposite complaint on the net, but almost all Macports hate was from many years before.
I am the only one who chose not to rely on Homebrew!?
As for bread, no, I am horrible at cooking!
I suppose I never run into this problem because I don't use the software to its full extent and therefore don't miss any features! I must be lazy.
Homebrew also recommends using /usr/local as the root which I think is just plain bad advice, but it is simple enough to change it to something else.
MacPorts was originally written by the BSD team at Apple; if /usr/local was where a packaging system was supposed to stuff itself on OS X, they would have used it -- instead of /opt/local.
The co-opting of /use/local breaks all kinds of stuff -- for instance, /usr/local/lib is in the default linker search path and can't be removed, which means that trying to not link against homebrew libraries requires some pretty evil hacks -- such as library symbol interposing to hide /usr/local from stat(), etc.
On a Mac, there is no system-blessed pacakage manager - the official packages are pre-installed on your Mac and only change when you get an OS update. They tend to be installed in /Library or ~/Library. All of the add-on package managers therefore play a role much closer to that of hand-installed source. It's logical that they install to /ur/local. In particular, one of my main use case for package managers is when I want to try out a package that has a whole bunch of dependencies. I might want to compile the package that interests me by hand, as I need to tweak the config, but I don't want to have to do the configure-make-make install dance for the 30 packages that it has as dependencies. That's where homebrew / MacPorts comes into the picture, they save me that work. But they should be installed into the same hierachy as the package that does interest me, as they are at the same level of "officialness".
One last thing. I know Fedora, Gentoo and MacOSX fairly well, and I have also worked a fair bit on a hand-rolled linux distribution. None of them ever had /usr/local/lib in their LD_LIBRARY_PATH by default, I've always had to configure that in my .bash_profile. This is exactly what you would expect, by default the directory should be empty, so why add it to the default LD_LIBRARY_PATH, that doesn't make any sense.
Right, that's what it's for, it's also why a 3rd party package manager shouldn't use it.
I mean, in the end it seems like almost nobody cares, but it's always been a pet peeve of mine.
I expect to find system-specific applications in /usr/local. I get the argument otherwise, and it has merit, but not enough to not do it, if you get me.
Which is one very big reason why commandeering /usr/local for a single package manager is inappropriate; it means that your 3rd-party package manager cannot share the system with any other 3rd-party package manager.
To re-iterate -- the BSD team, who maintained hier(7), very intentionally didn't put MacPorts in /usr/local.
I switched to Fink, which broke occasionally but I was usually able to rescue it without too much hassle.
Eventually I stopped using Fink maybe a year (or two?) ago in favor of homebrew, and have not had any serious problems since. brew's structure combined with 'brew doctor' and a vast and frequently-updated array of available packages seem to have done a pretty good job of avoiding the "can't get there from here" problems I had with fink and macports.
There's benefits to both approaches. However, I really only need a few extras on my OSX laptop, and I don't really want to end up compiling dozens of extra stuff just to get the latest version. Sometimes I want to force that new version, but only if there's specific functionality I'm after. Others really want to get the latest and greatest of everything constantly...
Macports was perhaps necessary a while back, when most people didn't realize Mac OS X was just another BSD based UNIX. Now that the word is out, most software builds without a hitch.
And honestly if you can't download a source tar archive and compile it yourself with your own customizations, then don't call yourself a hacker.
I'm faster with the Windows-style taskbar and uBar (http://brawersoftware.com/products/ubar) was the sponsor of the last episode of John Gruber's podcast.
For launching I use a tool like Quicksilver or Alfred of Spotlight.
This way I get more screen realestate, I see no point staring at a dock icons all the time.
My dock resembles Command-Tab.
I'm certain OS X was set up this way when I first got my computer, but I've used some people's Macs and they don't have it. So... maybe it wasn't? But anyway, default or not, it works well.
I last used DragThing back in the OS 9 days. With the OS X dock, it didn't seem as necessary. Couple that with LaunchBar (or Alfred/Quicksilver) and I have basically my launch needs met.
On one hand, I feel so much more aware of what's currently running on my computer, but on the other hand, I feel a bit like the kid I mocked in the 2000s who would move his Windows task bar to the top of his screen because he missed using his Mac.
[0]http://manytricks.com/witch/
And don't feel bad - if NeXT had had a taskbar, we would all have been using a taskbar for the last 14 years!
Two differences. One is that we moved to an org repo, so the first form is relying on the github redirect from the move. The other is that the second form relies on the semi-recently introduced "auto-tap" syntax in homebrew.
Functionally they will get you to the same place (we've got code to notice that your remote is pointing to the old repo location and update it), but the second form is newer and cooler. ;)
I didn't do much research into whether or not anyone would pay for the service or how many users they might be. But it sounds like this is a stab at helping individual users set up something personal.
The older I get, the more I leave things alone. Swim with the current.
Me too, but I'd never discourage anyone from tinkering. Sure you might break stuff, and that's a learning opportunity.