Tripping over the potholes in too many libraries - <AUTHOR> http://rachelbythebay.com/w/2020/08/09/lib/ <comment><USER2> From personal experience: it doesn't take a FAANG type of scale to reveal those "potholes". For most open-source projects (and especially things like pip, npm and other infrastructure and build tools) a simple, almost classical enterprise outbound proxy with authentication and MitM-style HTTPS- reencryption is more than enough kill almost every assumption they have in their code. In my case, that proxy tended to deliver incomplete files at random, which makes you discover that there is no checksumming happening. Then you build a local package proxy to help with that and then you find out that a particular library doesn't re-evaluate proxy environment variables on redirect, so that a redirect from external site to internal does not work. I can't remember filing that many issues at open-source projects as that time and it's been a draining game of whack-o-mole. At the same time you are reading tutorials called "How I did something in three hours" and you consider whether after-hours drinking might have been a better career choice.

Sorry. Enough ranting. That problem is everywhere, not just in libraries. I'm just not sure the problems lies in the users of those libraries, it's not too easy to _use_ those libraries, it's too easy to _publish_ them with a generic sounding name, but solving only a particular use case.

<comment><USER3> Could you explain a bit more? I think most pkg repos are just static directories. If you do https reencryption, and https certs do not match EVERYTHING will break.

<comment><USER2> Yes, it will. Normally, the IT department would roll-out their MitM CA certificates globally into Windows trusted certificates store or something like it. However, if you are trying to do CI/CD on a Linux server, you have to manually provide those CA certificates to the tools you are using. Many tools are developed in a kind of "HTTPS everywhere" bubble, so that they think HTTPS just works and don't provide any kind of remedy for broken, outdated or plain internal certificates. Then you start working around it and it feels like it never ends....

<comment><USER4> I find that software support http_proxy and https_proxy environment variables well enough nowadays (tip: the variable name is case sensitive sometimes, must be lowercase).

The real struggle for me is if the proxy requires authentication. It's very often not possible to configure a username/password and either way I don't want to put my employee password in every goddamn configuration file.

The CA certificate must be setup on Linux hosts, that's the bare minimum if the company wants to do SSL interception (add to /etc/pki/trust/anchors and call update-ca-trust), then things mostly work out of the box.

I've had one job where I spent a lot of time debugging and setting up PKI in a bank, have a postmortem here of how various libraries retrieve CA from the system (including obscure bugs around python ssl). [https://thehftguy.com/2020/03/19/jp-morgan-postmortem-why- yo...](https://thehftguy.com/2020/03/19/jp-morgan-postmortem-why-you-should- not-re-use-private-keys-or-csr-when-renewing-ssl-certificates/)

Of course the real solution is to have an internal mirror of linux/python/java packages.

</comment></comment></comment></comment><comment><USER5> I have been thinking a lot lately about a possible solution for a small portion of this problem: Microdependencies. I'll explain in more detail in the context of JS, but it applies to other languages as well.

Currently package repositories like NPM host 2 types of dependencies: big community packages (frameworks, database drivers, validation libraries, query builders,...) and smaller function-scoped utility packages (left-pad, is-even, math functions,...)

My proposal is to create a new package manager for the latter (or adapt existing ones) which handles micro-packages, typically scoped to 1 function, 1 file or a small set of files. The big difference with regular NPM is that these micropackages do not get downloaded into node_modules, but are downloaded inside the src directory and committed to source control. This means that when you add a micropackage to your project, its source code is pulled into the regular src folder and is subject to the same code review as the other code your team writes. When the micropackage is updated the changes are visible during code review as well (instead of just being an opaque version bump in package.json)

This process makes small dependencies more visible and has review builtin. It also solves the problem of having to rewrite the same logic in every project in a slightly different way.

Edit: I'm not currently working on this due to time constraints but if anyone wants to talk about this, hit me up.

<comment><USER6> I think the answer is to not import the dependency at all.

If you absolutely can't write a single function, then copy/pasting it from a set of "known good" functions would be better than importing a dependency.

Of course, just writing the function would be better. It would probably take less time than discovering the package, working out the interface for it, discovering that it doesn't actually work for your use case, discovering another, better package, etc.

<comment><USER7> Many useful libraries cannot be easily re-created. Consider datetime handling and X.509 parsing.

<comment><USER6> I agree, and happily import moment.js for that reason. But that's not what the GP was talking about. This is not a "microdependency". It's something that should have been included in the standard library, except that JS doesn't have one of those.

</comment></comment></comment></comment><comment><USER8> This comes up all the time and I never understand this attitude.

Yes: dependencies are bad. Not having dependencies and writing everything yourself: also bad.

Honestly, you have to rely on heuristics in your deps. How active is the project? How simple is the thing it's doing (simple enough to probably not have major bugs, but not so simple it's faster to code it yourself) etc.

You get so much velocity from depending on external libs, it's straightforwardly bad not to take advantage of it. Are the junior devs at your company really going to write a better config handling library than the random one from github? Probably not. Maybe they'll both be bad code but the open source one has a better shot of someone else noticing it.

<comment><USER6> But once they've done it your junior devs will know how to write a config handling library. And they'll have hit a few bugs so they'll know about file locking, and concurrency problems, and overwriting, etc. It will be a great learning project.

If you teach them to just import a dependency, then that's all they know. They'll never be able to write a concurrent library, they'll just know how to import one.

Having lots of velocity is bad if there are too many potholes in the road. Slow is smooth, smooth is quick.

<comment><USER8> > But once they've done it your junior devs will know how to write a config > handling library

This is true, but there are always so many things that need building. It's kind of like needing an end table, and either buying one from Target or building it yourself in your garage. End tables aren't that hard to build! The end table at Target is a piece of crap! You'll learn a lot trying to build your own end table! These things are all true, but the question that you have to ask before all that is: do I want to spend my limited time building an end table?

> If you teach them to just import a dependency, then that's all they know. > They'll never be able to write a concurrent library, they'll just know how > to import one.

This is probably true of some developers, but I don't think I've run into a developer that doesn't love building things themselves. (Possibly selection bias). The tendency coders have is to code. They're going to write something from scratch (and learn a lot) whether you tell them to or not.

> Having lots of velocity is bad if there are too many potholes in the road. > Slow is smooth, smooth is quick.

I agree with this principle. The way I think of it though is that it's not a road you're on: the asphalt stretches out in all directions, and you don't know which direction you'll be going next. It's very often the case that you spend a bunch of time smoothing over a single pothole to perfection, and crash into a another one right next to it. It is probably correct to shittily half- fill all the potholes around you just to avoid catastrophe and come back later to the ones you run over again and again.

<comment><USER6> > It's kind of like needing an end table, and either buying one from Target or > building it yourself in your garage.

Except that, in this analogy, you're a carpenter. Building furniture is your profession, and hopefully something you enjoy doing. Learning how to build end tables quickly is a useful skill to have in your profession. Practising that skill by building an end table for yourself is not a waste of time.

> It is probably correct to shittily half-fill all the potholes around you > just to avoid catastrophe and come back later to the ones you run over again > and again.

Indeed, but that's another skill :) Knowing when to accumulate tech debt because you're not sure if the feature will be needed is important. And again, it's a skill one acquires with practice.

<comment><USER9> > Except that, in this analogy, you're a carpenter.

Alright, and if you're a junior carpenter, are you going to be tasked with chopping down the perfect trees and whittling those down into the perfect legs and tabletops from which you will assemble your perfect end tables? Probably not; you're almost certainly gonna start off by, at most, going to your local hardware store, buying whatever shitty wood they've got, and putting that together into something that might look god-awful but at least functions approximately like an end table. Only after you've gotten good at building end tables with off-the-shelf wood are you likely going to have the requisite understanding of the limitations of said off-the-shelf wood to have any interest (let alone understanding) in going with custom wood.

Similar deal with software. If you're a junior programmer, yeah, you might be encouraged to develop your skills by developing libraries, if you're lucky, but in most shops you're probably gonna be tasked with, you know, actually delivering software, and that software will probably need to use existing libraries for expediency's sake. It's exactly why a hefty chunk of web development nowadays involves full-blown frameworks like Rails or Django (or even lighter-weight alternatives like Sinatra and Flask, respectively) instead of people hand-crafting HTTP request parsers / response generators and hooking 'em up to raw sockets.

"Store-bought" libraries, like store-bought wood, ain't perfect by any stretch. They still provide a reasonable starting point for getting a project done reasonably quickly instead of getting stuck in the weeds (literally) of growing your own trees.

<comment><USER6> I think we're probably extending the analogy too far, but I'll play along.

We don't craft programs out of machine code any more. We use high-level languages. So that's where we're not growing our own trees any more. I think the rest of your analogy agrees with me: even junior carpenters need to know how to build an end table by actually building them rather than buying them from Target.

It's a judgement call, I'll agree. But only allowing your junior devs to write glue code for imported dependencies means that's all they know how to do. They'll get the idea that that's all coding is - find the right dependency and write some glue code, and you're done.

I've seen this attitude so much recently, especially in startup product development, and it's actually dangerous. No-one audits their dependecies, they just read the description, import it and try to work out how to make it do the thing. If it works, who cares if it's huge, or has 34539473 other dependencies, or has been taken over by a malicious maintainer? Velocity, right? Get it into production and on to the next feature.

This is going to end badly.

<comment><USER9> > We don't craft programs out of machine code any more. We use high-level > languages.

A.k.a. we chop down existing trees instead of growing our own.

> This is going to end badly.

While I don't disagree, the alternative is more often than not for nothing to ever get shipped because the development team is busy reinventing the universe, especially when a "don't use libraries" mentality gets taken to its logical conclusions ("we need perfect custom hardware to run our perfect custom operating system written to run our perfect custom programming language/runtime to run our perfect application" \- just because Google has those sorts of resources doesn't mean a lone developer trying to get a side project done has those sorts of resources).

There is, however, a reasonable middle ground: start with those dependencies, and then as you encounter their limitations start working to replace them. The vast majority of development teams don't have the resources to make "do everything in-house" the default, but they _might_ have the resources to selectively fork or replace a critical library once they've built an initial implementation of their project on top of said library. To your point about junior devs and learning opportunities, this is a perfect way to learn: "alright, so you built this app with this library, great, now write a replacement for that library that does A, B, and C instead of X, Y, and Z".

<comment><USER6> I agree with that. I think I just draw the line further down the scale than you. Possibly, that's because I'm an old fart and more used to having to write everything from scratch, and so therefore more used to it (and less liable to consider that wasted effort).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> There are so many problems working in tandem here:

\- Leaky abstractions which are treated/documented as if they're perfect. Read a file, do a thing, write a file. Except when running in parallel, things are never that simple.

\- Lots of important projects ("base of Arch Linux" level important) still don't have public repos, an official site (or even page) with references, bug tracker, or any reasonable way of contacting the maintainers. How do these projects get updated? I guess they simply don't.

\- Even the best feedback mechanisms are still awful. Figuring out whether something is effectively abandoned before spending 30+ minutes writing up a bug report could take longer than writing the bug report itself, encouraging writing the absolute minimum (which ends up being less than minimum half the time). Every project is also its own unique snowflake. They want different types and amounts of information, some won't touch an issue unless it's reproducible in the very latest commit (requiring hours of setup and lots of domain knowledge to compile the damn thing), and they all have a completely different process.

\- Most tools are still skewed towards one maintainer per project. Take any random GitHub abandonware as an example. You can fork it with one click, but so have 20 other people. You can put up a web site for your fork, but search engines will rank the original web site (or just the GitHub repo) highest for years. You can rename it, but now you've just burned bridges with all the other forks _and_ the original repo, in ways which would be difficult to repair. Now try to migrate all the issues, mailing list, forum, IRC channel or other communications. It's basically hopeless unless the original maintainer is completely on board.

\- Most open source software solves only the author's immediate problem. But not a single user of the software has _exactly_ the same problem to solve as the original author. So pretty much by definition no library will solve the problem you are dealing with.

Maybe one way out of this mess for any particular language might be if the standard library was meant to grow to take over popular code, possibly with a tiered approach. You could nominate a library, then it would go through reviews, extensive testing, the whole shebang, before being accepted into a low level "this might someday be part of the standard library in some form" tier. This ideally would make it possible for example to replace core libraries in steps, steadily pushing the old one out of core and pulling a better alternative in.

</comment><comment><USER11> I guess the conundrum is: for 80% of people, maybe an 80% library is good enough; and 80% of library vendors are happy to write libraries that are 80% good enough - and 80% of customers have learnt to put up with stuff that occasionally doesn't work?

To me, the best solution is a language ecosystem that distinguishes itself by having properly written standard libraries to start with - whether built in, dynamically linked or optionally included in your project one way or another. For example, key=value config file parsing and saving should absolutely not need a third-party library. That should be as much a selling point of your language ecosystem than having a package manager that can pull directly from github.

One of the few upsides to "enterprise Java" is that there's a lot of "enterprise level" libraries around for it; even a lot of the open source ones are maintained by organisations like the Apache foundation rather than some random person on the internet. At one place I used to work, we had a whitelist of approved libraries and vendors, and even if you could in theory just import a library from the web, you had to make a case to your manager and get someone to sign it off if you wanted to use something not on the list. (As a side- effect, they'd also check the licence conditions, as we were writing closed- source commercial stuff. As a young intern, I got my first lesson in what (L)GPL meant when I requested to include something in one of our projects.)

</comment><comment><USER12> I think a lot of comments here are missing the fact that one could reimplement the config file handling library and atomic file update library in less time than it took to track down the package responsible for the bug and root cause it.

I've found such issues are the common case for libraries written in languages that encourage tons of tiny dependencies.

</comment><comment><USER13> This is so bizarre, as if fixing a config write to be atomic would somehow fix the root issue of _this program was not designed with a config store in mind that can tolerate multiple instances of itself_. Because of course it doesn't. Because having multiple instances in parallel was a novel requirement you introduced that the original author obviously didn't care for.

This isn't a learning experience about flock at all.

</comment><comment><USER14> > _My guess was that people get into these situations where it seems like a > library is going to be a solid "100% solution", and yet it lets you down and > maybe reaches the 80% mark._

That's probably true. I think a difficulty in avoiding this is that often the person reaching for this library, if they tried to write it themselves, would only hit the 60% mark.

And I don't think there's anything wrong with that. There are people out there writing code at many, many different skill levels. Libraries -- even those that are less than perfect -- let people get things done that they might not be able to do on their own, or would do a worse job of without the library.

<comment><USER6> I'm always amazed by this attitude. That somehow the authors of random libraries on npm are amazing coders whose code quality can't be touched by mere mortals like us.

Firstly, if you've always imported a dependency to get around a problem, then yes it's going to be hard to solve that problem yourself. But it's also a learning experience. Keep doing it and eventually it won't be hard.

Secondly, the library probably isn't a perfect match for your use case, and probably contains a lot of flexibility to match a wide range of use cases. Maybe as much as 80% of the code isn't actually any use to your project. It'll be more complex code, because it's dealing with a wider set of use cases. The thing you'd write to solve your particular use case would be smaller and cleaner almost by definition. You'd end up with less code, that you understand well. This is always a better position to be in.

<comment><USER14> > _That somehow the authors of random libraries on npm are amazing coders > whose code quality can 't be touched by mere mortals like us._

That's not what I said, nor what I believe. But I think it absolutely is true that most developers would struggle to reproduce the functionality of a fairly meaty dependency they've chosen (that is, not most of the dreck on the npm registry).

If a dependency exists for what you need to do, and after some vetting believe it to be of good quality, it's highly unlikely that it would be a good use of your employer's time to reimplement it yourself. I agree that it'd probably be a good learning experience to do it, but that's not the only consideration.

As for the rest, there's nothing that you're saying that's particularly wrong, but it's absolutely wrong if you apply it 100% of the time, because that would mean everyone would have their own bespoke web framework, networking library, UI toolkit, etc. I don't expect that you're actually making that argument, so it's a bit uncharitable of you to suggest that I'm making the exact opposite one, that no one should ever think about implementing something themselves.

Dependencies have a cost. _Not_ using a dependency also has a cost. Figuring out which cost is lower is part of the job, and that decision needs to be made several times on every project.

</comment></comment></comment><comment><USER15> Reusing code - your own or someone else's - often turns out to be a mistake. Reimplementing functionality also often turns out to be a mistake. _Either way_ people get fooled by 80% solutions. There's no simple answer to this. I can give a simple _algorithm_ \- look at how much time you'll spend on each vs. where it's most important for you to spend your time - but you still have to apply that algorithm to your own data set to know which choice is right. And sometimes you'll get a wrong answer, and it'll be annoying (as appears happened in the OP's example). That's why they pay us the big bucks.

</comment><comment><USER16> I think the generally accepted fix here (despite Rachel's aversion) is to submit a PR to the file writing library that fixes the corruption issue (likely using atomic rename), then get the tool to bump the version of their dep or vendor in the fixed version.

I'll admit, though, that the balkanization of code adds overhead from the abstraction. I just don't think it's a bad thing, because it's all very new and things are still shaking out.

Imagine if the fix lands in the config file writer library and all the downstreams regularly upgrade their deps; the fix is now a lot more widespread. This is better than every single end dev knowing about atomic renames, I think.

<comment><USER17> It is likely that fix would break somebody else's code which unwittingly depends on the bug. Then, burden of educating the users would fall on maintainers. Who, most likely, aren't having any of that. (Author even linked a article about this.)

<comment><USER18> How could you depend on a race condition bug?

<comment><USER17> It's not so hard to imagine a scenario where system happens to depend on both data concurrently written into a config file by 2 processes. If the file is properly written and renamed then data from one process gets lost, and/or if there is locking, one process will suddenly stall.

</comment></comment></comment></comment><comment><USER19> >"In short, I think it's become entirely too easy for people using certain programming languages to use libraries from the wide world of clowns that is the Internet. Their ecosystems make it very very easy to become reliant on this stuff. Trouble is, those libraries are frequently shit. If something about it is broken, you might not be able to code around it, and may have to actually deal with them to get it fixed.

Repeat 100 times, and now you have a real problem brewing."

A future job interview question that might be asked at my future company:

"Let's say you're using a library for specific functionality, a library that you haven't written. Now let's say that there's a bug in that library that you can't work around.

 _How would you debug that library?_ "

See, there's a differentiator there.

There are programmers who can _debug libraries_ , and then there are programmers that can _merely use libraries provided to them_.

Given a choice, you want a programmer who can _debug libraries_ working for your company...

</comment><comment><USER20> As people here point out, using 3rd party dependencies is inevitable, unless you're a tech colossus and can afford to write everything from scratch.

For the most part, these 3rd party dependencies work fine. In my experience it is fairly rare to encounter a show-stopping bug.

I have a simple mitigation for the "potholes" though - try to take the time skim through the code of the library ahead of time and try to figure out what it is doing. That way if you do hit a problem, you can fork and fix. Doing this can also give you a sense of how well-written a library is to begin with.

</comment><comment><USER21> I've run into an application, used for monitoring, that had that exact type of bug, albeit not with a dot file.

A customer of my old business had built a little monitoring system for their compute nodes mounting a parallel file system. Their integrated test had every compute node open a particular _fixed_ path and file name (of course the same on every node across the system) for read and write.

This "monitoring" script meant that they could have up to 2000 or so simultaneous IOs going to the same file, with no read/write locking. The tool read/wrote some number of bytes to get a performance read.

The end result was 1) lots of contention of course at the metadata layer, 2) often times spurious and incorrect reports of the parallel file system being offline (it wasn't).

We tried helping them on this, but they insisted they were doing this correctly (they weren't).

This is less about libraries with potholes per se, and more about critical applications (to a degree similar to libraries providing critical functions that need to be correct in semantics, implementation, and in error generation) that are broken due to a misdesign/mis-implementation somewhere.

With regard to her commentary on CPAN, one of the more annoying things I've dealt with in many libraries is their choices of error return. Some will throw exceptions. Some will return real errors you can process in-line. I am not a fan of throwing exceptions, and when I build larger Perl apps, I tend to insert some boilerplate exception handlers specifically due to the burns I've encountered in the past when modules do dumb things.

</comment><comment><USER22> Rachel seems to trip over the concept of Division of Labor[1] to a point. There is arguably more net gain from not having everyone reinvet OpenSSL just to communicate.

Or maybe she's more against being indiscriminate about re-use.

But there just aren't many companies big enough to engineer their own complete solutions.

[1] [https://en.m.wikipedia.org/wiki/Division_of_labour](https://en.m.wikipedia.org/wiki/Division_of_labour)

</comment><comment><USER23> > I will never know why the team chose to handle my report by swallowing the > error instead of dealing with upstream, but that's what happened.

The team avoided dealing with upstream in exactly the same way that _you_ avoided dealing with upstream. What's so difficult to understand?

</comment><comment><USER24> Honestly, you have this problem because you put up with it, or are "forced" to use certain software. Why is it everytime I venture into Python, interesting language aside, there are always multitudes of dependency problems even tied to the OS? People put up with it. Choosing quality over fast-food is a choice. Languages such as golang has largely solved much of this while still being pretty portable, and devs are encouraged to minimize deps.

Of course fast-food is tempting and may taste good, but after a while of abstention, this fades away. But it's a choice, and one might miss some opportunities.

<comment><USER4> Python is really easy to use. I don't get what's the troubles?

        git clone https://example.com/myproject
        cd myproject
        /usr/bin/python3 -m venv env
        source ./env/bin/activate
        pip install requirements.txt
        python3 src/myapp.py

</comment></comment><comment><USER9> A bit beside the broader point of the article, but...

> They responded. What did they do? They made it catch the situation where the > dotfile read failed, and made it not blow up the whole program. Instead, > they just carried on as if it wasn't there.

The tone here (and in subsequent paragraphs) seems to suggest that this is somehow the "wrong" answer.

Yet, it's exactly what I would've done, since _not_ doing this is clearly wrong. The file's corrupted with no hope of recovery, is not apparently meant to be user-serviceable (so user configuration is highly unlikely to be at risk), and is evidently not essential for the proper operation of the program (nor does it, in general, hold anything especially important - and no, some counter for when to nag about updates ain't important in this situation). There is absolutely no reason why this file's corruption should prevent normal operation; therefore, gracefully catching this error and expanding the "file doesn't exist" case to "file doesn't exist or is otherwise corrupt/unusable" and proceeding normally is absolutely the right call.

In an ideal world, they'd fix the actual corruption, too, but preventing that corruption from being an issue is the first and most critical step. I'd hardly call making software less fragile (said fragility being _exactly_ why so many "80%" libraries are indeed 80%) a "missed opportunity"; indeed, _not_ doing this seems like a glaring missed opportunity to make the software more robust against issues far beyond those caused by the limitations of some library.

That is:

> I will never know why the team chose to handle my report by swallowing the > error instead of dealing with upstream

Because _not_ swallowing the error would be a patently broken design, regardless of whether or not there was some library involved.

\----

EDIT:

> Yeah, that's right, because I worked for G or FB or whatever, somehow any > time I have a problem with something, it's because I'm trying to do > something at too big of a scale? Are you shitting me? COME ON.

I mean, yes? The situation described is very obviously one where the author is trying to use a tool clearly not designed for massively-parallel execution for a task involving massively-parallel execution. Why said author is somehow surprised that said tool breaks when put under that sort of stress is beyond me.

It's akin to buying a 1 ton jack from the auto parts store and then complaining to the minimum-wage employees thereof because when you tried to use it to change the treads on a 50-ton bulldozer the jack predictably flattened like a pancake.

There's always a point where off-the-shelf parts won't cut it and you gotta roll your own solution in-house. Evidently the author has a tendency to hit that point sooner rather than later. That's pretty rare, though, and condemning the very notion of an external library because of said libraries failing under _very_ exceptional circumstances seems absurd.

That is: no shit most libraries are written for the 80%, because the 80% ain't got the resources or motivation to deal with the consequences of NIH syndrome like the 20% might. They gotta ship _something_ , and can't afford to let perfect be the enemy of good.

The more reasonable approach (for those currently in the 80% but hoping to eventually be in the 20%) is to start with those off-the-shelf libraries, and then be prepared to fork 'em and use them as starting points for specialized approaches (or else swap them out with specialized replacements). In this regard the author's correct in that the package ecosystems of most languages are poorly suited to this, since they offer little to no mechanism for customizing dependencies without rather painful workarounds.

</comment><comment><USER25> > I show up with a problem ("hey, this thing keeps getting corrupted because X > and Y") and suddenly it's because I'm "from" G or FB or something and I > "want unreasonable things" from their stuff. So, my request is invalid, > thank you drive though.

No, the answer is they're trying to deliver impact for the customer and Rachel is instead asking them to invest time in a solution that doesn't bring them any closer to that. I'd imagine most of them would be fine with fixing the root cause, but for some fucking reason everyone from Google or FB feels the need to reinvent every wheel in order to peacock and show that their IQ is the highest.

With that said, at my "normal people" non-bourgeoisie company the 3P libraries are all converted to the internal build system. If there was a fuckup of this magnitude, someone would just create a branch and bump the version number with the fix. Problem solved.

<comment><USER26> This is a pretty bad take. Rachel has said implicitly that there was no version with a fix available and explicitly that working with the maintainers to get a fix is often unreasonably difficult. This matches my own experience fairly well. So your 'normal people' solution won't work.

You may also want to consider that there are good reasons for engineers and engineering management to be default suspicious of 3rdparty dependencies at large companies such as those you've listed. These reasons have nothing to do with peacocking or demonstrating high IQ (replicating things available elsewhere is not a way to demonstrate your intelligence, it turns out). They have much more to do with the high bar for security consciousness, unique need to deal with scale or low performance tolerance, or extreme organizational risk associated with being a company with a target on your back for every major hacker, researcher, regulator, journalist, or self-proclaimed watchdog — not to mention operating under several consent decrees already.

<comment><USER27> +1

The issue gets even harder when the code is proprietary. Had a situation with one of VMware's products that was being provided to us by a SAAS provider. It was a far amount of effort to a) convince the provider to file a bug with their vendor and b) then provide enough data to the VMware engineers so they could understand the value in prioritising a fix.

In our case, we identified the issue during a proof of concept so our vendor pushed VMware pretty hard because there was a sizeable contract at stake for them. Most engineers aren't as thorough in my experience.</comment></comment></comment>


Marissa Mayer Got a $1.2 Million Bonus at Yahoo After Six Months - <AUTHOR> http://mashable.com/2013/03/07/marissa-mayer-got-a-1-2-million-bonus-at-yahoo-after-six-months/

<comment><USER2> Wow. All I have to say is wow.

</comment><comment><USER3> Anyone close to Marissa Mayer should be filming ALL of her day-to-day activities and make a documentary in 2 years.

The subject will be either the miraculous turn-around or failure of Yahoo.</comment>


Army Picks Sig Sauer's P320 Handgun to Replace M9 Service Pistol - happy-go-lucky http://www.military.com/daily-news/2017/01/19/army-picks-sig-sauer-replace-m9-service-pistol.html <comment><AUTHOR> Given the HN article earlier today about people claiming they were humbled when they aren't, I find it amusing that the article quotes the CEO saying: "We are both humbled and proud that the P320 was selected by the U.S. Army as its weapon of choice."

[https://news.ycombinator.com/item?id=13480255](https://news.ycombinator.com/item?id=13480255)

<comment><USER2> It's believable though. The most powerful military force on the planet chooses something your company makes to become the standard issue. It's hard to believe that wouldn't feel humbling. What a sense of pride that must give them. Do those two feelings cancel each other out? It's important to not try to frame everything you read based on whatever article was recently up-voted here.

<comment><USER3> >* It's hard to believe that wouldn't feel humbling.*

The parent's point is that it wouldn't feel humbling in any original meaning of the word. You wouldn't feel "lowered in stature" etc for being chosen, but the opposite.

But of course this ignores that the word has shifted in use.

<comment><USER2> Yeah you're right when you mention the shift in use. Reminds me of people who use "begs the question" incorrectly (basically everyone and all the time) but how most people think of it now. Very pedantic though. (Pedantic is the HN norm though, so, when in Rome, do as the Romans do.)

</comment></comment></comment></comment><comment><USER4> Why not Glock, I wonder. If you're going to go striker fired anyway, Glock is the Kalashnikov of handguns. Simple as can be, and just keeps going no matter what. I have a Sig P226, it's a fine gun, I'm much more accurate with it (shooting stationary paper targets), but if you asked me what I'd take to a war zone, I would take a Glock 17 or a Glock 19. Much less of a chance that it'll crap out on me at the worst possible moment, which is an important feature, when your life is on the line, IMO.

<comment><USER5> Glock was out of the running because lack of a "real" safety and their unwillingness to add one

<comment><USER4> They have the only "real" safety: keep your finger out of the trigger guard. :-)

<comment><USER6> or for conceal carry...don't catch your shirt on the trigger...

<comment><USER7> Dude. I've been daily carrying a Glock since 2006, never had a negligent discharge.

<comment><USER8> Survivor bias - someone who has is less likely to post.

<comment><USER7> You can't just say "survivor bias" and think you have a solid argument. Let's examine your objection more critically.

I mentioned I'd carried every day since 2006. Suppose this isn't quite true, and I've only carried 330 days per year (this is too low, but still). Further, we just started 2017, and I started carrying in August 2006. This means I've carried roughly 3,437 days. If my carrying a Glock on any given day is as high as 99.9% safe (i.e., I have a 0.01% chance of a negligent discharge), then I should have a "survival" probability of only 3.2%. If my daily safety probability drops to only 99.7%, my probability of getting to now with no ND is 0.0%. Decreasing my daily safety probability to only 99% means my probability of no ND is 9.95e-14.

Now think about what this means. Either:

1\. Carrying a Glock is very unsafe, and I'm _incredibly_ lucky. In this case your claim of survivor bias would be warranted (assuming there weren't many others like me, which there are).

2\. Carrying a Glock is very safe, and the chances of an ND are substantially less than 0.01% per day, in which case the charge of survivor bias is unwarranted.

It strikes me that #2 is the clear winner here.

<comment><USER9> I think the main thing you've demonstrated with your calculations is that a 0.01% chance of negligent discharge per day is in fact rather unsafe. In particular, a 0.01% chance of discharging per day means that with daily carry for two years, you are more likely to have experienced a negligent discharge than not.

<comment><USER9> Sadly, this comment of mine is incorrect. I meant 0.1%. My error comes from the same error in the comment I was responding to:

> 99.9% safe (i.e., I have a 0.01% chance of a negligent discharge)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I keep waiting for someone other than the Maryland PD to appreciate the Beretta PX4 Storm.

Anyway, I think the decision to search for something "more potent" than 9mm is pointless. There's a real reason we ditched the .45 for 9mm, and there's a lot to be said for smaller, cheaper ammo that everyone in the army can shoot all day without breaking their wrists. 9mm isnt .22, and it's more than enough to stop just about anyone coming at you.

<comment><USER11> >I keep waiting for someone other than the Maryland PD to appreciate the Beretta PX4 Storm.

I should mention that the Slovakian army is adopting the Grand Power K100; the action is very similar to the PX4 Storm (the barrel rotates).

<comment><USER10> Yeah, the rotating barrel is actually very neat and effective. I had my reservations about it, but it's actually a pretty solid mechanism that all but eliminates recoil and improves subsequent shot accuracy. Thanks for sharing the info about the K100.

</comment></comment></comment><comment><USER5> Article touched on the subject at the very end, but the decision was pushed across the finish line just before inauguration. Tremendous waste in the program and would have been easy fodder for Trump.

<comment><USER12> In the follow on procurement or the contract competition? The M9 is pretty old school and should be replaced. The p320 is a pretty nice side arm at a reasonable price on the civilian market.

<comment><USER5> Agreed m9 was due and the p320 is a great weapon. But $17mm and two year trials is silly for pistols that were largely already on the market.

</comment></comment></comment><comment><USER13> Sig sauers prominently featured in person of interest as well... Giving some leeway for the fact that it's a TV serial, there has to be some merit in the handgun for the protagonist to fall back to it all the time.

[http://personofinterest.wikia.com/wiki/John_Reese](http://personofinterest.wikia.com/wiki/John_Reese)

_Reese's weapon of choice is a SIG-Sauer P226R..._

<comment><USER14> > there has to be some merit in the handgun for the protagonist to fall back > to it all the time.

Probably product placement.

<comment><USER15> The idea of product placement for a firearm just seems bizarre to me... but I'm not American either.

</comment></comment></comment><comment><USER16> Interesting to see this on HN. I know there has never been any love for the M9 from it's inception, so this is long overdue. Having a .357 option is going to be really popular I'd imagine.

</comment><comment><USER17> For anyone else interested in the acquisition side of this, here's the .GOV- official award notice[1] and PDF of RFP[2] that drove this competition.

[1] [https://www.fbo.gov/index?id=fb3dfb4ce966d2b1b0e017377b27cc1...](https://www.fbo.gov/index?id=fb3dfb4ce966d2b1b0e017377b27cc1b)

[2] [https://www.fbo.gov/utils/view?id=04ea995d09f89172f449616ffc...](https://www.fbo.gov/utils/view?id=04ea995d09f89172f449616ffcf97e7c)

</comment><comment><USER18> It seems a little odd that Germany has so many of the world's leading small arms manufacturers. I guess it's mostly the general manufacturing expertise.

<comment><USER19> US manufacturers have the benefit of a large domestic law enforcement and civilian market for small arms, but also have to contend with relatively stringent export controls on weapons.

Germany is the opposite. Small domestic LE/military market, minimal to non- existent civilian market, but they'll export to anyone who can pay.

</comment></comment><comment><USER20> Seems sensible. Fairly conservative switch from one DA/SA to another.

edit: I was totally wrong. I was thinking of the P220, not the P320. This is actually a huge change.

<comment><USER21> The Sig P320 is striker fired double action only pistol, and has the same trigger pull every shot :)

<comment><USER20> Whoa - I was thinking is the P220 / 226\. So yeah, this is a big change then.

</comment></comment></comment><comment><USER22> I remember reading somewhere that the modularity requirement was basically written to make sure the P320 won. No, I can't recall where or cite.

<comment><USER23> I looked into it and found this article ([https://bearingarms.com/bob-o/2016/03/21/army-general- screw-...](https://bearingarms.com/bob-o/2016/03/21/army-general-screw- procurement-nightmare-give-glocks/)) about a US Army General that was tired of waiting for the MHS competition (which is the competition that the P320 won) and was gonna try to bypass the competition and just get Glock 19s. However, he did not succeed and the P320 was chosen.

</comment></comment><comment><USER24> Fantastic although interchangeable grips are going to be a pain in the ass to keep track of. Not to mention I sure hope they settle on a single caliber across the force.

Can't wait to see how many models wind up on the property books if the Army decides to go for different options. Which knowing the Army that will happen...

<comment><USER25> Pretty sure 9x19mm is still the standard handgun cartridge across at least the U.S. military, if not NATO as a whole.

I also suspect they'll standardize around the full size P320. I don't think there will be such a sad explosion of combinations.

</comment></comment><comment><USER26> "We are both humbled and proud", what does this mean?

<comment><USER27> [https://news.ycombinator.com/item?id=13480255](https://news.ycombinator.com/item?id=13480255)

</comment></comment><comment><USER28> This seems like a disaster waiting to happen, modular, different calibers, threaded etc...

</comment><comment><USER29> I wonder when humans will stop using guns on each other. Maybe 2100?

<comment><USER30> When humans have an alien species to use guns against.

<comment><USER29> In all honesty, I watched Arrival last night, and I've been thinking about it all day. It's actually the main reason I posted my comment. I highly recommend watching it.

</comment></comment></comment><comment><USER31> I would have chosen Springfield armory XDs.

I love mine. Outstanding sidearm.</comment>


Hiding in N. Virginia, a daughter of Auschwitz - <AUTHOR> http://www.washingtonpost.com/lifestyle/magazine/hiding-in-n-virginia-a-daughter-of-auschwitz/2013/09/06/1314d648-04fd-11e3-a07f-49ddc7417125_story.html <comment><USER2> _By the end of the war, 1.1 million Jews had been killed in the camp, along with 20,000 gypsies and tens of thousands of Polish and Russian political prisoners._

Why simply mention Jews and explicitly mention Polish and Russian _political_ prisoners? Did innocent civilians not die at all?</comment>


Why rats can't vomit, and why humans do - <AUTHOR> http://www.ratbehavior.org/vomit.htm

<comment><USER2> My sister has pet rats, and I had to babysit them for a while. They're actually really cool, smart and interesting. I recently finished the book "The Omnivore's Dilemma" which draws a lot of parallels between rats and humans (basically we have a lot of the same adaptations around eating). I'd recommend the book and the pet.

</comment><comment><USER3> Out of all the submissions on the site, this is my favorite.

</comment><comment><USER4> Did anyone else feel a little tiny bit like vomiting while reading this?

It's fascinating.

<comment><USER5> The most fascinating thing to me is that people have actually devoted studies to finding out whether or not a large swath of animals can vomit.

<comment><USER6> People have devoted _careers_ to finding out which animals can vomit. A fellow named Borison has numerous entries on the final table -- assuming it's the same person, this bright spark hit the scene in 1953 with the finding that crab-eating macaques and rhesus monkeys can spew; and decades later, in 1981, he followed up with the surprising finding that while most rodents can't upchuck, the woodchuck could.

<comment><USER5> My God. You're _right_. I don't really know what to think here.

<comment><USER7> I'm thinking we need to register vomitr.com and crowdsource this. A community of people answering the question: Is your favorite pet species vomiting right now?

<comment><USER8> Unfortunately, yes. I just spent the last few evenings steam cleaning my carpets because my dog has a very sensitive digestive system...

<comment><USER5> Imagine our fortune if we were to engineer a non-vomiting dog! Also, cats. No more hair balls. Growing up around no less than 2 dogs and a cat throughout my entire adolescence gives me a desire for this tech. It would also make a good Founder story!

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I have no idea how this is hacker news, put I found it pretty interesting nonetheless. :)

<comment><USER10> Articles like this may not be "on topic", but they're unlikely to devolve into flame wars, and attract people interested in flame wars, as would an article about politics or (often) economics.

</comment></comment><comment><USER11> The table under Evolution of vomiting is especially interesting. Never saw vommiting pigeon!

<comment><USER12> I don't know if it counts as "vomiting" but it's how they feed the chicks, they regurgitate partially digested food.

Before you get disgusted: some humans will chew food in the month to feed to a baby. And pigeons can't chew.

<comment><USER13> The article explains the difference between vomiting and regurgitation. In general, vomiting is active and requires coordination of many muscles. Regurgitation is passive.

<comment><USER12> Pigeon regurgitation is active though. They do it on purpose to feed a chick.</comment></comment></comment></comment>


Ask HN: product doing very well but growing technical debt; what to do? - <AUTHOR>

About 4 months ago, I joined a friend of mine as a tech co-founder for a company he had been working on (he's biz, and darn good at it).
He had been contracting out the code for the MVP, and as things were working out, he figured it was time to fully delve into it and bring a full time cofounder on board. The contractor had no interest in doing so, and that's where I came in.
The code has been working well for all intents and purposes, and we have users (in the high 4 digits) who use the product everyday and love it, but it's showing limitations. Here's a quick overview (it's a Django webapp):
a) There are many inefficiencies in the code, and now that our userbase is starting to grow fast, it is causing major slowdowns. My current solution is to throw more dynos at it, which sort of works but is an ugly temporary workaround.
b) The code is more tightly coupled than not, which is making life tough when implementing new features. Many parts could be refactored.
c) There is no unit testing, which makes things harder than they should be when it comes to testing/hunting bugs.
d) Nothing is commented; and even though Python tends to be somewhat self-explanatory, it gets pretty dense when trying to understand what certain things do.
e) The architecture of it all is very monolithic; based on our plans for the future business development, quite a few parts should be decoupled and made more independent of each other.
A full rewrite seems out of the question, as we have many users and we need to keep on moving with bug fixing + shipping new features. For that same reason, it's hard for me to justify blocking 2 weeks to refactor a subpart of the application.
I'm the only engineer right now; we're funded and looking to hire more people, but it's going slowly.
Has anyone been in a similar situation before? Any recommended books/articles? If you're in SF and have relevant experience, I'll gladly buy you lunch in exchange for your thoughts. <comment><USER2> I have limited knowledge of Python / Django, but I have quite a lot of experience dealing with large projects in PHP and many of the frameworks and applications built with it.

Are you using Git for your source control? If so, you may want to start a new branch and work in it before doing any major re-factoring.

To start, I would try to find a small part of the application that you feel would be possible to re-factor in an hour or so. Before changing anything, I would load up the app locally in your browser and navigate to the portion that is dependent upon the code you're going to re-factor. Then I would re-factor things in as small a chunk as possible, constantly checking in the browser to make sure things still work properly. This is a rather bastardized approach to test driven development, but it can be quick and effective.

> The architecture of it all is very monolithic; based on our plans for the > future business development, quite a few parts should be decoupled and made > more independent of each other.

As a side note.. This type of thing I have seen way too much of in my time in the industry. It's very easy to get carried away and over-engineer a solution. I've found it's best to create a solution that solves only the problems you currently need solved. It's always easier to go back and extend while re- factoring than it is to try to re-factor a giant-freakin'-thing after the fact.

</comment><comment><USER3> Congrats on your success--you have the best kind of problem.

1\. You have a working product--do not do a full rewrite. Rewriting has so many pitfalls in the best of cases, and if it's just you, the context switches between the "old" (which you will still be spending most of your time maintaining) and the "new" systems will be brutal.

2\. This is the prototypical "real world" case. You're basically asking how you can prioritize immediate enhancements vs. long-term flexibility and maintainability. But _maintainability is a feature_. Any (good) book on agile development methodologies will tell you that consistent refactoring and cleaning of the code has direct user benefit, in that future velocity (user enhancements) will be better.

3\. The prudent way forward is to chip away at the problems. As you "touch" various parts of the system, start doing small refactoring work, adding comments, tests, etc. Remember, you're starting from nothing--anything you do in this regard is improving your situation.

4\. If you're not doing some sort of iterative development methodology, start. Personally, I have a preference for Scrum, because of its time-boxed nature. It lends itself well to devoting a section of each dev cycle (sprint) to the kind of cleanup work you need to do.

Good luck!

</comment><comment><USER4> I have a fair amount of experience dealing with this, as a contractor, full- time employee, and CTO. My background is even predominantly Python (used to do Django back in the 1.0-1.2 days).

The best advice I can give you is to do it step by step and don't let yourself get overwhelmed. It's just work. Just do the work. Here are some steps to take:

1\. Start cleaning up and commenting the code. Start using a linter. Don't attempt to refactor aggressively here. Don't refactor at all. Just surface details for now.

2\. Start adding unit and functional tests. If you have an API, test against it. As much coverage as possible.

3\. Start refactoring, breaking things, then fixing the tests.

4\. Repeat #3 until it's a clean codebase. This is the point at which you'd start looking at performance and coupling too.

A little bit at a time and don't get overwhelmed.

I'll send the consultancy invoice tomorrow.

</comment><comment><USER5> 1\. Introduce continuous integration.

2\. Slice up the codebase with encapsulation. If you have something that is incredibly tightly coupled that you can't refactor, just put a bubble around it.

3\. Base all of your optimizations on statistical analysis of your logs. If you don't have log data to that level, introduce some RUM.

</comment><comment><USER6> b,c,d and sometimes even e,a are normal, I would say, normal, every company has them, because we can always do better but we have always too little time. If you are making any money try to hire someone to give you some help.</comment>


What It Looks Like to Use the Internet for the First Time - <AUTHOR> http://motherboard.vice.com/read/what-it-looks-like-to-use-internet-for-the-first-time <comment><USER2> I stood beside my 67 yo mom when she used Internet for the 1st time. Her first reaction was Wow - Google knows everything. :)

</comment><comment><USER3> We've spent many millions broadcasting radio and TV to Cuba (see [https://en.wikipedia.org/wiki/Radio_y_Televisi%C3%B3n_Mart%C...](https://en.wikipedia.org/wiki/Radio_y_Televisi%C3%B3n_Mart%C3%AD)). I wonder what the obstacles are to providing internet access via something like Project Loon. Free, uncensored internet access would be a far greater catalyst for regime change in Cuba than those shortwave broadcasts ever were.

</comment><comment><USER4> By 2020 80% of humanity will have access to a smartphone connected to the internet.

As a programmer I am really optimistic about the future :)

<comment><USER5> They certainly won't be threatening your job any time soon. We won't be educating a new generation of programmers when 80% of users' primary computing device is a phone.

<comment><USER6> Why not? You can get a computer which runs linux, and lets you learn how to program, for far cheaper than the average cell phone costs. For example raspberry pi runs linux and you can buy it for $30.

Right now the thing that is stopping more people from learning programming is probably the unfriendliness that is associated with setting up your environment for the first time and learning everything from scratch.

<comment><USER5> The $30 price of a RaspberryPi is pretty disingenuous. You also need over $100 of accessories to actually use it as a desktop computer.

</comment></comment></comment></comment><comment><USER7> That was quick - when I was there at the end of 2013 internet access was hard to come by and very expensive, and also very transient

</comment><comment><USER8> If you don't read the article just look at the pictures, all you can see is people staring screens. That bothers me a lot.

<comment><USER9> It shouldn't. You're starting at a screen to read this. I am staring at a screen to write it. Communication with people outside of shouting distance has always required staring at something. It looks passive, but it opens up a world inside your head.

Put aside the romantic notion that these people are losing something. They're gaining access to the rest of the world. They deserve it just as much as you and I.

<comment><USER10> Highly related -- the notion that we need to preserve linguistic diversity by making sure obsure-language communities stay where they are, instead of learning languages that allow them to participate in the world economy.

Oddly, this is an area of debate in linguistics, where you find people saying things like "well, these communities with their languages spoken by 300 people are great for us professionally, but it's hard to say the parents are wrong for wanting their children to be able to have jobs outside the village." But... _public opinion_ (in the US) seems to be entirely on the side of stasis - if the world included an inaccessible 300-person village with its own language last year, moral correctness requires that that village and that language persist as they are forever, and what the villagers might want is irrelevant.

Communication media are not primarily of benefit for their aesthetic appeal. They are of benefit for letting people communicate.

<comment><USER11> >the notion that we need to preserve linguistic diversity by making sure obsure-language communities stay where they are, instead of learning languages that allow them to participate in the world economy.

In the Linguistics community, this is not an either-or proposition. The focus is on preservation of minority languages in the face of the economic necessity to adapt to the majority language. The economic necessity will always win out. There's no need to defend it.

Additionally, the ethical concerns with Linguistic preservation are numerous and well-acknowledged. There are many indigenous languages that may never be preserved simply because the people who speak them specifically refuse to participate in it and the professionals in that field respect that (they don't have much choice, of course).

I've seen this anti-preservation sentiment before and it's quite puzzling; it seems to assume a demand by the preservationists for monolinguistic isolation that doesn't exist. That is, most of the world's people speak 2 or 3 languages anyway, so the call for everyone to "learn English and forget the rest" or something similar is not even necessary.

<comment><USER10> I specifically called out that the linguistics community says a lot of very reasonable stuff here, in contrast to the public. Are you disagreeing with me about the public? I'm not disagreeing about the linguistics community (except to say that there are definitely pieces of it that take a whole-hog preserve- them-regardless-of-their-own-good view of things).

The demand for monolinguistic isolation is real, and springs from the same realistic viewpoint you've stated that "the economic necessity will always win out". That you don't share it doesn't mean nobody shares it.

<comment><USER12> That's an interesting contrast! Language preservation efforts by professional linguists do usually have a lot of respect for the speakers' autonomy, where tourists' desire for things to stay the same so they can go see them as they used to be might be less respectful of local people's autonomy.

Of course linguists also have a scientific interest which isn't necessarily motivated by a view that it's _good_ for people to speak their heritage languages, so much as that it's important for people documenting the language to have access to as many competent informants as possible (ideally also over time and from different walks of life). The ethical part as I understand it might be more like a desire for people to have access to the resources and circumstances that will let them become as competent as possible in all the languages they want to use.

</comment></comment></comment></comment></comment></comment><comment><USER13> Very sad that social surveillance systems like facebook are taking off in these uneducated minds. Firefox OS should contribute to liberating these people by enabling mesh apps... [https://news.ycombinator.com/item?id=10120722](https://news.ycombinator.com/item?id=10120722)

</comment><comment><USER14> Related to this is 'El Paquete' \- a weekly offline delivery of the internet. [http://www.bbc.com/news/technology-33816655](http://www.bbc.com/news/technology-33816655) [https://en.wikipedia.org/wiki/El_Paquete_Semanal](https://en.wikipedia.org/wiki/El_Paquete_Semanal)</comment>


Don't Try This At Home: Sepak Takraw May Be The Toughest Sport On The Planet - <AUTHOR> http://www.thepostgame.com/blog/training-day/201107/dont-try-home-sepak-takraw-may-be-toughest-sport-planet

<comment><USER2> This game is pretty insane. I never got the hang of it when I was growing up but the part about not letting the ball drop has definitely helped me sharpen my skills in other sports. And personally, I think it also focuses your mind and trains your concentration. Which is a huge issue when it comes to projects for me - I can never concentrate or stay focused long enough on a single idea.

<comment><AUTHOR> Well, much respect to you for having played this incredibly difficult game. I have played soccer in high school, and I can play volleyball, but knowing how to play those sports individually doesn't mean you can play this. The skill level, with your feet, required here is off the charts.</comment></comment>


Clay Shirky's Internet Writings - <AUTHOR> http://www.shirky.com/ <comment><AUTHOR> If you scroll to the right hand side of this page, you may see links (with terms like viagra) with mouseover text (similar descriptions) but behind these links appear to be articles or transcripts of speeches that Clay has given.

I have no idea why he would do that, can someone explain?</comment>


I Believe in the Middle Click - <AUTHOR> http://horia.me/the-middle-click

<comment><USER2> I hate javascript links that can't be opened in new tabs.

<comment><USER3> One of the strange things I've always found in Safari is that while some sites break Cmd+click (to open in a new tab), if you use the menu (right click > Open Link in New Tab) then that will work just fine.

<comment><USER4> The site is intercepting the click event, whether ⌘ is held down or not, but not right click (and maybe also not ⌃ click). When you ⌘-click, the "open in a new tab" behavior never fires, but when you choose the menu option, it does.

It's annoying, but not inexplicable.

<comment><USER5> The codepath for right-click and control-click is the same unless you go pretty far out of your way to discriminate — that's why both methods of opening the contextual menu work.

<comment><USER6> This is about CMD-Click, not CTRL-Click. CMD-Click sends a 'click' event to the page, since it counts as "left (primary mouse button) click", not "right click".

<comment><USER5> I was responding to jacobolus, who noted that many sites intercept clicks, "but not right click (and maybe also not ⌃ click)" (on the Mac, "⌃" is the symbol for the control key). I was explaining that those are pretty much the same thing from the program's point of view, so code that allows right-click will almost certainly also allow control-click.

<comment><USER4> This is incorrect. In Safari at least, if you attach a handler to the mousedown event, your handler will fire for both ⌃-click and right click, but the two events will be different.

In the former case, you have event.button = 0, and event.ctrlKey = true. In the second case, you have event.button = 2, and event.ctrlKey = false.

What happens depends on the logic inside the handler.

On the other hand, if you attach a handler to the click event, it doesn't seem to fire for either right click or ⌃-click.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I love and use this idea, but the OP missed the Shift key. At least Firefox and Chromium use Shift+click to open the link in a new window and I'm pretty sure IE does that as well but I can't test that now.

This is what I use:

      $('.some-snazzy-selector').click(function(ev){
        if( ev.which == 2 || ev.metaKey || ev.ctrlKey || ev.shiftKey ) return true;
        e.preventDefault();

        /* Awesome AJAX code goes here */
      });

I posted this comment on the blog, but it may reach someone else here, too.

<comment><AUTHOR> Yep, thank you. Post updated.

</comment></comment><comment><USER8> I believed in the middle click, too, and lots of other special clicks... until I switched to a MBP. The I customized the touchpad using the Better Touch Tool and I haven't looked back since! :)

</comment><comment><USER9> I use FF extension called DblClicker which lets me double-click a link into a new tab. It also closes (or duplicates) open tabs with a double-click.

Started using this when the middle-click on my mouse broke from too much use.

</comment><comment><USER10> I have never run into this problem, and didn't see anyplace where Delicious does this... is it really that common? (Aside from the middle-click-js-link- and-weep thing?)

<comment><AUTHOR> Delicious seem to have gone back to the original behavior: Middle Click opens a new tab.

But, generally speaking, developers don't really take this into account.

<comment><USER10> Small pond over here, but I don't know any developers who specifically override the middle-click functionality - though the javascript link is something even I've done.

<comment><AUTHOR> You don't specifically override the middle click. It happens when you override the click behavior -- middle click is included in that because it's still a click event, but with a slight difference in the event object being created. :-)

</comment></comment></comment></comment><comment><USER11> So many apps and sites lack this "feature". Because of that, now I need to call it what it isn't.

</comment><comment><USER12> Thank god for Greasemonkey.

<comment><AUTHOR> I know, but you can't Greasemonkey everything, eh?

I do that too, for what I visit regularly and presents said problem... but it can sometimes hit unexpectedly.</comment></comment>


Ask HN: Why do startups use third-party landing page service? - <AUTHOR>

This has been puzzling me for quite some time - I really can't think of any good reason why many startups use third-party landing page services.
My thinking is that any startup that has got to a state where they're ready to collect/offer beta or pre-launch registrations/invites ought to have all the resources to offer this on their own site.
So, why use third-party services? <comment><USER2> Two reasons I can think of:

1) Someone with no coding skills can put up a nice looking page without needing a designer or programmer. Market testing an idea then becomes a _lot_ cheaper. This happens before there is an actual "startup" with a dev team.

2) It could be cheaper/easier than building it yourself. From a managerial perspective, this could make a lot of sense. Option A is taking your dev team off the core product so they can build a landing page, integrate with MailChimp etc. Option B is paying a few dollars per month and having it done in an hour or two.

<comment><AUTHOR> Thanks for sharing your thoughts.

Further to your reason 1)

It is perfectly understandable for cases where people just want to 'market test'. What my question really concerns is not such cases but those that are more or less ready with their actual service and still use third-party landing page services.

I mean, won't it be like loosing good 'branding' opportunities for such startups?</comment></comment>


Aide: Nixon's war on drugs targeted blacks, hippies - <AUTHOR> http://www.cnn.com/2016/03/23/politics/john-ehrlichman-richard-nixon-drug-war-blacks-hippie/index.html <comment><AUTHOR> If I had a billion dollars, I'd try to develop a software tool that analyzes the behavior patterns of people in important positions in order to identify A) people who are more likely to be: amoral and destructive and B) hidden people who are likely to be strong, moral, and capable leaders.

I think it would take a team of special people who are both smart and not likely to get emotionally involved and fool themselves; decades to produce something like that.</comment>


Nasty SSL 3.0 vuln to be revealed soon? - <AUTHOR> http://www.theregister.co.uk/2014/10/14/nasty_ssl_30_vulnerability_to_drop_tomorrow/?mt=1413300796996

<comment><USER2> Dupe of [https://news.ycombinator.com/item?id=8452931](https://news.ycombinator.com/item?id=8452931)</comment>


How to write a Lisp compiler - <AUTHOR> http://stackoverflow.com/questions/3497168/lisp-compiler-design

<comment><USER2> There is also the awesome [http://web.archive.org/web/20101210113731/http://www.cs.indi...](http://web.archive.org/web/20101210113731/http://www.cs.indiana.edu/~aghuloum/compilers- tutorial-2006-09-16.pdf)

<comment><USER3> Final version of that fragment: <http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf>

It's actually mentioned in some of the comments of the SO post.</comment></comment>


Streaming data with Amazon Kinesis - <AUTHOR> https://blog.sqreen.io/streaming-data-amazon-kinesis/ <comment><USER2> There is also a jupyter notebook to accompany it: [http://nbviewer.jupyter.org/github/btel/streams_with_amazon_...](http://nbviewer.jupyter.org/github/btel/streams_with_amazon_kinesis/blob/master/Streams%20with%20Amazon%20Kinesis.ipynb)</comment>


More Unfunny Junk - <AUTHOR> http://arstechnica.com/tech-policy/2012/06/funnyjunks-lawyer-personally-sues-the-oatmeal-creator/

<comment><USER2> Watching this situation unfold is especially poignant for me. I'm also being sued personally -- despite my acting within the confines of a corporation -- by a lawyer working on contingency. Suing someone personally is one of the least scrupulous things that these litigious assholes (lawyers like Carreon) do. They do it because it's unnerving. Everything you have, plus anything you do in the future is put on the table, and clawing it back off of the table is expensive and difficult. It's a shake down, plain and simple.

Reading all the comments on HN is such an emotional roller coaster for me. Prior to my current legal situation, I held many of the same view points that I read here; e.g., "A judge is going to throw this out of court! This is absurd!" I've heard this same sentiment over, and over, and over from friends and lawyers with regard to my case, but guess what? We're about 2.5 years in to litigation, and only a handful of allegations have been dismissed. Several personal allegations are still in the complaint (a complaint is a legal filing in civil cases), so I still face losing everything, depending on the outcome of a jury trial.

The reality is that judges frequently cannot "throw this out of court" because it's not within their power. Judges can only rule on the letter of the law, and civil law is written to give plaintiffs their day in court without much consideration for the accused (yes, I'm a bit biased here). It's disgusting to watch all this play out with other people involved, but it's gut wrenching when it's your $100k+ hard earned cash that has been spent fending off this type of bullshit.

<comment><USER3> Also being sued at the moment. I'm in the UK.

It's only pre-action at the moment, so there's a chance to still avoid full on action.

I'm well aware of how real and serious this is though. That it could bankrupt me if only the slightest thing goes wrong (for me).

This is when being a bootstrapped sole founder is no fun... there is no safety net, nothing to catch you. I can't even afford representation, so I'm representing myself (nightmare!). I'm spending more time reading and researching rather than coding.

What I've learned most of all, is that right and wrong don't really matter.

If it's going to go to court, if it involves a jury (the action I'm involved in definitely would)... then all bets are off.

And all the while life goes on hold and projects are put on pause.

From the outside everyone has their views and express them frequently. This is all detached and partisan though, the reality is that it really can bankrupt you, or takeaway your future, or drain your current assets and reserves. It demands being treated with respect even if you believe your position is sound and the case unfounded.

The hardest bit, as you rightly say, is the gut wrenching fear and stress. The way it affects your sleep. The way it's hard to work or relax because your thoughts are always on the legal action. It affects everything.

<comment><USER4> You don't get a lawyer appointed when you can't afford one?

<comment><USER3> No.

Legal Aid is available for a very limited few (the most needy - which I actually would've met the criteria for being on a Ramen wage) and only in certain circumstances. The action against me includes a claim of defamation and this precludes Legal Aid.

Pro bono is available, but generally comes with many restrictions. Example: Must live within this catchment area, or be a woman victim of abuse, etc.

Where pro bono isn't restricted I've found that the lawyers are over-loaded and unable to take on any more. I've contacted a number of lawyers, and with the kindest apologies they've had to decline but then recommend someone else. The recommendations have formed a large circular loop, I've tried them all.

There are legal clinics. Attending a CAB (Citizens Advice Bureau) will generally see you referred to one. By and large these are operated by local small solicitor firms. Some legal clinics are much better funded and organised.

I attended SWLAC (South Westminster Legal Advice Clinic). Which is sole-funded by a barrister who wishes to remain anonymous. Largely these clinics deal with housing issues and fairly simplistic cases for the most vulnerable. So when I presented my case to them for advice (how to respond, interpreting the law and whether I'd got it right), they were quite challenged by it. For an hour on a Tuesday evening it's perhaps beyond their scope though they did their best.

Home insurance policies sometimes include Legal Defence cover. So I tried mine, which does have that cover. However I found that this cover is only available for a limited range of actions against you, and again does not cover anything that includes defamation.

The action against me purposefully conflates 2 things together... my role as the operator of a web site, and my role as a user of my own service. The claimant has attempted to argue that my use of my own service somehow removes the defences afforded to the operator of a site and would make me liable for the statements made by others on the site. The third party comments being the ones which are claimed to be defamatory.

There is more to it than this (but not much more), but as it may go to action I limit what I will say publicly.

</comment></comment></comment></comment><comment><USER5> The full PDF link of complaint is linked from here:

[http://www.loweringthebar.net/2012/06/carreon-v-the- oatmeal....](http://www.loweringthebar.net/2012/06/carreon-v-the-oatmeal.html)

Carreon did something quite interesting:

Carreon sues National Wildlife Federation and the American Cancer Society in order to _give them all of the money_ collected in their name, preventing IndieGoGo to take 9% of the collected money and Inman to get any cent himself and to have a chance to decide how much to pay to which charity (claiming that Inman promised to pay only USD 20,000 to both). And of course to prevent him photographing with the collected money. :) Ground: the collection of the money over IndieGoGo wasn't done according to the law that regulates collection of charities.

Moreover, Carreon claims that _he himself paid to the campaign(!)_ and wants to protect the charities and all contributors who assume that charities get everything that was paid.

Cool. It doesn't look like he didn't think about the suit.

</comment><comment><USER6> > "FunnyJunk is not suing him," Carreon added. "FunnyJunk didn't sue him. So > what are people bitching about?"

Oh, I don't know, the $20,000 'offer' which is tantamount to extortion?

</comment><comment><USER7> > "That fact that [Inman] wants to react by advocating net war against me and > accusing my mom of bestiality makes him lower than the low"

Reading the offending piece on theoatmeal.com it appears the mother mentioned is that of FunnyJunk owner rather than Carreon.

The leading text before the claimed offence:

>"You want ME to pay YOU $20,000 for hosting MY unlicensed comics on YOUR shitty website for the past 3 years?"

Considering the cheque was to be made payable to FunnyJunk (as requested in the letter), and as Carreon does not own the "shitty website" it unlikely the image depicts his mother at all but that of FunnyJunk's owner(s).

You could argue that the whole blog post is addressed to FunnyJunk, not Carreon.

<comment><USER8> :s/it appears/it should be obvious to anyone/

:s/You could argue that//

:s/Carreon/Carrion/g

<http://theoatmeal.com/blog/funnyjunk_letter>

<comment><USER7> Carrion as in carcass of a dead animal?

</comment></comment></comment><comment><USER9> Being sued by a guy who was once suspended by the Californian State Bar [1] and who said that he "stands behind myself" [2]. Not sure I'd be overly concerned.

1\. [http://archive.calbar.ca.gov/%5CArchive.aspx?articleId=83602...](http://archive.calbar.ca.gov/%5CArchive.aspx?articleId=83602&categoryId=83521&month=2&year=2007#s19)

2\. [http://www.ramblingbeachcat.com/2012/06/not-backing-down- ram...](http://www.ramblingbeachcat.com/2012/06/not-backing-down-rambling- beach-cat.html)

<comment><USER10> Just because he's an idiot and his case is baseless doesn't mean it won't be a pain in the ass to deal with.

</comment></comment><comment><USER11> I hope Matthew Inman won't be shy about asking for legal defense donations, because I don't think his fans would be shy about giving them. With any luck, a good lawyer, and a few years clogging up the legal system, this could be an expensive mistake for Carreon.

<comment><USER10> Boing Boing says he's getting pro bono counsel: [http://boingboing.net/2012/06/18/funnyjunks-lawyer-sues- amer...](http://boingboing.net/2012/06/18/funnyjunks-lawyer-sues-ameri.html)

</comment></comment><comment><USER12> He's apparently suing the charities too. WTF. I'd like to hear him explain how the charities are responsible.

<comment><USER13> There's a more detailed look at that aspect (all be it speculative until the filing is on Pacer) on Techdirt

[http://www.techdirt.com/articles/20120618/00025519366/charle...](http://www.techdirt.com/articles/20120618/00025519366/charles- carreon-sues-matthew-inman-charities-hes-raising-money.shtml)

<comment><USER12> "Carreon also hints that Inman might be responsible for someone setting up a fake Twitter account in his name which had some "offensive statements." His evidence that Inman was responsible? At the same time that the fake account tweeted some stuff, Inman posted a tweet mocking Carreon in somewhat offensive terms. That tweet did not link to or reference the fake account, but according to Carreon: "I don't know if that's coincidence. Why was he on twitter at the same time the impersonator was? I don't know.""

Ohhh man, that's gold.

</comment></comment></comment><comment><USER14> "Mom! He hit me!"

But seriously, this guy is just trying to milk his 15 minutes.

It'll all be over soon. Nobody is going to end up doing anything, and the parties involved all get an increase in notoriety.

It's like a mutual troll, and the joke is on anyone who buys into this jersey shore type hype.

<comment><USER15> _Nobody is going to end up doing anything_

Except that something has happened, as the lawyer has filed lawsuits.

<comment><USER16> Filing a lawsuit for a lawyer is a like us portscanning someone. It's not a big deal.

<comment><USER17> Unless you're the non-lawyer getting sued. Then you either need to put in time and effort responding to the lawsuit or money getting someone else to respond to it.

The idea that litigation is just something that happens is ridiculous. It's a time consuming, expensive and often very painful process for the accused, innocent or not.

</comment></comment></comment></comment><comment><USER18> I have been trying extremely hard to give Carreon the benefit of the doubt and understand his reasoning. I am beginning to wonder if he perhaps has a touch Asbergers syndrome, or something of the sorts.

In reading his remarks, he is obviously thoughtful, well read, and genuinely believes himself. But, there seems to be a stark contrast between what is going on in his head and the "real" world. Regardless, this is the online equivalent to trashy reality T.V. and I can not seem to tear my attention away.

<comment><USER19> I've met him on a few occasions. He's smart and generally the IP lawyer I've recommended to friends and associates. Kind of hard to do that now, but there you have it.

[edit: fixed typo]

</comment></comment><comment><USER20> "They say a man who represents himself has a fool for a client and a jackass for a lawyer. With god as my witness — I AM that jackass!" -- Gomez Addams

</comment><comment><USER21> Can't the Oatmeal guy counter sue for for libel? (He didn't get a horde of trolls to attack this guy, they are all acting on their own accord)

</comment><comment><USER22> Nice headline Nate. Well played.

</comment><comment><USER23> So it seems to me that FunnyJunk trolled the Oatmeal into a legal fight with a lawyer, with one threatening letter.

If there is a lesson in this, it is that some humility goes a long way. In his furious stupor with FunnyJunk he attacked their lawyer as well.

<comment><USER24> Nothing on him? _He_ has stuff on them - namely, copyright infringement (which may or may not be covered by the DMCA safe harbor). And he didn't start a war with their lawyer, it was the other way around.

<comment><USER9> If Innman hasn't registered his work with the U.S. Copyright office, then he can't sue for copyright infringement damages. Not that he can't claim copyright, just can't litigate. Not sure if he can file after someone posts his copyrighted material and then claim damages though - here's hoping he can!

<comment><USER9> Uh, why was this downvoted? The U.S. Copyright Office has this in their FAQ - see here: <http://www.copyright.gov/help/faq/faq-general.html#register>

<comment><USER25> It's not clear from that FAQ itself but if you read PDF (to which the link is broken, but here it is: <http://www.copyright.gov/circs/circ01.pdf> ), they make it pretty clear that the registration can occur _after_ the infringement. However he'd only be able to get actual damages (not statutory damages or attorney's fees) unless it's been less than three months since the work was created.

<comment><USER9> I did a bit of research, and I believe that it's covered by 17 USC § 411(c). You can only sue for copyright infringement within 3 months of the work being "first transmitted" (which I assume also includes publication), and 48 hours after the work has been "transmitted".

Not sure if there is some other part of the U.S. Code that applies though.

<comment><USER25> >You can only sue for copyright infringement within 3 months of the work being "first transmitted" (which I assume also includes publication), and 48 hours after the work has been "transmitted".

I'm not a lawyer, but I don't think 411c applies in this case. That subsection refers to works whose transmission and fixation are simultaneous, which I believe is specific to live broadcasts and performances. I'm not entirely clear on how all of the timing language there is supposed to work, but I don't think any of it applies to webcomics anyway.

What would apply, however, is section 412 below that, which basically says what I outlined above; if you want to sue for anything beyond actual proved damages, you have to have registered either before the infringement, or within 3 months of creating the work.</comment></comment></comment></comment></comment></comment></comment>