What Can You Put in a Refrigerator? - <AUTHOR> http://prog21.dadgum.com/212.html <comment><USER2> The more I have to deal with corporate project management patterns, the more I think the whole approach behind specifications is wrong. Trying to focus on what the "domain objects" are and what is their flow is pointless, especially if you're dealing with real-world objects (like the fridge from TFA). You can model _something_ this way, but it will be usually the imaginary perfect path, a narrow vision of how things _should_ be done, that will break on first contact with the real world - a world that is messy and requires humans to improvise on the spot.

I'm starting to believe that one should focus on the workflow instead. After all, the reason for writing software as a tool is to simplify or automate some existing process. So focus on what people are already doing and what they're trying to achieve and find a way to remove repetitions, unnecessary delays, etc. Just look on what people are doing and find a way to do some parts of the process faster and better.

<comment><USER3> That's where user stories can help:

"As a user, I want to store my food and drinks in the refrigerator so they don't spoil"

"As a user, I want to store drinks in the refrigerator so I can drink them cold"

"As a user, I want to store my medicine in the refrigerator so it can stay below 25 C"

</comment></comment><comment><USER4> The original spec, "Anything that fits into a refrigerator," is a pretty darn good one. It conforms to Postel's law: "Be conservative in what you do, be liberal in what you accept from others".

We can develop a spec in a vacuum, but we can't be sure what users actually want from our refrigerator. Maybe a live penguin actually _does_ belong in there, as in the famous children's novel.

<comment><USER5> Can you put a baby or pet into a refrigerator? What about a freezer?

<comment><USER6> Well, it isn't the _refrigerator_ that's going to stop you.

<comment><USER7> Yes! Things shouldn't prevent all the crazy that's out in the world... Users will try to find creative ways around requirements, being more graceful in handling the crazy is usually appreciated

<comment><USER8> On the other hand "Make doing the right things easy and the wrong things hard" are good design rules. Putting something alive into a refrigerator and leaving it there, will probably make it dead. It might be a serious mistake by the end user. The smart refrigerator of the future might want to double check; "Are you sure you want to put the milk in the crib and the baby in the refrigerator?"

</comment></comment></comment></comment></comment><comment><USER9> "Any contained item that can fit inside a refrigerator, whose quality would degrade significantly more when kept at room temperature rather than at 1-4°C, by the estimated time of use/consumption."

The term "contained" above is restrictive, and probably needs further precision. Only things that thrive inside an opaque and sealed container would fit the definition above. Otherwise, things that can affect the quality of other items (i.e., gas emanation), things that need light, things that need oxygen, things that need a specific range of moisture, things that can grow and/or move, would all need their containers to provide these conditions and/or have a dedicated location inside the refrigerator.

<comment><USER10> * Puff pastry that needs to be chilled for five minutes so that the butter doesn't melt into the flour before you do the next roll.

* Jello that needs to be set

* Sprouted beans / seeds for which you want to restrict the rate of growth

<comment><USER9> "Any contained item that can fit inside a refrigerator, whose quality would be better if kept at 1-4°C rather than at room temperature by the time it's used/consume."

<comment><USER11> I've definitely just placed a stalk of broccoli on the bottom shelf of my fridge with no container.

<comment><USER12> I would argue that the broccoli contains itself, or perhaps that the skin/surface of the broccoli is the container. (Though some people would argue that all vegetables in the fridge should at least be bagged, to prevent transfer of germs/grime.)

</comment></comment></comment></comment></comment><comment><USER13> Anything the user decides to put in the refrigerator, provided we put warnings in small text on the document that accompanies the refrigerator for catogories of items we know to be unfit for the refrigerator so as to cover our asses if the user does not heed our warnings.

In terms of software, trying to decide up front for the user what they can do is the wrong approach. Even constraining them is flawed, with the exception of constraints for liability issues. What the user needs is the meas to express their decision making as to whether something should go into the fridge, so they need an input mechanism capable of doing selection, which has access to the context in which the item might be being placed into the fridge.

Does this sound like any configuration format you've ever used? The typical key-value stores which attempt to give you a declarative list of what you can put where, without the means to compute whether or not it might be a good idea first are almost ubiquitous, and the number of programs which take the right approach: give the user a proper, expressive programming language to configure the software, are few.

Just as it happens, we've developed ACME Refrigerator v2.0, which now allows you to store chocolate bars in it; a feature we missed in v1.0. Upgrade now for just $400.

The absurity of this idea with a fridge seems lost in software because we can upgrade at almost zero cost in just a few minutes, but that's only masking what is an obvious design flaw.

Which raises the question: What can you put in a software package definition?

</comment><comment><USER14> Fun read. This reminds me of how "object-oriented" programming goes wrong for beginners. ...Not helped, alas, by all of the texts that thing it's helpful to demonstrate OO concepts by modeling things like "cat is a subclass of animal" :/

<comment><USER15> Not to derail too much, but.

I had a textbook that started to explain OOP by basically saying "A dog is a class. A dog has a tail that can be in a wagging state or not. A dog has a name..."

And I'm sitting there thinking "No, dog's don't 'have' names. We call them names and they respond to names. They sometimes know their name. It's a different kind of 'have' than having a tail. I have a name for my dog. Should the person class have a dogs_name member variable now?" A tail is a subset of a dog. A name is a property of the abstract system in which the dog resides.

A class is a model of something else. You can model a dog with an object, but you can't know how good of a model it is unless you dig down into it and see where it breaks down. It _will_ break down, because software is an abstraction, and abstractions, being abstract, are _not_ the things they are abstractions of. And there are not many things that behave like OO objects because they are far too simple to represent reality in any high-fidelity sense. And it's dishonest to pretend they do.

Not to say there isn't some pedagogical advantage to using the analogy, I just think a better one could be used. Like talking about messages or something.

<comment><USER16> Hopefully it wasn't "POOP": [http://www.amazon.com/gp/product/1878739441](http://www.amazon.com/gp/product/1878739441).

</comment></comment></comment><comment><USER17> This essay assumes the wrong answer. The intelligence has to be built into the item, not the appliance, just as we do now. Packages have messages such as "Refrigerate after opening" on them. Anything that needs to be refrigerated will need to communicate that need, along with details such as temp, to the automated system.

<comment><USER18> Best before dates are a waste of time. I noticed this travelling in less devloped countries where they don't usually have them. And plenty of times I have had chicken that smells off despite being before the date on the packet. I had one cheese that got way better after being a month past the date.

<comment><USER19> Best before dates are a really good idea if you want to reduce the number of food poisonings in a large population. Food is (statistically) very safe before the best before date, assuming proper storage. Most of the time it's still safe well past that date, but you would dramatically increase the number of people who get sick.

It's the same with pasteurized milk. Unpasteurized milk is mostly safe to drink, but occasionally you get really sick. In a large population the difference is noticeable.

Again the same with the much stricter cleanliness rules for restaurants and the like. Usually it's safe to store prepared food without refrigeration for a day, restaurants mustn't. It's also mostly safe to cook on a dirty stove, restaurants mustn't. The difference between your home kitchen and the restaurant is the number of people served.

<comment> nommm-nommm Best before dates have nothing to do with safety, they are about quality. They are (mostly) voluntary and set by the manufacturer.

[http://www.webmd.com/a-to-z-guides/features/do-food- expirati...](http://www.webmd.com/a-to-z-guides/features/do-food-expiration- dates-matter)

</comment></comment></comment></comment><comment><USER20> The question is wrong, as it stands the answer is "any non-fluid or contained fluid that will fit".

"What should one store in a refrigerator?" is a better question.

<comment><USER21> I would argue that pretty much anything you would put into your refrigerator is contained inside packaging. Sometimes that packaging is just a simple plate.

<comment><USER2> I put a cat in the refrigerator more than once - for some reason, my cats loved sitting there for few mintues long when there were young. There were definitely _not_ packaged.

</comment></comment></comment><comment><USER22> It reminds me of this "What is a Photocopier?"

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

</comment><comment><USER23> "Anything that fits in the refrigerator and will remain contained within it." Covers all uses for refrigerators and prevents anyone from putting bulk liquids, penguins, coyotes, live hand grenades, radioactive material, nuclear weapons or Indiana Jones inside.

<comment><USER24> But not pet hamsters!

</comment></comment><comment><USER25> Reminds me of a question I have been wondering about: Can you formally specify what is the purpose of a suitcase?

In principle, you could dump all your clothes, toiletries, etc. in a pile on the airport checkin counter, and if system were organized enough, it could deliver all your stuff to hawaii and lay it all out on the hotel bed for you.

E.g., a robot would scan all your belongings at the airport, and dump them all into a big pipe... each item would get properly routed to your hotel room... kinda like how the internets work!

Is it just a question of organization? "Everything in this suitcase belongs to this person and should move together to the same destination."

<comment><USER26> > kinda like how the internets work!

Using this analogy, isn't a suitcase roughly equivalent to a packet? It's tagged with source/destination, and basically standardised so the routing gear doesn't need to care about the specific items you are routing.

<comment><USER27> You know, I think the analogy might actually be the wrong way round....

</comment></comment></comment><comment><USER28> Bacon, cheese, steak, and bottled beer. Being single sure makes writing specs easier.

<comment><USER25> don't forget ketchup.

<comment><USER29> Heathen!

</comment></comment></comment><comment><USER30> I think this is hinting at the problem that occurs in OOP, when the business rules of the system are expressed with virtual methods in classes as part of an inheritance chain, in the business domain

Example: eric lippert tries to model an RPG in OOP and tries to model the character "uses" command: [http://ericlippert.com/2015/05/11/wizards-and- warriors-part-...](http://ericlippert.com/2015/05/11/wizards-and-warriors- part-five/)

</comment><comment><USER31> Anything that you can fit in and that you can also easily get out again.

(The latter requirement rules out not only liquids but also e.g. a pile of salt or rice.)

<comment><USER32> So, your pet cat?

</comment></comment><comment><USER33> If this is how you're defining requirements for software or new product creation you're doing it wrong.

The goal should never be to describe every single outcome or scenario- the goal should be to build understanding between business/product/development team so that they understand the point of the work that the software replaces. It's no different with hardware or really any new product creation. The goal is to create a conversation that gets us to solving the problem- when the spec gets to covering all cases the chances we get this wrong and stray from solving the actual problem goes up massively.

<comment><USER34> The article is making a point about understanding or what happens in a conversation for something like requirements, neither you nor him provided an exact answer as to how to define requirements, because it's something we havn't yet been able to automate.

Also it's starting a conversation about the very topic..

<comment><USER33> Good point- that all said, if we're automating requirements we're not solving the problems that tend to matter. The key to requirements building is in the process. The best process I've found so far is User Story Mapping (Jeff Patton has an amazing book on it)

</comment></comment></comment><comment><USER35> I say we make a refrigerator library; then anyone can define a refrigerator within the library; then we can call the function and apply it to out arbitrary needs. #include <refrigerator.h>

<comment><USER36> Wrong. We need refrigeration factory that returns a class called RealRefrigerator that extends AbstractRefrigerator and implementing IRefrigerator, which then must be DI by configuring external XML (bonus points if the xml itself is stored in the database, so no way to reach the config with grep).

The outdated approach of if (food.canSpoil()) { refrigerator.put(food) } was too burdensome and did not conform to all of the best practices.

</comment></comment><comment><USER37> Amazing how many people try to create a specification without knowing the problem.

A specification should be for a solution to a problem - "We need a way to keep xxxxx cool". That problem defines what needs to go into the refrigerator from the outset.

What's the actual problem space here ?

</comment><comment><USER38> You can sometimes explain better by a set of examples rather than an explicit categorical description. The base set of examples I started with is what my mother put in her refrigerator.

</comment><comment><USER39> I'm reminded of an excellent quote from Bertrand Russell:

"Everything is vague to a degree you do not realize till you have tried to make it precise."

</comment><comment><USER40> cream, mayonnaise, ketchup, soda and PAPER, SNOW, A GHOST.

\- Joey Tribbiani, Friends episode 10.11

</comment><comment><USER41> The penguin line made me lol.

</comment><comment><USER42> I'm going to repost something I had said in response to this article on another site. I think it's an awesome example of what can happen when you create a language with extensibility in mind.

\</comment><comment></comment><comment></comment><comment>-

Scala solves this problem really well with typeclasses.

You can define a typeclass like

        case class Refrigerated[T](thing: T) // this is just something holding things that have been refrigerated.
        trait Refrigeratable[T] { // this is the typeclass
          def refrigerate(thing: T): Refrigerated[T]
        }

Now we have a refrigerated object that holds some object that's been refrigerated, and it looks like I'm about to do some class composition, but I'm not. Bear with me.

Now, we have some sort of data class

        case class Pillow(fluffiness: Int, warmness: Int)

Pretty straight forward, we now have a Pillow with measurable fluffiness and warmth

Next, lets implement refrigerated for pillow.

        implicit val pillowRefrigerable: Refrigerable[Pillow] = new Refrigerable[Pillow] {
          def refrigerate(pillow: Pillow): Refrigerated[T] =
            Refrigerated(pillow.copy(warmness = pillow.warmness / 2))
        }

So there's an implementation of Refrigerable for pillow. Refrigerating a pillow just cuts the warmness in half.

So actually using the Refrigerable stuff. There's two ways to go about this. One way is to just use the Refrigerable instance to refrigerate the pillow.

        def refrigeratePillow(pillow: Pillow): Refrigerated[Pillow] = pillowRefrigerable.refrigerate(pillow)

Nothing special there. You could basically do that in any language. So how does scala do it better? Well, we can define a refrigerate method for anything Refrigerable like this:

        def refrigerate[T](thing: T)(implicit refrigerableInstance: Refrigerable[T]): Refrigerated[T] =
          refrigerableInstance.refrigerate(thing)

Now this is really cool. Anything type that we have a Refrigerable instance for, can be used as an argument for refrigerate. And we don't have to explicitly state what Refrigerable instance we're using. Calling it looks like

        val refrigeratedThing = refrigerate(anythingWithARefrigerableInstanceHere)

Okay. We still haven't gained a whole lot. All we've done so far, is make it so we don't have to explicitly state what Refrigerable to use. So let's go an extra step. Let's make it so we just call refrigerate on the Object itself rather than passing the object as an argument to a method. This is possible, because scala let's us make extension methods for generics.

        implicit class RefrigerableOps[T](thing: T)(implicit refrigerableInstance: Refrigerable[T]) {
          def refrigerate: Refrigerated[T] = refrigerableInstance.refrigerate(thing)
        }

Okay, now this is really cool. We've defined a method for any type for which we have Refrigerable in scope. This means we can now refrigerate our pillow more easily:

        val refrigeratedPillow = myPillow.refrigerate

What?! That's great! And it gets better. Now that we've implemented this boilerplate, giving other things this wonderful syntax is easy. Let's say I want to refrigerate my cousin, because she's too hot.

        case class Cousin(hotness: Int)
        implicit val refrigerableCousin: Refrigerable[Cousin] = new Refrigerable[Cousin] {
          def refrigerate(cousin: Cousin) =
            Refrigerated(cousin.copy(hotness = cousin.hotness - 1))
        }

Now we can make our cousin less hot! Great!

        val refrigeratedCousin = cousin.refrigerate

This is basically a good way to make things open to extension without subclassing it's awesome!

You can even do more to simplify making the Refrigerable instances. You can effectively make them one liners.

</comment><comment><USER43> A porpoise</comment>


John Tierney: Why people can handle the truth regarding their own DNA. - <AUTHOR> http://www.nytimes.com/2011/01/18/science/18tier.html?_r=1&src=me&ref=science

<comment><USER2> I can handle the truth. I'm quite a bit more skeptical about my insurance company, big pharma, and the other "players" in an already gamed system.</comment>


Working Effectively with Unit Tests - <AUTHOR> http://blog.fogcreek.com/working-effectively-with-unit-tests-interview-with-jay-fields/ <comment><USER2> I constantly have problems with people posting the same information on unit tests, again and again. I know how to set up (for example) RSpec, MiniTest, Cucumber, FactoryGirl. The thing that people struggle with is how to use these in a larger, practical sense, rather than in just the trivial. I think this puts a lot of people off testing.

<comment><USER3> Agreed. I have only used TDD once as a front-end web developer, and I've found that I do struggle with the practicality of it. I spent half my time managing and maintaining my tests. When I did the math, It seemed that all that extra time spent was more than It would have taken to simply chase down bugs that would have arisen in a non-tdd environment. It just seems to take more time than is practical. Especially in agile startups.

<comment><USER4> Perhaps. The difference is that in one case you'll have the machine automatically tell you when and why your code stops working because of a regression, and in the other you have no clue until the customer hits it. It's not only about proving it worked once, it's about proving it with every commit.

</comment></comment></comment><comment><USER5> A nice article, and I think I should add the book to my (already too large) to-read pile.

I totally agree with "DRY might not be great in all cases" \- In tests, it's often better to make each single test as expressive as possible. I once read (and forgot who said it):

"Code should be either DRY (don't repeat yourself) or WET (write expressive tests), but never damp)"

And here's a shameless plug: I recently wrote an article about how tests can help you achieve simple design, and the next article in the series will be coming soon: [http://quickglance.at/en/simple_design/passes_its_tests](http://quickglance.at/en/simple_design/passes_its_tests)

<comment><USER6> > "Code should be either DRY (don't repeat yourself) or WET (write expressive > tests), but never damp)

I'm getting so tired of people who try to capture the intricacies and complexities of our profession with witty one liners that have to be taken like dogma.

Just use your common sense, let your experience guide you and if you're not sure about something, ask your teammates.

<comment><USER5> Who says that they have to be taken like dogma? Sometimes the one-liners are just easy to remember. Often they are funny. They can be a great tool to quickly illustrate a point or start a conversation.

The one liners can never replace a conversation or explanation. They cannot replace common sense or real knowlege. I would never treat them as laws or follow them by the letter...

</comment></comment></comment><comment><USER7> This is one of the most sensible articles I have seen on unit testing. Rather than religiously insist on tests first or 100% coverage, judge when it is valuable to have these things and when they are not important. Far too many articles on testing test the framework / language being used.

</comment><comment><USER8> I like Jay's comments about how tests are wasted if you don't know exactly what you want, and just try out different things (because then you need to change/delete the tests when you end up changing your code).

As for common mistakes with unit tests, my top 5 list is:

1\. Testing algorithms together with coordinators.

2\. Mocking too much.

3\. Not using asserts.

4\. Leaving print statements in the tests.

5\. Checking the log statements, not the result.

More details here: 5 Unit Testing Mistakes [http://henrikwarne.com/2014/02/19/5-unit-testing- mistakes/](http://henrikwarne.com/2014/02/19/5-unit-testing-mistakes/)

<comment><USER9> Here is another one: failing to understand that tests introduce additional maintenance and design overhead.

Quis custodiet ipsos custodes?

Tests are additional code that is tightly coupled to the target code that is meant to be used in production. This additional code requires design, debugging, and maintenance just like the target code. It is also tightly coupled to the target codebase: a change in either necessitates at least an inspection to determine what, if any, changes must then be made in the other.

This all adds overhead to the whole process, and too often I see casual, glib statements implying or even asserting that the overhead is nonexistent or else pays for itself. It isn't free and it is especially not free the more dogmatic the test proponents and tests themselves are.

<comment><USER10> Your complaints are actually the whole reason tests exist. Of course you know that your code works when you write it. You then write tests that are tightly coupled to the behavior that you require from the code to run it through its paces as you work on it.

Speaking of coupling, tests prevent tight coupling between different pieces of your codebase. Since there are then at least 2 consumers of any piece of code, the implementation does not get coupled to a particular one as easily.

Also, if you would like to work with a module or microservice based approach, tests are simply necessary to work. If you're storing different pieces of the codebase in different repos, you will need to have tests to work on them at all.

Basically, if you are "testing" your production code with other pieces of your production code (I hope you don't do this), it will become tightly coupled. Test your code with tests.

<comment><USER9> I'm not sure we disagree about the purpose and utility of tests. I certainly was not complaining about tests. If anything, I was complaining that too often, in my experience at least, it seems to be presented as an undeniable truism that, generically, 'tests' are always a benefit, and usually the more tests the better.

My point is that tests (at least, unit/integration tests of the variety usually mentioned in TDD) are more code that has to be maintained (and designed, and debugged). They incur overhead and as such impinge on development resources. As a result tests introduce the need for considering tradeoffs between developing tests and developing the software product itself. Simply writing tests for the sake of having tests to test code is naive; at least as naive as assuming that once working a given piece of code works forever, but it is a mistake that I've witnessed on more than one occasion.

</comment></comment></comment></comment><comment><USER11> I write lots of unit tests. One thing I'm struggling with now is the organization of a large number of tests. It's hard to know what I have tests for without going into my tests directory and reading comments. Even then, I feel like I could do more to have a "big picture" overview of my testing strategy rather than seeing a bunch of one-off tests. I haven't quite figured out what that should look like.

I think the IDE could do more in some cases. For example, when unit testing a method, I'd like to be able to tag a reference to the method I'm testing. Then, when I'm in my code, my IDE could show me the docstrings of tests I have for that method.

It's the difference between "hello world" and software design principles used to build large scale systems. I see lots of "hello world" for testing, but not much of the other side. Does anyone have suggestions?

<comment><USER12> The way I personally solve this problem is by organizing my code and my tests in a similar structure. Split application code up into reasonable files, and split the tests up the same way. Depending on your language/test framework, it also helps to put the test right next to the code... i.e. in Go, you can have component.go and component_test.go in the same directory.

I do agree though that it would be nice to see an IDE have some smarts about tests...

</comment></comment><comment><USER6> Terrible audio. Next time you interview someone, ask them to install Audacity and to run it during the interview. Then have them send you the audio file via Google Drive.

</comment><comment><USER13> I have to say that the trade-off argument brought up between DRY and readability is pretty lame. If you have a junior developer who can't make sense of the test because you put the test data in a separate class or are using a setup method, then teach him or her how to trace the call to the setup method and then read through it.

If we follow this logic then all code should follow the same methodology of readability because tracing through method calls is too cumbersome. Obviously that isn't the case for most code, so why would it be true for unit tests?

<comment><USER10> Part of the benefit of tests is that they are a form of documentation.

<comment><USER13> I don't think having readable tests and DRY are necessarily mutually- exclusive. If you name methods and variables with lengthy but very descriptive names your tests can still be readable. In fact the more you modularize your setup methods the more readable they can become. For example:

TestData.CreatePerson();

TestData.AddSsnToPerson();

TestData.PersonModule.checkWhetherPersonHasValidSsn();

...is pretty readable despite being broken up. It may or may not be true that if you just went through the setup here it may be more readable, but the benefit to this approach is that you only have to write a method to add an SSN to a person object one time and then everyone can use it without needing to understand the structure of different objects. Notwithstanding readability, I would argue that DRY makes _writing_ tests easier than cramming a bunch of setters into every test case. Once somebody understands what a setup method does, in every place that it is used in other tests the tester can skip over that part and move on to testing their specific use case.

</comment></comment></comment><comment><USER14> Much of what passes for testing is a near-criminal waste of corporate resources. I've seen so much rubbish test code.

<comment><USER15> Tests are a great thing when everyone involved understands their value. In my former team we had a big number of unit & integration tests that saved my ass many times.

On the other hand, when the team has a KPI "we need a big test coverage!" and people are lazy or simply bad developers, you end up with a code like

      try {
        runTheWholeApp()
      } catch (e) {}
      assertTrue(itRan)

<comment><USER16> Mutation Testing can test your tests in these situations.

Well actually if the organization is that dysfunctional it's probably game over, but Mutation Testing can catch you when you do this accidentally.

</comment></comment></comment><comment><USER17> Does anyone have any resources for best practices unit testing web apps written with frameworks like Django, Rails, etc? Whenever I try to apply TDD to a framework, I find myself testing the functionality of the framework (which should already be tested), rather than my app itself. How do you decide what to test when you are effectively cobbling together framework concepts? Is this the time for focus on integration tests over unit tests?

</comment><comment><USER18> I wish the audio quality was a little better. Is there any post process work that can be done to improve the quality?

<comment><AUTHOR> Sadly that's with post-processing improvements. Without the guests recording their own audio and then syncing it after (which is something of a big ask), we're reliant on the quality of the connection. Something to work on for sure. I'm hopeful solutions like [http://podclear.com](http://podclear.com) can help.

</comment></comment><comment><USER19> For tests we should use DAMP, Descriptive And Meaningful Phrases, instead of full DRY

</comment><comment><USER20> Rant about "unity". The idea of unity is vague. Almost every person has a different definition of unity. Do not think about unity think about granularity, or even better facets of behavior. The amount of integration can scale to infinity. You can have infinity layers of integration between unity and end2end tests. The attempt to classify granularity is a waste of time.

</comment><comment><USER21> You may want to invest a few bucks in a good mic.

<comment><AUTHOR> Yeah, sorry about that. Derrick has one, but was moving house at the time of recording and it was packed away. So future ones should be using that, at least on the host side.</comment></comment>


A U.S. Bomber Crashed on Greenland with 4 Nukes aboard in 1968 - <AUTHOR> https://www.fastcompany.com/40518772/thule-accident-nuclear-weapon-lost-greenland-us-denmark <comment><USER2> As I've mentioned before, we dropped nukes all over the place until we changed our policy about 1970, after dropping four nukes on Franco's Spain. We did a lot of crazy things during the Cold War. These stories seem eternally popular on HN.

<comment><USER3> Sounds legit.

<comment><USER3> To be clear, "dropped" is different than "lost". When someone describes dropping a bomb they're describing an intentional explosion.

<comment><USER2> Nope, I mean dropped as in the first definition, as in fell out of the airplane, plummeting pell-mell towards the Earth

<comment><USER4> When people read about "dropping four nukes on Franco's Spain" they will think it means deliberately dropping four nukes with the intent of exploding them.

You may have had a different meaning of "dropped four nukes" in mind, but when the common everyday meaning of a phrase is one thing, and you mean a different thing, it helps everyone if you can be clear and specific about what you're actually referring to.

<comment><USER5> I would think most people would be aware that the US has never nuked Spain and reconsider that initial interpretation.

</comment></comment></comment></comment></comment></comment><comment><USER6> Or that time a U.S. Bomber crashed on U.S. soil (North Carolina) with 2 nukes on board during a training mission; one of which was armed!

Link: [https://en.wikipedia.org/wiki/1961_Goldsboro_B-52_crash](https://en.wikipedia.org/wiki/1961_Goldsboro_B-52_crash)

<comment><USER7> Even if it was armed, it would be unlikely to go off. Here is a quote from a missile silo accident: [https://www.armytimes.com/news/2017/11/04/details-of- south-d...](https://www.armytimes.com/news/2017/11/04/details-of-south-dakota- nuclear-missile-accident-released/)

"Incredible as it may sound to a civilian, Hicks said he spent no time worrying about the thermonuclear warhead. He had been convinced by his training that it was nearly impossible to detonate a warhead accidentally. Among other things, he said, the warhead had to receive codes from the launch- control officers, had to reach a certain altitude, and had to detect a certain amount of acceleration and G-force. There were so many safeguards built in, Hicks later joked, that a warhead might have been lucky to detonate even when it was supposed to."

<comment><USER8> Some folks who knew more than you and I seemed to think there was potential for a nuclear disaster.

> In 2011, Lt. Jack Revelle, the bomb disposal expert responsible for > disarming the device, claimed "we came damn close" to a nuclear detonation > that would have completely changed much of eastern North Carolina

> In a now-declassified 1969 report, entitled "Goldsboro Revisited", written > by Parker F. Jones, a supervisor of nuclear safety at Sandia National > Laboratories, Jones said that "one simple, dynamo-technology, low voltage > switch stood between the United States and a major catastrophe", and > concluded that "The MK 39 Mod 2 bomb did not possess adequate safety for the > airborne alert role in the B-52".

</comment></comment></comment><comment><USER9> And Bayes Rule was used to find one of the bombs:

[https://en.wikipedia.org/wiki/1966_Palomares_B-52_crash#Weap...](https://en.wikipedia.org/wiki/1966_Palomares_B-52_crash#Weapons_recovery)

[https://en.wikipedia.org/wiki/Bayesian_search_theory](https://en.wikipedia.org/wiki/Bayesian_search_theory)</comment>


yGuard – An open-source Java obfuscation tool - <AUTHOR> https://github.com/yWorks/yGuard <comment><AUTHOR> Recently here at yWorks we have refactored yGuard to be distributed under MIT licensed. As a goodie for new year, we'll share it with you!

<comment><USER2> Not going to use yGuard anywhere, but thanks for opensourcing it. On the other hand, I stumbled upon yEd some time ago and it has been my go-to tool for diagrams ever since. Thanks to all the folks at yWorks that work on yEd !

</comment></comment><comment><USER3> What is the modern use case for byte code obfuscation? It cannot provide any strong protection against reverse engineering, so what's the point?

<comment><USER4> Perhaps it's being open sourced because there's no longer a market for this sort of thing.

<comment><USER5> It's been free before. It's not that we made money with it.

</comment></comment></comment><comment> half-kh-hacker As someone also working in the Java obfuscation space, it's cool to see old obfuscators becoming open-source.

yGuard seems to only provide shrinking and remapping at this moment in time, however. Heavier-duty obfuscators will also incorporate various other transforms (like concealing string constants) to make the code harder to read.

<comment><USER6> Does it affect performance?

<comment> half-kh-hacker A little, but you can balance the obfuscation's complexity so that the HotSpot JIT is able to inline the transform.

Of course, this comes with a trade-off that custom deobfuscation transformers will also be able to inline these, but that's theoretically possible for every transform, anyway, since you can try some symbolic execution until you get the string values back out.

</comment></comment></comment><comment><USER7> It's kind of ironic that code used for proprietary purposes is open-sourced.

Thank you for open-sourcing it.

However, I hope I will never use this (or any such similar) piece of code.

</comment><comment><USER8> I thought people use spring for that :)

</comment><comment><USER9> It's not obvious to me, unfortunately - what exactly is being obfuscated here, the source code?

<comment><AUTHOR> The java byte code residing inside your JAR(s). It will be disassembled using ASM7, then obfuscated and reassembled.</comment></comment>


Head Space: Behind 10,000 Years of Artificial Cranial Modification - <AUTHOR> http://www.atlasobscura.com/articles/head-space-artificial-cranial-deformation

<comment><USER2> I'd like to know if this increases intelligence, the article states it does not decrease intelligence, and this article: [http://www.theguardian.com/uk/2003/sep/28/research.health](http://www.theguardian.com/uk/2003/sep/28/research.health) states that the important brain growth occurs during early childhood. Some of the brain cases in the pictures look 50% larger.

<comment> maze-le I doubt it. Intellect is not --only-- determined by the brain size, but by the interconnectivity of the neurons in the brain and maybe several dozen other parameters we don't understand (like: individual neurochemistry; the rate by wich new connections are established etc.).

Also, the article states:

> subsequent research has led experts to believe that cranial modification has > no impact on cognitive function, nor is there a difference in cranial > capacity.

So, these heads only look big. The volume of the cranial cavity doen't seem to change. Where normal heads are small but volouminous, these heads are big but narrow.</comment></comment>


Mars rover reaches Endeavour crater, finds signs of ancient Martian water - <AUTHOR> http://arstechnica.com/science/news/2012/05/the-opportunity-rover-endeavours-to-find-signs-of-ancient-martian-water.ars <comment><USER2> _> Over seven years into its (originally) 90-day mission, the Mars rover Opportunity arrived at the rim of Endeavour Crater._

This is absolutely amazing engineering. I would love to see NASA double down on robotic exploration (and mining) of the solar system for the next decade or two.

Really advance the state of art of robotics, make discoveries that would be extremely difficult and costly for people to do, and get many more missions per/dollar than a manned program could.

<comment><USER3> _> This is absolutely amazing engineering._

It was also luck.

The rovers had their power requirements and solar panels designed so that 90 days of mission could pass before getting occluded by martian dust. Once on Mars NASA discovered that occasional whirlwinds, which existence was unknown during mission planing, cleaned the panels back to usable current output levels.

<comment><USER4> Serious question: why not have wiper blades?

I'm having a hard time accepting we can land a rover on another planet, but we can't find a way to clean some dust off of it.

<comment><USER5> Fans would be a smarter solution. Wiper blades plus dust and dirt = a mess, not necessarily clean solar panels. Engineering something that would be reliable on Mars would be rather difficult, and would add mass and complexity to the rovers, which would take away from the mass needed for other instruments and time needed for testing everything else. Also, dust buildup on the solar panels was only one factor limiting the expected lifetime of the rovers, so instead they chose to balance the engineering of the vehicle and concentrate on hitting the base mission lifetime expectancy.

<comment><USER6> Reasonably sized fans wouldn't work in Martian atmosphere..

</comment></comment></comment></comment></comment><comment><USER7> Another nail in the 'dry Mars' hypothesis. Fascinating stuff of course, it will get really interesting when Curiosity gets there. Looking forward to that!

<comment><USER8> The "dry Mars" hypothesis has been dead for decades. At this point we have about as much evidence for water on Mars as we have for water on Earth.

The media is always keen on every new "omg, there was once water on Mars" discovery, but we've moved on to trying to figure out the details; where, when, how much, where did it go?

<comment><USER9> _At this point we have about as much evidence for water on Mars as we have for water on Earth_

Be careful with language like that. Sloppy journalists might turn that into a "we need to balance both sides of the story" and we'll wind up with people denying the existence of water on Earth.

<comment><USER5> [http://www.smbc-comics.com/index.php?db=comics&id=2376#c...](http://www.smbc- comics.com/index.php?db=comics&id=2376#comic)

</comment></comment></comment></comment><comment><USER10> Recommended reading for Mars rover fans: a diary of a Mars rover driver.

<http://marsandme.blogspot.com/>

</comment><comment><USER11> Woooow. Makes you think twice about panspermia theory, being descendants of Martians.. (latter is Neil Tyson comment)</comment>


Editable WebGL Car with post processing effects - <AUTHOR> https://clara.io/view/d3b82831-d56b-462f-b30c-500ea1c7f870/webgl

<comment><USER2> Hmmm. Black canvas with the following in the console on Chrome OS: [.WebGLRenderingContext]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glClear: framebuffer incomplete (clear)</comment>


New technique increases 3-D printing speed by 1k to 10k times - <AUTHOR> https://phys.org/news/2019-12-technique-d.html <comment><USER2> How is this different than photolithography?

<comment><USER3> It seems more like holography.</comment></comment>


Original Linux announcement - <AUTHOR> http://groups.google.com/group/comp.os.minix/browse_thread/thread/76536d1fb451ac60/0b46287f469f6ef5?lnk=st&q=&rnum=1#0b46287f469f6ef5 <comment><AUTHOR> There's currently a thread about spamming mailing lists to announce your product, so I thought I'd dig up some of the original announcements of some successful products so people can see what a good one looks like.</comment>


Starting up: Registering a company - <AUTHOR>

We are trying to startup and now we are on the stage when we'll need to have our legal company.
Any advice will be helpful and appreciated - I do have a lot of questions, cause I never did that myself before.
1) When it is smart and necessary to create a company? -- we are about to launch and provide paid services. I know we can still act as a private person, but then all the legal actions (if any :-) will be against private person, and it will be persons' responsibility. Companies like "protect" people against that, right?
2) Which type is preferable - C-Corp or S-Corp? We will be looking for funding - angel or VC, so need to think ahead not to have this as a problem to get funds.
3) How to register company easier? I found a bunch  of sites, but which one is better? Any experience?
4) We are living in California, and company needs to be in California or in Delaware (I heard that last one is easier with the taxes questions, etc.?) What happens if we'll relocate eventually to different state?
5) Do we need to have an office address? Or some specific P.O. Box? We are living in apartments, so we definitely will move, so all the addresses are kind of "temporary" ;-)
6) Where can I find information on which tax forms do we need to fill and when? For the company? We do not suppose to have a lot of going on there for now, so I hope to be able to do that myself, but need some guides...
7) Any rules or guides on how we need to log our investments into this company? I.e. my partner invested 5k and me invested 6k, so do we need to put this legally somehow? We trust each other, so we don't really need that, but may be it's legally required?
8) Do we need business account (checking, credit)? Probably we don't need it, but may be it will be smart to open small business credit line from the very beginning to grow eventually?
...and anything else you can add. Thanks! <comment><USER3> I am in the process of writing this up as the next chapter of my online book but a family emergency came up so rather than waiting, I will just repost an earlier comment.

<http://www.StartupForLess.com>

Assuming your are a bootstrapper meaning that you have a few co-Founders who are the key contributors and can each afford to not take salaries for at least two years to get the product off the ground, then your best bet is to form a LLC (Limited Liability Company). Keep in mind that bootstrapping is not a permanent state of mind but rather a pramatic approach to build a viable company and maximize your chance of success as well as your networth. If the old argument was "A small slice of a larger pie is better than a large slice of a small pie", bootstrappers are all about getting a "medium slice of a medium pie". The idea here is that you want to take the company to a point that if you still need money from a VC, you take money when all you need is money.

 __ __ __ __ __ __ __*

My experience is that LLC (Limited Liability Company) is a much better vehicle for starting a company than a S-Corp. LLC is an interesting hybrid between a corporation (S or C) and a partnership.

Legally LLC is not a corporation but more like a partnership. But it is an effective shield for limiting your personal liability the same way that a corporation would, yet at the same time, doesn't require the declaration of a liability-bearing general partner which is what you have to do with a Limited Liability Partnership (LLP).

Also, from the customer perspective, an LLC sounds a lot like a corporation so it doesn't have the stigma that comes with an LLP (people think of dentist, doctor and lawyer when you present them a business card that says LLP). Just like LLP or a S-Corp, an LLC is not a taxable entity so losses and profits can flow directly to the partners.

On the other hand, unlike an S-Corp, the profit and loss can be distributed anyway that is agreeable to the partners and not necessary according to the percentage ownership, which is very convenient.

Also, LLC has no limitation on foreign ownership or ownership by another corporation (Until it became AT&T again, Cingular was a LLC owned by SBC and BellSouth).

All it takes to form a LLC is an operating agreement, which is not even a legal document and does not need to be filed. So you don't need a lawyer to do what is basically common sense. So be sure you spell out the ownership structure of the LLC (there is no reason why it has to be equal but there is no reason why it cannot be, so whatever is agreeable to all partners is fine).

But be sure to spell out the circumstances when a particular partner is deemed non-contributing and therefore can be invited out by the rest of the partnership. Also, spell out what happens to his/her shares if any partner was to resign, to be terminated with and without clause, incapacitated and death (either work-related or not).

So a typical solution is to give everyone three or four years to vest and everyone agree that any shares that are unvested can be repurchased by the remaining partners at the original price. Also, make sure that everyone agrees to a right-of-first-refusal and a co-sale arrangement so that if one partner decides to sell his/her vested shares, everyone else has the right to either buy the shares or to sell part of their own vested shares to the same outside buyer at the same time.

Furthermore, make sure you put a price on the shares so that everyone writes a check and buy the shares outright (which can be very low so that the total is on the order of a few hundred dollars). This is very important because once the stock is purchased, you have started the clock for capital gain and keep in mind that these are 1244 stock which means that if you keep them for five years (which you probably will since that's how long it will take to build a company if not more), then only half of your capital gain is taxable.

There are other benefits as well but the most important one is that if you ever leave your own startup, you can walk away with property that you already owned and you don't have to worry about exercising your options and get hit with Alternate Minimum Tax (AMT).

On the other hand, for working capital, ask everyone to put in the cash as an interest-bearing loan so that when the company starts making profits, you can get the money back without any tax consequence.

Also, even as a LLC, you can elect to file your tax return as a S-Corp. This is important because as you continue to bootstrap your company, instead of paying the partners salaries, you can pay everyone a nominal stipend (which is subject to payroll tax) and declare the rest dividend, which is not subject to self-employment tax (it would be if you file tax return as a LLC).

Finally, when you are ready to take VC money, they will want to bring in a high-power lawyer and chances are that they will want you to form a C-Corp. By then, you can do a tax-free transfer between assets of the LLC and shares of the new company. The VC's are going to put a vesting schedule on your new shares, which you will need to negotiate. But hopefully by then you have some leverage (like customers and profitability) and you can negotiate from a position of strength.

But the most important issue here is that with a C-Corp you can start from a clean slate which is what the VC's want.

Hope this helps.

\--Denny--

Denny K Miu

<comment><USER4> The material about LLC is in the following chapter ...

<http://www.lovemytool.com/blog/2008/01/bootstrapping.html>

</comment></comment><comment><USER5> 1) [http://novcrequired.com/2007/should-you-incorporate-your- con...](http://novcrequired.com/2007/should-you-incorporate-your-consumer-web- startup/)

2) C-Corp if you plan on getting any investors. (S-Corps are easier to deal with come tax time, but have significant limitations concerning investors.)

3) Nolo (<http://www.nolo.com/>) has been suggested

4) Delaware is usually advised.

5) I always use my parents' address. They haven't moved in 20 years. I'm not positive, but I'm pretty sure your real operating address doesn't have to be the same as what your incorporation papers say.

6) I have yet to find a good resource for this.

7) Set a valuation of the company, and divide it by how many shares are outstanding. That is the share price. You can buy shares at that price. After that, issue paper stock certificates and record it in your general ledger (most general ledger software (IE QuickBooks) has a whole section for "Owner's Equity"). Going forward, don't forget to issue stock for "sweat equity" on a vesting schedule. (I always get confused about the differences in shares declared vs outstanding vs issued. But I think this is right)

8) I always open a business checking account and a business credit account with American Express. Be careful with credit (depending on how careful you are and what contract you sign, you may be personally liable for the debt), but it is usually cheaper than equity.

</comment><comment><USER6> 1) As early as possible. If your company is a success, the earlier you start it the better(because when you first start and issue shares/units to yourself and your partner, the company is worth very little. Later on, if you raise money, the company will be worth more and if you wait until then to issue shares to yourself you'll have to pay taxes on that). However, doing all this stuff is a pain in the butt and it costs hundreds to many thousands. An LLC usually is the cheapest way to go.

2) VC's can only invest in C corps. S corp is only good if you have profits.

3) Get a good lawyer. Talk to friends who have done startups and get a referral.

4) If you do a Corp as opposed to an LLC, it will most likely be in DE. You have to register as a foreign entity in the states you do business in(another $500 or so).

5) I recommend getting shared space. If that's not an option, get a P.O. Box. Depending on what your company does, using a personal address might be fine.

6) Get a good lawyer and a good accountant. The less time you spend on this stuff(I'm assuming your strengths are in building the product or sales and not paperwork) the better. 7) Have a partnership agreement. If you Incorporate, the lawyers will work this out. But at the very least, make sure you have a written, signed partnership agreement detailing everyone's responsibilities. Even if its your brother, just do it.

8) Get a checking account. Stay away from credit cards.

If you are an internet startup and will be raising capital, traction/the product is important and revenue less so. Anything else, focus on getting customers.

</comment><comment><USER7> When you're thinking hypothetically about incorporating in the future, YC is a great place to get feedback. When you have multiple founders, and you're about to launch, and provide paid services, you should be asking different questions. Where do I find a good lawyer? How much should I expect to pay?

</comment><comment><USER8> This has been discussed many times before - try searching for it.

You definitely need a business bank account.

Since you have a partner, perhaps seeing a lawyer would be a good idea - <USER2> could consider things like vesting, too.

</comment><comment><USER9> Talk to a lawyer and an accountant. It'll be well worth the couple hundred dollars.

<comment><USER10> I hear this one a lot, but no one ever explains why. Would someone like to explain their reasons for suggesting to get a lawyer?

<comment><USER7> Internet advice can be obsolete, generally wrong, or wrong for your specific situation. A lawyer has more incentive to get things right.

</comment></comment></comment><comment><USER11> nice</comment>


How does Weave use Cryptography? - <AUTHOR> http://kix.in/2009/10/11/how-does-weave-use-cryptography/ <comment><USER2> The latest version of Weave (now "Firefox Sync") also uses J-PAKE for exchanging keys between devices.

[http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exch...](http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling)

Earlier versions required you to type a 30-character encryption key on each device that you connect to your sync account. Since your encryption key is never sent to the sync server, you had to transfer it manually. Now you can do the same by exchanging a much shorter (12-character) code, with a UI similar to Bluetooth pairing.</comment>


Moving from London to San Francisco - <AUTHOR> http://corp.fightmymonster.com/?p=176

<comment><USER2> Interesting enough but it misses perhaps the hardest and most onerous portion of this move for most people and companies: the visas/immigration process.

The three people on the "Who We Are" page seem qualified enough to get O-1 (Individuals with Extraordinary Ability or Achievement) visas, perhaps.. but that's the interesting part of the story that's missing. Or is it in another post?

 _Converting to Sterling, you'll probably pay about 20% more than what you'd expect for similar quality engineers in London._

I'm sure many in London would be intrigued where all the typical full-time software engineer salaries of £62k-£78k are to be had ;-) Maybe I talk to the wrong people or we're just more secretive in the UK but it's not often I hear salaries like that being thrown about.

<comment><USER3> With $2.1m in funding, I suspect it might not be too hard to get E2 visas. (non-resident visa for the purpose of managing an investment in the US) They also recently relaxed the rules on self sponsoring H1Bs if the company has enough cash. Not that I can speak from experience.

I'd love to know what kind of requirements for the O-1 visa apply in the context of our industry, as that seems the strongest visa of them all by far. I assume nobody can talk about their experiences publicly as the whole process goes through immigration lawyers and I guess immigration aren't going to be too pleased with publicly available "instructions" on how to legally enter the country, either.

<comment> excuse-me The height of the goalposts seem to change with the market. In the last dot- com bubble my UK PhD supervisor was offered head of physics dept at an IVY league school.

He couldn't get an O-1, he was told that "a Nobel prize would help"

<comment><USER3> Those are some pretty high goal posts. That would mean a quota of 10-15 per year. Aside from the celebrities-du-jour who of course never seem to have trouble getting them.

</comment></comment></comment></comment><comment><USER4> What visa did they use? That's the hardest part.

</comment><comment><USER5> I don't really understand why you'd move a tech business to somewhere where there's famously a shortage of tech talent? Sure the pool of engineers in London may be smaller, but so's the demand surely?

</comment><comment><USER6> For all the hackers in London... the last line of this article is why you should be moving to SF :)

<comment><USER7> The US government does a pretty good job of discouraging that sort of thing these days.

</comment></comment><comment><USER8> Good tips. Will be interesting to see how much longer this cycle runs.

</comment><comment><USER9> Leaving London for San Francisco. That's too bad. San Francisco is a dump.</comment>


Google Russian purchase blocked - <AUTHOR> http://www.ft.com/cms/s/0/908886aa-a14e-11dd-82fd-000077b07658.html

<comment><USER2> the tin foil folks here in russia think that google has ( _cough_ ) somehow persuaded the regulators to block the deal, because google thinks they can acquire the same company (or, in fact, some other company) for a much lower price in a few months, when the crisis takes its toll on russian economy.

sounds unconvincing to me, though. i suppose google could just walk away instead, citing the general uncertainty in the markets.

<comment><USER3> Well, given it's Russia, it is very much likely that someone in the food chain just wasn't, ahem, _compensated_ to their liking.</comment></comment>


Big Brother flies into Valley with 'crime-fighting' eyes - <AUTHOR> http://avpress.com/n/09/0709_s3.hts <comment><USER2> Oh great. Thanks Dick.</comment>


Facebook Fails at https - <AUTHOR> http://musiform.tumblr.com/post/1399511094/facebook-fail <comment><USER2> Even before FireSheep, that was known for anybody who cared to try it. The test (enter FB address with https, try to get the next page) doesn't need FireSheep at all to be demonstrated. And FireSheep doesn't do anything new except packaging the existing technology to make it extremely easy for everybody to experiment. But until FireSheep, if I'd tried to explain the problem to anybody, the best I'd get would be "meh." The worst: "you paranoid." Nice to see the change in the attitude.

<comment><USER3> This. I was trying to explain to my co-workers that this issue has existed for as long as the web has existed and they didn't really understand what I was talking about.

Not until they saw a demonstration video did they believe that it was as bad as I was telling them it was. It is hilarious as a security guy watching "new" exploits come out and watching them go into serious mode since this is a new exploit and it is a bad one and it is going to cause doom and whatnot.

If you can't trust the connection you are on, then time to not use said connection or VPN somewhere. Plenty of places to find hosted VPN services.

<comment><USER4> > Plenty of places to find hosted VPN services

Care to recommend one? I've had a few unsatisfactory experiences (terrible bandwidth, unreliable servers, etc.) and would love a good recommendation.

<comment><USER5> Have you tried these guys: <https://www.goldenfrog.com/vyprvpn/vpn-service- provider>

<comment><USER6> ibVPN is as good as vyprvpn but is cheaper and has more servers <http://www.ibvpn.com/> \+ it provides free accounts weekly

</comment></comment></comment></comment></comment><comment><USER7> I've known about this for awhile, which is why I use Firefox + HTTPS Everywhere by the EFF, to force encryption on Facebook.

</comment><comment><USER8> I don't really understand why this is a surprise or that we needed "Firesheep" to make this popular. This is just no-brainer. The ironic thing to me is that Facebook is so popular with colleges, exactly the places where kids sit there with wireshark running, happily gathering data. Firesheep is neat but I am confused as to why it takes this Firefox extension to point this out. I mean, everyone has heard of SSL right? What did we think that was for?

</comment><comment><USER9> Hilarious outrage. I keep telling people to learn some basic networking ever since I fired up a traffic sniffer on a Lan when everybody was still using POP3. Facebook forcing https on all it's pages won't solve anything, people need to educate themselves before using one of the most complex systems humanity has built.

</comment><comment><USER10> Perhaps supporting ssl and/or tls across their infrastructure isn't a priority. Why is that a "fail", as you so succinctly put it?

In addition, I'd like to ask the entire world to stop using 'fail' as a noun. It's lazy and incorrect.

<comment><USER11> I guess you missed the big story today about Firesheep:

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

<comment><USER10> That doesn't invalidate my point. Supporting SSL is certainly more costly when you're serving content on the scale of FB.

The costs must be weighed against the benefits. Calling FB out as a "fail" is failing to understand all of the issues.

<comment> mike-cardwell People need to stop repeating this same old false argument. Read <http://techie-buzz.com/tech-news/google-switch-ssl-cost.html>

"all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."

</comment></comment></comment></comment><comment><USER12> that dovetails nicely with other posts today on HN about how one can be a great programmer without knowing and understanding the systems fundamentals (ie. C, low level networking...) . Such programmers and their companies are fast in building cute web apps, yet fail to understand/model and as result correctly engineer what happens outside of the web app box supplied by the framework (for example like in this case, how it looks on the wire at transport and application layers)

<comment><USER13> It's a near certainty that Facebook knew, understood, and accepted this vulnerability, since it's as old as the hills and Facebook employs and works with many smart web security people.

<comment><USER12> >with many smart web security people

that is exactly my point. "Web security" being treated as a separate area where only specific people specialize instead of being treated as a basic fundamental prerequisite for a web developer.

<comment><USER13> I'm not following. I'm saying: Facebook certainly knew that if you logged in via a public wireless network that your session cookie could be stolen. They accepted the risk, like many, many other companies do. What do the fundamentals of web dev have to do with this?

</comment></comment></comment></comment><comment><USER14> I don't want SSL for Facebook. SSL is slow, and its only slower the worse your latency. Until SSL is fundamentally changed to be fast, I'm going to avoid it at all costs.

Currently on my production application it adds a minimum of 200ms per request.

This is yet another reason to use a tool like 1password.

<comment><USER15> Turn on persistent connections on your server, ensure you have session caching enabled on your server, and ensure your servers are sharing the session cache.

</comment></comment><comment><USER16> Any Facebook employee reading this? That'd be a great thing to fix, and the PR of a positive privacy story about Facebook would probably be welcome.

I'd also love if they enabled encryption for FB chat, even if you used an external client like iChat or Pidgin.

</comment><comment><USER17> That's a nice app that's linked there, but has anybody made a version for android yet? That would be really fun -- and considering the number of hot spots in major cities would really take things to the next level. ;)

</comment><comment><USER18> I just tried going to <https://news.ycombinator.com/> and got Error 102 (net::ERR_CONNECTION_REFUSED): Unknown error.

</comment><comment><USER19> Not as badly as billing.microsoft.com

</comment><comment><USER20> It's kind of shocking that the session vulnerability seems to be so new to so many. It is painfully obvious. It's one of the reasons that many sites demand that you enter your old password before entering a new password (ensuring that, in the event someone steals your session cookie [which includes simply accessing a public PC], at least it's a temporary vulnerability).

This particular entry, however, uses the worn and now ridiculous "fail" meme five different times. Fail.

</comment><comment><USER21> Whats the point? Sensitive Information like the login page is secured by https (which is a great thing) but why encript the data you don't need to have encripted?

It's (for me) pretty simple. they force the users to use http because the amount of cpu time which is spent for http user is lower than the time for https...

just my two cents

<comment><USER22> Reading about Firesheep you'd find out that the session cookie is passed in the clear and acquiring that allows you to steal someone's session. This is easy on WiFi. That's why it matters.

<comment><USER21> Eew... i'm sorry. i didn't realized this point... you're right sir! this behaviour isn't good...</comment></comment></comment>


Bluetooth ZX Spectrum: Recreating the Sinclair ZX Spectrum by Elite Systems Ltd - <AUTHOR> http://www.kickstarter.com/projects/952953995/bluetooth-zx-spectrum-recreating-the-sinclair-zx-s?ref=live&utm_source=dlvr.it&utm_medium=twitter <comment><USER2> I hated the Sinclair/Timex ZX Spectrum keyboard. Looks like they're on the right track.</comment>


The Propaganda About Russian Propaganda - <AUTHOR> http://www.newyorker.com/news/news-desk/the-propaganda-about-russian-propaganda <comment><USER2> Glenn Greenwald had this story nailed a few days ago: [https://theintercept.com/2016/11/26/washington-post- disgrace...](https://theintercept.com/2016/11/26/washington-post- disgracefully-promotes-a-mccarthyite-blacklist-from-a-new-hidden-and-very- shady-group/)

<comment><USER3> Yasha Levine also wrote an interesting article on this: [https://surveillancevalley.com/blog/on-russia-hacking- americ...](https://surveillancevalley.com/blog/on-russia-hacking-american- democracy)

</comment></comment><comment><USER4> Even controversial site bellingcat producing fakes (see [http://www.spiegel.de/international/world/expert- criticizes-...](http://www.spiegel.de/international/world/expert-criticizes- allegations-of-russian-mh17-manipulation-a-1037125.html) ) is avoiding to be tied with PropOrNot insanity but WaPo journos picked the crackpot theories up easily.

</comment><comment><USER5> The media has a terrible time reporting on anything that requires scientific understanding to assess. The only real solution to this is to put folks with technical training in the media, and to give them real veto power on stories. The current mechanism where a non-technical writer reads a summary of technical results (e.g., a university press release) then asks a few technical contacts their opinion, is hugely flawed.

Ultimately, this road leads to the writing component of journalists being reduced to commodity status, so writers won't let it happen easily. And in any case, readers are selecting outlets based on their ability to tell a compelling story rather than get that facts right, so there's no market pressure.

<comment><AUTHOR> journalists tend to pride being "good at everything, great at nothing." unfortunately it's tough to scale expertise when the domains are so specialized. i'd speculate this is expemplified by all the "ai" we keep hearing about lately which is probably just vanilla machine learning algos at work

</comment></comment><comment><USER6> Seems like we could crowdsource these lists. We could sign up for the ones we like, inserting them into our blocker plug ins and let FB know which ones we cared about.

(Then we could live in even more extremely segregated bubbles!)

</comment><comment><USER7> The thing to wrap one's head about, in regard to the "pro-Russia"-slanting body of opinion (and not infrequent bursts of outright disinformation) that have become increasingly prevalent in the past few years (not so coincidently with the start of Putin's apocryphal 3rd term): _These people think this stuff up largely on their own, because it suits their own (half-baked) intellectual agenda_ (faux anti-globalism, "the enemy of my enemy is my friend", and all that).

Yes, occasionally they'll suck up snippets of dialog, or memelets that might first have originated in sources actually supported by the Russian government (and indeed, there are more than a few bonafide trolls out there in certain media outlets; and of course, the occasional Putin-enchanted celebrity here and there; etc).

But by and large, this contact is incidental. And if people go around denying that the invasion of the Crimea was really and invasion, or that we "don't really know" what happened to MH-17, or (as one very educated acquaintance of mine said to me recently) "Have you read Putin's Syria speech? It was actually quite thoughtful"... it's probably not because they've been brainwashed by RT and Sputnik News... it's because that's the way they think things "ought to be" (and because they apparently don't to a lot of primary source reading... they're very susceptible to letting their intuition and gut feelings run amok over the basic chronology of recent events). Sources directed by the Russian government might provide a bit of an echo, and "fluff" this mentality up a bit... but I suspect not by all that much.

Or as the quote at the end of the article puts it: "To blame internal social effects on external perpetrators is very Putinistic."

<comment><USER8> Instead of engaging in amateur psychoanalyzing of your educated acquaintance because he dares praise Putin's speech, you could have also chosen to read it yourself. Here, let me help you.

[https://www.washingtonpost.com/news/worldviews/wp/2015/09/28...](https://www.washingtonpost.com/news/worldviews/wp/2015/09/28/read- putins-u-n-general-assembly-speech/)

<comment><USER7> Thanks, but I read it when it first went around. Like a lot of things he says, it was indeed cogent and thoughtful -- but also, at its base, fundamentally warped.

<comment><USER9> That's quite a bold statement. Would you like to elaborate on it?

<comment><USER7> As to the other main thrust of what he's saying (supporting Assad as the lesser of evils... like you know, back in the good old days of the anti-Hitler coalition): let's just say things are "a bit more complicated" than the way he presents it. And that he's side-stepping some very important things -- the atrocious human rights record of the regime he'd like us all to throw our weight behind [1]; (this is time-traveling a bit, but) the conduct of own armed forces[2] in that country since that speech (for example, their use of cluster munitions, against those some UN conventions he claims to hold so sacrosanct); and this little bit of unpleasantness [3] (NSFW).

[1] [https://en.wikipedia.org/wiki/Human_rights_violations_during...](https://en.wikipedia.org/wiki/Human_rights_violations_during_the_Syrian_Civil_War) \-- especially the part about _" According to various human rights organizations and the United Nations, human rights violations have been committed by both the government and the rebels, with the "vast majority of the abuses having been committed by the Syrian government"_.

[2] "Russian airstrikes have killed around 3800 civilians, about a quarter of them children" \-- [https://en.wikipedia.org/wiki/Russian_military_intervention_...](https://en.wikipedia.org/wiki/Russian_military_intervention_in_Syria)

[3] [https://en.wikipedia.org/wiki/Ghouta_chemical_attack](https://en.wikipedia.org/wiki/Ghouta_chemical_attack) [NSFW]

</comment></comment></comment></comment></comment><comment><USER10> And now The New Yorker joins PropOrNot's shit list.

<comment><USER11> McCarythism in the digital age.</comment></comment>


Why Vaccines Matter - <AUTHOR> http://www.thegatesnotes.com/Thinking/article.aspx?ID=110

<comment><USER2> This is what wealth is all about - Choice.

Bill and Melinda now have the choice to help millions of people around the world, and they do so.

More importantly, their contribution of wealth - even in the form of vaccines worth 50c - means millions of parents now have the choice to spare their children from illness and death.

This is what Bill will be remembered for - right now he's the Microsoft founder doing good with his billions, but in 100 years' time, he will be the technology guy who drove vaccines into Africa and saved thousands upon thousands of lives.</comment>


What's a CPU to do when it has nothing to do? - <AUTHOR> https://lwn.net/SubscriberLink/767630/594421f913c3d00a/ <comment><USER3> I have no idea on how many other OSes do this, but at least OpenBSD will use idle time to pre-clear memory pages that have been returned to the OS, so that when the next process has them mapped, it doesn't have to zero-fill-on-demand at the very latest moment. It has to be done at some point, but if you keep a queue of pages needing to be cleared and dealing with as many as you can while any core is idle, a non-100% busy system can be seen as to "improve" performance a bit by timeshifting the task to not-directly-after-former process but also not when the new process is calling for memory to be mapped in.

But when that list is empty, doing the right kind of CPU sleep is totally worthwhile of course.

<comment><USER4> I expect most BSDs do this.

Dragonfly actually _removed_ it two years ago: [http://lists.dragonflybsd.org/pipermail/commits/2016-August/...](http://lists.dragonflybsd.org/pipermail/commits/2016-August/624202.html)

      - Pre-zeroing a page only takes 80ns on a modern cpu.  vm_fault overhead
        in general is ~at least 1 microscond.
      - Pre-zeroing a page leads to a cold-cache case on-use, forcing the fault
        source (e.g. a userland program) to actually get the data from main
        memory in its likely immediate use of the faulted page, reducing
        performance.
      - Zeroing the page at fault-time is actually more optimal because it does
        not require any reading of dynamic ram and leaves the cache hot.
      - Multiple synth and build tests show that active idle-time zeroing of
        pages actually reduces performance somewhat and incidental allocations
        of already-zerod pages (from page-table tear-downs) do not affect
        performance in any meaningful way.

<comment><USER5> I expect openBSD to continue to do this anyway though because there is the possibility that someone can reboot the system to a new OS (presumably designed just for this purpose) and read whatever was in RAM. Of course programs that deal with encryption zero memory before returning it (It is hard to make sure the compiler doesn't optimize this otherwise useless work out), but most other programs that deal with secrets are not so well written and will live sensitive information around.

<comment><USER6> > the possibility that someone can reboot the system to a new OS and read > whatever was in RAM

or physically pull the RAM out, keeping it cold with LN2, and stick it into devices designed for reading it all out.

<comment><USER7> Canned air upside down works reasonably well and is easier to handle

</comment></comment></comment></comment></comment><comment><USER8> This is when I miss the days of big iron. The Burroughs B5500, 6500 and 6700 all had massive light displays of registers. The idle process loaded the registers with a bit pattern that showed the Burroughs logo, a circle with a B in it. You could watch the panel and see how busy the system was by how often you could see the logo flash in the lights.

<comment><USER9> Your comment got me curious: apparently Linux controls LEDs activity through /sys/class/led [0]

A cursory search led me to this project[1] that blinks the power led according to the disk activity, which is not far from your idea (replacing the disk activity by a composite of system load for instance?)

[0][https://www.kernel.org/doc/Documentation/leds/leds- class.txt](https://www.kernel.org/doc/Documentation/leds/leds-class.txt) [1][https://github.com/fabio-d/block-led- trigger](https://github.com/fabio-d/block-led-trigger)

<comment><USER10> Isn't there already a disk activity led? Well, on desktop boxes anyway.

Eons ago I had a small program on Linux that blinked the otherwise-almost- useless scroll/numlock leds based on network i/o activity. It was fairly cool.

<comment><USER11> Reminds me of the book Cryptonomicon by Neal Stephenson, where the character writes some code to redirect stdout to blink the num/scroll/capslock status LEDs in Morse code.

</comment></comment></comment></comment><comment><USER12> This is really impactful work. Data centers are 2% of US electricity consumption, and a 20% improvement in idle energy usage will cut that by a sizable fraction. (Even if virtualization is intended to reduce idle hardware capacity.)

<comment><USER13> Well, if your goal is to reduce electricity consumption, the proper way would be to increase prices for it. It's just there might be easier and faster ways, not only improving idle CPU states.

<comment><USER14> I hate that approach so much. By increasing prices you're not reducing demand, you're just making it less affordable for people who might need it equally than those who are in better paid jobs etc.

I prefer the approach of improving energy efficiency (short to mid term time scale) and investing in greener energy sources (mid to long term) to bide us time until nuclear fusion becomes viable and thus electricity consumption no longer becomes a harmful process.

We shouldn't punish people less fortunate than ourselves for our own gluttony - which is all that raising prices would do.

<comment><USER15> >I prefer the approach of improving energy efficiency (short to mid term time scale) and investing in greener energy sources (mid to long term) to bide us time until nuclear fusion becomes viable and thus electricity consumption no longer becomes a harmful process.

Raising efficiency probably won't help at all due to Jevon's paradox: [https://en.wikipedia.org/wiki/Jevons_paradox](https://en.wikipedia.org/wiki/Jevons_paradox)

"""

In economics, the Jevons paradox (/ˈdʒɛvənz/; sometimes Jevons effect) occurs when technological progress increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the rate of consumption of that resource rises due to increasing demand.[1] The Jevons paradox is perhaps the most widely known paradox in environmental economics.[2] However, governments and environmentalists generally assume that efficiency gains will lower resource consumption, ignoring the possibility of the paradox arising.[3]

In 1865, the English economist William Stanley Jevons observed that technological improvements that increased the efficiency of coal-use led to the increased consumption of coal in a wide range of industries. He argued that, contrary to common intuition, technological progress could not be relied upon to reduce fuel consumption.

"""

<comment><USER16> The Jevons Paradox is an extreme form of the rebound effect[0]. More normally, we expect efficiency gains to be only partly offset by changes in behaviour.

As an anecdotal example, we replaced one 60w incandescent bulb in our bathroom with 4 x 5w LED spotlight bulbs. This is both an increase in light, and a reduction in energy usage, even though it doesn't reflect the full efficiency gains of the LEDs.

[https://en.wikipedia.org/wiki/Rebound_effect_(conservation)](https://en.wikipedia.org/wiki/Rebound_effect_\(conservation\))

<comment><USER15> It doesnt have to be behaviour of the consumer. It can mean that the value proposition of application development can move to more less-efficient programs. e.g. we have more and more memory in computers so developers often say "meh, memory is cheap" when developing Electron apps that take hundreds of GB. This can definitely result in "meh, CPUs are efficient" (even if it's a non-sequitor in this case).

<comment><USER14> Fair point. We've definitely seen that trend happen where software will often be written to take advantage of the resources available rather than written to be efficient. Not just in recent times with Electron but throughout the evolution of GUI-driven operating systems (eg compositing desktops, themeing, pre-compositing animations, etc).

The gaming industry demonstrates this the most clearly but it's definitely present in general purpose computing as well. eg when Windows XP was first released (pre-service packs) it required twice the hardware specifications of Windows 2000 yet offered little functional difference (read: actual real world stuff that could be done on it) aside themeing.

Thankfully that trend with Windows has reversed somewhat but it's still ever- present with desktop software and their movement towards using web-based technologies.

<comment><USER17> > _The gaming industry demonstrates this the most clearly_

I think the gaming industry actually also demonstrates _the opposite_ the most clearly.

I'm often blown away by how efficient some games are, and how well they take advantage of advances in hardware.

I look at something like World of Warcraft, a 14 year old game that has trouble running on my desktop computer despite its graphics being... _limited_ to say the least. And then I look at Breath of the Wild. A patently stunning game.

And then I remember which one of the two is a mobile game.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Now we just need to iron out bugs which prevent CPU's to reach certain low- power states. Turns out in modern CPU's that's surprisingly difficult to achieve, as not only the CPU is considered for such power states, but attached components, like the NVMe controller, as well. Matthew Garrett explains pretty good what's happening there: [https://mjg59.dreamwidth.org/41713.html](https://mjg59.dreamwidth.org/41713.html)

</comment><comment><USER19> This reminds me of what apple did with scheduler in macOS Mavericks [https://www.apple.com/media/us/osx/2013/docs/OSX_Power_Effic...](https://www.apple.com/media/us/osx/2013/docs/OSX_Power_Efficiency_Technology_Overview.pdf)

</comment><comment><USER20> I once increased coin-cell run-time of a client's hardware (ARM) platform from 1 month to 1.5 years simply by replacing almost all sleep() functions with low-power-mode-enter.

<comment><USER21> I'd argue that, in this context, sleep() itself is buggy

<comment><USER20> That was a no-OS situation. sleep() is usually implemented as a calculated number of cycles of `nop`s in those SDKs.

</comment></comment></comment><comment><USER22> Why does a CPU _have_ to run?

EDIT:

> If the hardware doesn't make allowance for this, then the CPU will have to > run useless instructions until it is needed for real work.

Do any consumer processors (think Intel iBlah) not support turning off the CPU when it's not needed?

<comment><USER23> Some cheap microprocessors do that, usually in devices where power consumption matters they have a small companion microprocessor (a micromicroprocessor so to speak) that will power down the big one if necessary and enter a sleep state itself to severely cut down on power consumption (some devices can go as low as microamps).

Generally, most modern CPUs support turning off when not needed, however, this is generally referred to as power-on-standby (S3, IIRC). The CPU is off, most things are off, RAM is on.

The CPU itself has to continue to run because there is almost no timeperiod larger than a few seconds in which there is truly nothing to do and shutting down CPU cores and clocking the remaining one is efficient enough.

<comment><USER24> A good example of this: [http://www.home-automation-community.com/arduino-low- power-h...](http://www.home-automation-community.com/arduino-low-power-how-to- run-atmega328p-for-a-year-on-coin-cell-battery/)

<comment><USER25> Another good example are the javascript microcontroller boards. Because of the event-loop model of the Js engine, they can simply see there's no code to run and shift into power saving modes without the dev having to do anything special.

example: [https://www.espruino.com/Power+Consumption](https://www.espruino.com/Power+Consumption)

<comment><USER26> That's great, I didn't realize there were micros that could do that automatically. Much simpler than the usual mucking around with registers.

</comment></comment></comment></comment></comment><comment><USER27> The article states makes numerous mentions of the "the governor":

>"In this loop, the CPU scheduler notices that a CPU is idle because it has no work for the CPU to do. The scheduler then calls the governor, which does its best to predict the appropriate idle state to enter. There are currently two governors in the kernel, called "menu" and "ladder". They are used in different cases, but they both try to do roughly the same thing: keep track of system state when a CPU idles and how long it ended up idling for."

Could someone say exactly what "the governor" is? Its a code path in the scheduler? It wasn't clear to me from reading the article.

<comment><USER28> The kernel subsystem that handles this is called cpuidle: [https://lwn.net/Articles/384146/](https://lwn.net/Articles/384146/) . It has two different governors, ladder (which chooses an idle state adjacent to the existing state) and menu (which can choose any idle state)

<comment><USER27> Thanks this is really helpful. Cheers.

</comment></comment></comment><comment><USER29> I appreciate the article being written in a language a person without much CPU knowledge, like myself, can understand. Fascinating.

</comment><comment><USER30> This reminds me of a story I read from some operating system book: Guys working on an early OS profiled the system and found that one particular routine is taking a lot of CPU time. They worked hard optimizing it but found it didn't improve the overall performance at all. Turned out that routine was the idle loop of the OS.

I don't remember if it was a true story or just a joke.

</comment><comment><USER31> > _Idle states are not free to enter or exit. Entry and exit both require some > time, and moreover power consumption briefly rises slightly above normal for > the current state on entry to idle and above normal for the destination > state on exit from idle. Although increasingly deep idle states consume > decreasing amounts of power, they have increasingly large costs to enter and > exit._

What causes this? I would have thought that "stop computing for a bit" would be a simple thing to do, but I clearly don't know much about processor design.

<comment><USER32> I work in CPU design. It all comes down to saving power given how frequent idle-state entries are (especially C1 enters with almost most wait-for- interrupt operations) Stop-computing isn't well defined. As long as the clock ticks, the frontend will keep fetching instructions. Sure you can keep feeding it NOPs, but instead, we save power by entering idle states.

The quickest to enter and exit (C1) simply clock-gates the core. Caches are preserved. The next c-state might turn off caches too (and thus incurs the penalty of flushing caches on entry and starting with a cold cache on c-state exit). Further C-states might require even more work to enter and exit but consume much lesser power when in that state.

The cpuidle governor decides which C-state to enter since a deep C-state entry and exit may end up consuming even more power than keeping the system running or in C1.

</comment></comment><comment><USER33> > but ARM CPUs, for example, will also benefit.

IIRC the majority of phones out there use tickless config, so the ARM CPUs that benefit here are the server-class ones. But good show, indeed!

</comment><comment><USER34> An interesting thing regarding the NOP (no operation) instruction many CPUs have, is that it many times is implemented as a pseudo-instruction. Ie, what actually runs is something that has no effect, eg move contents from a register onto the same register.

It has also given name to the human activity of "NOPping", similar to zoning out.

</comment><comment><USER35> Note that this seems to be about not waking up the CPU (by timer ticks) more frequently, to allow it to go into a deeper sleep --- AFAIK the actual "idle loop" just executes the HLT instruction, which puts the CPU in a "wait for interrupt" state, and for newer CPUs they go into successively lower power states the longer they're halted.

This reminds me that earlier operating systems like DOS and Win9x kept the CPU in a busy polling loop when idle --- which was great for responsiveness, but not power consumption nor heat; applications like [http://www.benchtest.com/rain.html](http://www.benchtest.com/rain.html) soon appeared, which replaced the idle loop with an actual HLT loop and actually had a noticeable effect. The DOS version is at [https://maribu.home.xs4all.nl/zeurkous/download/mirror/dosid...](https://maribu.home.xs4all.nl/zeurkous/download/mirror/dosidle.html)

<comment><USER28> It's more complicated than that these days. Rather than HLT, you call MWAIT with an argument that corresponds to the C state that you want to enter - <USER2> OS has a better idea than the CPU of how long it's going to be asleep (basically what this article is about), so it can tell the CPU to enter a deeper state. The CPU may make an executive decision based on its own needs to enter a different state (potentially even a deeper one), but it's largely still up to the OS to choose rather than the CPU entering progressively deeper states.

</comment></comment><comment><USER36> Does it also imply that a non-blocking event loop in the userspace application is energy-inefficient?

Likewise, given that some OSes APIs (syscalls) provide both non-blocking and blocking modes, should we prefer the blocking ones concerning energy efficiency?

<comment><USER37> They are pretty much equivalent. The kernel will only schedule your program when an event happens. The difference is that by using a blocking syscall you will need more threads which indirectly decreases energy efficiency through increased context switching and RAM usage. If you only have a single thread then blocking or non-blocking is going to consume the same amount of energy.

</comment></comment><comment><USER38> 20% is much win, very interesting and nice progress on the kernel there! very useful!

</comment><comment><USER39> How does this work on a single-CPU system? Wouldn't the various idle checks and governor calls keep the CPU always busy? Or is there some way to turn off something so these instructions don't mark the CPU as "active"?

<comment><USER40> FreeRTOS or most RTOS use idle time to go into low power or sleep mode. It makes sense in an embedded system which is often powered on batteries.

</comment></comment><comment><USER41> Blinken dem lights.

</comment><comment><USER42> Hangs out on reddit?

</comment><comment><USER43> >> What's a CPU to do when it has nothing to do? > Mine Bitcoin!

This would be great for CryptoNote Webminers running WASM in the browser to help users understand you don't have to juice every thread/cpu in order to effectively mine at scale using a proxy like the one provided in Webminerpool.

<comment><USER44> > effectively mine at scale

You mean "in order to spend an extra $2 in power to make 3c for someone else"? Very effective.

As long as there are more price-efficient mining pools which are an appreciable fraction of mining power, it will not be cost effective to mine anywhere less efficient since margins will naturally approach what those larger pools can support.

A consumer desktop will never be able to compete with a centrally cooled data- centre which likely gets special power rates and was intentionally built in a location power is cheaper in. Especially not if it's having to go through wasm.</comment></comment>


Stephen Hawking: AI will decimate middle class jobs - <AUTHOR> http://www.businessinsider.com/stephen-hawking-ai-automation-middle-class-jobs-most-dangerous-moment-humanity-2016-12?utm_content=buffer5550e&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer <comment><USER2> "Technology has already gutted many traditional manufacturing and working class jobs — but now it may be poised to wreak similar havoc with the middle classes."

This is accurate. It is Moravec's Paradox.

I keep repeating it because there is a slew of newspaper articles since Trump's victory claiming that Silicon Valley destroyed the manufacturing jobs.

This isn't even wrong.

It is true that _technology_ destroyed them, but we're talking about Industrial Revolution era technology.

Highly Repetitive manual tasks have been automated by machines. Finishing components and configuration of components is mostly performed in Chinese factories or in Western factories, some of which are so highly automated they are called black sites. Anything that could be put into a factory for making the parameters of the task simpler, is mostly already there.

The 'low hanging fruit' for disrupting the working class is gone, long gone.

It now requires very sophisticated AI and robotics to really impact the remaining working class niches. This is easily several decades away.

Guess who performs a lot of work with raw information? The middle classes. That's why they are in the crosshairs of Silicon Valley.

A cynic might suggest this 'panic' over the working class losing their jobs has a lot more to do with the middle classes losing theirs.

<comment><USER3> When reading such things, I don't understand why people hate on UBI.

I mean, what are the alternatives?

You can prohibit automation per law, so that everyone can stay in their jobs. This will probably fail because not every country will pass such laws.

You can try to teach the people new stuff that can't be automated easily.

But does a clerk want to become a pastry chef or gardener (some of the harder to automate jobs it seems)?

Or teach them "higher" education in the hopes they can create their own automations and make money with it, but how much of these clerks are good enough to get through universtiy decades after they left school.

<comment><USER4> Because welfare of any kind is seen as a moral failure by many. UBI is just a more streamlined version of moral failure. I don't agree with this sentiment, but many hold it.

As far as alternatives to UBI go, a lot of people have the hope that automation (indirectly) will create new jobs, and society will ultimately adjust to fill those jobs. I don't know if this will always happen. Many people aren't going to buy any pastry or ask for gardeners if only a handful of them can afford these things to begin with.

<comment><USER3> > people have the hope that automation (indirectly) will create new jobs

I think so, too.

But I also think the new jobs would be better if they weren't created because of fear, but because people wanted to do them.

</comment></comment></comment></comment><comment><AUTHOR> In China the risk of automation is as high as 77%.

[http://www.businessinsider.com/clsa-wef-and-citi-on-the- futu...](http://www.businessinsider.com/clsa-wef-and-citi-on-the-future-of- robots-and-ai-in-the-workforce-2016-6?r=UK&IR=T)

<comment><USER5> China's middle class is actually growing though, whereas it's static or shrinking in most western countries.

<comment><USER6> Those those observations are not mutually exclusive.

</comment></comment></comment><comment><USER7> More like AI will decimate jobs in the knowledge economy. AI cancer recognition is better than most doctors already.</comment>