The memory safety problem isn't bad coders - <AUTHOR> https://medium.com/@sgrif/no-the-problem-isnt-bad-coders-ed4347810270 <comment><USER2> I remember when I first added ESLint to our large JavaScript codebase, and then again when I added Flow. I'm a perfectionist when I code, but it was shocking to see some of the things I'd written. Mistakes that I thought were so unlike me, but had been sitting there for months anyway, waiting to blow up.

The human brain wasn't designed to handle the complexity of large codebases. There are just too many compounding implications of everything for us to hold them all in mind at once. The very best coders miss things all the time.

Instead of seatbelts, I would compare tool assistance to aviation instruments. It's not primarily something that just catches you before a disaster; it's something that helps you make the most effective use of your mental resources. We don't ask pilots to fly commercial airliners without advanced software and dozens of readouts and displays to guide their attention and decision-making in an overwhelming sea of information. We shouldn't expect the same of programmers.

<comment><USER3> The comparison with aviation instruments is apt: I remember seeing a TV special that talked about how in the early days of aviation (circa WWI) the pilots' culture of seat-of-the-pants flying and bravado was resistant to suggestions that human senses are just not equipped to differentiate between certain inertial reference frames, of which one leads to getting into a death- spiral.

It was not until an early aviation safety pioneer came up with a demonstration on the ground (something like a spinning chair and blindfold - I forget the details) that pilots who went through the demonstration were shocked to discover they "fell for" the physical illusion they believed they were immune to.

I feel like programming is in the same state today. Especially the more C/C++ code I see in my career: I'm _absolutely convinced_ humans should just not expected to manually manage some of the things they try to do now.

<comment><USER2> C/C++, and in many cases Lisp, seem to be the most entrenched communities when it comes to the "culture of seat-of-the-pants flying and bravado". For contrast, JavaScript has as much flexibility and nearly as many foot-guns as those languages, but its community has been much more receptive to safety rails and static analysis. (Hopefully this doesn't start a flame-war; that isn't my intention)

<comment><USER4> How. Dare. You.

More seriously, JS has had its own resistance movements. TypeScript was actively disdained until, as far as I can tell, Angular switched to it. Probably partially because it was MS, but also because there was a lot of resistance to static typing despite the demonstrated safety benefits.

<comment><USER5> Doesn't static analysis requires static typing? There certainly has been a strong resistance to the introduction of static typing in the js community.

<comment> core-questions I'm not a very good developer, though I do have plenty of released-and- working-well things out in the world. I will say, it seems to me like static typing would reduce my creativity and flow and require me to spend more time planning stuff, which is not fun, and would make updates take more time as I patch stuff in all over the codebase. It's sort of the polar opposite of Ruby- style "duck typing".

Do they really help enough to be worth it?

<comment><USER6> I'm actually kind of surprised that programmers, of all people, would oppose guard-rails.

At university, it was a meme that no one's C program ever compiled the first time they tried.

I can't imagine even the best programmer in the world can avoid that kind of problem, without static analysis and static typing. Maybe you can have a 90% success rate on short programs, I'd believe that (my first-compile success rate on AoC was closer to 50%, and I was like #30 or so on the leaderboard [1]). But to do it perfectly, in real-world code? That I don't believe.

The nice thing about static typing is about catching mistakes earlier, and making it easier to figure out what your mistake was. Without the type annotation on the function, when you get a crash a few days later, it's harder to figure out "is the function wrong, or is the code calling the function wrong?" With it, those questions are automatically answered.

The best I've heard is that for short scripts, static typing doesn't help _enough_ to be worth the extra time it takes. But with modern type inference, it takes very little extra time at all.

And the extra time it does take, to write out interfaces and stuff, you can avoid in TypeScript with type assertions and `any` assertions. But honestly, it's usually worth it: It's not like you _don't_ plan out the interface; you just used to keep them memorized instead of writing them down, and then regret it a few weeks later when you want to make a change.

[1] To be fair, it was 50% because I was optimizing for programming speed for the leaderboard rather than accuracy; I'm sure I could have gotten closer to 90% if I were optimizing for accuracy. But anyone who argues that avoiding static types saves time has to accept that you make a lot more mistakes if you're trying to save time.

<comment><USER2> > it was a meme that no one's C program ever compiled the first time they > tried

Ah but see, the compiler _is_ a guard-rail. Technically, it's a static- analyzer. I don't think anyone is against making existing guard rails more helpful via editor integration; the conflict comes with adding _new_ guard rails. Take the following example:

      let foo = {
        bar0: 12,
        bar1: 14,
        bar2: 16
      }

      // example 1
      console.log(foo.bar0);
      console.log(foo.bar1);
      console.log(foo.bar2);

      // example 2
      for(let i = 0; i < 3; i++) {
        console.log(foo['bar' + i])
      }

Example 1 can be statically verified by a JavaScript type checker. Example 2 can't. There are advantages of being able to do the second thing - more code reuse, possibly less refactoring needed. But it's impossible to verify that those properties exist on that object without _running_ the code. The argument is that oftentimes, the type checking is more valuable than the loss of "creative" freedom. But it does mean limiting the kinds of things you can do.

<comment><USER7> In case anyone missed it, example 2 _is_ allowed in typescript.

<comment><USER6> It's not, not without an assertion:

[https://i.imgur.com/DJjzPDF.png](https://i.imgur.com/DJjzPDF.png)

Well, it's allowed in that it will still compile the code (because TypeScript is a superset of JavaScript), but it'll still yell at you.

<comment><USER7> Yes, without an assertion. Just change your compiler options.

[https://www.typescriptlang.org/play/#src=%20%20let%20foo%20%...](https://www.typescriptlang.org/play/#src=%20%20let%20foo%20%3D%20%7B%0D%0A%20%20%20%20bar0%3A%2012%2C%0D%0A%20%20%20%20bar1%3A%2014%2C%0D%0A%20%20%20%20bar2%3A%2016%0D%0A%20%20%7D%0D%0A%0D%0A%20%20%2F%2F%20example%201%0D%0A%20%20console.log\(foo.bar0\)%3B%0D%0A%20%20console.log\(foo.bar1\)%3B%0D%0A%20%20console.log\(foo.bar2\)%3B%0D%0A%0D%0A%20%20%2F%2F%20example%202%0D%0A%20%20for\(let%20i%20%3D%200%3B%20i%20%3C%203%3B%20i%2B%2B\)%20%7B%0D%0A%20%20%20%20console.log\(foo%5B'bar'%20%2B%20i%5D\)%0D%0A%20%20%7D%0D%0A%20%20)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> In general, in favor of as many correctness and other checks at compile time as possible. Make tools as powerful as possible. I really liked this tweet:

"What if...

\- your programming language required you to write useful docs,

\- using those docs, it checked your program for mistakes,

\- it even used the docs to speed up your program,

\- this feature already exists!

And what if it was called static typing."

\- [https://twitter.com/DWvanGeest/status/1092095822559358976](https://twitter.com/DWvanGeest/status/1092095822559358976)

<comment><USER9> The problem with that reasoning is that nearly every language with static typing also has some kind of type inference. You'll just wind up with a bunch of autos/vars.

<comment><USER10> I don't really use auto unless I'm interfacing with some templatized nightmare body of code where the typename is very difficult for my tiny human brain to interpret. Using "auto" is usually a code smell, because it means your type system is too complex for you to reason about.

<comment><USER11> This is a valid, strongly typed C# object:

var foo = {bar = 1, baz = "Hello", boo = "World"};

You get auto complete help and compile time type checking.

foo.bar = "Goodbye";

Won't compile. What would it buy you to not use 'var' and create a one time use class/struct?

<comment><USER12> It would make me ask why you need a one time use struct at all and probably remove it.

<comment><USER11> More complicated example:

var seniorMales = from c in customer where c.age > 65 && c.Sex == "male" select new {c.FirstName, c.Lastname, c.Age}

foreach(var customer in seniorMales) { Console.WriteLine(customer.Firstname + " " + customer.Lastname); }

Why would I create a class/struct for that use case?

Side note: this is why I find ORMs in most languages besides C# useless. Here, "customers" can represent an in memory List, a Sql table or a MongoDB collection and the LINQ expression will be translated appropriately to the underlying query syntax.

The "ORM" is integrated into the language and yes anyone can write a LINQ provider.

<comment><USER12> This us one of the cases where I would want you to write an explicit type for seniorMales. Reasoning about the LINQ expression is just complex enough that by not constraining its type to your expectations you can easily obscure a mistake in your thinking that would otherwise show up in the data types.

<comment><USER13> I think the anonymous type is much better. It's type safe, you can easily see how it's defined but you don't pollute the rest of your code with one-off classes that make only sense within the function.

If I had to review the code and saw an explicit type I would recommend an anonymous type.

<comment><USER12> It is not better. I don't know what type FirstName or Age is. Can Age be negative? Is FirstName an array of char or a string? Can FirstName be more than 10 characters long? It could be a double value for all I can tell from that line of code!

<comment><USER11> The select statement is projecting the Customer type from either an external data source or an in memory source. That information wouldn't be encoded into the POCO whether or not it was anonymous.

Changing select new {...} to Select new SeniorPeople {...} wouldn't give you any more information. At most if I was writing that as part of a repository class I would be sending you back an IEnumerable<SeniorPeople>.

If you were to send me an expression to use in the where clause you would send me an

<Expression<Func<SeniorPeople,bool>>

You have no idea what that expression is going to be translated to until runtime.

Either way, you are just working with non concrete Expression Trees that could be transformed into IL, SQL, a MongoQuery etc. All of the constrainsts would be handled by your data store.

You don't even know before hand whether you are iterating over an in memory list, or streaming from an external data source.

I could switch out Sql Server for Mongo and you as the client wouldn't be any the wiser.

And we haven't even gotten to the complication if the result set was the result of a LINQ grouping operation.

<comment><USER12> You are comstructing an elaborate strawman that does nothing to work in your favor. If anything, yur essay just makes it clear that it is impossible to glean the data type from the LINQ expression itself.

Yet, any code using its result will contain implicit assumptions about that data. Therefore, in order to maintain type safety, the expected type of the return value must he stated.

That type must also be independent from whatever LINQ does internally to produce that return value. Otherwise, the LINQ providers wouldn't be as exchangeable as you claim.

<comment><USER11> You also included information about "constraints" like is it a positive or negative number and string length. That wouldn't be encoded in the type. Why would I go look up the types either way? I'm using a strongly typed language, the IDE would tell me that anyway. While I am writing code, I see a red dot showing me immediately if I'm using the type incorrectly. Any assumptions that were incorrect, I would get immediate feedback.

<comment><USER12> Not necessarily. Is Age unsigned or not? This constrains the possible range of values. In other contexts, there is a lot more information inferred by the integer type used.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> > "The problem isn't the use of a memory unsafe language, but that the > programmers who wrote this code are bad."

This really goes to show how _anti-worker_ the media is even among high-skill jobs.

In my mid 20s I now mentor a bit in coding. I've worked with young devs that inherently know many of the obvious security pitfalls that have caused massive security breaches a la Equifax.

Are devs at the front of these breaches bad? I don't believe so. Many went through grueling multi-part interviews to land the position.

No, the issue a management one. Anti-worker is a meme in America and this is just another manifestation of the disingenuous "lack of tech talent" whining used to recruit more H1B.

It's also why unreleastic growth targets cause gaming tech workers to face layoffs despite record breaking sales.

<comment><USER15> Well, although it could be anti-worker, it could also be one-upmanship among programmers with fragile egos: _I 'm_ not a bad programmer; _they_ are.

And I think ego is a barrier to accepting tools that prevent errors. To accept the tool is to admit to yourself and others that you are going to make the error (sometimes) without it.

<comment><USER16> I've seen the ego issue pop up a lot in some communities. The biggest example I can think of is the OpenBSD mailing list. Any time I'd see an outsider bring up Rust or other safer languages, the overwhelming sentiment is that languages with built-in safety features are for people too stupid to write C, and that safety features restrict good coders ability to write performant code.

<comment><USER17> While that sentiment is certainly alive and well, that's not the _actual_ reason why the OpenBSD crowd is not gung-ho about Rust: [https://marc.info/?l=openbsd- misc&m=151233345723889&w=2](https://marc.info/?l=openbsd- misc&m=151233345723889&w=2)

The takeaway of that thread is that OpenBSD's "shut up and code" mantra is applicable here. If you want a Rusty OpenBSD, then start replacing pieces of OpenBSD's C codebase with Rust (you might have to fork OpenBSD for awhile in the process).

You'll probably run into quite a few issues. Most severely, OpenBSD must be self-hosting (i.e. able to compile itself) on every hardware platform on which it runs; if a modification causes that to be no longer true, then either that hardware target must be dropped or the modification must be rejected. Considering that Rust doesn't support compiling for all the hardware platforms OpenBSD supports (let alone compiling a rustc that actually does run natively on each platform), Rust is immediately a nonstarter.

</comment></comment></comment></comment><comment><USER18> Even if the problem was "bad coders", the answer is still better tooling.

The tooling we have now is pretty poor, in general. Sure, we can catch certain classes of bugs. Many bugs still occur in areas that aren't covered by those classes, even in the most robust languages.

Obviously memory-safe languages would help enormously. I also think that compilers are still in their infancy.

</comment><comment><USER19> >> I wanted to avoid spawning a thread and immediately just having it block waiting for a database connection...

>> The problem is that the database connection would sometimes use a re- entrant mutex when it was acquired from the pool...

>> with a normal mutex we would be fine, since you only one lock can exist and it doesn't matter if we unlock it on a thread other than the one we locked it from...

>> Fundamentally, we just can't have a re-entrant mutex be involved and also be able to pull the connection from the pool on a different thread than it is being used...

Truly good coders are very rare because it's not just about mastering all the available tools and abstractions, it's also about the ability to come up with abstractions that make it simple for anyone looking at the code to understand what is happening.

Good coders can write simple code to do complex things.

</comment><comment><USER20> I can see how this article might be comforting for some, but "bad coders" is still a problem. There are a lot of amateurs in this industry (even ones with years of "experience").

You can create an extremely opinionated language which doesn't give any freedom for creativity, solutions and expression, and devs will still find a way to duck everything up.

IMHO, OP saw a problem but didn't arrive to the right solution.

<comment><USER21> I don't see how the article is trying to be "comforting," or dismissing the value of skill and education. I also don't see how the `Send` trait featured in the article "doesn't give any freedom for creativity."

I read it as claiming that skill and education are _insufficient_ to prevent these bugs, and that automation is still valuable no matter how skilled the programmer is.

<comment><USER2> In a broad sense, the forces of safety and flexibility in a language tend to be at odds. Rust does a lot of clever things that push that curve some, but a big part of what makes it safer than C++ is what you _can 't_ do.

<comment><USER22> Rust is actually looser than C++ in some respects. For example, there are no type-based aliasing rules to worry about in Rust. This makes writing "type punning" style code less of a headache for me, personally.

</comment></comment></comment></comment><comment><USER15> One thing that clouds the issue here is that it really is true that better coders do write _fewer_ of these kinds of bugs. That's a real correlation and not a fictional thing.

So I think what we need to do is acknowledge that but keep it in perspective. While better coders write fewer security bugs, even the best programmers still write some. So it can't be our only line of defense.

Also, suppose for the sake of discussion it were true that top programmers did write zero security bugs. Realistically, as an organization, how would you ensure you employed nothing but exclusively these programmers? Even if you make it a top priority, you can't guarantee it.

Especially since the way you become a great programmer is by starting off as a less-great programmer and getting experience. And while you're doing that, you're churning out software which is by definition written by a less-great or not-yet-great programmer.

<comment><USER23> And to take it further, let's just consider that we as programmers have a _lot_ of work to do. The current scope of "things people are writing code for" is nowhere near the total scope of possible useful things we could be working on. We want to enable more people, even if they are not "the best" programmers, to build software, safely.

People who suggest "well, just hire better programmers" are incredibly naive and probably have never actually had to deal with the challenges around hiring programmers.

</comment></comment><comment><USER24> In fact, I think it's the case that the most consequential security issues tend to come from the _best_ programmers. That's because the best programmers tend to be the ones working on high-impact projects such as the Linux kernel. The more widely used the software, the more impact the security issues in that software have.

</comment><comment><USER25> No need to say 'bad', but there is definitely a shortage of experienced coders.

\- Competition/Compensation for experienced coders has risen sharply

\- There are many more inexperienced SDE's coming from colleges/bootcamps/etc

\- Senior titles are often given to individuals who are still very early in their careers

Now, these factors might be necessary/good in the short term as software continues to eat the world.

But, let's not pretend that the talent shortage isn't a problem.

<comment><USER26> Somewhat hilariously, the problem isn't lack of talent in programmers, but lack of talent in companies. Someone on this thread claims everyone is being stolen by top tech companies, that means it's you who needs to make your business more attractive, not that there's a shortage of coders.

Experienced programmers know they don't have to settle for less.

<comment><USER25> The two issues aren't mutually exclusive.

The supply/demand balance for experienced engineers is such that many companies are (explicitly or not) choosing to go with less experienced engineers.

</comment></comment></comment><comment><USER27> >> With a normal mutex we would be fine, since you only one lock can exist and it doesn't matter if we unlock it on a thread other than the one we locked it from.

Sorry if this is a dumb question, but I'm confused. Aren't mutexes always supposed to have ownership which implies that only the locking thread can unlock them?

<comment><USER28> > Sorry if this is a dumb question, but I'm confused. Aren't mutexes always > supposed to have ownership which implies that only the locking thread can > unlock them?

Mutexes are supposed to ensure that exactly one thread can accesses resource ("have the lock") at a time. There's no fundamental reason you can't pass the lock from one thread to another, as long as they don't both have it at once. But it may not be supported by the particular mutex implementation. It's not supported by the recursive mutexes the author was using, and I'd bet there are also non-recursive mutex implementations which don't support it. I agree with the author that it's great Rust can catch this sort of mistake.

btw, I think recursive mutexes and handing off locks are bad ideas. Both for the same reason: I want short critical sections to improve contention.

* Code that uses recursive mutexes tends to be sloppy about this; it's unclear from reading a section of code whether it even has the lock or not. (This also sounds like a recipe for deadlock when you need multiple locks.) I'd much rather structure it so a given piece of code is run only with or without the lock. In C++, I use lock annotations [1] for this. If I need something to be callable with or without the lock, I might have a private "DoThingLocked()" bit, and a public "DoThing()" bit that delegates while holding the lock. This should also be more efficient (though maybe it's insignificant) because there's no run-time bookkeeping for the recursive mutex.

* Handing off the mutex to another thread also feels like a smell that you're holding the lock longer than you need. I don't recall a time I've ever needed to do it. From the description here, it seems totally reasonable to hold a mutex while getting a connection from the pool and while returning one to it, but not between. I'd think you could get the connection, then create the new thread (passing the connection to it).

[1] [https://clang.llvm.org/docs/ThreadSafetyAnalysis.html](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html)

<comment><USER27> Thanks, this adds a whole new perspective for me wrt mutexes. I wasn't aware of all these other usage patterns for them at all.

Most of my work is in the OS, drivers and low level space, and I'm a beginner there as well, hence the short critical sections under a single owner are the only places I had encountered them before.

</comment></comment></comment><comment><USER29> The main problem is that being secure doesn't increase the revenue of companies substantially, otherwise C/C++ programs would be rushing to Rust. Still, the speed of improvement is great.

I'd love to see Firefox take over Chrome in speed and show that C++ is getting closer to being an outdated language.

</comment><comment><USER30> Contrasting C and Rust completely misses the issue. Yes, obviously Rust will do away with some important classes of bugs and security vulnerabilities, but it's got nothing to do with addressing the problem. The problem is that there are billions of lines of C out there, and it will take many decades to replace them with software that's written in a memory-safe language. The issue is what do we do with all that existing software, as rewriting it at any reasonable cost or time frame is simply not an available option. A possible solution could be something like sound C static analysis tools that can _guarantee_ no overflows etc. without a significant rewrite. The question we should be asking is how easy it is to use those tools, how scalable they are etc.

<comment><USER31> No, it is the issue. Before one can even consider the proposition that it might not be wise to write X in C, you first need to convince people that the tool (that is, C) is actually a problem. That's what the OP is targeting: people think the problem isn't the tooling, but the programmer.

The task of figuring out how to actually use the language is an entirely separate, though valid, problem. But it's not some giant mystery. The folks working on Firefox haven't set out to rewrite the entire thing in Rust. They're choosing targeted places where it works. Insomuch as I know, this has been a success.

<comment><USER30> But even if (assuming that safe languages have reached a point where they can be a suitable replacement to C in all circumstances, which they haven't yet) not a single new project is written in C from now on, it will take decades for our software to become more secure. The question is what do we do until then. There are some excellent tools that can be used, but aren't.

<comment><USER31> Who are you arguing with? Not me, because I didn't claim otherwise. And certainly not the OP. You're missing the part where people don't even recognize the problem in the first place. You have to fix that first.

<comment><USER30> I think enough people recognize the problem with C. But a rewrite is just not a relevant solution to the actual problem we're facing. It's a long-term solution, but that's not what we need _now_.

</comment></comment></comment></comment></comment><comment><USER32> TL;DR: "[Coding perfectly and anticipating any possible change to how the tools work] are not reasonable expectations of a human being. We need languages with guard rails to protect against these kinds of errors."

I definitely agree with this. And it also applies to a lot more than what the article is focused on (low-level security). It seems that right now the entire programming ecosystem seems to jump to "you just don't understand it" rather than "this should be more intuitive, or at least safer by design."

<comment><USER33> There are several quasi-related variations. Arguments against higher level languages and abstractions.

Examples:

If you have to use a garbage collected language (eg, just about any modern language) it's because you're too stupid to know how to manage memory properly.

[ various arguments against type safe languages, turning runtime errors into compile time errors ]

Higher level languages and abstractions are just bloat. [or are too bloated, etc]

Managed language runtime systems are too [ big | expensive | bloated | slow ] etc. (eg, the Java runtime, or .NET runtime, to a degree also Python, JavaScript, Lisp(s), etc)

Counter arguments:

Any sufficiently complex program will need the managed runtime, garbage collection, abstractions, type safety, etc.

Greenspun's tenth rule: ([https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule](https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule))

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

We could just write everything in assembly language, er, . . . um . . no, in hex code. And key it into the front of the machine on toggle switches with blinking lights. We could! Yes, really! So why aren't we? Why isn't, say, LibreOffice written in assembly language?

I use high level languages, runtime systems, GC, etc because I'm not optimizing for cpu cycles and bytes. I'm optimizing for DOLLARS. A long time ago, in a galaxy far, far away, computer hardware was the most expensive resource. Today developer time is the most expensive resource. Everybody is happy to have their word processor upgrade a year sooner even if it means it uses a mere extra 500 MB of memory.

<comment><USER34> The devil is in the details usually here. Bloat can absolutely affect your bottomline in many ways.

<comment><USER33> One man's 'bloat' is another man's features.

Consider both Microsoft Word and Notepad.

Which is more bloated? Which is more light weight?

Which has more powerful features, some that you don't even notice right away, like spellcheck, grammar check, etc?

Which has fewer features?

People usually complaining about 'bloat' in a high level language or its runtime are really complaining about features that they either don't use, don't understand, or don't even realize are there.

<comment><USER34> > Which is more bloated?

Microsoft Word

> Which is more light weight?

Notepad

> Which has more powerful features, some that you don't even notice right > away, like spellcheck, grammar check, etc?

Microsoft Word

> Which has fewer features?

Notepad

Users who are complaining about bloat are usually complaining about either application performance, ease of use and basic task completion complexity and/or general cluttering of the UI. Longer than expected load times can lead users to believe an application is bloated as well. It's true that all these things might be caused by something other than bloat, but these are typical repercussions of adding general cruft and also these tend to be design decisions and implementation details separate from the feature that the bloat was added for.

Developers complaining about bloat (not the ones on HN giving a critique of a github repo after browsing it for a couple minutes, but the ones who are actually knee deep in source code trying to meet a deadline for a specific feature or bug fix and to whom the bloat is literally a gravity well affecting their development pace and agility) are usually referring to previous development cycles that they believe unnecessarily introduced complex libraries for simple tasks or outsourced application logic to dependencies that are not under control of the in-house development that have unnecessarily made the code base unwieldy and created more rotten code overall from a maintainability/extensibility vantage.

In both these cases, a good early signal of detrimental bloat would be someone taking out a PR that introduces 500MB to the application. Justifying it as I'm maximizing for DOLLARS makes me think of someone who just won the lottery deciding that as a result of their net worth increasing a thousand fold, they're going to start willingly paying 1000x the price for things and also buy 1000x the amount of things. Should anyone try to convince them of how this logic is going to work out (perhaps someone stuck behind them in line at the store as they ring out the tens of thousands of grocery items, each of which provides a special value most people don't use, understand, or even realize is edible), the lottery winner calmly explains to the well-meaning individual (who happens to have just as high a net worth as the lottery winner it turns out but has achieved this over time and will have a higher net worth going forward from here) that perhaps this well-meaning simpleton just don't realize how much money has just been won.

And sure, an application like Microsoft Word that has been actively developed for more than 35 years will likely have bloat, especially when maintained to preserve backward compatibility. There's a statistical minimum in this regard. Whether or not the bloat is as bad as it needs to be is another thing.

If the development team behind Word has simply been adding 500MB here and 500MB there and defending it with "we're not going to write the new features in assembly" or "this helps me as a programmer be more productive" or "this source modification is so large because of all the features you don't know about" or "what?! we're not in North Korea" or all of the above, they are 100% creating more work for themselves and this extra work definitely comes with a price tag. In fact, without really have much insight into the general culture or incentives over there, it's a reasonable bet they've taken steps to prevent developers from introducing tech debt and bloat with this sort of defense.

Either way, it's weird to point to Microsoft Word's accumulated debt and overall decreasing performance specs as a result of multiple decades of evolving development as a reason to dismiss bloat as a non-issue. If I were a career non-bloat advocate, traveling from university to university on my canola oil powered moped I'd be pointing to Word as a reason to take bloat seriously and a reminder that the feature your adding now will likely be on the opposing force of a future person's battle with bloat and you should fight it with all the flower power you can muster or risk them tracking you down with a vendetta after they realize it was your commit making their job shit right now.

</comment></comment></comment></comment></comment><comment><USER35> Possibly sounds like a bit of a design issue to me, author /assumed/ that reentrant mutexes wouldn't be added to the code, and this wasn't documented or tested for properly...

</comment><comment><USER36> I think this argument grants too much to the C-believer crowd by presenting a case where even an infallible programmer would have ended up making the mistake. The author is arguing with people divorced from reality on their terms.

Next, you'll get counterarguments from the peanut gallery proposing that the merging the changes was just the fault of bad process, and as long as people don't make the mistake of applying a bad process, evrything would be fine.

</comment><comment><USER37> > This wasn't caught when I finished writing the code. It was caught weeks > later, when rebasing against the other changes of the codebase. The > invariants of the code I was working with had fundamentally changed out from > underneath me between when the code was written and when I was planning to > merge it.

Aside from the wider question about bad coders, I don't understand why he didn't catch this when he wrote the code. Didn't it fail to compile?

<comment><USER38> I believe the implication is that when he wrote the code it compiled just fine. There were no reentrant mutexes, so one can assume the database connection he was working with conformed to Send at that point, and it was only with the addition of the reentrant mutexes that the connection lost the conformance to Send.

</comment></comment><comment><USER39> > ... use a re-entrant mutex when it was acquired from the pool ... normal > mutex we would be fine, we unlock it on a thread other than the one we > locked it from ... re-entrant mutex remembers which thread it was locked > from, we need to keep the resource on the same thread

Sounds like a "bad coders" problem to me! This design is so screwed up that no tool or smart compiler can save you from problems here.

</comment><comment><USER40> This article hits the nail on the head. When speaking with someone who argues that we don't need memory-safe languages, just better programmers, I always like to ask if they've ever had to use a debugger/ever made a single mistake programming. What you're asking of programmers is that they never make mistake, whether it be a memory-safety bug or just a regular bug. It's simply not possible.

</comment><comment><USER41> I have argued many times it isn't the language that is the problem, necessarily. Never have I argued against tooling, though. Rather, toolchains can be added to without being replaced.

That is, my problem with this blog and most posts like it. Your tooling should not begin and end with your compiler. It is a vital part of your tooling, no doubt. But if all you did was compile it, you are playing a risky game.

</comment><comment><USER42> The problem often is needing to fight with less technical higher-ups for adequate time and resources for tooling/testing/infrastructure work.

</comment><comment><USER43> Reading the argument laid before me in this post. I disagree. It most certainly is due to negligence. Human negligence. Poor communication, and project management.

Maybe, you can't correlate this to "bad coders", however, if the coders have the issues described within this post then most certainly I would consider them "bad coders" when paired together.

</comment><comment><USER44> As a python user I understand the need for better invariant checking, but should it be encoded in types, contracts or conventions?

<comment><USER45> My goal wasn't so much to promote any specific answer, just to rebute the argument that the solution to memory safety bugs is to have better C programmers

<comment><USER10> Yes. Often the difference between a mediocre programmer and an excellent programmer is ability to use tooling effectively to understand how their program works and where it fails.

</comment></comment></comment><comment><USER5> The problem isn't bad coders for security bugs _at Microsoft_. But outside is the realm of sql injections vulnerabilities, unpatched software, default passwords left unchanged, hardcoded passwords in code, unprotected mongo dbs exposed to the internet, xss vulnerabilities, etc etc.

There the problem lies between the chair and the keyboard.

</comment><comment><USER46> The argument "it isn't language, it's bad coders" is a pretty good way to identify bad coders.

</comment><comment><USER47> Is anyone else bothered by the use of the word "coders"? Like, coding is something you do to medical records. We're _programmers_ , god damn it!

</comment><comment><USER48> What is it with these people and controlling the choices of other, quite possibly more experienced, programmers?

Why is it not enough to offer better tools and let the rest take care of itself? Or to solve problems using a tool that fits your way of thinking? Why do you need a cult/marketing effort if the language is as good as it claims to be?

The more of this bullshit I'm confronted with, the less inclined I am to ever let Rust slip into a project I'm involved in.

<comment><USER49> Because ecosystems are driven by mindshare (popularity), convenience, adoption potential barriers, public shaming (eww, that's nasty, but .. people are people), and other psychological micro-foundations. Basically it's a cold war of persuasion. Sometimes leading by example works, sometimes by showing how awesome, cool, fast, safe your shiny stuff is, sometimes it works by appealing to people's sense of the "greater good" (how many Korean, Chinese, Iranian, Saudi, etc. democratists are in secret prisons, because broken C code).

And of course there's some truth to it. Look how Py2 is still not dead, because rewriting twisted is hard. (Which no one said it was easy.) And how long it took for distros to make it the default, and how long it took for anyone to not default to it. And of course there were people even complaining about how Py3 broke all their nice code that worked before by accident.

So if collectively everyone had made a push some years ago, we would be long over. But of course organizing these things is an even bigger problem than just sitting down and firing off PRs to twisted.

</comment></comment><comment><USER50> You shouldn't rely on your tools protecting you because they won't.

I do part time work as an external examiner, sometimes for first year CS students, so I get to see a lot of silly code. Like the result of having been tasked with doing Fibonacci recursively. Which, as most of you no doubt are aware, can be done correctly in several different ways. The most basic is to simply implement it with its two base cases and run it until you meet them for every sequence. A more efficient way is to implement it with a way of keeping track of Fibonacci sequences that you have already computed, as to not do them more than once.

Both these ways work perfectly fine within the toolset, one just does it a lot better.

<comment><USER10> > This is a very basic example, but most students solve it the inefficient > way, but in most situations you'd really rather have the ones who did it > better.

I would much rather have the student who solves it the inefficient way but who runs a profiler on their code with a real-world input, determines that their naive algorithm is unacceptably slow for certain inputs, and makes an adjustment to optimize it.

If I'm only ever going to use the first 16 Fibonacci numbers I don't really care if they're brute-force computed recursively. I'd much rather spend valuable engineering time on optimizing something that actually matters. Requiring students to prematurely optimize some ivory tower algorithm as a precondition to working in the real world is precisely why we have a shortage in the first place. You should be training the students to optimize the algorithm when it needs to be optimized, and not just hiring people who've memorized a few very specific algorithms and can bark them on command during your interview.

<comment><USER51> My response would be "just use a loop and get it done so we can move onto the next task". There are only two pieces of state here. Let's not drag out the big guns and make something hard to read.

Fibonacci is too simple a case to demonstrate the power of recursion, and people have beef with the textbook examples. It has a confounding factors that actually makes recursion an over complicated solution, and not _enough_ factors to make it a good example for dynamic programming. Also it simply doesn't scale to inputs that only take microseconds to calculate.

It's like those interview questions that leave you with more questions than answers, like "are they bad at interviews or just crazy?"

<comment><USER10> Exactly. It's like a golden opportunity for me to demonstrate some engineering chops and instead the interviewer expects me to just whip out some caching implementation for some nebulous reason because that's what they would have done. If there's a real problem with either of our naive implementations the proper thing to do is to tell us what the problem is and leave us free to solve it.

</comment></comment></comment></comment><comment><USER52> The problem here is the author's development process. There's an "old" programmer adage in regard to version control: merge early, merge often. It addresses the author's issue directly.

So yes, it's not the code that's bad. It the development process. Bad (ok, fine, inexperience) developer.

[https://queue.acm.org/detail.cfm?id=1643030](https://queue.acm.org/detail.cfm?id=1643030)

<comment><USER53> That's the point.

There is always something you haven't thought of (or did wrong), once you get to certain level of complexity.

<comment><USER48> Regardless of language.

You'll have different kinds of bugs, but as long as there are programs they will contain bugs. Or the languages themselves will, or the libraries used, or the OS.

Assuming the presence of bugs/failures and providing powerful tools to deal with them like Erlang is a more realistic option if you ask me.</comment></comment></comment>


Show HN: Mammoth Tweets-Create and Tweet Reviews,garage Sales and More for Twitter - <AUTHOR>

Mammoth Tweets-Create & Tweet reviews,garage Sales & more for Twitter!<p>http://mammoth.social <comment><USER2> This has been done a lot of times. What makes Mammoth Tweets different?

<comment><AUTHOR> Hi fiatjaf. Hopefully u had a chance to try out the app. We are different because all the other apps take u to a different page to view the entire text, we are displaying everything in the Tweet itself. Very useful tool for creating quick tweets like restaurant and product reviews, short recipes, DIY tips and the list can go on. Thanks for your comments, would appreciate any additional feedback.</comment></comment>


JobboardPlugin - <AUTHOR> https://jobboardplugin.com <comment><AUTHOR> JobboardPlugin allows any business to add a career page on their website without any coding skills. Job offers can be edited via a simple backoffice and changes are applied in real time.</comment>


Show HN: kenHub - anatomy learning platform - <AUTHOR> http://www.kenhub.com

<comment><USER2> I'm not into anatomy but I have to say that I really enjoyed the demo! The way it went a bit harder each time, with the same elements really help! Great product! I liked it!

</comment><comment><USER3> Wow, how incredibly timely...

Just this morning I was griping to a friend about my frustration at the lack of modern / affordable / convenient / dynamic tools for learning Anatomy & Physiology as it's a course my SO is currently taking.

This looks really, really good. A potential godsend.

</comment><comment><AUTHOR> would really appreciate some feedback / suggestions / ideas. I know probably most people on HN are not really into anatomy. Nevertheless, it's nice to hear different perspectives. We're not going to be the next facebook, but we really hope to improve how students learn anatomy.

<comment><USER4> Uhm. One thing I struggle a bit with when clicking through and answering the questions is to see what orientation (front/back/rotated(?)) the bones have, especially around the hips. Perhaps some cards at the beginning of the lower extremity to prime that aspect could be useful. My 2 cents. :)

<comment><AUTHOR> Good point. We're already thinking about adding exactly this. Currently trying to work out how to display this visually without overloading, and also not making it too easy for people who want more challenge.

</comment></comment></comment><comment><USER5> Site looks like it will be very helpful for students/people learning anatomy.

After completing your demo, I joked with a colleague of mine that "I'm already closer to being a doctor".

Would be a great tool for universities, as well as primary and secondary schools. Remembering the names of bones in the body when I was 14 wasn't very enjoyable; this would have made it much more interesting for me. Not to mention that it harps on multiple senses which would have helped me get a better score when I was 14 ;-)

</comment><comment><USER6> Looks really promising! If I had to learn anatomy, I guess I would use your tool!

</comment><comment><USER7> I will use it for my drawing learning. Thanks.

</comment><comment><USER8> wow, spent like 5 mins on the demo and already i feel like a doctor! omfgZoMG awesome!

</comment><comment><USER9> Demo is awesome!</comment>


The Economist: Essays on transgender identities series - noir-york https://www.economist.com/open-future/2018/07/09/our-second-week-of-essays-on-transgender-identities <comment><AUTHOR> I posted one of these that I found interesting and woah, did I get an outburst from an acquaintance that had not appeared to even read the essay. It included things like, "you should talk to some of the trans and nonbinary people you know about your deep prejudice against them," and "think about whether you have some issues with feminism that you need to work out," and "every one with any knowledge of intersectional feminism or any respect for the humanity of gender-fluid individuals knows better by now so you sharing it now really says quite a lot about you that I don't want to be associated with."

Careful, everyone.</comment>


Cool Stuff the U.S. Government Has Done (and Is Doing) - <AUTHOR> http://b0ing.me/cool-stuff-the-u-s-government-has-done-and-is-doing/ <comment><USER2> This list is so bare it's depressing. Here's some more stories, but really, this page should be at least 10 pages long just for the past 12 years. Hell, reading a Noam Chompsky book or two will give you even better material going back before the 60's through the 90's.

2001-2011: A decade of civil liberties' erosion in America [http://www.civilfreedoms.org/?p=7260](http://www.civilfreedoms.org/?p=7260)

The 10 most outrageous civil liberties violations of 2006. [http://www.slate.com/articles/news_and_politics/jurisprudenc...](http://www.slate.com/articles/news_and_politics/jurisprudence/2006/12/the_bill_of_wrongs.html)

Are we becoming a police state? Five things that have civil liberties advocates nervous [http://www.pbs.org/wnet/need-to-know/the-daily-need/are- we-b...](http://www.pbs.org/wnet/need-to-know/the-daily-need/are-we-becoming- a-police-state-five-things-that-have-civil-liberties-advocates-nervous/12563/)

Obama crushes civil liberties like Bush never did [http://www.wnd.com/2012/03/obama-crushes-civil-liberties- lik...](http://www.wnd.com/2012/03/obama-crushes-civil-liberties-like-bush- never-did/)

For a brief look back in history: Who is the worst civil liberties president in US history? [http://www.guardian.co.uk/commentisfree/2012/nov/02/obama- ci...](http://www.guardian.co.uk/commentisfree/2012/nov/02/obama-civil- liberties-history)

</comment><comment><USER3> I'm on my phone so I can't really put out a long response but... > There are only about 4 hops between any 2 people on Facebook. If you take the median number of Facebook friends on one account (100) and raise it to the 3rd power, you get 1 million people every time one person is placed under surveillance.

Cool, 100^3 = 1mil. I wonder what the average number of shared friends a user has with their network. Otherwise by this reasoning there are about a million times more people on facebook than there are facebook accounts.</comment>


Building an Ember app with RailsAPI Part 3 - <AUTHOR> http://reefpoints.dockyard.com/ember/2013/01/10/building-an-ember-app-with-rails-api-part-3.html

<comment><USER2> Ember is touted as a solution for large scale applications. Shouldn't the Ember team build a large scale application that is a little more than a todo list to prove this? Tutorials do not prove that EmberJS can scale into a much larger application. Thanks for creating a tutorial though.

</comment><comment><USER3> If you have been following the series be sure to go back to Part 2 and update your code to reflect the newest changes on master branch. Even in the past week there have been some big changes!

</comment><comment><USER4> Loving this series, but it feels like waiting for v1 to be minted would have been a good call. Hopefully we can keep these up to date well into the future.

Thanks!

<comment><AUTHOR> Thanks Pete, I agree it has been a moving target. This has been mostly an exercise in teaching myself Ember and sharing that knowledge. I hope to update the posts for any changes that happen leading up to 1.0

</comment></comment><comment><AUTHOR> Source code: <https://github.com/bcardarella/ember-railsapi></comment>


The White Album Problem - <AUTHOR> http://www.erichstauffer.com/technology/white-album-problem

<comment><USER2> Digital preservation is _definitely_ a problem, but relying entirely on the cloud seems misguided too.</comment>


1st Video Ever of Moon Orbiting Earth - <AUTHOR> http://sploid.gizmodo.com/first-video-ever-to-capture-the-moon-rotating-earth-is-1480576442/@barrett?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+gizmodo%2Ffull+%28Gizmodo%29

<comment><USER2> Very cool, but I'm not sure where the article got the 8,800mph number. From what I understand the Earth relative speed is around 23 or 24 thousand mph.

Edit: the referencing article at [http://www.nasa.gov/jpl/juno/juno-earth- flyby-20131210.html#...](http://www.nasa.gov/jpl/juno/juno-earth- flyby-20131210.html#.UqeRiPRDvnF) says it got an 8800 mph boost.

<comment><USER3> Juno launched by Atlas 551 rocket, but that powered only as far as the asteroid belt. Then the Sun sucked Juno back in, effectively causing Juno spacecraft to orbit the Sun. The Earth flyby was planned as a trajectory to increase Juno's speed relative to the Sun so it can reach Jupiter. Earth's gravity causes a change in velocity to the spacecraft relative to the Sun, as much as a second Atlas 551 would give. Like a ricochet/slingshot.

</comment></comment><comment><USER4> Just amazing!</comment>


CRISPR between the genes: how to experiment with enhancers and epigenomics - <AUTHOR> https://genomics.quiltdata.com/2016/04/18/crisper-between-the-genes-enhancers/ <comment><AUTHOR> Hi. In this post we discuss CRISPR as a kind of "GPS for the genome" that allows scientists to explore protein, RNA, and DNA interactions in intergenic regions. This is a cutting edge application of CRISPR. We ran through all of the human genome to find more than 2 million guide RNAs "between the genes" and made the data publicly available. Send us your questions and comments. If you're looking for a background in running CRISPR experiments, check out our first post [https://news.ycombinator.com/item?id=10973394](https://news.ycombinator.com/item?id=10973394)

</comment><comment><USER2> If you don't want to turn-off a finicky set of science geeks please flip the stock image at the top of your web-page. It screams that you don't know the normal handedness of DNA [1], (and calls to suspicion what other basic structural genetic facts you-all might be unaware of)

[1] [http://users.fred.net/tds/leftdna/](http://users.fred.net/tds/leftdna/)

<comment><AUTHOR> thanks for catching that. we swapped out the stock image for a shot of the author's lab. perhaps not as pretty, but certainly not as misleading :)

this is not the first time i have been bitten by stock photography. i'm concluding that it's worth the effort to shoot originals whenever possible.

<comment><USER2> Graphically well done. I don't know about "misleading", but that certainly appears more authentic. As to any "shoot originals" of DNA strands we have to satisfy ourselves with crystallographic or NMR models, (nuclei and electrons being somewhat shy beasts as far as photography is concerned). One only has to depict it helixing to the right as it recedes from the viewer to be free of annoying quibbles (from me [wink])

<comment><AUTHOR> yeah, i'm not planning to "shoot originals" of DNA any time soon. just article headers at the macro-molecular scale :)

after your comment i carefully examined every detail of the picture (not just the handedness) and, as a chemist, was annoyed by enough details (especially the hydrogen bonds) to nix the whole thing.

</comment></comment></comment></comment><comment><USER3> To do some very basic research in math, the absolute minimum one should know is the basics of number theory, group theory and real analysis. By analogy, what's the absolute minimum knowledge for someone who wants to enter the field(as far as CRISPR goes) to at least be able to read papers and maybe do some labwork? Thanks.

<comment><USER4> I'd strongly recommend starting with the non-profit Addgene's guide to CRISPR ([https://www.addgene.org/crispr/guide/](https://www.addgene.org/crispr/guide/)). A great place to start and accompanying blog posts keep up to date. Also a great place to get the DNA building blocks, libraries, etc.</comment></comment>


Tumblr VC returns: Make that 1,400% - <AUTHOR> http://www.crainsnewyork.com/article/20130522/TECHNOLOGY/130529942

<comment><USER2> For anyone still interested in the returns on the Tumblr deal for both VCs and employees--here is an update (and, um, big revision) of my original "Union Square Ventures GETS 5000% RETURN!!!" story.</comment>


FBI Harassment - <AUTHOR> https://blog.patternsinthevoid.net/fbi-harassment.html <comment><USER2> I'm reminded of Hemingway, who was in the last years of his life accused of delusional paranoia, and in part because of that forcibly committed, given shock treatments, and repeatedly attempted suicide (and, sadly, eventually succeeded).

And then, decades later, it was revealed that the FBI actually was constantly watching him, following him, and tapping his phones and communications. [http://www.nytimes.com/2011/07/02/opinion/02hotchner.html](http://www.nytimes.com/2011/07/02/opinion/02hotchner.html)

<comment><USER3> hm, here the story is clear, as presented by the self declared "harassment victim": the FBI politely asked for a meeting (without making a time consuming investigation before that), several time, but still politely, and the "target" never was interested, had some anxiety attacks, and eventually made a paranoid blog post.

I would kindly advise some rest.

<comment><USER4> The federal law enforcement agency is trying to talk to someone and making it quite clear they don't want that person's lawyer present for the conversation nor even know the topic.

What exactly would it take to cross your threshold for paranoia?

<comment><USER3> That they actually search to take contact beyond a few phone calls.

</comment></comment></comment></comment><comment><USER5> The FBI is very good at getting you to trip up when facing questioning and using that against you.

Isis is wise to stick with a lawyer but the 'approach her in public without a lawyer' smacks of using this 'lying to the FBI' tactic to get her charged as the first step if the FBI is targeting her for some reason.

See this from Popehat (Ken White)

[https://popehat.com/2013/05/01/shut-up-i-explained-mostly- po...](https://popehat.com/2013/05/01/shut-up-i-explained-mostly-pointlessly/)

<comment><USER6> Man that was a chilling reminder. Nothing good comes from saying anything to law enforcement when they come calling.

</comment></comment><comment><USER7> Oh by the way, the entire time this page has been open in your browser we've been using you as a FlashProxy to connect Chinese people to Tor. Thanks!

<comment><USER8> Seriously? That's outrageous.

<comment><USER9> And likely illegal.

<comment><USER10> Illegal where?

<comment><USER9> In the US.

<comment><USER11> Why?

<comment><USER12> Quite possibly unauthorized access.

<comment><USER11> Who is not authorised to access what?

<comment><USER8> When you visit a website that downloads Javascript to your computer, you are giving the site an implied license to execute code reasonably related to the website. If they go off and use that capability to do something else, you've exceeded the scope of that implied license.

It's like going to a kitchen remodeling store and hosting a dinner party there. Yes, they invited you in, but the scope of that invitation was looking at new counters, not hosting a party. That's trespassing. In the computer realm, it may well be a CFAA violation.

<comment><USER11> Okay, but then you must believe that online advertising, as practiced today, is also illegal.

<comment><USER13> What advertising burns up my bandwidth indefinitely without informing me whatsoever? This is an obnoxious position.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> At the risk of not taking it seriously enough, does this woman sound a little overly paranoid to anyone else?

They call and ask to speak with her, and suddenly she's talking about flight records and backdooring software... admittedly the stuff about having teams in multiple cities looking for her was a little disconcerting, but if they wanted to arrest her or coerce her into something shady they'd have done it, and probably quickly and not very politely.

I'd have just assumed they were investigating a case that was tor related and either 1. Didn't know enough to understand that she wasn't involved just because she contributed to the software or 2. (less likely) Wanted her opinion on some of the tech specifics of how Tor works.

Maybe just show up to meet them, with an attorney (of course!) and if they start asking anything serious the attorney tells you to shut up and you leave.

It sounds to me like the agents were doing their jobs in their normal, properly secretive if a bit ham-fisted way, and this person totally freaked out.

<comment><USER15> Her name is literally Isis, and she is a core developer of Tor. If those aren't enough buzzwords to get the FBI swarming around her house, I don't know what is. I don't blame her for being paranoid, but I don't understand why she _refused to talk to them at all._ From the post it seems like she was okay with a phone call, but they wanted to meet her in person. So perhaps she was scared of being detained. That makes sense I guess, but if they really wanted to detain her, it would have been easy to do at the airport.

<comment><USER2> > but I don't understand why she refused to talk to them at all

Talking to law enforcement is the job of your lawyer. If law enforcement refuses to talk to your lawyer, is it really that far-fetched to think they may want to do other things outside the bounds of the usual legal process?

<comment><USER16> I can't up vote this comment enough. Law enforcement are not your friends and they are not on your side. My very close friend's dad has been a cop for 35 years and he has told us this over the years. Want another opinion?

See this from a cop and a law professor [https://www.youtube.com/watch?v=6wXkI4t7nuc](https://www.youtube.com/watch?v=6wXkI4t7nuc)

<comment><USER17> The author links to that video in the article, which shows that she's aware of the games that are played.

They're using bully tactics. Did they have to show up on her family's doorstep? No. Did they really have people watching out for her in five cities? No. Was there any reason they couldn't communicate through her lawyer? No. Did they have to speak to her in person? No. Do they have the right to circumvent her legal counsel (or make threats to do so)? No.

They're just playing mind games, like they're trained to do. Spooks gonna spook.

</comment></comment></comment></comment></comment><comment><USER18> Former interviewee of Mark here. His modus operandi is subtle harassment. Isis' lawyer should file a complaint with Mark's boss.

<comment><USER19> Care to speculate whether this is a tech savvy agent who wants something interesting or a clown who will have misunderstood everything?

</comment></comment><comment><USER20> Well, there has been no harassment. Leaving a card on a door or having a phone call with the lawyer is the daily work of law enforcement. Most of this story is made up in the mind of the author - from the motive they had, to the fact she would have been detained any minute.

<comment><USER21> Her post is a good illustration of the chilling effect created by minimal but specific attention from essentially all-powerful state agencies. That the potential events of which she was concerned haven't yet occurred still leaves them as effective inhibitors of legal conduct and a source of gratuitous distress.

<comment><USER22> a.k.a. Tyranny.

</comment></comment></comment><comment><USER23> " Should I be worried about what happens to me when I return? Why is the FBI trying to make a developer of an open source encryption tool feel unwelcome in their country of origin? Should I try to get a different citizenship? Is my family safe in the US? Should I worry about the FBI raiding my parents' house and shooting our family dog? Should I worry about FBI agents stalking and harrassing my mother?"

So, exactly like Soviet Union then? I guess you can't learn anything from history if you haven't actually lived through it.

<comment><USER24> >> Should I worry about the FBI raiding my parents' house and shooting our family dog?

If you read the news, you should be afraid of this, even if you have never broken a law in your life.

<comment><USER25> There are about 70million pet dogs in US.

How many have been shot by FBI? The Puppycide documentary kickstarter guessed at one dog death every 98 minutes, which makes about 5300 a year.

That's too many, but it's not something that pet owners should be worrying about.

EDIT: (Compared to the say 1.2 million road traffic deaths of pet dogs each year in the US.)

<comment><USER26> The moment that a weapon crosses the threshold of a building that was, moments before, weapon free, the odds of a pet dog, or a person, getting shot go from 0 to non-zero.

Personally, cops make me nervous. Whenever I'm on the subway and a pair of cops end up in the same car I'm in, my odds of catching a stray bullet go up. Before the cops got on the train there were (very likely) 0 guns in the car with me, after they got on, there are (at least) 2.

You can't get shot if there aren't any guns within range. Call it irrational, but the only place where I can be reasonably comfortable with guns is at a well managed shooting range.

<comment><USER25> Sure, I agree, I think gun ownership is weird and horrible, and I wish the US would dis-arm. You'd see a dramatic drop in completed suicide for one thing.

But even in the incredibly violent US, with poorly trained gun happy police, only 5,500 dogs are killed each year. That's way too many, but parent said "you should be afraid of this" \- no, you really shouldn't. If you own a dog you should be far more worried about the risk of the dog being run over; or of the dog being over-fed (half of American dogs are overweight or obese) or of all the other far more common stuff that kills dogs.

(All these numbers are estimates, so who knows how good they are).

</comment></comment></comment></comment></comment><comment><USER27> So, here's some things.

1) The FBI are monumentally stupid. In a technical sense, and in a practice- of-law-enforcement sense. They're beat cops without the experience and too much power over red tape. Generally expect them to treat you like a rookie detective who read a manual about tricks to coerce consent from perps.

2) Neither warrant canaries, nor giving the FBI information on how to track your work, is not going to help you. They don't care if you do cooperate, they only care if you give them something.

3) If they really wanted to abuse you and your family, they would just do it. There is no point in thinking up these scenarios and putting yourself through hell. You have to move on with your life. If you think the gov't might be interested in you, sure be prepared, but unless you're going to spend your time working connections and getting government influence to have leverage in a future confrontation: let it go.

</comment><comment><USER28> site down here

mirror: [https://github.com/isislovecruft/patternsinthevoid/blob/mast...](https://github.com/isislovecruft/patternsinthevoid/blob/master/content/hacking/fbi.md)

</comment><comment><USER15> Did anyone else notice she's very explicitly pointing to her warrant canary that she's maintained for over a year? Also, the Tor project retweeted her canary tweet.

The canary is from Feb 22...

[https://fyb.patternsinthevoid.net/canary.html](https://fyb.patternsinthevoid.net/canary.html)

<comment><USER29> Her canary updates bi-annually only though.

</comment></comment><comment><USER30> This certainly sounds like a very stressful situation, and I really hope the situation resolves in such a fashion as she no longer feels threatened.

That said, I don't understand why, once she was in Germany, she didn't call the FBI at that time to find out what the heck was going on. Since she's not on US soil she doesn't have to worry about the FBI physically tracking her down, and if the FBI asks questions she doesn't want to answer she can hang up. Worst case I can think of is the FBI asks a question with at least one potential answer that would incriminate her, she feels uncomfortable answering for whatever reason, and the FBI then interprets her ending the call there as suspicious (I don't believe the right against self-incrimination applies in this particular circumstance).

Edit: As mentioned in another reply ([https://news.ycombinator.com/item?id=11631827](https://news.ycombinator.com/item?id=11631827)), I'm not suggesting that she should give information to the FBI or otherwise cooperate. I'm suggesting she should seek information from them, with the proviso that she will not be answering questions (and therefore her refusal to answer after being asked a question will not be suspicious). Heck, since the FBI indicated they don't necessarily believe her lawyer represents her, she could just call them and say "Please talk to my lawyer <insert name here>, he represents me in this matter" and hang up.

<comment><USER31> The police are not your friends. They will leverage any slip up you make to squeeze you in to doing what they want. Thus the lawyer. SHe works for Tor. Could you imagine what they might squeeze her to do?

Also, they're not going to say anything over the phone that they aren't willing to say to the lawyer.. so no real point in calling.

<comment><USER30> They already said earlier that they would accept a call. They changed their story to saying they'd really prefer to meet in person, but since they already admitted they'd accept a call then that should still work.

In any case, the point isn't to cooperate with the police. The point is to just find out what the heck the FBI actually wants. Finding out what they want doesn't mean actually giving them what it is they want. She could say upfront that she's not answering any questions and just wants to know what they want from her. If they won't tell her under those conditions, well, she's no worse off than she is today.

<comment><USER32> No, don't do this, ever. Never think you are going to outsmart a professional doing his/her job - be it feds or police, you are going to lose. Imagine this happening in your line of work, it'd be absurd thing to happen, right?

In general, don't take health or legal advice from HN. There are other places for that, and there is money to spent well.

<comment><USER30> This isn't about outsmarting anyone.

</comment></comment></comment></comment></comment><comment><USER33> > I still planned to continue moving, of course, but now things would need to > go to different places, and by different means.

> I started having panic attacks, thinking that I'd need to get myself and > literally every object, including electronics, that I cared about accross > the border

> Every device I owned could be compromised, I'd lose all my data, my pictures > of family and loved ones, fiction I'd wrote as a teenager, and Lisp I'd > wrote as a child

> I'll admit I actually cried, not knowing when I'd hug my mom again

> I didn't talk to anyone who wasn't already in regular contact with me, > fearing I might endanger them

> I didn't talk to anyone who wasn't already in regular contact with me, > fearing I might endanger them — some thug might show up at their mom's door > or make some threats to their lawyers — and I didn't want to risk harming > people I care about. It hurt to not tell my friends what was happening. I > felt gagged and frightened.

> I wanted to read the number theory papers I'd just downloaded and play with > a new pairing-based cryptography library I'd just been given the source to, > but I couldn't do those things either, simply because I was too stressed out > to think straight.

None of this is the reaction of a healthy person. Panic attacks? Not talking to people for fear of endangering them? Crying herself to sleep? Not knowing when she'd hug her mom again???

It's also worth noting that the quotations of the FBI agents include all of their tics and stutters. This is often done in an effort to discredit the person being quoted.

This is not harassment.

<comment><USER2> > "But... if we happen to run into her on the street, we're gonna be asking > her some questions without you present."

That sure sounds like intended harassment to me.

<comment><USER34> The person can always refuse to answer questions without their lawyer.

<comment><USER2> If someone has already directed law enforcement to their lawyer, attempting to talk to them in person without their lawyer present is overwhelmingly likely to simply result in being referred to that lawyer again. The result is wasted time and an unpleasant experience.

The law enforcement in question would already know this, so pursuing it anyway is harassment, regardless of it being legal.

</comment></comment></comment></comment><comment><USER35> This blog post shows how to absolutely TERRORIZE a core developer using: 1\. Bussiness card of an FBI agent, with a "call me" text hand-written on it 2\. A phone and 10 minutes of time

If you have a few business cards and an entire afternoon, you can nuke entire projects (?) Something is not right here!

If you hurt your leg, you go to a doctor and he fixes you up. There is no shame in going to a doctor. If a postcard and a phone call can ruin your life, you can ALSO go to a doctor, and guess what, he will fix you up in that case as well! Try it. Go for one session with an open mind and (unless you have a really horrible doctor) it will help tremendously.

</comment><comment><USER36> The blog seems to be down. Does anyone have a link to a cached copy?

<comment><USER37> [http://archive.is/loVuK#selection-389.255-409.27](http://archive.is/loVuK#selection-389.255-409.27)

</comment></comment><comment><USER38> As a web developer wanting to dive into cryptography, where should I start? A goal of mine is to to contribute to an open source project in the next 6 months.

<comment><USER39> Did you finish cryptopals?

cryptopals.com

<comment><USER38> I had not even started, but now I have. Thank you!

</comment></comment></comment><comment><USER22> Her canary is from 22 Feb 2016.

What conclusion should I draw from this??

</comment><comment><USER12> This blog post is complete bullshit.

It could've been fit in a single tweet "FBI TRYING TO CONTACT ME. DO NOT KNOW WHY. IM FEELING VERY EMOTIONAL"

The FBI wants to talk to the author, and she has avoided them. That doesn't mean the FBI is harassing her, they haven't even taken any active measures against her.

</comment><comment><USER40> Maybe it was something to do with ISIS being her username? Just speculating though.

<comment><USER41> I think that is genuinely her Christian name. Ancient Egyptian Goddess of health, marriage and wisdom.

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

<comment><USER42> And it is a _beautiful_ name. Too bad the name got marked with a bad reference pretty much forever now.

I remember elementary OS wanting to name their 0.3 version Isis. Unfortunately, they had to change it because that was the time when ISIS was all over the news. All of their releases so far got named after ancient god: Jupiter, Luna, Isis (that got renamed to Freya) and the next edition is going to be named Loki.

I got really sad when they announced the change of the name because elementary OS is my primary operating system and I really liked the name Isis before all of this happened.

</comment></comment></comment><comment><USER43> this is totally tangential, but reading this "Personal or political views presented within this post absolutely do not reflect those of my employer(s), client(s), and/or legal counsel" reminded me how i've recently decided thats a silly thing, or at the very lease needs to be qualified. we all influence, and are influenced, by those around us. culturally, politically, etc etc. and if we work somewhere, our political and personal views will influence the company, sometimes in little ways, sometimes in bigger ways. i know the statement is meant like "the company does not formally hold my political opinion", but i guess i think the formal position on anything is secondary to how things shake out in practice.

<comment><USER44> So what? I'm sure my family and I influence each other's political opinions as you say, but my opinions certainly don't reflect theirs.</comment></comment>


New Intel Spectre variation to be announced - <AUTHOR> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639 <comment><AUTHOR> I just received a warning from a hosting provider that there are two new Intel Spectre announcements in the works.

[https://cve.mitre.org/cgi- bin/cvename.cgi?name=CVE-2018-3640](https://cve.mitre.org/cgi- bin/cvename.cgi?name=CVE-2018-3640) is the other one.

Rest of the announcement:

" Leaseweb is aware of the announcement made today by Intel regarding the two security issues in Intel products designated Spectre-NG (comparable to the Spectre vulnerabilities made public earlier this year). We are closely tracking the situation as it develops, and working together with our vendors to evaluate our infrastructure and customer-related environments.

WHAT IS AFFECTED? This issue affects most CPU models. Both vulnerabilities are so-called "side channel" attacks, which allow an attacker to access memory without permission and can lead to unauthorized access to data on the system. The vulnerabilities are particularly relevant for multi user and virtualization/Cloud systems.

These are local exploits which means that remote attackers are unable to take advantage of this problem, and an attacker needs access to the system itself. There are no known / public exploits to this problem yet, but Intel was able to replicate the issue, which means the attack has been confirmed, but no exploits are as of yet available in the wild.

WHAT ARE THE NEXT STEPS? Intel is working with their vendors on making a fix for this problem, which will include a solution on the operating system level as well as a microcode patch. The first patches are likely to be available in the last week of May.

Operating system level fixes will be available quickly, notably from Microsoft, Canonical, Red Hat and VMware. We expect Debian, CentOS, and other vendors to follow quickly after that.

Leaseweb will start patching and updating systems as soon as fixes are available, and we will notify customers if there is any impact to their service. If you are a dedicated server customer, please ensure to keep your operating systems updated in the following weeks, and keep an extra eye on critical or security updates from your OS vendor."</comment>


CloudFIRE – Decentralized Open-Source Replacement for Cloudflare and Pubnub - <AUTHOR> https://github.com/coinkite/cloudfire <comment><AUTHOR> I think a replacement for cloudflare is important because Cloudflare can censor any site (and they do if their CEO wakes up in a bad mood) and their captchas make it impossible to use tor.</comment>