The 80/24 Rule - <AUTHOR> https://blog.ploeh.dk/2019/11/04/the-80-24-rule/ <comment><USER3> I have started to move in the other direction for C#. A long sequence of code that flows in one direction should be kept in one method if possible. Good reasons to break up a method are things that are _not_ readability but other things such as re-use testability. If the methods are only called in one place and not performing a piece of work that is testable, then they shouldn't be methods.

But

       DoAll() {
         DoA();
         DoB();
         DoC();
       }

Is simply not better in any way than

        DoAll() {
          // A
          ...
          // B
          ...
          // C
          ...
        }

Private methods will blur this somewhat. The key to readability is not having to jump around. Ideally of course methods are both short _and_ reusable, readable without jumping etc, but given the choice between a 100 line method or the same code broken into 10 methods of 15 lines each (yes, more lines), where each method is only called once from a main method, I'd rather read the first. The 100 lines might indicate some _other_ problem with the api (a chatty Dx12/win32-like API for example).

This obviously varies from case to case, I think one of the worse things a team can do is enforce hard rules that invariably lead to "style rule-induced damage".

<comment><USER4> I very much disagree. The in-lined version can easily be confusing, harder to change, harder to test and even error prone.

By splitting code into functions you have a more well defined scope for each of them and they can be understood in isolation.

You also get the benefit of getting a quicker overview (if you care to name your functions well) in your calling function (DoAll).

Then there is the issue of maintainability. When I have to change something in a big (in-lined) function then I'm much more anxious about the whole context. My instinct is often to refactor it into smaller pieces so I can narrow down the changes and isolate them correctly and exactly from the context.

This might very well be a thing of preference?

<comment><USER5> I suspect this is mostly preference.

Personally, I really dislike pulling everything out into small methods - <USER2> literally forces you to remember a crap load of names. I find remembering names to be extremely high cognitive load.

Worse, the names WILL lie to you. Especially if you weren't the one doing the naming.

So not only are you forced to remember a bunch of labels that better fit someone else's mental model, you're still not off the hook for understanding what the code in those tiny methods is doing, and considering how it might impact the task at hand.

So now you're stuck with twice the work - Remembering which name goes with which functional piece of the task at hand, and then remembering how that name actually accomplishes the task (the actual code).

Worse, because functions are moved out of line, I find it much harder to jump between relevant bits of actual "doing things" code.

Basically - The ONLY time I want to split code off into named chunks is when the alternative is copying/pasting code somewhere. I look for code which is getting reused and break that out.

The in-lined version is faster to read, faster to understand (and by understand I mean REALLY understand, not some hand-wavey "I trust this name" understand, but as in you actually know the operations and changes to the system that the call will result in)

The downside to inline code is you have to actually read it. I find a lot of the folks who really like short methods struggle to parse the language they're working in and fall back on the name without actually understand what the chunk of code does. But I think they're also the folks who have a better memory for names.

<comment><USER6> Reducing cognitive load by breaking things into digestible pieces can be hard, and at times it's hard to say if option A is better than option B, but it is _not_ preference.

If `extractId` is an eight-step process that's only used once, but I step over it and check locals to find that the variable was correct before the call, and wrong after, then I just found my problem. That would be faster than stepping over each step to find the problem -- basically the debugging version of divide and conquer (for finding the solution, optimal would be binary search, but for readability and maintainability, that should _not_ be the goal).

Another example is if I have a boolean condition that incorporates extremely complex logic but is only used once, if I assign it to a variable called `nameWasPreviouslySet`, that is easier to read and understand, and if I'm debugging and expect `nameWasPreviouslySet == true` at _this_ point, and it's not, then I've figured out the bug is in setting `nameWasPreviouslySet`. So DRY shouldn't be the only reason to refactor -- refactor for readability also.

<comment><USER5> Ok, so lets take your example at face value. You have an extremely complex step of code that you only call once.

Already, you have invariants that are easy to break. You're assuming it's only called once. That's relatively safe if you're inline, that's bogus as soon you've broken it out into a named function.

Some other dev WILL come along and re-use your helpfully broken out code somewhere, and that invariant no longer holds.

Even assuming no one else has re-used it, what ensures that the problem is actually in that method? Particularly if that method itself calls out to many small named methods.

So you have some complex code that does something, but the "things" it does are call out to other small chunks of code.

so now you have

DoComplexThings => { DoSubThingA DoSubThingB DoSubThingC DoSubThingD DoSubThingE return }

So you're back to binary search - The problem is in there somewhere, but "in there" is actually calls out to many other functions again. Which one is broken?

And wait! DoThingD got changed at some point and will now fail if you run it before DoThingC, but there's nothing in the names that tells you that.

So you have hidden deps between chunks of code that are all trying to accomplish a single goal.

If you're debugging that, you almost certainly have to go through all the code in that method again, except you have to page back and forth in your editor to get the meaningful pieces into view. All so some OTHER dev could give it name that was meaningful to them, but likely not that helpful when you're debugging because the mental model they have of the system resulted in the bug in the first place.

\---

Now, rant aside - I think we agree more than we disagree, I think good names matter, and I think there's a lot of wiggle room around when a thing should be broken out.

But if the code is trying to do a single thing, and it's not re-used, I'll take a single cohesive method over 8 tiny abstractions ANY day.

<comment><USER6> > if the code is trying to do a single thing

What is a single thing? Login? Initialize db? One line of code, 3 lines of code, ...

If you have 100 lines of code and 6 nestings, even if none of that is or, as far as you can tell, should ever be re-used, you should break that into smaller, digestible chunks of DoSubThingA, etc.

It's kind of an aside, but you mentioned e.g. `DoThingD` got changed or "some other dev WILL come along" \-- if some other dev comes along and doesn't bother to check where and in what context `DoThingD` is being used, and changes it in a way that breaks `DoThingC` or `DoThingE`, they aren't doing their job. Particularly, if `DoThingD` wasn't written to be re-used, and they just use re-write it and use, particularly in a way that breaks its original invariance... I would be having strong words with that developer.

</comment></comment></comment></comment></comment></comment><comment><USER7> The question is, why didn't the author write his article in smaller 50-word block tree, conveniently connected by a-hrefs and/or separated to multiple pages, all links well named.

It is a straight wall of text instead, that is hard to follow and using implicit references all across.

<comment><USER8> Actually, the more technical a text is the more likely it is to contain references and (sub)headers. Also, I certainly would not describe this text as a 'straight wall of text'. A straight wall of text would be a text without paragraphs or headers.

<comment><USER9> Breaking text up like that is the equivalent of chucking some line breaks in a function and a few comment headings, not creating a bunch of pointless functions and scattering them around the file (or codebase).

</comment></comment></comment><comment><USER10> I've seen this idea cargo-culted way too often. There's nothing wrong with long functions. In fact, long functions are often easier to grok than ones split apart into dozens of pieces.

Create useful abstractions. Don't create abstractions for the sake of creating abstractions.

<comment><USER11> I share your sentiment. Some of the programmers I've worked with would build functions for every thing within a larger function.

Need to chunk the data? Function. API Call? Function. Parse the response? Function.

So I asked: "Are you ever going to use these internal functions for anything outside of this function?" And their response was: "No, but it makes debugging easier."

It does not. It makes it exponentially more difficult. Maybe I just work with too many terrible programmers...

<comment><USER12> One middleground option if you have a long function but also want to break it into chucks for easy readability: In C# and some other languages you can put braces around a block of code without actually having any condition on it.

Or just throw some big comment headers in.

<comment><USER13> VS Code has regions, which look like preprocessor instructions but I don't think they actually have any affect on the code. They do, however collapse while providing a nice label.

<comment><USER14> Jetbrains IDEs have those too

<comment><USER13> Thanks, I've been using PyCharm for years and didn't know that.

</comment></comment></comment></comment></comment></comment><comment><USER15> > Novice Programmer: "Putting all this code in one function would be easier to > write."

> Master Programmer: "You fool! You can't just stuff all your code into one > function because it's easier to write!"

So the Novice Programmer separated all the code out into different functions and showed the results to the Master Programmer.

> Master Programmer: "You fool! Why have you broken this out into different > functions when it all belongs together in the same function?"

And in that moment the Novice Programmer achieved enlightenment.

<comment><USER16> > achieved enlightenment

I haven't. What are you saying?

<comment><USER17> I believe that it means that some things aren't always very clear cut, and one could make a reasonable argument to do it either way.

<comment><USER16> The best I could interpret it is to have it both ways; break it down into small private functions, then nest (edit: encapsulate) these in a larger one where they can't be seen by anyone else.

<comment><USER15> Both and neither.

It depends on you and your team, the project requirements, the rest of the codebase, and so many other things. The choice you make is less important than _why_ you make it.

<comment><USER16> Maybe the western approach of actually giving useful information beats the zen approach of confusing the fuck out of people.

<comment><USER15> You're going to hate reading this: [https://www.mit.edu/~xela/tao.html](https://www.mit.edu/~xela/tao.html)

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I would argue exactly the contrary: [https://redbeardlab.com/2019/02/07/write- long-function/](https://redbeardlab.com/2019/02/07/write-long-function/)

Very seldomly the problem is to understand one function, most of the time the complexity is in understanding how everything fit together. Having dozen of little functions does not help at all.

On the contrary having few, well designed, well interfaced functions that takes care of all corner cases and just work helps tremendously. Those functions are almost always long.

</comment><comment><USER19> I find this an artificial metric. Normally code just gets split organically as you notice that you can reuse this bit here or that bit there. Some functions won't split and that's OK. (Reference to the 2k-plus-line main interpreter loop in Python.)

Actual reuse is the primary drive for this. Trying to adhere to some other concept instead is dangerous. I've lost countless hours trying to make code "properly object-oriented", or "isolated", or "pythonic" until I realized it's all a delusion.

<comment><USER20> It wasn't always artificial. When you really were working on a screen that showed 24 lines of 80 characters, it was a good practice to be able to view your entire function at once. That was especially important since at the time we lacked tools like debuggers, and so there was more focus on being able to find bugs by reading.

Today the hardware improvements make those numbers obsolete, but the numbers were picked in the first place because a "screenful" was picked to be a reasonable amount of information to handle at one time -- not just for code, but also for code.

I was never religious about the rule, but it still feels like a good code smell to keep an eye on. If a function gets too big, I start wondering if it's really still doing one thing.

</comment></comment><comment><USER21> I prefer 120 characters of width, modern monitors are wide-screen, I think it's ok to adjust a little to accommodate this reality.

<comment><USER22> You don't even need a wide-screen monitor for that. I like to turn my coding screen 90 degrees, to portrait mode, to get more vertical space and still can see the line at 120 characters.

I call it the TIE-fighter setup, the screen in the middle is in landscape mode and the two others are in portrait mode, gives a lot of screen-space without having to turn the head much to see it all

<comment><USER23> > I call it the TIE-fighter setup,

I have the exact opposite setup, with the vertical screen in front of me. How would you call that setup?

<comment><USER24> Satellite setup! (side monitors are solar panels?)

<comment><USER23> not as awesome as "TIE fighter setup", but it does the trick

</comment></comment></comment></comment></comment><comment><USER25> This is one of those things that is older than the printing press. We learned a long time ago that there is a more or less optimal column width for text and it's based on the physiology of the eye. I haven't been able to find a great reference online in a brief search, but this[1] has the basics.

[1] [http://maxdesign.com.au/articles/em/](http://maxdesign.com.au/articles/em/)

</comment><comment><USER26> I first saw this in the Linux kernel style guide back in the 90s. The idea was that you should be able to read a function without scrolling. So that meant it would fit on screen in a standard terminal. It's a bit extreme for practical use, but the concept is important to keep in mind.

I was helping a Jr programmers with a code review a few months back. He'd been told that a particular chunk of code was "unclear", with specific emphasis on 4-line bit of logic in a 30-ish line function. He had no idea how he could make the code "more clear". It did what it did; the logic was a bit complex but the code was exact and correct.

The solution: factor out the 4 lines of code into a function. It was only ever called from that one place, but by making it a function you give the code a name, with clear inputs and outputs. Nothing changed about what the code did, but it became a lot easier to reason about.

It's a helpful lesson that generally doesn't really sink in for the first few years.

<comment><USER27> Do you think that's a good practice? I have always been conflicted.

For one, writing a new function isn't just for vanity--it changes the actual machine code generated (unless an optimizer is smart enough to fix it). I don't like changing the actual operation just to make a program more readable.

But sometimes it just is easier to move a bunch of crap to a function and abstract it away.

<comment><USER28> > For one, writing a new function isn't just for vanity--it changes the actual > machine code generated (unless an optimizer is smart enough to fix it). I > don't like changing the actual operation just to make a program more > readable.

Inlining should, but does not always prevent this. Because compilers have all kind of limitations when they are no longer able to inline. From what I read I have got the feeling it got better in recent years, but I have not studied the issue.

That said for > 99% of the code written a function call has no measurable performance impact. Few of us write code in a hotspot of an operating system or a very tight loop of some number crunching application. A bit more than 1% might possibly write vectorized code, but still the huge majority never does.

Programming suffers much more from bugs than performance issues. And if there are performance issues, they are typically because of improper algorithms, wrong I/O patterns or high memory consumption, not because of a couple of additional function calls.

</comment></comment></comment><comment><USER29> Terrible advice. A method perform one coherent action... if that action takes 1000 lines of code due to some wacky business logic, then the function should be 1000 lines, not split into multiple functions just for the sake of some weird rule.

<comment><USER30> did not agree about it, Wacky business logic can break up into small function or smaller business logic. The way to keep track in a huge function will make your brain struggle/question in middle of way. The good engineer need to find out where need to break. We need write code for readable and archive business logic.

</comment></comment><comment><USER31> Or, to understand this one level deeper: Functions/methods should do one thing, and do that one thing well. In general, each of those one things should be smallish things that you use to compose bigger things, which also do one thing and do it well.

24 lines is as good a rule of thumb as any, as long as you're not actually counting the lines. Your goal is flow and readability (ultimately: maintainability), not some countable metric.

</comment><comment><USER32> John Carmack's take on this seems a lot more sensible to me: [http://number- none.com/blow/blog/programming/2014/09/26/carm...](http://number- none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html)

</comment><comment><USER33> There is a lot of disagreement here with the ideas presented, but i think most of the arguments are taking the ideas too literally and extremely... as with any advice there are no hard and fast rules.

I have some guiding principles similar to the author which make me end up essentially doing the same thing (I also like to keep under 80w and roughly 24h, but there are many exceptions)... yet my principles are seemingly contradictory e.g: 1. minimalism, 2. holism.

Notice that they are not imperative, they are merely principles / desirable attributes, by minimalism I usually mean what the author is talking about but in a more general way, keeping small code blocks is one such desirable... but this does not mean split everything up into micro functions that cause a horrible nest of layered calls, because that goes against the principle of holism... this I believe is also similar to what the author wants - holism is part of legibility, whereas reducing your function scope and interface are only immediate legibility of the local code.

Ultimately what i'm talking about is balance, which is why I think it's better to present these ideas to people as principles rather than imperative rules which can be followed rigidly (wrongly).

</comment><comment><USER34> If his point is that you should dogmatically reduce long functions into a bunch of small functions, I think he is completely wrong. If his point is that when the clearest way to implement some functionality is with a single long function and not several small ones, and that that is likely indicative of poorly architected code and/or data models, I probably agree with him.

Iff you have some poorly architected code that results in you writing a 500 line function, breaking that poorly architected code down into 20 small functions will only make things worse. However it might be that you could re- architect the code and data models in such a way that functions don't need to be large to be clear then that is probably a good thing.

So please don't go breaking a long function into a bunch of smaller ones, where your small functions' names are effectively code comments, but if you can, rearchitect the code so that a set of smaller functions can accomplish the same task in a more clear way, I am all for it.

</comment><comment><USER35> Me and my coworkers are working with multiple, widescreen monitors. These can display, even in a crowded IDEs with larger fonts hundreds of characters in a line. Oh, and they have the capability of _wrapping_ text.

Yet, a lot of the purported best practices, a lot of the frequently used linters etc. complain about that 80 character limit.

Now, when I'm reading Python that follows the actual best practices of named arguments and descriptive variable names, I might have to follow a function call so far down that I forget what it's name even is.

Fun!

I've also had the experience of trying to follow code that follows the other best practice of breaking out everything into a separate function. It's always a joy to have to follow that trail out of the call stack when trying to debug, and having to back out potentially tens of files while trying to navigate some unfamiliar code, losing all the rest of the context on each single jump.

<comment><USER36> > wrapping text

Oh my. Who uses wrapping text for coding?

<comment><USER37> Why wouldn't you?

You do need some sort of indication in your editor that the line is soft- wrapped. If you have line numbers in the gutter, then you already have that.

</comment></comment></comment><comment><USER38> > You've probably heard about the 80/20 rule, also known as the Pareto > principle. Perhaps the title lead you to believe that this article was a > misunderstanding. I admit that I went for an arresting title; perhaps a more > proper name is the 80x24 rule.

You got me there.

The 24 lines convention is interesting. Made me realize that linting rules exist for function length: javascript: [https://eslint.org/docs/rules/max- lines-per-function](https://eslint.org/docs/rules/max-lines-per-function) Can't find the equivalent for python though

</comment><comment><USER39> Sorry, this sounds a lot like motivational "feel good" advice that's in essence empty and confuses more than helps.

"write small functions" sure, how does it help managing complexity? Now you have several tiny functions and need to jump across files and functions to understand how everything works (+ the overhead each function adds - parameters, return values, etc)

Sure, small functions have their place, but sometimes it is easier to have a big block of code that does what you need. Or as another comment said, write small functions but big procedures.

Now for my favourite pet peeve: that 80 columns is some kind of "best practice". In reality it has been cargo culted since the days of the initial IBM PC and there is no reason for such an arbitrary number to exist. But the church of 80 columns keep repeating their mantra mindlessly, mindlessly uglyfying lines of code which go over only a couple of characters beyond 80 columns and wasting coder time with this instead of actually asking the question: is the code actually easier to read now or not?

Because to me, calling a function with one parameter in each line is extremely ugly (especially under-indented as the examples presented in the article)

Is a line that's 85 characters essentially harder to read (especially now with multiple screen sizes and widths) than an 80 char one? No.

I'm not advocating for writing 200 character lines of code, but to not be absolute about it.

</comment><comment><USER40> Old Forths with block-based I/O used 64/16 (so that definition takes ≤ 4096 bytes and fits into disk block).

Makes no sense in the modern world of course, but, in the context of block editors, it creates a development environment where making complex and bloaty word definitions is actively discouraged -- an idea that Aaron Hsu briefly mentions in his APL talks [1].

[1]: [https://www.youtube.com/watch?v=gcUWTa16Jc0](https://www.youtube.com/watch?v=gcUWTa16Jc0)

<comment><USER41> Of course, in the Forth environment, the more any word definition bloats, the harder the stack tracing you have to do in order to understand the operation flow, so keeping things neat and to the point is even more important.

It might be a failing of my own, but I've always wanted a concatenative language IDE to have a stack window, with manual labeling, so I could see what all is on the stack and follow the information flow better.

</comment></comment><comment><USER42> I prefer another rule for short functions. You should be able to explain what the function is doing in one sentence. If you need two sentences, you should break it into more functions.

On the other hand, if your descriptive sentence is basically just duplicating the statements in the function, then your function is most likely too small or too granular. Depending on situation, you might be able to fix it.

</comment><comment><USER43> I tend to have a rule/aspiration that I could frame as "80 || 24": don't force me to read too much in two axes. So a longer routine that does maths, maybe even with nested loops, but using short variables and few function calls is quite easy to follow.

As are short routines that have long identifiers. Like your average OOP or Lisp code.

I even think that multiple statements per line are falsely maligned. Wirth used them quite a lot, and not just in stuff meant for publication. If you've got everything on a few lines, it's not that hard to follow.

Interesting sidenotes for this would be syntactic elements beyond functions/methods. Starting with nested functions, where I actually found the function-hoisted JavaScript variant better than Lisp's flets/labels or modern JS arrow functions.

Other areas that don't seem to be investigated a lot would be inner-procedural _refinements_ (ELAN, some C preprocessors), folding/structured editors and Knuth-style Literate Programming.

</comment><comment><USER44> This is really good advice. There are a ton of different reasons why you can end up breaking this rule and almost all of them are things you want to avoid: multi-purpose functions, adding to old functions that should be refactored, adding an extra case to an if statement that should be broken down, etc.

</comment><comment><USER45> I love this. For as long as code needs to be maintained, code will always be just as much about communicating with people as it is about people communicating with machines.

One thing I still enjoy about message passing OO (by which I really mean Ruby) is how it's really easy to separate concerns to the extent that each file contains one module/class with one public and a few private methods in it. I went a bit bonkers this year and found myself doing one method per module, which is the extreme version of this.

Languages with mixins are great for this too. Mixins are, amongst other things, a nice shortcut around composition that lets you put individual facets of functionality in separate files, albeit with fewer guarantees about code remaining uncoupled.

It's a shame Ruby's module system doesn't better support _private_ for modules though.

<comment><USER27> According to the SICP "Programs must be written for people to read, and only incidentally for machines to execute."

</comment></comment><comment><USER46> > Most mainstream languages, however, seem to be verbose to approximately the > same order of magnitude. My experience is mostly with C#, so I'll use that > (and similar languages like Java) as a starting point.

I see this, too. For a couple decades, all mainstream languages had roughly the same order-of-magnitude verbosity, and then when GC languages arrived, it took a big leap. Now we've plateaued here for a while. When closures became mainstream, that was a smaller leap.

This leaves me optimistic for the future. I find Lisp to still be much more compact than mainstream languages. Maybe once this generation has fully accepted the current level functionality, and gotten tired or frustrated with it, we'll see another jump in mainstream language expressivity.

</comment><comment><USER47> A reasonable line width contributes so much to readability.

While I'm fortunate enough not to experience much of it in the code I read, I do see a lot of websites which grossly violate sane line width rules by stretching the body text to the full width of the browser (looking at you Wikipedia ). Take [https://en.wikipedia.org/wiki/Cyclomatic_complexity](https://en.wikipedia.org/wiki/Cyclomatic_complexity) as an example.

Edit: Martin Fowler's blog ([https://martinfowler.com/](https://martinfowler.com/)) is probably a good counterexample to this.

</comment><comment><USER48> > Like all other programmers, other people's code annoys me. The most common > annoyance is that people write too wide code.

> This is probably because most programmers have drunk the Cool Aid that > bigger screens make you more productive. When you code on a big screen, you > don't notice how wide your lines become.

This is part of why I only _ever_ edit code in a half-screen-width window; the other half of the screen is always filled with either another editor, or a terminal. This ends up coming out to more like 100 characters per line rather than 80, but the principle is the same.

</comment><comment><USER49> I disagree with article. For me function is an abstraction of re-usable code to achieve a single goal(or Intended state). Think of the list of function in system as a list of APIs for a service, the more you create for unintended purpose, the more likely it is a tech-debt.

so, I will say make function for a Goal/Intend in mind, abstract only generic logic to small functions, which have guessable behavior through identifiable by name. Long functions are good if they need to be.

</comment><comment><USER50> Here's a case for 80rule: our vision is (mostly) two dimensional, research shows reading comprehension drops as lines get longer, that's why books and newspapers mostly have fairly narrow columns, comprehending code is less about reading but more about scanning and picking up context for things, much easier to do when perimeter is minimized.

Lots of gut instinct here, not enough citations, maybe one day I'll compile a more substantiated post about this.

</comment><comment><USER6> Agree fully, and as mentioned in the article

> I tend to stay within it, but I occasionally decide to make my code a little > wider.

No coding rules should be religiously held. If you're trying to re-write an 81 column line to fit the rule, even though it's concise and more readable at 81 columns, you're doing it wrong.

</comment><comment><USER51> I don't know how everyone uses such small font sizes. I think mine is set to 16pt.

The one thing that frequently makes me ignore line lengths is URLs. They seem to be most readable when on one line, even if it's 200 characters long.

Also, what kind of variable name is `maîtreD`? I doubt many regions have î on their keyboard.

<comment><USER52> Their eyes must be much better than mine. I think I would probably have eyestrain and be even more tired at the end of the day if I had to squint at 8pt font all day.

</comment></comment><comment><USER53> I had some issues when giving 80 char wide code into print. 70 worked.

Just as a small info :)

</comment><comment><USER54> I cannot overstate how important this concept is. Write code (and DESIGN SYSTEMS) that fit in your brain, because the faster you can reload it back into your brain, the quicker you can dispatch bugs and new features down the line.

Nothing in my professional career has caused me more anxiety than encountering complex code to solve a simple problem. It's infuriating, and has _long lasting_ deleterious effects for the life of that code.

What's especially insidious about this problem is that for folks who value short term success over sustainability, they'll struggle with this for a long time, and have all kinds of reinforcement to be skeptical that any of this is even a problem. Once you get used to struggling with complex code some people start to think it's all that can be written.

<comment><USER55> Artificially slicing up functions does not make the code fit in my brain, it just means that I have to load in more functions in order to have the required context.

<comment><USER54> Definitely, which is why doing it just to get small blocks of code won't work. It has to be part of the entire design, and sliced at real, logically separate spacings.

It's hard! But immensely rewarding if you get it right. You have to be thoughtful as you design and build.</comment></comment></comment>


Is Snowden Obliged to Accept Punishment? By Michael J. Glennon - <AUTHOR> http://justsecurity.org/11068/guest-post-snowden-obliged-accept-punishment/

<comment><USER2> With National security cases one can make an analogy with the physics of a black hole. Reality gets bent, near-irresistable forces are present, information gets hidden, and normal laws get twisted. (OK, details are wrong, but it's an analogy, all right?) And for anyone who lets themselves get sucked in, the outcome isn't good.

Though he is arguing against Kerry's position, the author accepts a mainstream government biased position by constructing his piece around the word "punishment." That word is loaded with assumptions, like the assumption that a crime has been committed. Because of the distortions of the national security case gravity well, the larger fear for Snowden, even in a courtroom, would be retribution, not punishment.

</comment><comment><USER3> A finely balanced piece providing a solid counter to Kerry's comments, in his own language, backed with legal and historical precedent. It's tough to improve on that.

Recommended reading for those keeping abreast of the situation.</comment>


'Dead Skunk' Stench from Marijuana Farms Outrages Californians - <AUTHOR> https://www.nytimes.com/2018/12/19/us/california-marijuana-stink.html <comment><USER2> Ultimately, this is an ordinary agriculture problem. The media will be all "WOOO POT!" about it because it's new and controversial, but the odor problem is the same problem you get from all sorts of farming practices, some of which smell considerably worse than even a big pot farm (which is pretty stinky). It'll get solved the way all such problems get solved - zoning. Same thing that keeps you from having a hog farm or a chicken slaughtering operation near people's houses.

I don't expect grow operations will ever hit the scale of other agriculture, either - there's just not enough demand, and legalization isn't going to make some order-of-magnitude change in that. When I was in Colorado this spring, in a small town way up in the mountains, my host pointed out multiple well-known growing operations in various buildings in town. All hydroponic, indoor farming, so the light and temperature and water can all be controlled. Easy to air filter that.

<comment><USER3> Not to mention, one of the people in the article who is complaining about the pot lives right next to a stinky dairy farm:

"But she says she made the choice to live next to a dairy farm and prefers that smell to the odor that drifted over from the marijuana farm next door to her house."

So it's okay to make a smell if it's one you prefer. If you're some whacko anti-pot person who thinks that it's going to destroy society, you'll find any reason to not like the pot.

<comment><USER4> Well, did she move there before or after the pot farm?

I live out in the country and this issue comes up over and over. People from the suburbs/city decide they want what they think is a peaceful, bucolic country life and move to a rural area without learning enough about the area they're moving to.

And then they find out the farm next door has constant loud machinery noise when planting or harvest time comes. Or when the wind shifts, you're gagging because of the smell from the hog lagoon or dairy farm down the road. The farmers have been there, doing their thing for decades, and they're not about to stop just because someone moved in and can't deal with the reality of living near a farm.

Hell, we used to have a neighbor who complained about horses pooping on the road. Still don't know if she expected us to put diapers on them.

</comment></comment></comment><comment><USER5> Homeowners have a relatively simple way to fight back!

Simply grow some hemp plants, and kill your females.

High quality marijuana production requires the female plants do not get fertilized, which means an absence of male plants.

Once fertilized, cannabis puts its energy into seed instead of increased flowering.

Wind and insects will distribute the pollen to your neighbors, and the plants will start making seeds instead of stinky flowers.

<comment><USER6> This sounds like a great way to get murdered.

<comment><USER2> These are ordinary legal businesses. They don't murder people, any more than liquor store owners shoot at each other.

Not resorting to extra-legal means to settle business disputes is one of the big advantages of decriminalization.

<comment><USER6> They aren't ordinary legal businesses. It is a fact that they are still illegal under federal law, regardless of whether you or I agree with that. If you have ever spent any time in Humboldt County, you would know that if you don't enjoy being shot at, you should stay away from marijuana grow operations.

<comment><USER2> The federal government is mostly irrelevant here. If they started busting state-level-legal grow operations in a more than symbolic manner, they'd find themselves in uncomfortable conflict with state governments. And with states decriminalizing at a rapid pace, the problem gets even bigger. Eventually, the federal government will throw in the towel.

As for Humboldt County grow operations... see what I wrote earlier about the benefits of decriminalization. There's no _reason_ for legal businesses to shoot at anyone. They're supposed to call the cops when they need someone shot, and they do. Shooting trespassers at rural grow operations is an anachronism from the days when that was their only recourse to defend their business.

</comment></comment></comment></comment></comment><comment><USER7> I've got some buyers regret over supporting various decriminalization and legalization pushes merely over how common the smell has become from the increased exposure to individual smokers in So Cal. I never considered what it'd be like to live near production.

I still believe in the principle that the criminal justice system is a poor avenue for addressing most issues related to drug use. But I think the jury is still out whether individual users are generally good at being good neighbors about their use. And industry... honestly, I'd think that an industry that recently had to hide as much production activity as possible would be better about this. But monetary incentives are a hell of a drug, and this isn't going to be the last issue a market oriented society that brings cannabis industrialization into full fellowship is going to face.

<comment><USER8> Don't worry. Experience from Washington and Colorado shows that over time smokers move to vaping and concentrate because it's vastly more convenient than carrying a bunch of plant matter around.

The vape cartridges and the concentrate wax are essentially scent-free. Certainly less smelly than nicotine and recreational non-drug vapes.

Industrial production will move out into the country as with any agricultural or livestock production that has a smell and you'll never notice it. The shit smell of a beef ranch dwarfs any odor you'll ever get from a pot production facility.

Cannabis doesn't have a lot of societal overhead.

<comment><USER9> How is a vape pen more convenient than a couple of joints? The joints don't require batteries and after you smoke them there's nothing to carry around!

<comment><USER8> The pen-style batteries charge from USB and are as easy to carry around as a pen or, say, a lighter. Do you normally light a joint and discard the lighter? Are you carrying around one strike-anywhere match per joint?

The user pushes a button, breathes in some vaporized oil, and puts the battery back in their pocket or bag. It takes about four seconds. A user could do this in a bathroom, a confessional at church, on a bus or on a train.

It is much easier than setting something on fire, passing it around while it's burning, and then putting that fire out.

A gram cartridge is about the size of a pen cap, lasts even a heavy user for a week or more, and doesn't make the user's bag smell like weed.

Are you imagining those giant wizard vapes that are the size of a pack of cards?

</comment></comment></comment></comment><comment><USER10> James Madison University is located a few miles from a dog food factory and the entire town smells like it.

Also dead skunk is how you know it's good so... _shrug_

<comment><USER11> I don't smoke, so I may be wrong, but isn't skunk smell a bad thing?

<comment><USER12> Cannabis smell is not the exact same smell as skunk - you can differentiate between them with your nose alone, and from this one can have a positive preference for the former (and a negative reaction to smelling the latter..) - but they both comprise various thiol compounds, so they are both pretty similar and striking.

Sometimes people think the depth of the scent of the un-smoked weed means it contains a deeper variety of specific volatile organic compounds called terpenes. I'm not sure if the distinct aroma-causing compounds make much of a difference for the end result compared to the cannabinoids, but people use their nose as a quality estimator this way.

</comment></comment></comment><comment><USER13> This is a zoning issue, not a marijuana issue. Why did the government allow a greenhouse which was zoned for daises swap to marijuana?

Yes, marijuana stinks. So do slaughter houses and landfills. There's a reason we don't zone these near residential areas.

<comment><USER14> Is it typical for greenhouses to be zoned for particular individual types of plants?

</comment></comment><comment><USER15> You have to hope that after legalization producers will stop competing on how strong it reeks, since we'll all know it's real and won't be evaluating on the fly. Problem is that it might take generations to breed out the smellier=stronger thing.

Somebody here has the power to start branding based on being strong but not smelly; get on it first, you'll find a huge market.

<comment><USER16> Will pot consumers like that? I think marijuana smells fantastic, I doubt I'm alone on that. It's an acquired taste similar to beer and coffee. This would be like if breweries stopped making IPAs because some people find them too strong.

<comment><USER17> The trend for almost five years has been less bitter IPAs. IPAs are still the hottest trend in craft beer, but the days of one-upmanship in bitterness stopped around the time Heady Topper gained prominence. Subsequently there was a rise in "session IPAs" \- usually about 5% ABV and 45 IBUs. In the last two years, the most hyped style has been the New England IPA. All the hop aroma of yesterday's 100 IBU Double IPA but with half the bitterness.

</comment></comment></comment><comment><USER18> I wonder if this is worse than living near a hog farm?

<comment><USER19> As a former resident of Indiana, no, it's not. Different, yes, but nothing is quite as bad as a holding pond at a hog farm on a hot summer's day.

<comment><USER20> Oh yes, there are worse things: chicken farms. Hog farms are certainly smelly but chicken farms are... disgusting in a way all of their own, a nauseating smell which makes you glad you did not eat a big lunch. I've lived on a (small scale) hog farm - studying at an agricultural university, being in need of a place to live and finding a farmer who had a cabin on his farm ready for rent leads to such - and have cycled through areas with chicken farms.

I studied forestry and know what I prefer on a hot summer's day, the orangey tang of a Douglas fir stand or the resinous smell in a pine forest on sandy soil are infinitely preferable over both hogs and chickens. Or weed, for that matter.

<comment><USER21> I'll never forget the first time I smelled a soggy goat farm on a hot day.

</comment></comment></comment></comment><comment><USER22> I've wondered if whether the decriminalization and/or legalization of marijuana would eventually lead to people selectively growing strains that don't smell as strong. I guess that it's not a priority for the people that partake, and therefore not a priority for the producers.

<comment><USER23> I believe low smell would be prefered for illegal grows as it attracts attention.

</comment></comment><comment><USER24> Easily controlled via requiring growers to use carbon air filters. They are quite effective. It obviously won't help with the outdoor grows, but most grown in cities isn't grown outdoors.

</comment><comment><USER25> its no where near as bad as a paper mill

<comment><USER26> I think that's the point, though: legal marijuana farms are an industrial process. The fact that we can put them in the same category as a paper mill is noteworthy.

I'd agree that they're less offensive to the sense of smell than paper mills, or dog food manufacturing, or any number of other large scale commercial operations. But now that recreational marijuana is legal in so many places we have to consider (and regulate) it like the industrial process that it is.

</comment></comment><comment><USER27> I went to college in Kenosha, WI (North of Chicago, South of Milwaukee) -- and they have cabbage patch farms around the area.

The stench coming from those farms, woowee!

</comment><comment><USER28> activated carbon ventilation filters, maybe? The world's biggest sploof.

open-air farming is harder to handle. I grew up a few miles away from a pig farm, and late august was unavoidably...special. You get used to it, but the first hot end of summer day was a salient experience.

</comment><comment><USER29> Those specific respirator filters only do light organic vapors (as opposed to say the 3M 6001 cartridge), so the smell can't be that bad.

(Or you know, leave out the hyperbolic pictures.)</comment>


Ask HN: What makes a good recruiter email/advert? - <AUTHOR> I suspect most here experience the same thing. On a daily basis you'll receive numerous emails or adverts from a variety of channels.
My question is simple: What makes a good one? Or what makes a bad one?
The vast majority are simply copy/paste templates where your name is replaced. The sender clearly doesn't know you. Instead I'm looking for data if targeted adverts would be better. For example, an advert quoting your recent OSS contributions, StackOverflow questions and blog posts that in turn links back to the job description. This is in contrast to the mass blanket approach traditionally taken.
I don't believe standard recruitment companies could perform this research step but my belief is that such adverts would increase engagement, even if nothing comes from the lead directly. <comment><USER2> > What makes a good recruiter email/advert?

Personalized emails are the ones that breakthrough. True, the average Bozo Recruiter will not take the time to compose a thoughtful individualized note. On this subject, Oren Klaff is masterful > [http://pitchanything.com/how-to- get-your-pitch-past-the-inbo...](http://pitchanything.com/how-to-get-your- pitch-past-the-inbox/)

> I'm looking for data if targeted adverts would be better.

It's a Big Idea, SmashFly is doing interesting work in Recruitment Marketing > [http://www.smashfly.com/](http://www.smashfly.com/)</comment>


Windows 10 upgrade resets your default browser to Edge; Mozilla is very unhappy - <AUTHOR> http://arstechnica.com/information-technology/2015/07/windows-10-upgrade-resets-your-default-browser-to-edge-mozilla-is-very-unhappy/

<comment><USER2> Previous discussed: [https://news.ycombinator.com/item?id=9977836](https://news.ycombinator.com/item?id=9977836)

</comment><comment><USER3> Why not? Look at how Google is proactively preventing Microsoft from delivering a good YouTube experience on WP: [http://www.theverge.com/2013/10/7/4813836/microsoft- reverts-...](http://www.theverge.com/2013/10/7/4813836/microsoft-reverts-back- to-basic-youtube-app-windows-phone)

All weapons are good in the war for clueless users, the experienced ones will find their way.

</comment><comment><USER4> I saw this yesterday and the amount of Mozilla hate was weird. I know they've dipped in popularity over the years, but theirs is the only browser I still trust with my data.

Anyway, the option to not set Edge as default was incredibly easy to understand. It asked you to toggle which programs you wanted to set as the new defaults. You uncheck what you don't, click "next" and there you have it.

<comment><USER5> People hating on Mozilla is about as weird as hating on Microsoft, Apple, Google, etc. That is to say - it's not weird at all. You're just saying that because you like their bullshit better than the other company's.

Me personally, I think they're run by a bunch of lying thieves who have been bought out. If they actually cared about openness, they'd have done a lot more with the hundreds of millions of dollars that they've collected over the years.

</comment></comment><comment><USER6> Mozilla changes your default search engine to Yahoo. I wonder if they would be as upset if Bing had outbid Yahoo for this privilege.

Both companies should be prosecuted under the CFAA for these acts, making unauthorized changes to computers that don't belong to them.

<comment><USER7> I wonder if _Express Settings_ includes setting the browser back to MS default.

<comment><USER8> It isn't. When the Express Settings option came up I selected the (well hidden) option _not_ to use it, and unchecked every option I was given. My default browser was still switched to Edge.

<comment><USER9> Supposedly, the hard-to-spot option not to use Express Settings reveals another, equally hard to spot option later on in the install that lets you set your default browser to something other than Edge.</comment></comment></comment></comment>


US Jobless Rate Fell in May as Hiring Rebounded - <AUTHOR> https://www.msn.com/en-us/money/markets/us-jobless-rate-unexpectedly-fell-in-may-as-hiring-rebounded/ar-BB154ATi <comment><USER2> [https://news.ycombinator.com/item?id=23428340](https://news.ycombinator.com/item?id=23428340)

Dupe</comment>


Reddit's Chief Apologizes After Employee's Dismissal - <AUTHOR> http://www.nytimes.com/2015/07/07/technology/reddits-chief-apologizes-after-employees-dismissal.html

<comment><USER2> The general impression I see the most is that Pao and here team are trying wash the site of any content that Corporate Advertisers find offensive and try to monetize as much of the site as they can starting with a monetization scheme for IAMA where PR firms can use IAMA as celebrity advertising with softball pre screened questions.

Victoria was the key person organizing IAMA guests across the whole of Reddit. She helped to enforced the strict policy that IAMA have that the person is actually there and not a PR rep fielding questions. And that the questions are real and generally keeping the quality and integrity high.

There has already been a number of high traffic subs that have decided to close down and move to voat.co or other sites.

It's telling that instead of addressing the community directly Pao and here group stage a PR blitz in the media trying to spin a false narrative instead of addressing Reddit first and dealing with Redditors concerns about moves to limit free speech. Commercialisation and firing of key community friendly staff. It shows total concept for Reddit users and the same sort of dishonest personality that would try to destroy the credibility of her former employer Kleiner Perkins with false gender discrimination lawsuits for 100 million. which she lost spectacularly with all 12 jurors siding with Kleiner Perkins.

Pao has shown on numerous occasions she is a toxic personality. And has no interest in Reddit and the communities there.

if anyone is planning on launching your FREEZE PEACH community platform NOW IS THE TIME...

</comment><comment><USER3> The whole backlash against her has quite frankly been revolting. I no longer care what she did to offend so many people, but sympathise with her as this is undoubtedly a horrific experience for her.

The firing of the key employee may of been stupid, but not deserving of some of the hatred being gleefully promoted across Reddit. Trying to get her photo coming up for searches of Hitler, commenting on her physical appearance, all the horrible little shits on the internet are coming out in droves over this.

The petitions opening (and longest) paragraph is idiotic and attempts to assassinate her characters and it's sad that "censoring" a community promoting hatred of obese people is something that motivates people to take democratic action.

<comment><USER4> Key employees, multiple.

/u/kickme444 who have been running redditgifts, and have been running give- away events between users of reddit have also been fired, most notably the secret santa. He did a TedX talk here: [https://www.youtube.com/watch?v=phoUVH05kEg](https://www.youtube.com/watch?v=phoUVH05kEg)

It is an interesting move to lay-off your employees that are closest to the end-users, I hope reddit will survive their internal struggles.

<comment><USER2> Its much worse then people know out of 38 admins who have left Reddit since 2008 23 have been within the last 9 months. [https://archive.is/vMQfS](https://archive.is/vMQfS)

</comment></comment></comment><comment><USER5> Reddit has jumped the shark.

I remember when this happened with Digg; Digg reached a certain level of success, but then discovered that it's existing users were a barrier to acquiring new users and getting revenue. They picked a fight with their power users, who left, but never got anybody to replace them, so then the spammers took over.

Digg users formed a diaspora and moved to reddit.

Many sections of reddit are overrun by the kind of people who hate Ellen Pao and everything she stands for. These people may have a point, but they are haters at the core and, like the Digg user base, they are a barrier to mainstream success.

I think reddit is going to look like a fight between an immovable object and an irresistable force and that just can't be good.

<comment><USER2> the backlash against Pao is from all the major subs /history /science /video /iama and the rest. Thousands of subs turned there subs private in protest to force the 'new management' to come to the table and answer some urgent questions and address major issues that are effecting all the subs.

This is about a series of bad decisions by Pao and her 'new management' trying to make fundamental changes to how Reddit works which most Redditors think will damage the community and viability of the site. Possibly to the point of a mass exodus as Reddit is turned into DiggBook 2.0.

Narrative spinning about 'haters' and 'misogynists' is deflection. Trying to cover the bad decision making and contempt under a 'victim hood status'. Much like Pao used fake gender discrimination allegations to try and extort millions of dollars from her former employer. False victum hood and extortion is what Ellen Pao stands for. And perhaps anti free speach censorship and spreading toxic corporate marketing.

<comment><USER5> IMHO it is the largest groups on Reddit that are the worst, although I am sure it has some really nasty little corners.

Now being a hater doesn't mean you're not right, but all of your valid issues are contaminated with the baggage that everybody involved is bringing in from the rest of their lives.

</comment></comment></comment><comment><USER6> It's funny but Reddit is not the front page of the internet. It's the comment section of the internet. If you actually see what's going on here, it's the same people who care to comment on things. Some of whom are trolls and very difficult to control. The trolls from your comment section are having their day on Reddit. And the community is behind them.

</comment><comment><USER7> I think the community have gone beyond the point where an apology from Ellen Pao will be sufficient enough to quell the dissatisfaction users have with Reddit. The only solution I can see is Pao stepping down or being replaced, followed by some actual management policies and ways of keeping the community happen (acknowledging them would be a good start).

The site has been on a downhill slope for a while now and as shown, this isn't a localised incident, a lot of people are not only angry about the handling of Victoria's dismissal, but how the site is being run. Why now? Why is Ellen Pao only apologising for years worth of mismanagement of Reddit after the community took a stand? This goes beyond what just happened, this has been a long time in the making. It comes across as a forced apology because before all of this blackout controversy, they were doing nothing. The community was being ignored, mods were running rampant shadowbanning and removing threads, mad with power. And ironically mods want better tools and more power? The promotion of krispykrackers just goes to show how out-of-touch Reddit has become with its users.

It's great that they're acknowledging there are issues and that they will do better, but I think it is too late. Maybe I am wrong, but I just can't see things getting better or if they do, staying better for long. I have moved over to voat.co and when it comes back online, my 8 year old Reddit account will be nothing more than an effigy to a site that was once great. I personally have nothing against Ellen, the whole problem with Reddit goes well beyond her and members of the community also share in the blame. The centralised approach Reddit takes to management is its downfall and if they're not careful, we could see what happened to Digg when they messed over power users happen to Reddit as well (evident by the influx of users over at voat.co).

</comment><comment><USER8> The reddit post and comments has much more useful info: [https://www.reddit.com/r/announcements/comments/3cbo4m/we_ap...](https://www.reddit.com/r/announcements/comments/3cbo4m/we_apologize/)

</comment><comment><USER9> Earlier discussion: [https://news.ycombinator.com/item?id=9840805](https://news.ycombinator.com/item?id=9840805)

</comment><comment><USER10> Reddit is undergoing a gradual decline, whose climax might have been this.

While Pao is also blamed, these problems are a reflection of a long-standing centralized management team.

</comment><comment><USER11> Let's be frank, if it was "Eric" rather than "Ellen" Pao (and, even more so, if it were "Smith" rather than "Pao"), we wouldn't be hearing 1/1,000,000th the uproar we've heard about all this.

Nothing drives Angry White Men on The Internet more ballistic than a woman or a person of color in a position of authority. You see the exact same thing with the sheer insanity the right-wing is driven to by President Obama's essentially centrist administration.

<comment><USER12> Please provide evidence to support your statement, because I do not see how your second and third sentences necessarily follow from the first.

<comment><USER11> We unfortunately do not have enough women or people of color in positions of authority for me to provide some rigorous statistics documenting the experiences of a swath of such people (though this gives a good indicator we've got a problem).

However, it seems quite clear to me that minorities in positions of authority or public visibility face a level of vitriol unlike that experienced by some boring old white guy. Look at the level of hatred directed towards Hilary Clinton or Barack Obama; look at the hatred directed towards a woman trying to present at a tech conference; look at the _death threats_ Anita Sarkeesian has received for making YouTube videos on video games.

<comment><USER13> I love your parody of delusional sjw. Very authentic. If only you had mentioned the patriarchy! It would have been sjw bingo.</comment></comment></comment></comment>


In-Memory caching: Why we can't just trust the database to get it right - <AUTHOR> http://www.25hoursaday.com/weblog/2008/11/09/InMemoryCachingWhyWeCantJustTrustTheDatabaseToGetItRight.aspx

<comment><USER2> So if you're running a server with 32GB of RAM and your entire database is 4GB, why can't the whole database just be kept in memory and be done with it?

I don't see an obvious way to do this in MySQL at least and it certainly doesn't do it automatically.

<comment><USER3> It essentially will be after everything's paged in. If you want to be sure though, create a RAM disk and stick your data files on there, though then you need to deal with system crashes on your own.

<comment><USER4> I wonder how creating a raid1 device composed of a real block device and a ram disk would serve in this regard. Has anyone tested this?

<comment><USER5> It would be pointless. Just let linux cache the data and don't worry about it.

If you must, cat all your database tables to null (i.e. read all the data in them) a few times, then you'll be sure they are in memory.

If you used a ramdisk you'll be paying double: once for the data, and again for the cache.

<comment><USER4> Raid1 idea was a suggestion of how to deal with system crashes, not to populate the buffer cache.

</comment></comment></comment></comment></comment><comment><USER6> So, I'm just back from a party and I'm still a little tipsy, but here goes. . .

It's not always about being faster. Sometimes, it's about being more scalable. If I gave you a computer twice as fast as mine and told you to O(n^2) sort a million things, it would take you a lot longer than me using the slower machine, but using an O(n * log n) algorithm.

This gets us into the difference between MySQL and memcached. With MySQL I can say "give me the people where the first name is 'Brian' and the last name is not 'Applestein'" Awesome! Convenient, useful, slow :-(. With memcached, I can say, "give me key 'Per:48'". Um, not that useful or convenient, but fast as hell.

Why? What memcached is doing is creating a hash table. Basically, it knows where something is going to be stored because of its key. So, 'Per:48' will always be in place X because that's where it hashes to. When I want to retrieve that key, it doesn't have to look. It can just go! That means that it runs in constant Order(1) time. MySQL is going to use an index (if you're lucky). That index is going to sort the items in a specific order and then MySQL can retrieve an item in log n time. log n > 1 for almost all values (sorry, I don't deal with math below like, 10 since it's never relevant in my work since, well, scaling to 3 items doesn't matter).

So, even if MySQL kept everything in memory, it wouldn't be as scalable as memcached. memcached is able to do an Order(1) hash lookup. MySQL (with an index scan) is log n. This brings me to the query cache. While I don't pretend to know all of the internals of these technologies, I'm guessing that MySQL's query cache is basically like memcached. You have another key -> value store. Basically, MySQL has stored the result set as the value of the key which is the query.

The problem with the query cache is that it becomes invalid the second something is changed in the database, thus making it useless for scale.

So, why does memcached overcome that problem? Well, part of it is that when you scale, you leave behind those awesome queries that are so neat. You want to get all of the friends of "Matt"? Well, grab the serialized object "Matt" from memcached. That should have a list of the ids of his friends. Ask memcached for the objects matching that list of keys. As you can see, memcached isn't relying on a query of Matt's friends. Maybe you have never done that before. BUT, you have put each record into memcached and therefore it is available in this context. Where the entire query cache becomes invalid everytime someone hits the database, you can hack MySQL to update memcached with the one record that has been updated without invalidating the things that haven't changed.

If you have questions, you can always respond and I'll try to answer in the morning. Basically, querying is never infinitely scalable. It's log n. Hash lookups can scale. While more memory makes a database faster and scales it higher, it doesn't match a cache like memcached because queries are a more costly operation than hash lookups. Yeah, it's a pain. You and I probably won't have to deal with it much since databases are pretty damn efficient and log n is pretty good. If you become the next Twitter, hire someone who can explain this comment. Before then, don't worry so much! You'll give yourself wrinkles!

<comment><USER7> Yeah. Every time when someone tries to make a case for memchached they bring in Facebook and LiveJournal.

Well guess what: you aren't Facebook. You don't serve 21,000 requests per second. And you never will. Go and look at the size of your MySQL tables, then look at how much RAM your server has and what percentage of it is allocated to filesystem cache and how many real I/O reads/writes your hardware RAID does per second. Then come back and tell me again why do "we need to switch to memcached"?

</comment></comment><comment> patrickg-zill I think what he is trying to say, is that knowing how your database stores and accesses the data, can help you make better decisions in writing SQL statements.

The example he gives is that a stored procedure for a large query used to take almost 1GB but now it takes only about 1MB because he is "cooperating" with the way the database slings data around.</comment>


Active Record Query Interface 3.0 - <AUTHOR> http://m.onkey.org/2010/1/22/active-record-query-interface <comment><USER2> This does introduce some fairly fundamental changes in the API. Breaking every book ever written about your framework is fairly ballsy.

In a lot of ways it's the inevitable conclusion of Rails' trend towards named_scope'ing everything. Chaining everything ends up being pretty flexible, even when you're building up things dynamically (I'm seeing a lot of `.send('the_scope')` in my future). And the lazy-loading should be quite helpful.

And the weird side-effect is that you can now write it somewhat as SQL: User.select().from().where(), etc., which conceivably could help those new to the framework.

Really, though, I'm still surprised at the rather large change here. At least it seems we have ample time to start the transition before 3.2 (and, as one commenter mentioned, you could start building your own .where() named_scopes today to somewhat ease the transition).

<comment><USER3> _And the weird side-effect is that you can now write it somewhat as SQL: User.select().from().where(), etc., which conceivably could help those new to the framework._

which kind of defeats (part of) the point of it being a sql abstraction layer, doesn't it? granted, most of activerecord's backends are for sql servers, but now adding a sql-like syntax to other generic (nosql?) backends seems kind of confusing.

personally i wish they'd just keep find() and all the old methods for compatibility. the new stuff is neat but i don't see the point in deprecating and then actually removing the old things that have been around for many years.

<comment><USER2> Yup, that was my first thought too. But you kind of need to know SQL to really figure out the current API, so maybe moving closer to that isn't a bad idea. In any case, you only need to know the _idea_ of SQL, really, since chainable scopes let you go wild with where().joins().where().where() and you don't have to worry about syntax or aliasing.

You can still use find() through 3.1 (so for at least a number of months I'd expect). At that point, they'll offer backwards compatibility via a plugin, so no worries.

</comment></comment></comment><comment><AUTHOR> At first glance, this looks like it has "massive rewrite" all over it:-/ It does look nice, but that's a lot of very widely used code that's being deprecated.

<comment><USER4> This is just the tip of the iceberg in Rails 3. The architectural changes are widespread. Things like routing and generators are straight replaced with much more powerful versions. both those things need to be rewritten on a _completely_ different API. The layout of the API docs is dramatically different with components shifted all over the place. This may well be frustrating to existing app developers who have a more modest pace of development and just want to focus on incremental improvements. However if you look at the modularity and flexibility these changes bring, you'll realize that Rails 3 is now several orders of magnitude more flexible and it becomes viable for a much larger set of problem domains.

The Rails core team is not content to dramatically slow down improvements to accommodate an installed base, they want to take advantage of good ideas and keep Rails at the forefront of web development--and this is not change for change's sake, all the deprecations and outright replacements are _well_ justified.

There's no doubt this will wreak havoc with traditional teams maintaining mature apps that don't have the budget or interest to spend time refactoring existing code. I do feel their pain. But old code still runs. You have the choice of sticking with 2.3.x or else capitalizing on powerful new improvements. The only choice they've taken away is the ability to sort of putter along on a series of bland updates to a mature framework. Maybe that's where Rails will be in another 5 years, but not today.

</comment></comment><comment><USER5> This is a great change. We almost never use .find() anymore in our rails 2.3 projects and everything uses named_scope() or scoped() (which return relations). This change will discourage really bad practices that I've seen in a lot of rails code.

If you've been doing things right you won't need to change much code. If you've been doing them wrong you will likely see a significant performance increase after updating your code.

Here's a line from our 2.3.2 project (Get all organizations that the user is a fan of):

@user.organizations.scoped(:limit => 10).with_role("Fan")

And what it will look like after this change:

@user.organizations.limit(10).with_role("Fan")

<comment><USER6> You can do the "after" right now.

named_scope :limit, lambda { |num| { :limit => num } }

</comment></comment><comment><USER7> Fairly much awesome (not totally awesome because I'll have to maintain old projects as-is, not worth updating with so many API changes).

While I use a few different programming languages in my work, I am now fairly much only using Rails for web applications. This process was finalized when I converted a customer's project from Common Lisp to Ruby and Rails last summer.

</comment><comment><USER8> This is a great change. After you use Sequel for a while (which operates this way) it's really hard to go back to ActiveRecord and pass hashes all over the place.

</comment><comment><USER9> Very cool, very LINQish (for the C# lads out there). Includes deferred execution and everything!

Color me excited.</comment>


Ask HN: Adult learning Calc - <AUTHOR> For fun in my free time I'm writing a game in unity and c# where you pilot a plane. I could not find an auto pilot script so i am writing it from scratch.
While trying to figure out how to dynamically set the planes elevator deflection based on the planes vertical speed and distance from the desired altitude i discovered that writing an auto pilot involves some advanced math :)
My math resume ends at high school trig.
I am hoping to discover what flavor of math should i focus my studies on to achieve my goal and possibly hoping to avoid learning any fluff in the process.
Thanks all <comment> FourierT-form I would start with vectors and physics.

Note that there is some basic calculus involved in both of those.

The Wikipedia is a bit dense, but if you take the time to follow links to concepts that you aren't familiar with you should be good.

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

You might have done a little bit of calculus with High School trig without knowing it. Sometimes Trig is mixed in with Analysis for some nuanced reasons.

I would check out the Khan academy post for a basic grounding in calculus.

[https://www.khanacademy.org/math/calculus-home/limits-and- co...](https://www.khanacademy.org/math/calculus-home/limits-and-continuity- calc/limits-introduction-calc/v/introduction-to-limits-hd)

</comment><comment><USER2> See [http://shop.oreilly.com/product/0636920028970.do](http://shop.oreilly.com/product/0636920028970.do)

</comment><comment><USER3> This sounds like a fun project !

Have you looked into PID controlers? The basic idea is stupid simple and uses no big math.</comment>


Books or video tutorial: the best way to learn coding? - <AUTHOR> <comment><USER2> I think the answer is "yes". In other words, _both_.

I'm only speaking for myself here, when I say the following things... for me, I'm my own worst enemy when it comes to learning.

This happens first and foremost by getting _distracted_ with social media (Facebook, Twitter, HN).

To quote Cal Newport (an author who speaks on this _very thing_ ) from his book Deep Work. "To learn hard things quickly you must focus intensely without distraction."*

So let's say you're not aiming to be quick about learning to code, necessarily. It still follows that not being distracted is key.

I think covering both books and video helps you get information from multiple inputs, and covers different learning styles. ANYTHING to get the concepts cemented in your head.

Most of all, do what you can to learn in an environment where you're not bombarded by many things designed to distract you.

I recommend this book. I'm in the process of reading it now, myself. I feel like he's talking directly to me, and that I could have been MUCH more effective in both learning and work, had I discovered this MUCH sooner.

Good luck. I'd be curious to hear how you're making progress on your learning journey.

*Newport, C. (Grand Central, 2016). Deep Work: Rules for Focused Success in a Distracted World [Kindle version, page 36]. Retrieved from Amazon.com

</comment><comment><USER3> Both actually.

Speaking for myself... I start with video. It is easier to find, easier to follow and easier to implement. Now when you finish with video course, search for "best" or "amazing" book for that particular language or framework.

Because of video course introduction, most part of the book will be like "seen somewhere" or "read somewhere". so the reading of book becomes tolerable and more understanding.

Bottom line, (I believe ) Video courses are never enough and books are long and difficult. So, start with video course and finish it with a book.

IMP point : practice while going through the whole process.

</comment><comment><USER4> I'm more of the type to prefer textual content. A lot easier to scan through and process at your own pace than video content that you naturally are expected to perceive in a time-based manner.

</comment><comment><USER5> Depends on what I'm trying to learn. If it's a programming language, or something math-heavy, I prefer books. If it's GUI programming, I prefer videos. I tried learning Android programming from their official documentation, and felt lost with all those hyperlinks that made a horrible directed multicyclic graph. I did not consider books for this because it's a fast-moving target. I learnt python entirely from their official documentation.

</comment><comment><USER6> It really depends on the person. Personally I like official tutorial webpages and videos for learning the basics, and books for gaining a deeper context or best practices.

</comment><comment><USER7> When I need to learn a new language I tend to buy a book for the first few chapters so I can learn the basics of the language(variables, control structures, etc). Then I'll subscribe to whatever the most popular video site is pick a project I want to implement and start working on it and when I need to know how to do something look for a video on it and read the transcription since I don't actually like watching the videos.

</comment><comment><USER8> When trying to learn programming for the first time, find a book that has lots of exercises. I used an earlier edition of [http://openbookproject.net/thinkcs/python/english3e/](http://openbookproject.net/thinkcs/python/english3e/), but I've heard that people like "learn python/java/ruby/... the hard way".

</comment><comment><USER9> As others have said, both have their place for me.

I like videos that give me a conceptual overview, or tell me the thinking behind why they coded something in a certain way. For details and reference I use books (unless it's a fast-changing technology, in which case the language/tool's docs are where I go), or I need a deeper dive on something that's not just code.

</comment><comment><USER10> Videos are a good starting point. But both books and videos are bad since most stuff is dated. Tech keeps getting updated and you are stuck with the version you "studied". So, IMO, get started with videos, learn using books/blogs/stackoverflow etc. but keep revisiting so that you are really on top of things.

</comment><comment><USER11> To me, books are a great high-bandwidth way to absorb the full breadth of the topic. Videos are more linear, and slower. But videos can help if you lack motivation or focus to read books.

But either way, to internalize the learnings requires doing many coding exercises.

</comment><comment><USER12> Videos can be better for high level content, but books and blogs are better for code. I say can because producing high quality programming related videos is rare from what I've seen (do we need something like markdown for videos?).

</comment><comment><USER13> Books can be a pretty lonely way to learn technical material. Videos, much less so but I find it can take a bit longer to grasp video content because you always have to be engaged since it is not easily scannable.

</comment><comment><USER14> I prefer books - or really, just plain old tutorials on the web. I created [https://enlight.ml](https://enlight.ml) to do just that. Check it out! :)

</comment><comment><USER15> Text hands down. We can easily scan and skip parts that we do not need. Videos are such a drain on time and are boring. Its hard to go back and forth.

</comment><comment><USER16> Brute Force</comment>


Bad bots now make up 20 percent of web traffic - <AUTHOR> https://www.zdnet.com/article/bad-bots-focus-on-financial-targets-make-up-20-percent-of-web-traffic/ <comment><USER2> The rumors of very nasty behaviour between competing saas companies is confirmed by tech at the top of list with 34% bad bot traffic. Is anyone providing bad bot as a saas service? Send an army of automated bots on your competitors e-commerce website.</comment>


Ask HN: How do you make something people want? - <AUTHOR> <comment><USER2> Two ways to approach it:

Make something. Most people won't want it. Show it to lots of people until you find some who are mildly interested. If nobody's interested, make something else. Otherwise, make what the people who are somewhat interested want. Repeat until you've made something people want.

Want something. Find other people who want it. Research the hell out of possible ways that you might make it. Talk to lots of people that might help you. Most won't, but some may give you some pointers or point you toward people who _can_ help. Repeat until you've made something people want.

Empirically, the second seems to converge faster, but both can work. People tend to fall on different sides of the "I make things" vs. "I want things" spectrum, so the first approach will work better for some folks and the latter better for others. (I'm very much on the "make things" side of the spectrum, for example, so was basically forced into starting by making bad ideas and then incrementally refining and retargeting them until they become good ideas.) Know your strengths and what you care about and play to that.

Also, it can help a lot if a "make something" person partners up with a "want something" person, but this requires that they have compatible interests, working styles, and personalities. This itself is kinda a magic combination...if you find a team that works, run with it, but if you don't, either keep making things or wanting things until you do.

<comment><USER3> "If I had asked people what they wanted, they would have said faster horses." - Henry Ford

</comment></comment><comment><USER4> There are hundreds, if not thousands (x) of people just like you. Make something you want.

Then listen to people, adapt the edges 20%. You will reach millions.

This has probably been said before.

</comment><comment><USER5> I think a better question is "How do you make something people will use?" People want a lot of things that they won't necessarily use. Look at all the apps on your phone that at some point you "wanted," but now are never used.

</comment><comment><USER6> Look and listen for people's problems. Then come up with a brilliant solution.

The world's biggest problems are the world's biggest business opportunities. On this subject, Peter Diamandis writes a great blogpost > [http://peterdiamandis.tumblr.com/post/128046793118/problems-...](http://peterdiamandis.tumblr.com/post/128046793118/problems- are-goldmines)

Also, podcast discussion with Dan Sullivan >[http://www.abundance360summit.com/podcast/2015/10/19/episode...](http://www.abundance360summit.com/podcast/2015/10/19/episode-11-problems- are-goldmines/)

</comment><comment><USER7> Ask yourself if you make something-

1\. Why will you use it? 2\. How much will you use it? 3\. Will it use it daily or atleast with proper interval?

Then ask to be users around you and listen what they say on those 3 questions and derive from it.

</comment><comment><USER8> Good comments here; an easy idea but harder to implement is something people already use (a lot) and make it easier and/or cheaper. Like Uber for instance.

Cheaper is something people always want.

</comment><comment><USER9> Aptitude. Some people can (and want) to sing. Esoteric talents abound. Use your aptitudes to help you make something people want. If you're good at, say for example singing, that is the natural talent you can bring to a making project. Make something you can make really well. Otherwise you might end up bored as hell.

</comment><comment><USER10> You don't make something that people want, rather you make something and then sell it in such a way that make people want it.

</comment><comment><USER11> By making something for yourself.

</comment><comment><USER12> Think of something you want... too techie? how about something your mom or gandpa wants.

Start making it, as you get into it expand the audience scope to include more people. Make sure you have other people try it out to get different perspectives.

</comment><comment><USER13> I think, talking to them is the first step then telling them what you can do for them can help you make something.

</comment><comment><USER14> start with customer development, interview a whole bunch of potential customers. Then try to distill the data down into some generalization. If you can identify a pattern, your idea may work

</comment><comment><USER15> By making something you need.

</comment><comment><USER16> By knowing what people want.

<comment><USER17> how do you know what people want? By asking. How do you find these ppl to ask? By going to where your target audience hangs out. How do you know what questions to ask them?</comment></comment>


Buffy vs. Edward Remix Unfairly Removed by Lionsgate - <AUTHOR> http://www.rebelliouspixels.com/2013/buffy-vs-edward-remix-unfairly-removed-by-lionsgate <comment><USER2> This article is actually worth reading. It's actually written by somebody who knows what they are talking about.

      "Buffy vs Edward remix was mentioned by name in the official recommendations by the US Copyright Office (pdf) on exemptions to the DMCA as an example of a transformative noncommercial video work."

<comment><USER3> But what does it mean? What is an official recommendation by the Copyright Office - an actual license to reuse stuff? Or just a recommendation with no legal consequences at all?

So artists are supposed to create works employing fair use, and then hope they'll get a recommendation by the Copyright Office? If yes, they can publish their work, if no, they'll have to trash it?

</comment></comment><comment><USER4> The article links to an independently hosted HTML5 copy of the video, in case you want to see it first-hand. It's very cleverly done, quite amusing (at least if you're a Buffy fan), and definitely looks like fair-use:

<http://www.rebelliouspixels.com/popupvideo>

<comment><USER5> Man, those textual pop-ups are annoying!

ADDED. Version without the pop-ups: [http://www.rebelliouspixels.com/downloads/Buffy_vs_Edward_36...](http://www.rebelliouspixels.com/downloads/Buffy_vs_Edward_360p.mp4)

<comment><USER6> _> Man, those textual pop-ups are annoying!_

Amen. I find it hard to get upset about the takedown notice when _I_ want to take it down for melting my eyes. Perhaps this is unfair of me, but there it is. Thanks for the clutter-free link.

<comment><USER7> That was a tech demo for popcorn.js, showing how you could replicate the popup video feel. The bubbles are overlaid on top of the html5 video and controlled through javascript.

</comment></comment></comment></comment><comment><USER8> I think there is a real possibility that this maneuver could blow up in Liongate's face. Presumably there are some important decision-makers who take the argument for fair use seriously: that's why this dispute process exists in the first place. This video is an exemplar of what normal non-lawyer people would classify as fair use, if they're familiar with the concept at all. If Liongate's lawyers are willing to get in the mud over a few ad dollars (rather than the high-sounding crap we usually hear from the content industry), and they get their way, then clearly the system requires more protection for fair use. They might not have run this plan by all the suits at MPAA.

</comment><comment><USER9> Basically it looks like YouTube is too scared of lawsuits to acknowledge any fair use rights exist at all. Either you agree with ads, or your content is getting removed, the whole appeals process may work only if the content is not actually copyrighted, but is completely useless for fair use grounds as claimant can just repeat their claim of copyright ownership (which is true) and have it deleted anyway.

<comment><USER10> That's absurd. Youtube provided extensive avenues of dispute and appeal. I think Lionsgate is wrong in this case (although I'm not wholly sure, because using their source material for ~30% of the video is pretty substantial in my view), but Youtube isn't there to act as a court or arbitrator. by law, it has to respect the claims of copyright holders. It is not the agent of those seeking to use copyrighted material on fair use grounds. The authors dispute is with Lionsgate, not YouTube.

<comment><USER11> > _although I'm not wholly sure, because using their source material for ~30% > of the video is pretty substantial in my view_

It's a bit of a side track, but: Any commentary on a work could reasonably be expected to feature that work substantially, couldn't it?

<comment><USER10> I think there's a difference between quoting something in a review or as part of a presentation about film theory (or whatever), and quoting it in the context of a remix, where you're essentially engaging in fan-fiction first and commentary as a distant second (because the commentary is implicit and arguably subordinate to the entertainment function).

Now I am in favor of fairly wide latitude for this sort of reuse, which is a big reason I favor much, much shorter copyright terms, and graduated copyright at that (eg exclusive for 20 years, mandatory cheap licensing for the next 30, PD after that - for example). But it's hard to ignore the rightsholder's concern that this work is less about commentary than simply hitching a ride on a currently-popular franchise. It's not cashing in, since the person isn't trying to monetize it directly, but the person _is_ trying to build their creative reputation from rearrangement of others' work, while denying any and all revenue to the original creator.

As someone who has spent the last decade making films from scratch rather than remixing others' work, I think this is pretty weak sauce, just as I think that DJing falls far short of musicianship. I engage in both activities, but when I'm DJing I don't consider that to be creatively equivalent to composing something original. People who say all creativity is fungible are lying to themselves.

<comment><USER12> While a remix, it is also commentary on the work itself.

<comment><USER13> If that was the case, RiffTrax would be in the clear for releasing all their voiceovers with the original movies :)

<comment><USER12> Rifftrax is commercial, this is not

Rifftrax is additive, not transformitive

The person designated by the federal government to recommend who is exempt from DMCA restrictions recommended this work by name as an example of a work that would be hurt by not having exemptions to Decryption prohibitions. They considered it a valuable documentary.

>"Based on the video evidence presented, the Register is able to conclude that diminished quality likely would impair the criticism and comment contained in noncommercial videos. For example, the Register is able to perceive that Buffy vs Edward and other noncommercial videos would suffer significantly because of blurring and the loss of detail in characters' expression and sense of depth." -Recommendation of the Register of Copyrights, October 2012 (Page 133) Maria Pellante

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Takedowns on YouTube are, for corporations such as the record labels and movie studios, largely done under their ContentID system, not under the DMCA notice system. Google has a reputedly poor process for disputes that can lead to DMCA notices [1], but here it appears that the takedown was still ContentID rather than DMCA.

This is the one-sided system that the free market got us, where Google facilitates the removal of legal material. If you are lucky, you can get to the point where you follow the DMCA's rules.

[1] [http://arstechnica.com/tech-policy/2012/10/youtube- finally-o...](http://arstechnica.com/tech-policy/2012/10/youtube-finally- offers-a-meaningful-contentid-appeal-process/)

</comment><comment><USER15> So they got advertisment money based off something that was 2/3 content owned by another big media company?

<comment><USER16> Making money doesn't mean "not fair use." Just like not making money doesn't mean "fair use."

<comment><USER15> By 'they' I mean Lionsgate.

For a period the video was up, but with advertisement revenue going to Lionsgate. They were getting revenue from something that was largely someone else's copyright. In spirit, if they think they should be getting money, then Buffy's copyright holders should too.

Of course, neither should automatically be getting revenue, fair use and all.

<comment><USER17> > Of course, neither should automatically be getting revenue, fair use and > all.

that's not true - the author of the work should get revenue should they decide to (but only if they decide to). Lionsgate is not the author of the work. Some components of the work are from the copyrighted works owned by lionsgate, but that is due to fair use, and thus lionsgate has no claim on the copyright of the remix containing some of their stuff.

Fair use does not mean no revenue (nor does revenue even come into the argument!).

<comment><USER15> By neither I mean Liongate and the owners of Buffy.

</comment></comment></comment></comment></comment><comment><USER18> While I agree categorically with the necessity of allowing fair use, and the perniciousness of copyright cartels, I was nonetheless very tickled by this whine:

>But sure enough when I checked my channel, Lionsgate was monetizing my noncommercial fair use remix with ads for Nordstrom fall fashions which popped up over top of my gender critique of pop culture vampires.

</comment><comment><USER19> Google needs a policy against doing evil.

</comment><comment><USER20> Doesn't look like fair-use to me.

The rebelliouspixels version, with its extensive on-screen critique is fair- use since it appears to be a critique. But _if_ the original YouTube version lacked that, then the video devolves into little more than a fanfic video by a Buffy-loving Twilight-hater.

Even the rebelliouspixels version appears to contain far more "quoting" of the original material than is needed for its critique.

<comment><USER21> > This past summer, together with the Electronic Frontier Foundation, I even > screened the remix for the US Copyright Office at the 2012 hearings on > exemptions to the DMCA. Afterward my Buffy vs Edward remix was mentioned by > name in the official recommendations by the US Copyright Office on > exemptions to the DMCA as an example of a transformative noncommercial video > work.

It's definitely fair use.

<comment><USER20> Was the screening with the on-screen captions?

<comment><USER21> As to that, I have no idea. However, I would argue that the video is absolutely fair use even without the captions. Ignoring that its status as a critique is not strictly necessary for it to be fair use, the video would still be a critique without blatantly spelling out its point in words.

</comment></comment></comment></comment><comment><USER22> > This is what a broken copyright enforcement system looks like.

Alright, so how do we fix it? How can content producers protect themselves from legitimate copyright infringement on services such as YouTube that allow unverified uploads on a massive scale?

<comment><USER23> >How can content producers protect themselves from legitimate copyright infringement on services such as YouTube that allow unverified uploads on a massive scale?

That framing of the question is inherently biased. It assumes that if no good solution can be found, some bad solution that solves _that_ problem is the only alternative, regardless of whether it creates even more serious problems for other people.

It also assumes that the "problem" is sufficiently major to justify the implied "whatever it takes" approach to solving it. Notwithstanding that substantially all of Hollywood's collected works are available on The Pirate Bay and in a thousand other places, the studios continue to make record profits. While an elegant solution to the problem you mention would be convenient, the decidedly _inelegant_ approaches currently on the books or theorized by pundits are not inherently superior to the default alternative of doing nothing at all just because "something must be done" is a popular piece of political rhetoric.

</comment></comment><comment><USER24> I think he could have waited the two weeks to get an answer for his counter- notification before raising torches and pitchforks.

<comment><USER25> He's been responding, and responding to counter-responses, and then responding to secondary-takedowns, then counter-responding to secondary takedown denials for quite a while. I think it's appropriate to bring this into the public view.

<comment><USER26> Yeah he definitely did the due diligence before bringing it public...

On a side note, he did post his video here with popups that are basically an "American Pie" like parody of popups in films... except that I think the popups are supposed to be serious. They make watching the remix utterly impossible though. <http://www.rebelliouspixels.com/popupvideo/>

<comment><USER27> Direct link to the video: [http://www.rebelliouspixels.com/downloads/Buffy_vs_Edward_36...](http://www.rebelliouspixels.com/downloads/Buffy_vs_Edward_360p.mp4)

or [http://www.rebelliouspixels.com/downloads/Buffy_vs_Edward_36...](http://www.rebelliouspixels.com/downloads/Buffy_vs_Edward_360p.webm)

</comment></comment></comment></comment><comment><USER28> Buffy? Pfftt....how about Blade!

<comment><USER29> You do realize that the video critiques gender roles in pop culture?</comment></comment>


CISA Moves Forward: These 83 Senators Just Voted to Expand Surveillance - <AUTHOR> https://www.techdirt.com/articles/20151022/10133932597/cisa-moves-forward-these-83-senators-just-voted-to-expand-surveillance.shtml <comment><USER2> I continue to find it infuriating that the Republican party preaches "small government" and constantly fear-mongers about Obama forming a totalitarian government, and then they fail to vote against things like CISA.

Yes, I know that politicians say one thing and do another[1]. I just badly want to live in a world where people pay _some_ attention to what their officials are doing and hold them _slightly_ accountable, at the very least.

1\. [http://fivethirtyeight.com/features/john-kasich-a-jeb- bush-i...](http://fivethirtyeight.com/features/john-kasich-a-jeb-bush-in-jon- huntsman-clothing/)

</comment><comment><USER3> I am pleased to see my two senators rejecting this dreck, however it appears that they are in the minority.

I think this is a major loss. We can't encrypt our information or make technological solutions to totalitarian surveillance when our information is in the hands of backdoored companies, which we really can't avoid interfacing with.

We really need to put more pressure on the politicians via corporate rejections of legislation. They listen to money. Companies with cash to spare need to be taking the lead in forming super PACs etc to rail against the people who voted for this bill, especially during election season, but starting well before. These political problems don't go away on their own.</comment>


AMD Llano APU reviewed - <AUTHOR> http://tech.icrontic.com/articles/reviews/introducing-the-amd-llano-apu-and-socket-fm1/

<comment><USER2> I wonder if major pc manufacturers are going to pick it up.</comment>