iOS Static Libraries Are, Like, Really Bad - <AUTHOR> http://landonf.bikemonkey.org/code/ios/Radar_15800975_iOS_Frameworks.20140112.html <comment><USER3> I had a pretty detailed discussion with iOS engineers at a WWDC a couple of years back. It was a somewhat frustrating conversation, mostly because of how badly I wanted true user generated Framework support, but also because the engineers had decent reasons for the existing state of things. Primarily that Frameworks (in their fullest expression) are dynamically loaded.

Apple has made a decision that allowing 3rd parties to dynamically load code (outside of Apple certified frameworks) is a security issue on a mobile platform in particular. I don't have a solid counter argument, although there are certainly some technical constraints they could put in place to help mitigate the risk.

Anyway, agree with your essay in general. But I also understand how we got here.

Cheers

<comment><USER4> If anything, in my mind, _not_ using shared libraries is a security issue.

For example, if every application links to a static version of some image loading library, then all of the applications must be patched if there is a vulnerability in that library.

Whereas if they all share the same copy, you patch the library, and they all get fixed.

I'm aware that model works better when the same vendor is providing all of the binaries, but there are cases where it's also appropriate for general ISVs.

<comment><USER5> It's a two sided coin, if you update a dynamically loaded library that subtly breaks backwards compatibility, you end up with apps that mysteriously stop working because of some other update in the system.

Really, it's up to the app maintainer to update their program, and if it has a vulnerability, in theory the sandbox will prevent it from doing damage to others.

<comment><USER4> If someone updates a library incompatibility, they deserve what they get. That's why shared libraries have versioning.

In the mobile space, it would be even more beneficial if platform holders and ISVs actually followed this; the memory and space usage savings could be substantial.

<comment><USER4> I'm uncertain why someone would downvote my comment above, but shared library versioning is a real thing, and it is a best practice:

[http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html](http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html)

[http://tldp.org/HOWTO/Program-Library-HOWTO/shared- libraries...](http://tldp.org/HOWTO/Program-Library-HOWTO/shared- libraries.html)

[https://www.usenix.org/legacy/publications/library/proceedin...](https://www.usenix.org/legacy/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/)

Linux distributions heavily depend on this for the GCC runtime libraries (such as libgcc_s); it's how they provide backwards compatibility.

Many operating system distributors also rely on symbol versioning for their shared libraries as well so they can compatibly evolve interfaces for consumers.

So my original point stands, if someone incompatibly updates a shared library without accounting for versioning, they're doing it wrong.

</comment></comment></comment></comment></comment><comment><USER6> If you can distribute source Cocoapods is an excellent alternative to static libs.

And if you have to distribute static libs Cocapods again makes it much easier.

<comment><USER7> +1, cocoapods is really great and solves 99% of the issues.

EDIT: Issues I had with integrating third party libs into projects as dependencies in the past, not issues in regards to the blog post.

<comment><USER8> You might want to read the blog post again: CocoaPods does NOT solve the mentioned issues or provides the system that should be made available for developers as it exists on OS X.

<comment><USER7> Sorry, you're right, but still mean my own issues with dealing with third party libraries, it does help out quickly adding something so I could get to use it.

</comment></comment></comment></comment><comment><USER9> I wish that embedding resources in programs as const byte arrays were more common. I think that approach leads to a tightly integrated, low-overhead app, especially on platforms (not iOS) where users and third-party programs are free to do stupid things with the file system; the app either works completely or isn't there at all.

<comment><USER10> You mean like: [https://github.com/liuliu/mopack](https://github.com/liuliu/mopack)? But unable to inspect the embedded resource at programming time is a big show- stopper for me.

<comment><USER11>
        $ xxd -i some_file

<comment><USER10> last time I checked, Microsoft has a weird restriction on their c++ compiler (they don't have a c compiler) that only allows 4k length const chars, you have to concatenate consts to get arbitrary length.

</comment></comment></comment></comment><comment><USER12> I really don't see why dynamic libraries couldn't be allowed per app, in a similar vein to other mobile OS.

It is also sad state of affairs that Objective-C builds up on C's tradition of not having proper namespace support.

<comment><USER13> > I really don't see why dynamic libraries couldn't be allowed per app, in a > similar vein to other mobile OS.

Apple considers it a security issue, so presumably they have figured out attacks that exploit dynamic library loading.

In general though, "Because another platform does it" isn't always a good argument for a particular feature in a platform, particularly when that choice involves a tradeoff. Taken to an extreme, you would end up with a lowest common denominator of samey platforms that just copy each other's design decisions.

In this case Apple has decided that security is a top priority for them even if it comes at a price in terms of developer convenience. Other platforms are free to make different tradeoffs, and that gives users and developers a diverse choice of distinctive platforms available to them. This is a good thing. iOS doesn't have to become Android any more than Android has to become iOS.

<comment><USER12> By other mobile OS, I meant :

\- Epoch OS

\- Symbian

\- Windows CE/Pocket PC

\- Windows Phone 7/8

\- Android

\- Blackberry

\- Bada

The above vendors do have/had secure deployments mechanisms despite support for dynamic libraries.

<comment><USER13> Are these validated to be secure, in this way, or are you just asserting that they are? Bear in mind that many intentional features of Android would considered by Apple to be severe user privacy violations. There platforms aren't just different technically, their standards for what security is considered to be vary significantly. That's fine because if you want those features in Android, then Android has them, but if you prefer a garden with a higher wall, there's iOS.

<comment><USER12> You surely seem to have a problem with Android it seems, as you selectivly ignore all the other ones on your remarks.

</comment></comment></comment></comment></comment><comment><USER14> As much as I generally dislike the iOS ecosystem, Xcode and Apple in general this feels like complaining about nothing much of importance to me...

If you want to share code this becomes a non-issue - you include the code which can detect things like architecture and target at compile time and then its possible to not just transcend the boundary between iOS and OS X, but also Windows Desktop + RT, Android, other *nix flavours and that great operating system that will be released in 7 years time that we don't even know about yet...

a static library is a convenience of pre-compiled code, but also an inconvenience where you can't see inside or implement the many cool things you can with the preprocessor, meta-programming or even scripts that generate code or enforce constraints if you feel so inclined...

Why do you really want static libraries to be usable? Are they really a good thing? Is it really any more convenient than just including a folder of source code in the project?

The only real argument I can see is if you want to keep your code secret which I am philosophically opposed to in the general case...

<comment><USER8> The blog post contains lots of reasons, you might want to read it.

Here is only one example of why including via source code can be a bad thing:

> In the years past, for example, I saw issues related to a specific linker > bug that resulted in improper relocation of Mach-O symbols during final > linking of the executable, and crashes that thus only occurred in the > specific user's application, and could only be reproduced with a specific > set of linker input.

In addition: the writers frameworks/libraries are all (!!) open source! And you claim the only reason for using libraries is keeping the source secret. Yeah!

<comment><USER14> i had a good read... what precisely is the hole in my argument?

there are a few arguments there but they are not especially compelling imo and I feel the advantages of using naked code far outweigh the disadvantages of using a library (the only advantage i can think of which is genuine is hiding your code as binary). let me give my counter to some of the arguments made for why a library is a good thing by way of demonstration:

> a single atomic distribution bundle that applications developers can drag > and drop into their projects.

this is programming - drag and drop is a fantastic luxury and a terrifying one if you like to understand what happens. in any case dragging and dropping a folder in to xcode containing code and resources is just as easy but has the benefit of being absolutely transparent.

> One of the significant features of frameworks on Mac OS X is the ability to > bundle resources. This doesn't just include images, nibs, and other visual > data, but also bundled helper tools, XPCServices[1], and additional > libraries/frameworks that their framework itself depends on.

loose files have this desirable property except for being in a convenient package - including a folder reference or duplicating it as a group in xcode is a drag and drop operation.

> One of the features that is possible to achieve with static libraries is the > management of symbol visibility.

Yeah... loose code files have this /better/ than a library typically does if you like all symbols to be visible. (otherwise its a valid point and lets you hide your code again...)

> Dependent Libraries

including dependencies is a pain, but it makes sure people can use your code immediately. i like one-step processes - every project i've done in the last 5 years or so works with a single check-out from source control - in some cases even if you are lacking the ide or other important tools. the bloat is not relevant today, even on mobile platforms... although i don't seem capable of creating many multiple megabytes of code no matter how much i do except for including some enormous 3rd party library (freetype is the last one i had this problem with - i never use it any more).

> result in builds of the library being unique

this is a genuine problem - kinda - if your code doesn't build under multiple platforms and compilers to have the same behaviour then you have much worse technical debt than this to fix first... like making your code actually cross- platform and deterministic (if you actually need that).

however all of that aside I think my point about being super cross platform across *nix, iOS, OS X, Windows RT/Desktop, Android, Windows Phone 8 and unknown future operating systems trumps the lot...

EDIT: as a real world example consider stb_image.c - a fantastically useful header providing a very clean image loading interface for the most common formats (especially compared to any of the OS library alternatives on all of the platforms where the amount of boilerplate and needless operations is quite staggering for something so simple). I've used this on all of the above platforms and the only problem I have is that the author is not so keen on using the maximum level of warnings like I do... (I like the compiler to never be confused and have the best information available about my program, and incidentally libraries deny the compiler valuable information in many cases too...)

<comment><USER8> 1\. Sadly you ignored the example I posted completely.

2\. Integrating by source code is valid for some use cases, but it is definitely not for all. E.g. low level libraries like crash reporters which can not be platform independent. Or libraries that rely on platform specifics, like UIKit on iOS.

There is not one approach, one way that fits all. For some libraries/frameworks are the best, for others direct source code inclusion is best.

<comment><USER14> i didn't see it and still can't maybe i am being blind or selectively filtering it without realising... :/

> low level libraries like crash reporters which can not be platform > independent.

> Or libraries that rely on platform specifics, like UIKit on iOS.

this is actually not true and i can quite comfortably demonstrate this and have worked in multiple code bases that do such things across all the major platforms, including games consoles...

these pieces are the unavoidable platform dependent bits and can be conditionally compiled accordingly - they are however usually quite small, and also something which a library can not do

this is imo far and way the biggest strength of source code inclusing and precisely what i refer to by 'you can run on every current platform and even ones that don't exist yet'

even 'cross-platform' APIs like OpenGL necessitate this because they make mistakes, or have ES flavour on mobile with breaking changes vs. Desktop OpenGL.

EDIT: "> In the years past, for example, I saw issues related to a specific linker bug that resulted in improper relocation of Mach-O symbols during final linking of the executable, and crashes that thus only occurred in the specific user's application, and could only be reproduced with a specific set of linker input."

ah i guess you mean this. in which case how does a library avoid this? the linker inputs are usually roughly equivalent to libraries... the compiler generated a bad object file consistently? I'll agree that compiler and linker bugs exist but they are the exception and not the case - that effects source code and not the library is indeed an advantage of a pre-compiled library. I consider it vanishingly unimportant against being able to work across /all platforms/.

<comment><USER15> The issue isn't about "conditional compilation": the issue is about symbol visibility. In fact, I don't think _any_ of the issues discussed in this article--excepting the bug at the end with MH_OBJECT--would be solved by giving someone source code: adding a directory of C files to your project is _semantically identical_ to adding a .a file using -all_load. This is clear and somewhat obvious, as the only thing I did to create a .a file was to compile the .c files to .o files for you, which will be the very first thing your compiler does with the .c file anyway: all I'm doing is saving you CPU time and some hassle, I'm not changing what happens when the code hits the linker, and that's where the problem lies. Let's look at one random specific example from the article (which again, is full of things that happen at link time, and so would be exactly identical whether you started with source code or archive files): PLCrashReporter includes a custom build of sqlite3 that has different options than Apple's; you want the user's code to continue using the version of sqlite3 that comes on iOS, but you want PLCrashReporter and PLCrashReporter only to use the custom build. If I give you a giant wad of course code files, which would then of course include the custom build of sqlite3 with the extra options PLCrashReporter needs turned on, all of that is going to be compiled down to .o files (again, exactly what would be in a .a file that I'd give you were I to have compiled it ahead of time), and the sqlite3 symbols from the included modified copy would then take precedence over the ones that come with Apple's SDK for all files in the project: you solved nothing.

</comment></comment></comment></comment></comment></comment><comment><USER16> I miss one feature - ffi, and this is not only limited to iOS - with a .dylib/.so/.dll and some kind of readable interface ("C") you can export functions for other languages. For exampe luajit, python (ctypes, cffi), common lisp (cffi), etc.

Another thing is "replacement" \- switch one version with another. This way I've found that sqlite 3.8.2 was misbehaving for us lately, which points to be some kind of MSVC related error (compiled 64-bit for windows using VS2010).

Quickly switching to the previous one, without recompiling did another thing - I had to think less about other possible changes, since only one component changed - not the whole executable.

Then there are times where I wished everything was statically compiled :) - <USER2> all fronts (Linux, OSX, Windows) there are too many gotchas of pointing the right way to your dlls.

I seem to favor Windows (get the DLLs first from the apps' folder... well not strictly, but in general) - but then that's because Windows did not have good place to put the dlls to begin with (unlike unix).

</comment><comment><USER17> I've always thought that since an (iOS) app needs to be fully self contained, having only static linking makes perfect sense. You also gain dead code stripping, and linking only the archs that the main binary supports as well.

Most libraries I've dealt with have mostly amounted to interfaces to respective web apis. In those, having source code distribution makes perfect sense, even preferable when the libraries are fairly simple and that gives the freedom to compile them as one wishes. Doing it with sub-xcode projects I've found to be fairly simple, even if mucking around with header search paths is still a pain.

Granted, I haven't really experienced library author side of things, but most of these issues are about drag'n'drop ease of use, which I don't think _requires_ dynamic libs but is more of a tooling side problem, and frankly has always been a problem in the c/c++ land at least.

The lack of two-level namespace is a real problem that I've actually encountered. Then it was a simple rename of a class name away, but I can easily fathom a situation where it isn't that easy (like the example of embedded sqlite3).

Also I hadn't realised that the simulator and device builds are lipo'ed manually, that indeed should have a better way. But would dynamic libs really help in that situation, you would still ship x86+arm glued together without notion of the platform, even worse, you might be shipping the x86 as extra weight on appstore builds.

<comment><USER18> Just because dynamic linking is used doesn't mean the library doesn't get shipped with the app package.

</comment></comment><comment><USER19> Why use dynamic libraries if you don't need to save storage space or RAM?

We have moved beyond the era of scarcity and even on desktop platforms, lots of people are including static libraries so that they are not dependent on the upstream developers' idea of what is needed. So much of this code is open source that it makes sense to build your own static library, and maybe leave out cruft that you don't need.

Sure it would be nice to have a choice, but static libraries are not evil.

</comment><comment><USER20> I can't read this article without resizing my browser window. Fluid text width is awful. And yes wikipedia has the same problem.

<comment><USER21> I think fluid text works well for phones and stuff where if you rotate the screen it flows nicely. The problem is huge displays-- I'm at like 2560x width.

Edit: A solution I think works okay is simply adding

        max-width: 500px;

to the css properties for p.

<comment><USER22> You're not maximizing your browser, are you?

The monitor my browser is on has 2560 width, but the client area of the browser window itself isn't much more than 1200 pixels wide. I keep terminals and the tree-style tabs to the left of the browser.

</comment></comment></comment><comment><USER23> Besides maintainability, there is the issue of not being able to use certain open source libraries (without some legal complexity) when you statically link libraries. IMHO, that is a much greater problem.

<comment><USER24> The problems you refer to will still exist with the LGPL (inability to replace dynamic libraries).

<comment><USER23> Not sure what you mean. If I had the ability to use shared libraries, I would be able to use LGPL code.

<comment><USER24> iOS still requires signed code. My understanding is that the LGPLv3, like the GPLv3, will prohibit this because the user can't deploy it.

<comment><USER23> In practice, LGPLv3 is much different than previous versions of the LGPL. The truth is that many excellent projects have chosen to either stick to not go the v3 route intentionally (because of the extra restrictions), and if they do, several of them choose to dual license under both versions. I can think of numerous projects that are under LGPL v2 (like ffmpeg, GEOS, mapnik, custom webkit) which would cause an amazing suite of iOS applications to surface, but with the current situation, they cannot. Signing is not a requirement of any of those libraries mentioned.

<comment><USER24> OK, how does Joe Enduser replace an LGPLv2 library on iOS, as is his legal right under the license?

<comment><USER23> Would you kindly point out which section of the LGPLv2 gives you explicitly that right?

[http://www.gnu.org/licenses/lgpl-2.1.html](http://www.gnu.org/licenses/lgpl-2.1.html)

I would emphasize the terms "work that uses the library" vs "derivative work of the library" which have historically been used to differentiate between static vs dynamic linking.

In addition, how would I go about doing this in Android? And how does Apple distribute LGPL libraries (like Webkit) without "[allowing] Joe Enduser [to] replace an LGPLv2 library on iOS"?

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> Xcode (and the entire tool-chain) has support for static frameworks that would negate any distribution problems the OP wants. Apple snips that functionality out of the iOS SDK for some unknown reason, but I suspect that would be a much better request to ask for.

I do agree that the iPhoneSimulator and iPhoneOS SDKs should be better integrated at compile time. Yet, they were architected as completely different environments, so I suspect that won't be an easy request to fulfill.

Anyway, what benefit would having a dynamically loaded library give you when each app runs sandboxed? I can just imagine a scenario where one framework uses a version of ASINetworking and another uses AFNetworking and they both attempt to use some version of JSONKit to parse out the result. Objective-C and its amazing namespace collision management will just carefully (and by carefully, I mean, not at all) pick one implementation over the other and leave a happy warning for all to see.

<comment><USER26> Did you even read the article? All of this is covered.

The question of "what benefit would having a dynamically loaded library give you when each app runs sandboxed" seems to be answered in great detail under "Debugging Info and Consistency" and "Missing Shared Library Features"

</comment></comment><comment><USER27> A workaround is to write iOS applications in Monotouch, which does support DLLs.

<comment><USER28> The problem isn't that Darwin doesn't support dynamic linking (see: 99% of jailbreak tweaks). The problem is that you can't share the same library across different applications because of the sandbox / closed platform.

<comment><USER29> That's actually not the problem at all, as described by the article. The problem you describe is a completely separate issue.

<comment><USER28> I suck at reading.

</comment></comment></comment></comment><comment><USER30> Apple doesn't want small developers on iOS. I thought this was clear 5 years ago. Every thing they've done in both the market, the UI, and the OS makes it difficult for small developers to get a leg up and for new technologies to be adopted. To Apple, integrating 3rd party libraries is not a concern of there's, that's for the professionals to try to get to work, then use as a competitive barrier, thus increasing the quality of the top apps in the market, the only apps that matter.

<comment><USER31> I think you're seeing intentional malice where really there is a lot of indifference at some times, and lack of understanding what it's like to start in this ecosystem.

Cocopods is PAINFUL to get compliant with ruby sometimes, but other then that, works for a lot of the problems you'll see. It is a leap though.

<comment><USER30> Indifference for small developers? Whatever you want to call it, I don't care. An indifference at times about how they control the app ecosystem? No.. Just no.

<comment><USER28> It isn't about not wanting small developers on iOS. That's ridiculous.</comment></comment></comment></comment>


Skydiver Felix Baumgartner seeks to break sound barrier - <AUTHOR> http://news.bbc.co.uk/2/hi/8475288.stm

<comment><USER2> He's being sponsored by Red Bull (<http://www.redbullstratos.com/>). Their marketing video is actually really cool, it includes plenty of footage of Kittinger.

<http://www.youtube.com/watch?v=PyGmTV0q2kY> (make sure you switch to HD)

<comment><USER3> I used to think that Red Bull just put their logo on cool stunts, but it turns out that they have a really competent team of engineers and fabricators to pull this off. In fact, Joeseph Kittinger, who holds the record currently, said they were the first crew to approach him that sounded like they could do this without killing someone (since 1960!), so he's actually working with them on this.

</comment></comment><comment><USER4> "It is likely that in his long freefall of more than five minutes, he will exceed the speed of sound - the first person to do so without the aid of a machine."

If he can reach 120k feet, I bet there is a machine involved in the process. Why not just say he's the first person to do it through freefall?

<comment><USER3> They mean his acceleration will be without the aid of a machine.

<comment><USER4> Again, it's not true. He's just converting the potential energy stored with the aid of a machine into kinetic energy.

<comment><USER5> If you are going to be this pedantic, then even if he plans on growing wings and flying up there, you will still bitch because the meal he plans to eat the night before will be harvested by combine.

</comment></comment></comment></comment><comment><USER6> More details on the suit in this article / video: [http://www.pureskydive.com/2010/03/red-bull-video-reveals- ne...](http://www.pureskydive.com/2010/03/red-bull-video-reveals-next-gen- space-suit-and-pressure-helmet-designed-specifically-for-red-bull-stratos- mission/)

</comment><comment><USER7> From a quick Google search, the terminal velocity of a human being is roughly 120 mph. The speed of sound (at sea level) is 761 mph.

How is this feat possible?

<comment><USER8> My thoughts exactly...I'm sure he'll be carrying extra weight but I still don't see how this is possible given a certain terminal velocity, like you said.

*Edit...wikipedia says current world record is 614 mph set by Joseph Kittinger. He used the head down method in high altitude, less dense air. That's still not supersonic though.

<comment><USER9> As mentioned in the article, Kittinger "only" jumped from 102,800 feet. Baumgartner will jump from 120,000. Also, Kittinger was in a "rocking chair" position, not head-down. (<http://en.wikipedia.org/wiki/Joseph_Kittinger>)</comment></comment></comment>


Privatizing the Bonneville Power Administration - <AUTHOR> https://www.nytimes.com/interactive/2017/07/28/us/columbia-river-privatization.html <comment><USER2> What conceivable advantage does privatization of Bonneville Power(and the other facilities) provide? It is difficult to see how privatization will give us better service at lower cost. While discussing this proposal with a friend today, he opined that "we need more nationalization of infrastructure, not privatization". I agree.</comment>


Join Our Board: Companies Hotly Pursue New Wave of Women in Tech - <AUTHOR> http://www.nytimes.com/2016/12/30/technology/join-our-board-companies-hotly-pursue-new-wave-of-women-in-tech.html <comment><USER2> I feel like this is actually a disservice to intelligent women in tech.

Instead of basing it on talent, many of these companies just want a token woman to virtue signal to the rest of the valley that they are diverse.

Talent is all that really matters, regardless of your race or gender.

Update: Heh. It figures that fighting for equality would get a down vote.</comment>


Lessons from a product's Alpha - <AUTHOR> http://gobigorgoho.me/post/11569456134/alpha-lessons

<comment><USER2> It was an interesting read, but can you please post how you got your alpha users?</comment>


Beyond Instant results: Instant Previews - <AUTHOR> http://googleblog.blogspot.com/2010/11/beyond-instant-results-instant-previews.html <comment><USER2> This might be incredibly useful in weeding out ill-designed websites from the search results. I can see myself using it to quickly determine the legitimacy of the site before clicking through. Plus, it's not distracting like those snap previews on Wordpress.

</comment><comment><USER3> I'm happy that the particular implementation they A/B tested on me for days and weeks didn't make it. This is much more elegant.</comment>


We Should Regulate Ridesharing Like Buses and Restaurants - <AUTHOR> https://interconnected.blog/regulate-ridesharing-like-buses-and-restaurants/ <comment><USER3> Bad article, the only specific regulation they even mention supporting is "cleanliness" as if most uber/lyfts aren't clean already, more than buses at least, which they are comparing them to. And how are uber/lyft regulations even related to restaurants. Stop upvoting this blogspam

</comment><comment><USER4> > Where the current taxi regulations fail, and thus should not be replicated, > is that it artificially lowers supply via the so-called medallion system

Many cities regulate restaurants like this too, by rationing liquor licenses.

</comment><comment><USER5> Those are called taxis.

<comment><USER6> The regulation already exists, ridesharing companies just decided to break the law and challenge the definition of "employee" and "taxi" because ridesharing companies have an app. That was weird from the begging.

All the gig economy is just based in the idea that companies that do business thru an app doesn't need to follow established laws.

<comment><USER7> They were bad laws that deserved and earned open defiance. All people care about is getting from Point A to Point B in a quick, reliable and safe manner. People don't care if the driver has an expensive medallion that makes them a member of a government-sanctioned mafia, if the driver of the car is willing to fulfill the passenger's request in exchange for money.

When you make the request for a private car to take you somewhere, you're putting your life in the driver's hands for the duration of the ride. The medallion and privileges don't make a difference, but they can make the difference in the availability of cars in your vicinity.

<comment><USER6> > All people care about is getting from Point A to Point B in a quick, > reliable and safe manner.

Drivers also care about having a safe work environment, reasonable working hours and a fair pay. Capitalism is not just about consumers, but about consumers and producers.

Apps push employees to accept ever lowering salaries to achieve that "cheap trips" and to renounce to their rights as employees to increase "availability". Labour laws were created to address this situations and should not be ignored.

How would you solve these problems?

> The medallion and privileges don't make a difference, but they can make the > difference in the availability of cars in your vicinity.

Many cities require tests, background checks, etc. to get a taxi driver license. Apps seem to have lowered that standards. So, the opposite - <USER2> safe travel - could be the actual reality. I think that your statement needs some extra proof.</comment></comment></comment></comment>


Way for a Mouse to Escape a Cat, According to Math - <AUTHOR> https://www.wired.com/story/the-best-way-for-a-mouse-to-escape-a-cat-according-to-math/ <comment><USER2> I was wondering if this was going to be an article about the Numberphile video, and it is.

Video was great, article seems to only add a little of physics to the math in the video, but does provide some VPython code of the model and prompts to continue playing with it.

</comment><comment><USER3> Also check out Rado's classic "Lion and Man" [http://mathworld.wolfram.com/LionandManProblem.html](http://mathworld.wolfram.com/LionandManProblem.html)

</comment><comment><USER4> Another nut to crack: is the proposed tactic to escape really optimal? I think there's a variation of the tactic which will take a shorter time to escape.

<comment><USER5> The mouse could just back away, oscillating back and forth across the radial line from the cat (forcing the cat to keep changing directions) until it gets to "dash" distance.

<comment><USER6> _(forcing the cat to keep changing directions)_

Ahhh ... there's a difference between this puzzle and the real world. In the real world a cat can't change directions instantaneously.

In the real world (at least as seen on nature films) the escaping prey is always forcing the predator into changing directions.

Does anyone know if a mouse can really run faster than a cat? I've got to believe that those tiny mouse legs are no match for the strides a cat can take. Isn't the mouse's only hope of survival to quickly get to somewhere (like a mouse hole) that the cat can't follow?</comment></comment></comment>


Tesla is 'going out of business,' says former GM exec Bob Lutz - <AUTHOR> https://www.cnbc.com/2017/11/17/tesla-is-going-out-of-business-says-former-gm-exec-bob-lutz.html <comment><USER2> At least some points he makes are true.

 __Battery tech __

Tesla don 't own any important battery technology or patents.

Main battery manufacturers are Panasonic, LG Chem and Samsung SDI. Panasonic is the leader and Tesla's manufacturing partner, but LG Chem has made lots of progress and they are supplying to GM. Panasonic is rapidly expanding their own battery production is going to sell to other manufacturers also.

 __fixed cost and mass production __

Tesla has no experience with large scale mass production (producing less than 100,000 cars annually is not big league). They have struggled with quality and delivery even with modest volumes for years, it will be harder when volumes grow. They don 't survive massive recalls if the quality is not improving.

They have to get Model 3 into mass production within a year or they will run out of money and investor's and customers patience. Nobody want's to wait years for a car. Roadster and Semi are just distractions. Tesla's future is on Model 3.

</comment><comment><USER3> Wishful thinking. The main issue with Model 3 is just that they _can 't make batteries fast enough_. This is a solvable issue, and it would normally be considered a "good problem to have" (not being able to make products fast enough to meet demand).

The only reason this is seen so negatively right now is mainly because Musk has set such high standards for Tesla by trying to increase production by 5x within 12-18 months and hoping everything will go perfectly smooth.

<comment><USER4> Good problems to have are still problems and can still cause you to go out of business. Car manufacturing is _all_ about logistics, quality and capital management. Fail at any one of those three and your car company will fail. There is a pretty good reason why there has been a huge consolidation happening in the car industry over the last 30 years, getting those things right isn't easy at all.

</comment></comment><comment><USER5> Hmmm... Didn't Pontiac go out of business recently? I thought they were owned by GM. Am I wrong?

<comment><USER6> iirc they wound down a few internal brands several years ago following the financial crisis.

</comment></comment><comment><USER7> Well, he would say that, wouldn't he.

<comment><USER8> Same things he's been saying for years, yes.</comment></comment>


Babel – Nimrod's package manager - <AUTHOR> http://picheta.me/articles/2014/06/babel--nimrods-package-manager.html

<comment><USER9> This post got me thinking: why must every language reinvent the package manager, poorly? It seems profoundly wasteful. How much of the logic and infrastructure involved is actually specific to the language being used? I could be missing something, but it seems very little.

It would be really cool if languages just started using a common package manager instead. It could also be more fully-featured, able to do things like track dependencies that aren't written in the language like C libraries. We would also avoid having a ton of custom file formats and dependency solvers.

From what I've seen, Nix[1] is the perfect candidate for this. It's self- contained, can install packages locally and does a good job of simultaneously managing multiple versions of the same package: all very useful for development. It's also portable, working on Linux, OS X, FreeBSD and even Windows with CygWin.

In a sense, I suppose this would be like reinventing the system package manager. But I don't think that's a problem. Unfortunately, most Linux package managers seem configured in a way that is not convenient for development (ie global packages only). It's also a bit of a pain for a language community to maintain a package for everyone's favorite package manager; if they just settled on one (like Nix), they could have a single Nix repository similar to how they have a custom package list now.

[1]: [https://nixos.org/nix/](https://nixos.org/nix/)

<comment><USER10> We have this discussion literally every time. Different languages have different conventions and build systems, and packaging a library for every operating system package manager is just not feasible.

A single package, for a single package manager that runs everywhere and is tightly integrated with the language, is the only reasonable solution.

<comment><USER9> My point is _not_ to use the system package manager, but to replace the various language-specific ones with, say, Nix. It should be flexible enough to work with the different languages' build systems and conventions, while reusing all the existing systems for managing dependencies, conflicts and so on. Very little of all that logic is language specific, and it's traditionally done poorly by language-specific package managers.

Basically, I do agree on using a single package manager. I just don't think that the need to be integrated with the language is severe enough to warrant writing a new one for each language! It's much less effort for everyone involved to set integration up for an existing package manager instead.

In other words: replace Pip/Cabal/Babel/whatever with Nix, maybe with some plugins for the needs of your specific language. You would even still ship it with your language (optionally), so the only change would be maintaining a plugin, if necessary, instead of a whole manager.

<comment><USER11> > to replace the various language-specific ones with, say, Nix.

So now, to use packages for programming language X, I also have to install Nix, be running a Unix-based OS (sorry Windows folks!), and have whatever other dependencies and toolchain Nix requires installed.

This is the core problem. A programming language _needs_ a package manager today. Code reuse is too important for a language to succeed with out a nice user experience to get and share code and deal with transitive dependencies.

That puts a package manager on the critical path for a language. Given that, it's important that the package manager itself have minimal dependencies. It would suck, for example, if a package manager for Python was written in Ruby and required Ruby to be installed!

The only thing most languages' package managers are willing to depend on is the language itself and its core libraries. That means for every programming language, you get a new package manager.

It's not ideal, but it seems to be the best solution we've found given those constraints.

<comment><USER12> You're focusing too much on "THE Nix", and not the idea behind it. Nix is an idea which detracts from traditional package management by concluding that ranged dependency versions actually create more problems than they solve, so we should just do away with them, give every package an immutable identity, and specify the identities as dependencies - thereby making reproduction significantly more reliable and free of unwanted side effects like environment variables or user-built packages (outside of the distro's own).

Nothing in this idea says you need to run a Unix based OS, only the two current implementations of the idea (Nix and Guix) do so currently. The concept can be applied to a language specific package manager (LSPM) too, and IMO would be much better than the way many of the existing LSPMs behave - which is to duplicate dependencies into project directories - <USER2> completely eliminating the reason to have shared object dependencies over static linked dependencies in the first place - because you need to manually update the dependencies of every project when a dependency gets a bug-fix.

The real problem with LSPMs is that they're functionally incomplete PMs - <USER3> require you to (manually) use a system wide package manager to install the native dependencies which you inevitably need, because it's inefficient to rewrite everything in your language rather than provide bindings to a native library. The LSPMs basically spit out their dummy when you try to install something and a native dependency is not met - often giving a cryptic error message which doesn't explain the cause of a problem, or how to resolve it.

I've suggested several times what needs to be done to resolve this, and it doesn't involve throwing away the LSPMs, but augmenting them. The solution is to provide a system wide daemon which facilitates native installs required for by the language, whereby the LSPM can query and request the installation of packages over a well defined protocol, and the daemon forwards those requests to a system-level PM. This could also improve the state of GUIs for package management - allowing a unified interface to installing them rather than a dozen ad-hoc CLI interfaces.

Of course, I don't have all of the details on how this would be implemented - for starters, it would add a new dependency to every package manager using it (the IPC mechanism and protocol used), although almost any language can use a socket based IPC. Each LSPM would also need to introduce some new notation for "external" packages, which it doesn't manage internally, but instead sends off a query to the daemon, waits for a response which will either fail (the native package is not installed or won't be installed), which will also improve the state of error messages, or it may succeed, and the LSPM can continue building the rest of the project.

If such system is going to be built, the Nix model of immutable packages seems really the only sane approach to the problem. The identity-based approach to dependencies means that when building a package, you're always going to be building against dependencies the developers intended - because they're the same ones he/she tested against. Each time a developer builds successfully against a different dependency version he should add its identity to the package definition, confirming that it has been tested. If you decide you want to build against a different version, you can simply adjust the identities, but you _should not_ expect it to work without some manual fixing - <USER4> people tend to break things. If you happen to have luck, and your modified dependency works - you should publish the updated package definition so other people can learn from your testing, and blame you if you published a broken package (ie, failure to build implies a _bug_ , as it should)

<comment><USER11> > Nix is an idea which detracts from traditional package management by > concluding that ranged dependency versions actually create more problems > than they solve

That may be the right choice for the kinds of packages that Nix targets but not for other language's semantics. For example, I wrote the package manager for Dart and it specifically intentionally does use versions because forked shared dependencies don't play nice with the language's semantics.

> The solution is to provide a system wide daemon which facilitates native > installs required for by the language, whereby the LSPM can query and > request the installation of packages over a well defined protocol, and the > daemon forwards those requests to a system-level PM.

That's a large ball of complexity and dependencies. It isn't clear that that's actually a more effective solution than just rolling a package manager for each language.

> The identity-based approach to dependencies means that when building a > package, you're always going to be building against dependencies the > developers intended - because they're the same ones he/she tested against.

That doesn't play very well with shared dependencies in many cases.

Ultimately, every package manager has a bunch of policies embedded in it. Things that it just decides are The Way Stuff Should Work. Those policies are _heavily_ influenced by what how the programming language is used.

Trying to find the One True Package Semantics seems like a lost cause to me.

<comment><USER12> To me, the motivation for specifying exact dependencies as much a social concern as a technical one - it puts responsibility, or blame, where it belongs. If we take an example scenario for "bad packaging", something like:

* developer X releases package A, version 1.0

* developer Y releases package B, version 1.0, depending on package A > 1.0

* developer X releases package A version 1.1 with breaking changes

* user Z with package A 1.1 installed attempts to build package B and fails

Who is to blame in this case? At first thought you'd blame developer X for releasing breaking changes without bumping up the major version, however, there was nothing in his "contract" that says he cannot do this - moreover, even if one specified up front that they will "not release breaking changes without bumping the major version", how can you even enforce that at the software level?

The way we actually model the "blame" in the industry is to blame Z - <USER5> idiot user who can't build software, who failed to follow incorrect documentation and feels like an idiot because he doesn't know what was wrong - then he wastes significant time searching for solutions, debugging build scripts, re-versioning the dependencies by introducing A10 and A11 in place of A, because he needs both, and his PM can't have two of the same name, and the names can't contain periods (Arbitrary restriction of some PMs).

The actual blame here lies in Y - he is the one who documented that his software will work with any version of A greater than 1.0, but I find this declaration to be idiotic - he cannot possibly uphold this "contract", because he is not in control of A. The best guarantee he can give is "I've tested this with 1.0, but it may work with any later version, however, do so at your own risk."

Ok, so there's no really a "contract" to be held - particularly for public domain works and "permissive" licensed works where the developer is just giving stuff away for free, but in the case of copyleft works - such as the GPL, it specifically requires that you distribute all of the scripts required to build the software. While perhaps not a violation of the license in the legal sense - releasing build scripts which simply don't work is a violation of the spirit of the GPL.

We could argue that "may work with any later version" is precisely what we mean with "> 1.0", but it confuses me as to why anyone would think releasing an _untested_ build script would ever work - you would never release software into production without first testing it. Releasing a package with a dependency that _doesn 't yet exist_ cannot possibly be tested - it's not fit for production. If a developer has tested a piece of software with all dependency versions between 1.0 and 2.0, and decides they all work successfully, then I see this as the only real case where ranged versions are acceptable - except in this case you have a set of exact dependencies tested against which could be used instead of the range, so why not specify dependencies as a set?

These complaints are not specific to any language semantics - it's just a case of untested code being unreliable, and tested code, where all the "tests" are encoded into the definition of the software (thereby removing the "hidden knowledge" that goes into building it), is close to perfectly reliable - <USER6> failure to reproduce was probably beyond the control of a package publisher anyway (although when we have ReproducibleBuilds, this should never happen.)

> That's a large ball of complexity and dependencies. It isn't clear that > that's actually a more effective solution than just rolling a package > manager for each language.

As I stated, LSPMs are an incomplete solution - they don't provide the complete "dependency resolution" which we expect from a PM. If we take for example, I release a Cabal package for Cairo bindings in Haskell, and I run "cabal install Cairo", what actually happens?

If I'm lucky, a compatible (by magic) version of native cairo is installed, and it builds fine. If Cairo is not installed, it will fail with some cryptic message saying ExitFailure 1, something or other about gtkhs-buildtools. If I'm an expert already I can wave my magic wand and fix the problem, otherwise I'm googling a solution. Turns out the problem is simple in this case, I don't have the package "cairo-dev" installed on my OS, and I need to install it manually through another PM, say, apt.

But then this defeats the purpose - the LSPM, Cabal, has failed at dependency resolution - it can't resolve Cairo because it's beyond its scope - <USER7> Cairo on the system is the responsibility of the system PM (which is really an LSPM where the specific language is C, etc).

The point here is to eliminate the need for _manual_ installation of cairo - by providing the means for Cabal and apt to talk - Cabal can simply ask "do you have cairo", to which it can reply "yes", or "no, would you like me to install it", or "no, go away".

This may not be such a concern in dart, since you don't really have bindings to native libraries.

I don't see how this is a large ball of complexity, but I think it could reduce it. As things stand, some LSPMs attempt to somehow resolve native dependencies through ad-hoc means, by looking for them in specific locations in the filesystem, or by dumping the native dependencies into the project folder itself (good luck picking up bug-fixes and making portable projects this way). Other LSPMs simply shut down and cry when you need a native dependency, "it's not my problem".

Rather than trying bridge individual PMs on an ad-hoc basis, it would make more sense to come up with the right abstraction/verbs for them to talk - <USER8> each one have an adapter to a global "package manager manager daemon",. This would be like "QUERY cairo", "INSTALLED", "NOT INSTALLED", etc. (As I said, I don't have all of the details, as that would require a large social effort.)

The reason the Nix model would be required for this kind of collaboration of PMs should be obvious - if I query "cairo", is it going to ask apt to install cairo, or ask Cabal to install cairo? It can't possibly guess without the user disambiguating - adding version numbers here can't help either. The only solution here is to make sure there can be no ambiguity between them - different names won't work because the different package managers have distinct repositories managed by separate communities. The solution is an identity, hash-based, or based on a cryptographic signature - it's required for any kind of security if we were to have PMs talk to each other - however, using hash based identities, we can treat the knowledge of the hash as a capability, and if two different package managers (such as apt and yum) provided the same package identity, it wouldn't matter which one performed the installation, because it's the same capability.

I'm not trying to find the "One True Package Semantics", but rather, create an environment where each PM can handle its own niche, but bridge the gap that's missing where they simply stop working - by having some kind of shared language between them.

<comment><USER13> This isn't solvable with version numbers, either use Haskell or layer a type system over package interfaces along with the runtimes ability to upgrade and downgrade dependent packages on an link error.

It would be helpful of every successful package DAG for that occurrence we communicated somewhere for others to use.

<comment><USER12> Right. Version numbers can't work, which is why Nix avoids them and organizes packages by the hash of their full dependencies instead - thereby making every package unique and immutable - reliable upgrades and downgrades can be performed because there's no "unfortunate" side effects that can be introduced - such as the example I gave above where you need to introduce new packages "A10" and A11" instead of "A", because you need both, and you already mutated "A" to mean something other than it originally meant (hence, rollback is a breaking change with most PMs).

If we're looking for a way to "communicate" working DAGs for other people to use, I think the best place to look is existing in DVCSs - submodules/subrepositories basically provide what we need - because every commit to a repository using submodules refers to exact commits in exact branches of the submodules. If we managed to use git ubiquitously in such way that all of our dependencies were submodules, and in turn, those dependencies used submodules for their own dependencies, we have the entire DAG that would otherwise need to be written as Nixpkgs.

This also solves the version explosion issue, where there could exist dozens or hundreds of derivations of the same packages with slightly different configurations, bug-fixes or other changes - because a "derivation" just becomes a specific commit in a specific branch of a repository at a known URL, and to utilize the different version from a dependent software, you just update the submodule and point to the desired head.

<comment><USER13> Yep, we should run/deploy out of the DVCS.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I'm just happy other people than me like hg and Nimrod which is the sole reason of this comment.

<comment><AUTHOR> I'm happy you took the time to make this comment :)

</comment></comment><comment><USER15> With all the options, it's too bad the authors had to choose the name of a popular emacs mode.

Just makes it harder to find either.

<comment><USER16> To be fair, "babel" isn't really a unique emacs term. It had a meanings outside of emacs, and a movie... and multiple albums... and a book... and the open babel chemical project... and the python internationalization library...

Maybe it was confusing already?

<comment><AUTHOR> It really isn't an issue as long as there is only one package manager named Babel. If you can't find Babel by Googling "babel" then search for "babel package manager" instead, you will likely be doing that anyway.</comment></comment></comment>


Website to help you choose a license for your open source projects - <AUTHOR> http://choosealicense.com/ <comment><USER2> how about one that opens the source code, permits non-commercial use but prohibits commercial use without express permission.

or is that not open source?

You see, i want others to read and learn, but i don't want rich bastard companies to make money from my free work.</comment>


How I Made $350 In Two Days With Three Pages and Some Payment Code - <AUTHOR> http://dshipper.posterous.com/how-i-made-350-in-two-days-with-three-pages-a <comment><USER2> I've noticed a recent trend of self-promotion that I don't understand. I'm not writing to criticize, I just want to know why you say some of the things you do.

For instance, you call yourself a "rising sophomore". What does this mean? How is it different from any other sophomore? Can you explain why you chose that word and what the impression you intended to convey is?

Also, I love that you made a product like this quickly. In reading your story I noticed something you did right that I totally would have done wrong, and I appreciate being reminded of it. I applaud your gumption.

But then I clicked thru to the website and saw: "Our team of web usability experts has put together a comprehensive survey". So, do you have a team of web usability experts behind domain polish? I'm assuming it is your solo project. Why not say "Our carefully crafted, comprehensive survey" instead? Do you think that would really kill your sales that much? Do you have any qualms about saying you have a "team" of "experts"?

Notice, I'm not passing judgement... I'm asking questions because I want to understand your thinking, and also I find this alien culture of the "kids today" baffling and mystifying. :-)

<comment><USER3> "Rising" sophomore (or junior or senior) is a common U.S. expression. It just means he'll be a sophomore when school resumes this fall. There's no self- promotion, it is just used by students during the summer break.

<comment><USER4> It's common? Where? I'm from the US and I was put off by the statement as well.

<comment><USER3> Google rising sophomore, "rising senior" etc. Millions of results, common usage, neutral meaning.

<comment><USER5> I googled "rising senior" and got under a million results. Even more telling, the very first result was title "What is a rising senior?"

It's also worth pointing out that I'm US born and bred, spent 7 years at universities and was unfamiliar with the term. It sounded pretentious to me.

</comment></comment></comment></comment></comment><comment><USER6> That was a great read, very interesting.

I have to take issue with one point. It says:

        I've made $350 to date. All from three pages
        and some payment code.

Sounds brilliant, and it's the title here. Earlier, however, it says:

        I was scrambling to fill orders. I had a huge TextEdit
        file open with customer names, site URLs, and email
        addresses. I sent every email, and set up every survey
        by hand.

So, the three pages and the payment code were the structure, and in truth, you were doing the work.

        By 6 am I had completed processing every order and went
        to bed. I got up an hour later for work at 7 am.

        ...

        So now I'm sitting here writing this blog post with a
        bunch of orders to fill, features to build, and
        customers to help.

So this is a continuing requirement, that you service the requests from your customers via your web site.

It's a service, and it's making you money, and it's successful. For those things alone you deserve to feel happy and a little smug. But I felt misled by the title.

But having said that - all power to your elbow, and well done.

<comment><USER7> Give the guy a break, come on! He's so happy to have made this money, he doesn't count the work he has to do in order to provide that service.

It's a good story :)

<comment><USER8> If you are bragging on your efficiency, then it is relevant when more time and effort is required than was represented. Good for him and all, but reality is reality

<comment><AUTHOR> Thanks for the feedback! Although my hourly rate might be coming to below minimum wage right now - the idea is that once I've put the work in at the beginning to develop customer relationships, develop a brand, and add more features like automation, the amount of effort I will have output after that will be very minimal. It's like working for minimum wage for a few weeks with the expectation of making way more for the next year after that.

<comment><USER7> It beats flipping burgers anytime :)

</comment></comment></comment></comment></comment><comment><USER9> Feedback Army (which was actually built by HN user raffi when he was inspired by a comment on HN) has been doing this for a while.

The comment that inspired it:

<http://news.ycombinator.com/item?id=362459>

Various other HN discussions about it:

[http://www.google.co.uk/search?q=feedback%2Barmy%2Bsite%3Ane...](http://www.google.co.uk/search?q=feedback%2Barmy%2Bsite%3Anews.ycombinator.com)

</comment><comment><USER10> CrowdPicker has been doing this for awhile: <http://www.crowdpicker.com/>

<comment><USER11> other sites doing very similar things

pickfu.com

usertesting.com

feedbackarmy.com

<comment><USER12> I've used pickfu a few times - usually get results in 24 hours. I'm bad with colors so it's nice to be able to ask 50 people for $5 which look they like better of a site. It's great because I want real feedback - great when people really tell you if they hate something instead of getting the real world "Oh, nice" responses.

Also used it to ask about domain names.

Edit: I like the site - good layout & like the KISS approach. Good luck.

</comment></comment></comment><comment><USER13> Great post, Dan. It reminds me of the article the Buffer App guy wrote on his experience getting everything up and running. very smart and disciplined to root out the demand before committing dev. keep up the good work

<comment><AUTHOR> Thanks a lot! It took me a while to learn that lesson. My instinct was always to code first and ask questions later. I would recommend 4 Steps to The Epiphany - it was a big eye-opener for me about the development process.

</comment></comment><comment><USER14> I'm curious how you got into the stripe beta? Had you used them before with other projects?

<comment><AUTHOR> I just sent them an email...they're great guys. I just got some invites to it so send me an email (address is in my profile) and I'll give you one.

<comment><AUTHOR> NOTE: Sorry guys - all out of invites :(

</comment></comment></comment><comment><USER15> Nice job, Dan. Always rooting for fellow Penn guys :)

Do you expect to automate this any time soon?

<comment><AUTHOR> This weekend haha I'm not that much of a masochist to do it by hand forever :)

<comment><USER16> <https://github.com/mdp/rturk>

happy birthday!

<comment><AUTHOR> thanks Mark I saw that it's definitely going to make my life a lot easier

</comment></comment></comment></comment><comment><USER17> I just logged in to check out this site, and Dan was there, chatting live with folks. So cool. Go Dan Go! You got a customer in me... and I'll be back tomorrow with an order.

<comment><USER18> This was the same thing that caught my eye as well. I said congrats on the launch, and Dan was right there with a quick friendly comment. This alone convinced me to try it as I was on the fence.

The signup/interview through checkout process took about 30 seconds. Curiously awaiting the results. Thanks again Dan.

</comment></comment><comment><USER19> That was a great read!

I hate to nitpick, but this part caught my eye: _I needed to fix about the site – SSL (even though all of the payments are secured through Stripe)_. If the checkout page isn't loaded over SSL, my credit card number isn't secure since the page is still vulnerable to a MITM attack completely removing the Stripe code.

<comment><AUTHOR> Thanks! Yes there is a chance for a MITM attack but as far as I understand from talking to Stripe that risk is very, very low. I'm going to be adding SSL this week anyway however. Thanks for your comment!

<comment><USER20> It doesn't matter if the risk is low, the impact is high. Your customers will see you don't want to shell out 12 bucks for an SSL certificate to protect them.

<comment><USER21> Which provider do you recommend for a such a cheap cert that is accepted by a large percentage of browsers?

<comment><USER20> <http://www.gandi.net/ssl/grid>

</comment></comment></comment></comment></comment><comment><USER22> Well, if I understood correctly he didn't really make $350 in the end. He had his upfront costs, his processing costs and his turk costs. I'd be curious how much return he's getting after all that and figuring in something for his time. If he can automate some of his tasks to eliminate some overhead then he may have something. But if in the end he's making minimum wage after factoring in costs then, well, it is what it is.

</comment><comment><USER23> You have too much drop shadow on your buttons, it makes the text blurry. (Yes, I find reviewing your website ironic when your service is website reviews)

<comment><AUTHOR> It's very meta. I'll look into that thanks :)

</comment></comment><comment><USER24> How I Advertised All My Websites To YCombinator

<comment><AUTHOR> I'm sorry you didn't like the post. I'm really trying to share what I thought was a worthwhile experience with the community. I appreciate the feedback though :)

<comment><USER24> Hah, don't mind my snarky comment. Just get these kids off my lawn.

</comment></comment></comment><comment><USER25> Great article. It's a good reminder that you don't need funding and a huge idea to get a side project going.

Thanks for writing this!

<comment><USER26> I agree. I really liked the thought process and the history/experience that made you think of using MTurk for this project. It shows that we sometime stumble on ideas that aren't just useful for just ourselves.

</comment></comment><comment><USER27> You may want to check out the MTurk command line tools to help automate order processing: <http://aws.amazon.com/developertools/694>

Never used MTurk personally, there may be better things available.

<comment><AUTHOR> Thanks! Believe there are MTurk API bindings for Ruby (the site is built in Rails.) Appreciate the comment!

<comment><USER28> The API is actually very nice to use, you create a template for your HIT (which I'm assuming you already have done for what you're making), and then you just make a single REST call with a list of questions!

</comment></comment></comment><comment><USER29> So you worked presumably 35 hrs over the period of 3 days or so and what you did actually was created a job that paid you $10/hr. Correct?

<comment><AUTHOR> Well the point is that now I'm set up to continue making money with minimal effort for a long period of time. So in the short run yes I was making very little money per hour, but eventually the work put in vs money taken out becomes much greater.

</comment></comment><comment><USER30> So, if I understand this is essentially reselling Mechanical Turk services with a little work in hiding the details from the customer? I'm not quite sure if this is a scam or not...

...but I can think of plenty of cases where people sell "expertise" which boils down to the same thing... normally its a bit more complicated than this though. I wonder if the customers would pay if they knew of Amazon's service? My guess is they just don't know about it, or at least didn't think it would be any good for them...

<comment><USER31> You're wrapping Turk in a human. That provides value. +

Have you ever dealt with Turkers? I did for a client once. Here's the task, simplified: "I give you job title, you give me degree title. For example, if I say 'elementary school teacher' you say she has a Bachelors degree in Education and so your answer is Education."

Input (to turker): Car technician Output (from turker): BACHELORS DEGREE IN CAR TECHNICIAN

I rejected that: sorry, I will not pay you two cents for that work. The Turker got into a running email argument with me: "WHY U NO PAY?" "Because the answer is in all capital letters, does not follow formatting instructions, and is wrong." "U NO SAY WRITE SMALL LETTERS!!"

Regardless, though: reselling labor is not skeezy.

+: You might think Amazon Turk pays for human intelligence. No, it pays for human intelligence _that finds it economically viable to work on Amazon Turk_. Y U NO GET DIFRENCE.

</comment></comment><comment><USER32> So thrilled for you Dan. Congrats again. Swiperoo loves your service.

<comment><AUTHOR> DomainPolish loves you right back. Keep in touch!

</comment></comment><comment><USER33> you are the definition of hustling badass. gumption was a good adjective used here. cheers to your work and may one day we meet at the top ;)</comment>


World's First 1,000-Processor Chip - <AUTHOR> https://www.ucdavis.edu/news/worlds-first-1000-processor-chip <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=11935999](https://news.ycombinator.com/item?id=11935999).

</comment><comment><USER3> other comments: [https://news.ycombinator.com/item?id=11935999](https://news.ycombinator.com/item?id=11935999)</comment>


Ask HN: A/B/C testing - something bothers me about this one. - <AUTHOR>

Say you have a piece of digital content (a song or book), and you sell it on iTunes, Amazon and on your own website.  You're interesting in finding out which of those sales outlets your customers prefer.
So, you devise a test: you'll create three splash pages, each has some marketing copy and a single link to one of those sales outlets.  Randomly, one third of your visitors will see the iTunes link, one third the Amazon link and the remaining third will see a link to your own website's sale page.  The visitor is identifiable, so the same link is presented on subsequent visits.
I don't think this actually tells you about what your customer's like.  But I'm having a hard time saying why. If I'm presented with iTunes but I don't like iTunes and never click through, does that really say anything useful about whether I like the alternatives?
That we're even doing the test is a nice change of pace, but I hate the idea of doing a test and claiming the results mean something that they may not. I'm happy to hear that my misgivings are wrong. <comment><USER2> > _I don't think this actually tells you about what your customer's like. But > I'm having a hard time saying why. If I'm presented with iTunes but I don't > like iTunes and never click through, does that really say anything useful > about whether I like the alternatives?_

You're performing the test on one large group of people, not on lots of individual people. (Does that make sense?)

It doesn't tell you what Bob as an individual likes, but it might tell you what a collection of people prefer.

It's quite important with A/B testing to set a sample size at the beginning of the experiment and stick to it. A statistician will be able to explain why.

Because you're not testing individual people it'll be tricky to disentangle the reasons for preference from the data.

</comment><comment><USER3> The answer to your question is in the the question - which means you almost get it.

You are adding an additional variable: for example "liking iTunes or not" that can't be tested like this, so you are confusing yourself as to the meaning of the results.

You are also trying to imply meaning on the "not doing something" aspect of it "does that say anything about the alternatives". This can only be true if the alternatives are available at the point of selection. Therefore, you are right this says nothing about the alternatives.

If you really wanted to see which was the preference from all three then all three choices need to be available to choose equally. At the moment by only giving one albeit random choice you are not answering anything.

To understand this process better think of the classic "google blue" test, where the colour of the links in the search results was subtly changed for random users to find out which blue worked best.

</comment><comment><USER4> I agree this won't show what your customers prefer, because you aren't giving your customers a choice. This might show you which of these your customers will buy from if they have no choice though.

If you want to see which they prefer, why don't you just have all three options on the page and see which one gets the most sales? Surely you can just see how much revenue is coming in from the different outlets?

It seems to me like this isn't a great use case for a/b testing. If you have all three options and one of them never gets used, stop showing that option.

<comment><USER5> If anything, you could A/B test the order in which the options are shown.

</comment></comment><comment><USER6> Isn't the conversion rate what you're interested in? This experiment will definitely tell you whether one link has a higher conversion rate.</comment>


Yelp Hit With Class Action Lawsuit For Running An "Extortion Scheme" - <AUTHOR> http://techcrunch.com/2010/02/24/yelp-class-action-lawsuit/ <comment><USER3> _The allegations are demonstrably false, since many businesses that advertise on Yelp have both negative and positive reviews._

I don't see how that demonstrates the allegations are false. It demonstrates that there must not have been an extortion scheme that every business paid into.

 _Update:_ see mustpax's comment. Yelp is making a statement about businesses which have paid them.

<comment><USER4> That, plus they obviously they wouldn't alter or remove all bad reviews. That would be brain-deadeningly obvious.

<comment><USER5> I personally know of somebody who had their review deleted on Citysearch. She felt violated. If Citysearch does it, I wouldn't be surprised if their competitors do the same.

</comment></comment></comment><comment><USER6> Yelp could do a itself a huge favor by becoming more transparent about its so- called "Review Filter." All it needs is a "show all" link somewhere on the page showing the supposedly suspicious reviews that were deleted by the filter, along with a list of reviews (maybe just the author name and/or first sentence) that were deleted by the author or by Yelp staff due to a TOS violation.

Yelp claims editorial is completely uninfluenced by the sales team, businesses claim otherwise. Put the data out there and let people decide for themselves.

</comment><comment><USER7> Where there's smoke, there's fire - I think at this point Yelp is going to wind up paying out some bucks, but will likely refine their internal sales process.

<comment><USER8> "Where there's smoke, there's fire"

That's the mantra of conspiracy theorists, UFO forums, and Bigfoot communities. Let's give Yelp the benefit of the doubt before we assume that they are illegally extorting small businesses based on no public evidence.

<comment><USER9> There is a lot of smoke here, and by smoke I mean business owners saying this is true and multiple law firms circling. This is getting ugly for Yelp.

<comment><USER10> Just because there are accusations, doesn't mean that something is true. It's not like they have no ulterior motive for making accusations.

<comment><USER7> Absolutely.

BUT tort-law firms do NOT lightly make decisions about where to allocate resources when being the FIRST to move in a class-related suit.

Neither of the firms is huge or that well established, but I imagine that they have sufficiently compelling evidence in hand to proceed, and the point of doing a PR blitz like they've done is to find other pissed-off, potential clients which will only grow the pool of riches should they win.

</comment></comment></comment></comment></comment><comment><USER11> The article below was sumbitted to HN a while back- rather interesting.

Backstory: The East Bay Express published a story criticizing Yelp and accusing them of extortion. Yelp CEO responds, criticizing the article's use of anonymous sources and general accusations. The article below is a response to the CEO's using named sources along with very specific accusations of what yelp did wrong.

[http://www.eastbayexpress.com/eastbay/yelp-extortion- allegat...](http://www.eastbayexpress.com/eastbay/yelp-extortion-allegations- stack-up/Content?oid=1176984)

*this is not the same article linked to in the OPs post.

</comment><comment><USER8> Yelp does not need to extort people to be insanely successful. It would be a pretty bad move, given that if they did actually do this, someone could:

a) Simply print out the email where Yelp explicitly extorted them.

b) Record the phone call using Google Voice or whatever, where Yelp explicitly extorted them via the phone.

c) Save the hardcopy of the letter or fax where Yelp mailed them the extortion offer.

Those are the only ways Yelp communicates. It would be trivial for one of the millions of companies in Yelp's directory to blow the whistle with concrete evidence. Yelp, an extraordinarily valuable company, would be pretty much ruined overnight. Why would they run this risk to squeeze out a few extra bucks?

<comment><USER12> > Why would they run this risk to squeeze out a few extra bucks?

You must not hang out with enough sales people. Companies do irrational things for short term gains all the time. See Wall Street for a recent example.

<comment><USER8> That's not exactly my point.

Yelp has many _easy_ opportunities to be a shady company and raise its profit margins in ways that are 100% invisible. For example, they could claim that an ad impression got twice as many views as it actually did and there would be no way to call them on it other than a few internal potential whistleblowers.

However, running a blatant extortion scheme where there is inherently a huge paper trail is not one of those things. Any one of the millions of businesses could become a whistleblower simply by posting an email to Hacker News, and Yelp would go from a near billion dollar company to a fraction of that.

It saddens me that if someone accused my startup of doing something absolutely atrocious, illegal, and irrational, instead of giving me the benefit of the doubt, it looks like Hacker News would actually say "where there's smoke there's fire" and start to rationalize how I am likely guilty given zero evidence.

<comment><USER12> > It saddens me that if someone accused my startup of doing something > absolutely atrocious, illegal, and irrational, instead of giving me the > benefit of the doubt, it looks like Hacker News would actually say "where > there's smoke there's fire" and start to rationalize how I am likely guilty > given zero evidence.

It's not someone, it's hundreds of companies over a long period of time. Now a class action lawsuit. There are over 4 million hits for Yelp and scam on Google--this isn't a one-off accusation.

<comment><USER13> And there are almost 4 million hits for moon landing conspiracy, just because people believe there's faults doesn't mean there is.

</comment></comment></comment></comment></comment><comment><USER14> I am a former Yelp Account Executive; I was one of the people that would call these businesses. I have both positive and negative feelings about Yelp. It was a short stint (November 07 to March 08) because I wasn't very good at the job as I hated the work (though the company itself is fantastic) and didn't believe in the product we were selling.

Account Executives (and pretty sure everyone in the sales division all the way up to the VP of Sales) had no direct way of removing reviews (and I strongly believe this has not changed). When I was there, the only way for an Account Executive to have a review removed was to email customer service and provide a solid explanation as to why it violated the review guidelines. And I can tell you that many times it wasn't easy; customer service had strict guidelines to follow and I (and my friends) had plenty of arguments that went nowhere. Theoretically, an Account executive could make friends with a customer service rep or someone on the development team and try to persuade them to remove a review, but this is highly unlikely because if found out, everyone involved would be fired (so there's a huge risk) and I can tell you from personal experience, removing a few reviews is not going to make or break a sale (so it's not worth the risk).

While it was a (sometimes extremely) frustrating process, I feel it speaks to how the executives of Yelp really do believe in the integrity of their review guidelines.

As for reviews being deleted, I can tell you that in many of those instances, the review has been put in a "purgatory" where the system waits until it receives a signal that the review is not actually spam to let it surface back up to users. This happens to both positive and negative reviews; there is no scam going on here to hide negative reviews for businesses that pay and positive reviews for businesses that don't.

Why isn't Yelp more transparent about this process and their algorithm? For the same reason Google isn't transparent about their algorithm - to prevent gaming the system.

With the frequently repeated story of business owners being told that their negative reviews will be removed, I believe it comes down to a misunderstanding of the sales pitch (the majority of the time). One of the key points of the sales pitch involved moving a positive review to the top of the review order where a positive review would stay for the duration of the contract. This was especially effective for completing a sale if there was a negative review on top ("the first review your customers see will always be a positive one"). So if a business became a Yelp advertiser, the review order would change, but only with that one review that was moved to the very top. No reviews were deleted or otherwise manipulated.

Why do I believe it's a misunderstanding on the business owner's part far more often than a mistaken or even purposeful effort by the Account Executive? For one, Yelp is pretty damn serious about their rep and will fire anyone caught doing this on purpose right away. Also, Yelp's training was good when I was there and has become phenomenal since I left so I don't see many mistakes happening. Finally, and I'm not going to butter this up, there are a LOT of business owners out there who don't understand the web and plenty who are just plain dumb (Just because you own a business, doesn't mean you should). the majority of businesses we called are one off restaurants/bars (just look at the majority of restaurant websites), little retail stores or one man service shops.

Yelp is about the customer first and businesses second; because of this, there are always going to be business owners who feel screwed. With all that said, though, I feel that this latest lawsuit speaks to a huge problem that is only going to get bigger for Yelp as it gets closer to an IPO unless they significantly change their business pitch.

<comment><USER15> "One of the key points of the sales pitch involved moving a positive review to the top of the review order where a positive review would stay for the duration of the contract. This was especially effective for completing a sale if there was a negative review on top ("the first review your customers see will always be a positive one"). So if a business became a Yelp advertiser, the review order would change, but only with that one review that was moved to the very top. No reviews were deleted or otherwise manipulated."

That's probably enough to give this case legs. IANAL but have been party to an unfair business practices lawsuit, and it's very easy to step in it.

<comment><USER14> From the techcrunch article: "in which the company's employees call businesses demanding monthly payments in the guise of advertising contracts, in exchange for removing or modifying negative reviews."

Yelp doesn't remove reviews and reviews themselves aren't modified; simply one positive review is moved to the top. You could argue that by moving the positive review to the top, that in turn modifies the order of other reviews (positive and negative), but seems like very shaky ground for the case to stand on. Of course, I'm no lawyer, so take this all with a grain of salt.

Or are you pointing out the loose quote I posted ("the first review your customers see will always be a positive one") is what will give the case legs?

<comment><USER15> The loose quote mostly. It is essentially, "we can hide the bad reviews a bit if you pay us." Again, IANAL, but it doesn't take much to lose some coin on "unfair business practices."

</comment></comment></comment></comment><comment><USER16> I've heard they treat their reviewers pretty badly, as well. Warning: this is anecdotal and only one reviewer. He was pressured to stop writing anything negative at all about certain restaurants until he quit reviewing for them altogether. If that is how they treat volunteer reviewers, I imagine it's worse for paid staff.

In any case, I have enough bad feelings and stories about them to not trust anything Yelp publishes.

<comment><USER8> Everyone is a "volunteer reviewer" on Yelp. That's how the site works. If Yelp actually told this guy to stop writing reviews, he should post the email and it would be #1 on Hacker News, etc.

</comment></comment><comment><USER17> They have enough cash to beat out an animal hospital in a fight of attrition...

Worst case they blame the one sales rep (this is not yelp company policy blah blah), pay up, and promise to play nice in the future.

<comment><USER12> Except the animal hospital isn't the only one who's made similar accusations. If lots of parties join the class action it could get expensive quickly.

</comment></comment><comment><USER18> zing! should've taken that acquisition when they had the chance. "what's done in the dark eventually comes to light"

<comment><USER6> For all we know, the fact that this lawsuit was coming could have come out during the acquisition talks and could be some or all of the reason they were called off.

If the acquisition had gone through, this suit - regardless of merit - <USER2> have been a huge PR black eye for Google. Similar anger/distrust has been leveled at them by small businesses regarding search results placement and AdWords.

</comment></comment><comment><USER19> As a general user, I love Yelp. But I also have friends who run retail stores, and they have reported feeling violated by the Yelp process, which suddenly has a very large say in the success or failure of the business. There is no "opt-in" option for retail stores, rather, those stores have to pay to "manage" their listing. If Yelp were opt-in rather than opt-out, I suspect they would have never had a lawsuit. (I know this would change a lot of Yelp's site, though, so not sure how feasible it'd be.)

<comment><USER20> Is there a way for a business to get themselves delisted from Yelp (either manually or in a robots.txt automated way)?

<comment><USER21> I doubt it, and honestly I don't think there should be. Businesses can't be allowed to censor what is said about them at will.

Yelp may be a flawed implementation, but the concept is sound.

</comment></comment></comment><comment><USER22> Even when they stop doing this, businesses will still get mad. They are mad that one bad employee can mistreat one customer, and the Whole Internet will hear about it (because Yelp is actually popular). The extortion claim is the only way to get Yelp into court.

In the end, the local businesses will lose. And I think that's a good thing; they should hire good employees and provide good customer service! I'm glad that Yelp can make some money off their indifference.

<comment><USER23> Well, on the other side of it. It only takes one bad customer having a bad day to shit all over your business. Some people are crazy and vindictive. Like the guy who reported me to the Consumer Product Safety Commission on fictitious grounds because I refused to be extorted.

</comment></comment><comment><USER24> <http://www.yelp.com/myths>

<comment><USER25> Yes, that's a credible source.

</comment></comment><comment><USER26> I'm curious about the law here. What is the threshold for extortion? Seems to me that despite Yelp being pretty shady, modifying the appearance of UGC on their site seems like it might not rise to the level of extortion. After all they are not writing these reviews or encouraging them in any way. We don't even necessarily know if they are deleting them or just reordering or what.

</comment><comment><USER27> Perhaps, we should wait for Yelp to give their side of the story before hanging them a-priori. Perhaps a runaway sales account exec couldn't meet his/her targets and got cheeky.</comment>