Ok, we get it, some people are paranoid and afraid of running a "random script" and having to sudo to install it. Can we please have a discussion on the merits of the actual application. I just installed it - I trust 37signals enough to give them the benefit of the doubt - and love how simple it is to access different apps I'm working on at the same time without having to worry about configuration. Thanks 37signals.
Introducing Pow, a zero-configuration Rack server for Mac OS X
91–100 of 146 posts
Re: Introducing Pow, a zero-configuration Rack server for Mac OS X
#92Earlier quoted context omitted.
And npm is another popular one. I'm not sure if the multiple examples helps your case or tptacek's though. (That is, we all seem to be getting more and more comfortable with this style of installation.)
tptacek has a good point that you shouldn't just trust any old curl-based install, but I think that really applies to any install of any kind. I think you have to consider the source of any software package, it's not something specific to this particular method.
[deleted]
Re: Introducing Pow, a zero-configuration Rack server for Mac OS X
#93Hooray! No more mucking around in /etc/hosts, .rvmrc, or .profile! Now you can muck around in ~/Library/Application Support/Pow/Hosts, .powrc, and .powenv instead! Thanks but no thanks. Do yourself a favor and learn how to install rack and nginx. It's already dirt simple, and you'll save yourself having to go back and learn it when it's time to deploy your app somewhere other than your laptop.
Or, you could NOT muck about in ~/Library/Application Support/Pow/Hosts, .powrc, and .powenv, and just symlink your app directories into ~/.pow, which is probably how 99% of developers will use it.
To say that something is "zero-configuration" is complete marketing garbage. You get what you deserve if you choose to believe it.
Re: Introducing Pow, a zero-configuration Rack server for Mac OS X
#94Hooray! No more mucking around in /etc/hosts, .rvmrc, or .profile! Now you can muck around in ~/Library/Application Support/Pow/Hosts, .powrc, and .powenv instead! Thanks but no thanks. Do yourself a favor and learn how to install rack and nginx. It's already dirt simple, and you'll save yourself having to go back and learn it when it's time to deploy your app somewhere other than your laptop.
Or, you could NOT muck about in ~/Library/Application Support/Pow/Hosts, .powrc, and .powenv, and just symlink your app directories into ~/.pow, which is probably how 99% of developers will use it.
To say that something is "zero-configuration" is complete marketing garbage. You get what you deserve if you choose to believe it.
Re: Introducing Pow, a zero-configuration Rack server for Mac OS X
#95As an aside, does anyone know what was used to generate the "Annotated Source" code listings? They look absolutely beautiful. Were they generated from the underlying source, or put together by hand?
Re: Introducing Pow, a zero-configuration Rack server for Mac OS X
#96Earlier quoted context omitted.
The only meaningful difference between the two techniques is the extra step required to explicitly execute an installer. Is that your objection, that you don't like something being automatically executed upon download?
HTTPS, automatic installation, and UX that confounds security for end-users are my three objections to this gimmick.
Your HTTPS suggestion makes sense, but can you explain your other two points by contrasting with "gem install"? How is the installation any more automatic? How does the UX confound security?
Re: Introducing Pow, a zero-configuration Rack server for Mac OS X
#97Earlier quoted context omitted.
It's easier for a man in the middle to change a 15-line text script than to change a binary. Lowering that effort = increasing the odds and incidence of attempted attacks.
I request one thing, you send me something completely different. I don't see how making the "something" an ASCII script makes it easier than a random binary (and there's no requirement that the random binary has any relationship with what I requested). Oddly, I'm more used to seeing arguments that distributing source code is better than distributing binaries because you can inspect source code.
The scenario isn't that I send you something different, but that somebody else gets in between us and tampers with the data. That's what https tries to avoid.
We're arguing levels of badness here so it's a little hokey. But if you decide to open up your machine to run arbitrary code, a machine that can run shell will arguably get more infections than one that runs executables. To infect the ladder any script kiddies will need to know a 'harder' language and at least how to compile it. It's a couple more hoops to jump through. In the other case I could drive by and do scp ~/mailbox me@myserver:
Re: Introducing Pow, a zero-configuration Rack server for Mac OS X
#98As an aside, does anyone know what was used to generate the "Annotated Source" code listings? They look absolutely beautiful. Were they generated from the underlying source, or put together by hand?
Sam says it's generated by http://jashkenas.github.com/docco/ here: http://news.ycombinator.com/item?id=2420535
Re: Introducing Pow, a zero-configuration Rack server for Mac OS X
#99Earlier quoted context omitted.
Or, you could NOT muck about in ~/Library/Application Support/Pow/Hosts, .powrc, and .powenv, and just symlink your app directories into ~/.pow, which is probably how 99% of developers will use it.
To say that something is "zero-configuration" is complete marketing garbage. You get what you deserve if you choose to believe it.
Just what this thread needed, more FUD.
Re: Introducing Pow, a zero-configuration Rack server for Mac OS X
#100As an aside, does anyone know what was used to generate the "Annotated Source" code listings? They look absolutely beautiful. Were they generated from the underlying source, or put together by hand?
[deleted]