Go Slices Are Fat Pointers - <AUTHOR> https://nullprogram.com/blog/2019/06/30/ <comment><USER2> D slices are fat pointers as well:

[https://dlang.org/spec/arrays.html#dynamic- arrays](https://dlang.org/spec/arrays.html#dynamic-arrays)

My suggestion for C to adopt fat pointers:

[https://www.digitalmars.com/articles/b44.html](https://www.digitalmars.com/articles/b44.html)

<comment><USER3> > D slices are fat pointers as well:

So are Rust's.

Possibly more interestingly, so are its _trait objects_ , the trait object pointer is a (vtable _, instance_ ) rather than (instance*, length).

Also of note: that applies to "owned pointers" (`Box`) not just "references", despite the former looking very struct-like: [https://play.rust- lang.org/?version=stable&mode=debug&editio...](https://play.rust- lang.org/?version=stable&mode=debug&edition=2018&gist=a0d4e151acba3b8f273666946613f789)

In a way, C++ and Rust (and possibly D?) have pretty much an infinity of fat pointers as anything can be made to deref' to something else, and be more than one pointer wide (e.g. C++'s std::string and std::vector and Rust's String and Vec)

<comment> ainar-g

      > Possibly more interestingly, so are its trait objects, the trait object pointer is a (vtable,
      > instance) rather than (instance*, length).

The Go interfaces are the same. See [https://research.swtch.com/interfaces](https://research.swtch.com/interfaces).

</comment></comment></comment><comment><USER4> A word of caution to anyone writing C macros like the examples in the article... There is a potential error in this macro:

      #define COUNTOF(array) \
          (sizeof(array) / sizeof(array[0]))

Generally, when you write a C macro, you should parenthesize each use of any argument inside the macro. The exceptions would be cases like token pasting where you want the literal argument text and only the text.

I don't have a specific failure example in mind for the COUNTOF macro (maybe someone can post one?) - but here is a macro where it is easy to see the problem:

      #define TIMESTWO( value )  ( value * 2 )

      int ShouldBeEight = TIMESTWO( 2 + 2 );  // Oops, it's 6!

This happens because the macro call expands to:

      2 + 2 * 2

Parentheses prevent this problem:

      #define TIMESTWO( value )  ( (value) * 2 )

The macro also illustrates a common misconception: sizeof is not a macro or function call, it's an _operator_. So wrapping the argument to sizeof in parens isn't necessary unless they are needed for other reasons. (They don't hurt anything, they just aren't needed.)

So when I've written a COUNTOF macro (and it is a very handy macro in C/C++ code if your compiler doesn't already provide a similar one like __countof in MSVC), I write it like this:

      #define COUNTOF( array )  \
          ( sizeof (array) / sizeof (array)[0] )

The space after each sizeof is my attempt to indicate that the following parens are not function/macro call parens, but are there specifically to wrap the array argument safely.

<comment><USER5> You also shouldn't repeat the argument: "while(COUNTOF(ptr++) > 0) { }" would do horrible things (if it compiles; didn't check) for example.

There are various preprocessor tricks to avoid this stuff (eg "do{ x = (array); ... } while (0)"), but, honestly, if you want this sort of memory safety, C++ is your friend.

<comment><USER6> Even plain `COUNTOF(ptr)` is wrong, unless `ptr` is an array.

<comment><USER7>
        -Werror-sizeof-pointer-div

Or in C++:

        #include <type_traits>

        template < typename T, std::size_t N >
        constexpr std::size_t count_of(const T (&)[N]) { return N; }

        #define COUNTOF(a) std::integral_constant<std::size_t, count_of(a)>::value

(C++03 friendly versions are entirely possible, but left as an exercise to the reader)

</comment></comment></comment></comment><comment><USER8> Rust slices are also fat pointers. The std::string_view type is also a fat pointer. The Haskell ByteString type is also a fat pointer.

</comment><comment><USER9> This is analogous to spans and views in C++. I've rather enjoyed using span- lite [0], an implementation compatible with earlier C++ standards. (Roughly, all the syntactic niceness of an STL container without requiring ownership.)

[0] [https://github.com/martinmoene/span- lite](https://github.com/martinmoene/span-lite)

</comment><comment><USER10> Any slice implementation that references to the original data has to be some kind of "fat pointer". Is there any other way that can be done?

String.substring in Java does exactly that. I'm sure numpy arrays in Python are implemented like that, perhaps slightly more fatter.

<comment><USER3> > Any slice implementation that references to the original data has to be some > kind of "fat pointer". Is there any other way that can be done?

Yes, add one more level of indirection.

For instance traditional "oo" languages don't usually use fat pointers for dynamic dispatch, you have a single pointer to an instance which holds a pointer to its vtable.

In Rust however, the "object pointer" is a fat pointer of (vtable _, instance_ ). Go's interface pointers are the same (which combined with nils leads to the dreaded "typed nil" issue).

<comment><USER11> I don't understand people's beef with "typed nil". If an interface is just a fat pointer and the data is itself a pointer, then it stands to reason that the interface can be not nil while the data can be nil. If you understand the concept of pointers (or nillable pointers, anyway), surely this should not be surprising to anyone? It would have the same states as a asterisk-asterisk-int (HN formatting prohibits asterisk literals), would it not?

<comment><USER12> I think it's a combination of several things: First, you've got a good chunk of Go programmers who haven't dug down into the details of the internal representation of interfaces, because for the most part, they don't need to, and they either don't generally dig in to that level, or just haven't gotten around to it yet. (There's nothing wrong with this and this isn't a criticism. It's just that not everybody is an expert in everything they do or use.)

Secondly, I think that for a lot of people, when they have an interface that is itself nil, they mentally tag it with the label "nil", and when they have an interface that contains a typed value that is nil, they mentally tag this with "nil", and from the there the confusion is obvious. Mix in some concepts from other languages like C where nil instances are always invalid, so that you don't mentally have a model for a "legitimate instance of a type whose pointer is nil" [1], and it just gets worse.

Third, I think it's an action-at-a-distance problem. I'd say the point at which you have, say, an "io.Reader" value, and you put an invalid nil struct pointer in there that doesn't work, the problem is there. Values that are invalid in that way should never be created at all, so "interfaceVal == nil" should be all the check that is necessary. So you have a problem where the code that is blowing up trying to use the "invalid interface" is actually caused by an arbitrary-distant bit of code that created the value that shouldn't have been created in the first place, and that pattern generally causes problems with proper attribution of "fault" in code; the temptation to blame the place that crashed is very strong, and, I mean, that's generally a perfectly sensible default presumption so it's not like that's a crazy idea or anything.

[1]: For those who don't know, in Go, you can have a legitimate value of a pointer which is nil, and implements methods, because the "nil" still has a type the compiler/runtime tracks. I have a memory pool-type thing, for instance (different use case than sync.Pool, and predates it) which if it has an instance does its pooling thing, but if it is nil, falls back to just using make and letting the GC pick up the pieces.

<comment><USER13> This. Nil is the one case where you can seriously screw your self up in Go because it's an untyped literal that gets typed on assignment. Interfaces are fat pointers and a "true" nil pointer is nil interface, nil implementation. If your function is going to return a known subtype and you store that nil in a temporary you now return a known interface and nil implementation. Then your == nil check on the interface pointer will fail.

I royally screwed up a deploy once because my functions were returning nil error implementations that were != nil and triggered failure paths.

<comment><USER11> I agree that nil is error prone, but I don't think interfaces add any additional confusion so long as you think of them as a reference type and reason accordingly. Also, I think you're mistaken about "true nil". A "true nil" only requires the interface to be nil. The value doesn't matter as there necessarily is no value (moreover interfaces can have values which are value- types that cannot be nil!).

</comment></comment></comment></comment></comment></comment><comment><USER14> Another way to implement fat pointers is to keep the pointer representation the same but have another structure like an interval tree that stores a map of pointers to the extra information on bounds. That's how I implemented Bounds Checking GCC back in the day: [https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html](https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html) It has the advantage that pointers remain compatible with code that wasn't specially compiled to know about fat pointers (such as system libraries).

<comment><USER15> Seems like that would hurt memory locality, with a commensurate increase in cache-misses.

<comment><USER16> That's basically how Intel MPX works,

      https://en.wikipedia.org/wiki/Intel_MPX

as well as TinyCC's Bounds Check,

      https://bellard.org/tcc/tcc-doc.html#Bounds

which cites the aforementioned GCC patch.

I think AddressSanitizer uses a shadow mapping structure more similar to Valgrind.

Although your point about performance still stands. Intel MPX is dead--support removed from GCC, IIRC, because of hints Intel was abandoning it. We'll never know how well it could have been optimized in practice. I think ultimately we simply need proper fat pointers, but those might not become ubiquitous (in the sense of becoming a de facto standard part of shared, C-based platform ABIs) until we see 128-bit native pointers.

</comment></comment></comment><comment><USER17> (In the same vein of other comments...)

Algol 68 slices are also fat pointers. Only they also carry a `stride` field, since in Algol 68 you can slice multidimensional arrays in any direction.

<comment><USER18> A couple questions about that design. Is it worth paying the cost of an extra word in every slice, if strided slicing is rare in most programs? And when you wrap OS APIs that don't understand striding, do you have to use a different pointer type?

<comment><USER17> It's a subjective question, but given that A68's slices are already burdened with carrying their lower bound wherever they go, not much is lost with adding another piece of data to them. They are already quite fat, and more with each dimension. I think the ability of taking a column and just apply any sequence function to it is well worth it.

I don't think you could use OS APIs without boxing and unboxing data, but I think that's the case with every language except C.

</comment></comment></comment><comment><USER19> Obviously there are all kind of cute games that can be played with pointers if you know arch-specific details (IIRC v8 was using alignment guarantees to steal low bits at one point, might still be). And tagged pointers of various kinds go at least back to Symbolics if not further.

One that I thought was especially nifty was [0].

[0] [https://github.com/facebook/folly/blob/master/folly/PackedSy...](https://github.com/facebook/folly/blob/master/folly/PackedSyncPtr.h)

<comment><USER20> Lisp 1.5 was using tagged pointers by 1962, and I don't think it was innovative in this regard at the time.

<comment><USER21> Only because the computer it was on already had a tag field in every word. Other implementations of Lisp did similar things though: [https://www.snellman.net/blog/archive/2017-09-04-lisp- number...](https://www.snellman.net/blog/archive/2017-09-04-lisp-numbers/)

</comment></comment></comment><comment><USER22> Go interfaces are also fat pointers. Basically, the pointer to the type info/method set and the actual data are stored separately. [1]

As a result of this you can use pointers as interface types without boxing them. For example you can take an interior pointer to an array, or a C pointer, and use it as an interface type without boxing since the type info doesn't need to be stored with the data.

[1] [https://research.swtch.com/interfaces](https://research.swtch.com/interfaces)

</comment><comment><USER23> The "uint8* a, usize a_len" pattern is one of the ugliest aspect of C. It's probably the source of most bugs. To its defense, it was invented at a time where we were trying to save each byte of data and security was not really a thing. Unfortunately C is still quite popular.

<comment><USER24> IMHO if C had generics then so many problems could be fixed (e.g. you could easily have a struct Slice<T> for a fat pointer). Existential generics would even give you OOP (and, in a roundabout way, closures) for free. Hmm...

<comment><USER25> What are existential generics? I searched Google but couldn't find the meaning of the term.

<comment><USER24> [https://wiki.haskell.org/Existential_type#Dynamic_dispatch_m...](https://wiki.haskell.org/Existential_type#Dynamic_dispatch_mechanism_of_OOP)

<comment><USER25> thanks!

</comment></comment></comment></comment></comment><comment><USER26> Interesting that this post has been in the #1 place for so long. I don't use Go but I knew this already by having randomly read some things about the language. And slices are central language concepts after all.

Is it that the Go documentation doesn't cover the underlying implementation at the machine word level?

<comment><USER27> Docs explain this, not as detailed as the post, but it does touch on slices referencing/wrapping an array. However, there is a blog post dedicated to slice internals [https://blog.golang.org/go-slices-usage-and- internals](https://blog.golang.org/go-slices-usage-and-internals) that dives further in

</comment></comment><comment><USER28> Some errors I found:

        uintptr addr = (uintptr_t)buf & 0xffffffffffff;
        uintptr pack = (sizeof(buf) << 48) | p;

should be "| addr"

        #define ARRAYPTR(array) \
            ADDROF(array, COUNTOF(array))

should be FATPTR(array, COUNTOF(array))

</comment><comment><USER29> Fat pointers + threads permit torn reads/writes, leading to memory unsafety. It seems weird that Go allowed memory unsafety for this narrow use case - AFAIK only slices and interfaces are fat pointers.

<comment><USER30> If you need thread-safety you must at least use atomics anyway Either your platform has transactional memory, double-wide cas or you need to fall back to locks.

<comment><USER31> Using double wide cas for atomic pointer store and loads is a big pessimization though.

</comment></comment></comment><comment><USER32> I regret learning go as my first language.

Every other language just looks awful.

<comment><USER21> People say that about Lisp as well.

<comment><USER11> I think it's for different reasons. Go as a language is just fine, but Go as a framework for building software is just fantastic. The tooling is comprehensive and easy to use, testing is built in, and the happy path is almost always highlighted for you. No need to figure out which documentation generator, style guideline/formatter, test framework, build system, package manager, etc to use and these are easy to use (with the notable exception of package management, which has been rocky but is improving). Lisp is a neat and powerful little language but the tooling and documentation are often lacking and it's often difficult to figure out even which lisp is right for your project.

<comment><USER21> Except that most of the tools that come with Go are pretty mediocre. Go's debugger is worse than mediocre.

<comment><USER11> The debugger isn't great. Most things just work, and they just work well for the most popular use cases. Documentation is just comments—no special syntax to memorize and no need to maintain infrastructure to parse docstrings and publish to a web server. It also runs the examples to make sure they work. The build system doesn't require you to learn a special (typically imperative) project configuration language or Makefile generator. It also outputs a statically-linked binary by default—no VMs or interpreters or libraries to shop separately. Although it doesn't have a comprehensive assertion suite, Go ships with a unit test framework that just works, which is more than can be said for most languages. And all of these things are standard so you can pretty much jump into any project and build it, run its test suite, and begin contributing with little more than a text editor and the Go toolchain. So yeah, Go's tooling is simply fantastic and no other mainstream language except Rust comes close. This isn't a fanboy statement; there are lots of other factors to consider, but Go's tooling is top notch.

</comment></comment></comment></comment></comment><comment><USER33> Here's my own attempt at implementing these ideas in c

Basically feature complete, with unitests, and interop with c arrays

[https://tse.gratis/aArray/](https://tse.gratis/aArray/)

A few changes for a later version:

* Pure public domain license (it is that already, but the wording could be better)

* Remove c++ support... Not sure about this

* Let higher order map/filter functions take a void* payload when using plain c functions over clang blocks (or lambdas)

</comment><comment><USER34> > For example, currently on x86-64, only the lower 48 bits of a pointer are > actually used. The other 16 bits could carefully be used for other > information

Well, you can't dereference these fat pointers directly on amd64, you have to remove the tag.

aarch64 actually has a Top Byte Ignore flag though :)

<comment><USER15> I'd also expect that bit-fiddling on pointers, and then de referencing them, is undefined behavior.

<comment><USER35> In C, yes, but not in amd64 or i386 (or most instruction sets.)

</comment></comment></comment><comment><USER36> ...yes, and? How else could you possibly implement slices?

I don't disagree with any of this article at a factual level, I'm just trying to understand the author's message.

<comment><USER37> For people like me whose knowledge of C is close to 0, and had no idea what fat pointers were, that post was pretty interesting.

I've now learned 2 things: what fat pointers are, and that go slices are fat pointer.

</comment></comment><comment><USER13> I've seen this technique used in old codebases for strings. A typedef was made for a char* whose -1 address was a count and there wasn't a zero terminator. This was useful since string length checks were now O(1) and string manipulation can take a surprising amount of time in CPU bound programs.

It was an interesting idea but you needed a whole new set of string functions and bridge functions. It takes a runtime (or codebase) wide commitment to make it work.

<comment><USER6> That sounds like Pascal strings. Arguably saner than C strings, but lacking the main advantage of slices: multiple slices of different lengths and/or different starting points can refer to parts of the same string, so you can "slice" things without copying.

</comment></comment><comment><USER38> One of the things that was a gotcha for me when I started Go. Couldn't figure out why my slices weren't what I was expecting

</comment><comment><USER39> You can easily obtain convenient fat pointers with like the the 1990 dialect of C++ described here:

[https://www.amazon.ca/Annotated-C-Reference- Manual/dp/020151...](https://www.amazon.ca/Annotated-C-Reference- Manual/dp/0201514591)

</comment><comment><USER40> Another useful unsafe slice operation is casting a byte slice to a string so you can e.g. use it as a map key. Watch your lifetimes though!

You probably also wouldn't want to use any string manipulation functions on it, but I've never had a reason to do that anyway.

<comment><USER41> The compiler optimizes conversion from []byte to string on map lookup. [https://github.com/golang/go/commit/f5f5a8b6209f84961687d993...](https://github.com/golang/go/commit/f5f5a8b6209f84961687d993b93ea0d397f5d5bf)

<comment><USER40> That's awesome! I'll have to benchmark that and see if I can delete some code now. Thanks.

</comment></comment></comment><comment><USER42> Swift arrays are the only programming language arrays that have ever baffled me. I still have no idea how to manually reconstruct them given the array struct.

<comment><USER43> Swift arrays are interesting beasts because they need to support bridging into Obj-C, which makes them rather complicated. Look at ContiguousArray instead if you want the simple version that skips bridging support.

</comment></comment><comment><USER44> What surprises me in C programmers is that bugs like buffer overflow have been known for several decades but they still use raw pointers for strings and unsafe pointer arithmetics. At least in open source projects I often see this. C is really a language that doesn't move forward.

Also, no proper package manager.

</comment><comment><USER45> My favorite is Smart Fat Pointers. They are sexy!</comment>


Ask HN: Who wants to accept Check online? - <AUTHOR>

I am building a payments product which will help you accept checks online digitally without the customers having to mail you paper checks. Different from e-checks in that there are no NSFs and funds are guaranteed - also the user experience is totally different. More efficient and much cheaper than credit cards. Are you interested in your using it (US only for now)?
If you are interested, please leave your email/contact here and we will get in touch with you!
Or share your email here: https://docs.google.com/forms/d/10fAEOBu8h15p_eNPyJ8oYOmGHb1d-EkeRCYLwho03WE/viewform?usp=send_form <comment><USER2> I hate to burst your bubble or anything, but dwolla.com does this pretty well and cheaply. How will you differentiate?

I don't quite follow the "no NSFs and funds are guaranteed" \- are you implying that if the transaction is authorized there will never be a chargeback (or equivalent)? I need more info - I can't think of any way you could handle it sustainably.

<comment><AUTHOR> No worries. dwolla.com I believe uses and existing relationship with a credit union/bank and hence restricts real-time transfers to account holders of that/those bank(s) - which is a small percentage. Additionally it requires signups, SS# etc. so the experience is fundamentally different. The problem is not just being able to make a financial transaction but able to do it easily - when I'm transacting on the Internet the last thing I want todo is signup for yet another service

<comment><USER2> You're doing real-time payments?? My unanswered questions about no- NSF/guaranteed funds are even more pertinent then... It sounds like you've either got some ridiculously good creditworthiness detection, or you're glossing over a huge issue.

As a money transmitter, I don't know how you'd get around the legal requirements to collect SSN and contact info for US recipients...

Dwolla also has "Guest Sending" \- so users don't need to sign up for dwolla to send me money: [https://developers.dwolla.com/dev/docs/transactions/guestsen...](https://developers.dwolla.com/dev/docs/transactions/guestsend)

<comment><AUTHOR> As I alluded in my other reply we guarantee real-time authorization, not real- time settlement. Settlement can happen in batch mode using networks likes Check21 or ACH.

No NSF != Guaranteed funds

Any payor has the right to dispute a charge. That is a Federal Regulation (Reg E ) so no payment system can guarantee funds (other than wire transfers which are fund transfers not transactions i.e. not funds paid for goods/services received )

We guarantee no NSFs. With ACH NSFs are a big issue since until the 2-3 settlement is done one does not know whether the funds are going to clear. What the Payor disputes with the Merchant is between Payor and the Merchant

In so far as SS# collection etc. it applies only to the receiver not to the sender. MTA laws apply only if funds are being held.

As far as guest checkout for Dwolla and other services - please try it and let me know how far you can get without signing up for the service... the way I see it is guest checkout is simply deferring sign-up not obviating it.

</comment></comment></comment></comment><comment><USER3> You arn't explaining much of the actual benefits of the product, but for what you do describe: Bitcoin can also solve all of these problems. Why bother using checks when it's obsolete in 5-10 years?

<comment><USER4> You realize that checks transfer more money than any other strategy in modern times?

<comment><AUTHOR> Indeed.

"ballpark" numbers:

Total transactions volume VISA/MC CC in 2013: Appx $7-8Trillion Total transaction volume using paper Checks and ACH in 2013: Appx $70Trillion i.e. 10X

</comment></comment></comment><comment><USER5> How does it defer from a wire transfer?

<comment><AUTHOR> A typical payment/financial transaction has two parts, authorization and settlement. In a wire transfer authorization and settlement happen in real- time (they are known as RTGS = real-time gross settlement) i.e. the money is transferred in a single instruction in real-time and once this transaction is complete there is generally no recourse for roll-back. Hence wire-transfers involve high authentication barriers (typically faxing a request with signature or going to a branch) and cost a lot (typically $25 to $50 for outbound transfers) and hence are unsuitable for ecommerce

In our system the authorization portion of the financial transaction happens in real-time but settlement happens in batch (using settlement networks like Check21 or ACH). This makes it feasible for Internet based transactions i.e. ecommerce since authentication can be a simple click on a web page as well as retains the cost structure very low i.e. not just cheaper than wire transfers but also lower cost than Credit Cards.</comment></comment>


Texas Repatriates Gold at Federal Reserve in New York to Texas - <AUTHOR> http://gov.texas.gov/news/signature/21038 <comment><USER2> There are still a lot of gold bugs out there who really dislike the idea of fiat currencies and believe gold is an investment. Rick Perry, the former Governor of Texas, for instance thought it was treason that the Fed printed more money during QE. Fears of hyperinflation still seem to exist out there even though we went through a brief deflationary period.

The gold in question actually isn't in the Federal Reserve in New York. It is at HSBC in a private vault [1]. Texas bought the gold back in 2011 near the height of the gold bubble [2]. It has actually lost quite a bit of its value since then since gold prices are about 25% lower since it was purchased.

Sadly, the Governor seems to still say they are moving $1 billion in gold (as opposed to $750 million). You'd think losing $250 million would be a big deal for a state.

1\. [http://www.washingtonpost.com/blogs/wonkblog/wp/2013/03/26/t...](http://www.washingtonpost.com/blogs/wonkblog/wp/2013/03/26/texas- wants-its-gold-back-wait-what/)

2\. [http://www.ai- cio.com/channel/ASSET_ALLOCATION/UTIMCO_Bullio...](http://www.ai- cio.com/channel/ASSET_ALLOCATION/UTIMCO_Bullion_Buy__Political_Statement_or_Prescient_Investment_.html)

<comment><USER3> They haven't lost $250 million as they haven't sold their holdings.

For what it's worth, UT has the second largest US educational endowment now, only second to Harvard. On the whole, they've done very, very well. It doesn't surprise me that some of their investments are currently underperforming, as that's a hallmark of a diverse portfolio.

<comment><USER4> Paper losses are still losses.. If your holdings decrease in value by 25%, they need to increase by 33% to recover their previous price.

Another way to think of it; You can borrow against assets using the gold as collateral. Texas's borrowing ability is much smaller today than it was when the gold was worth $1B. It's clear that they've lost some tangible value.

</comment></comment></comment><comment><USER5> People still think gold is important? In the case of some massive catastrophe (eg. famine, nuclear war), it seems as if the skills of people to recreate society and technology would be much more important than some metal. I'm really, genuinely interested to hear about why physical possession of gold is that important.

<comment><USER6> People still think money is important? In the case of some massive catastrophe it seems as if the skills of people to recreate society and technology would be much more important than some treasure.

In tbe event of a massive catastrophe, gold is worth MORE than money. Think of it this way, name a civlization in history. Would you rather have $100 of their currency now, or $100 worth of gold from that era now?

<comment><USER7> If the era is January 1980 I'll take the cash. $100 worth of 1980 gold (bought with 1980 dollars) would be worth about $40 today.

<comment><USER8> Even though you are cherry picking a peak value, I don't follow your logic.

$100 worth of gold bought at $850/ounce buys 0.117 ounces of gold. Today that gold (at $1181/ounce) is worth $138.90.

Your cash is worth $100.

<comment><USER7> I was using inflation-adjusted prices. I took the phrase "$100 of their currency now" to mean one hundred 1980 dollars now, which would be worth about $250. Otherwise the argument is a straw man. Any non-perishable commodity is going to outperform an inflating currency in the long run. There's nothing particularly special about gold in that regard.

</comment></comment></comment></comment></comment><comment><AUTHOR> Texas is not the first to do this. Over the last year, The Netherlands, Austria and Germany have also started repatriating gold from the NY Fed. In a way this points at a lack of faith in central bank trustworthiness.

I actually wonder about two things here:

a) What if every other state follows Texas' example and repatriates their gold as well?

b) Perhaps a ridiculous hypothetical, but could this be the first step down the road towards secession? They'd need that gold if they ever wanted to establish their own country.

Also an interesting tidbit in the bill which may point at raising fears of confiscation among the more paranoid-minded: the bill includes a provision to prevent seizure, for private parties who want to avoid another 1933 style confiscation of their bullion by Federal authorities.

<comment><USER9> Texas likes to maintain the appearance of being just a hair's breadth away from secession at all times.

<comment><USER10> It is a common political strategy. Once the focus of the people shifts from the alternatives inside to the enemies and dangers outside, your approval ratings rise. Another pro is that you can assign blame when something bad happens as the public is already convinced of the common enemy.

Horst Seehofer does the same in Germany's Texas, Bavaria.

</comment></comment></comment><comment><USER11> Germany has been repatriating a little gold too, since some custodians haven't been very transparent in their auditing: [http://www.bloomberg.com/news/features/2015-02-05/germany-s-...](http://www.bloomberg.com/news/features/2015-02-05/germany- s-gold-repatriation-activist-peter-boehringer-gets-results)

<comment><USER12> And Austria repatriated 110 tonnes from the Bank of England this year. Venezuela 160 tonnes in 2011. Many other countries are moving in this direction.

Good interview from the "father" of the German repatriation movement: [https://www.youtube.com/watch?t=136&v=nmuNeQr276U](https://www.youtube.com/watch?t=136&v=nmuNeQr276U)

<comment><USER13> There's a bit of a difference between sovereign nations doing it and a state moving stuff around domestically.

</comment></comment></comment><comment><USER14> One hidden cost of this: If Texas wants to sell gold to someone else, and it's held at the NY Fed, it often just has to be rolled down the hall, which is pretty easy from both a security and transportation point of view.

If they house it locally, they have to ship it to and from NYC or elsewhere to exchange it with others.

<comment><USER15> > often just has to be rolled down the hall

Would they even bother moving it at all?

<comment><USER16> They don't. The bars have serial numbers and there's a registry of owners

<comment><USER17> The Ingotchain?

<comment><USER18> While your statement is meant to be ironic, yes that is pretty accurate. The same way a vehicle has a title and there are records indicating all of the owners, a bar of gold has some documents and a record of its owners.

<comment><USER17> It's meant to be one of those ironic comments that still contain deep insight—prompting you to think of me as a flippant genius, like Tony Stark. _fingers crossed that it worked_

</comment></comment></comment></comment></comment></comment><comment><USER19> It's a move heavy in symbolism but with no actual financial implications whatsoever--so, perfect for politicians.

<comment><USER18> Actually, this will "create" jobs somewhere in Texas. So there will be some financial implications for ~50 or so Texans.

</comment></comment><comment><USER20> > keeping taxpayer funds from leaving Texas to pay for fees to store gold in > facilities outside our state

Will they not still be paying for them through Federal taxes? If not, how do the upfront costs compare to the marginal costs of using a National depository shared by 49 other states?

</comment><comment><USER21> I think this is a trend, it is wise move for Texas. It might be also a move to make more independent Texas.

</comment><comment><USER22> good for you!!</comment>


Docker 1.3.0 Release Candidate - <AUTHOR> https://github.com/docker/docker/pull/8323#issuecomment-58556347

<comment><USER2> Well I'm happy about the volume bug fixes. That's a good step in the right direction.

<comment><USER3> Well, the volume bug fixes are fixing things with the volumes re-write which hasn't yet hit a release (which also adds no public functionality at this point) .

</comment></comment><comment><USER4> I'm happy about --registry-mirror and -ip-masq=false.

</comment><comment><USER5> Does this have namespace support?

<comment><USER3> If by namespace you mean user namespaces, no. Unfortunately golang has made this difficult... fortunately the fantastic folks on the Golang team have graciously added in the support we needed for Go 1.4 even though it's in feature freeze. So Golang 1.4 should be out in Decemberish timeframe, then we can update Docker to use Golang 1.4 and then wrap up work on user namespaces support within libcontainer/docker.

Totally just guessing here, but I'd say Jan/Feb timeframe for user namespaces.</comment></comment>


GW170817 First observation of gravitational-waves from neutron stars inspiral - <AUTHOR> http://www.ligo.org/detections/GW170817.php <comment><AUTHOR> This is the first observation in gravitational waves and light.

Two other relevant pages:

[https://www.ligo.caltech.edu/page/press-release- gw170817](https://www.ligo.caltech.edu/page/press-release-gw170817)

[http://www.ligo.org/detections/GW170817/press-release/pr- eng...](http://www.ligo.org/detections/GW170817/press-release/pr-english.pdf)</comment>


WhatsApp users will start seeing in-app ads within 'Status' feature from 2020 - <AUTHOR> http://9to5google.com/2019/05/23/whatsapp-ads-2020/ <comment><USER3> Has anyone here gone to the Facebook marketing summit? What's that like?

When they announce the intention to put more ads into the app, do people cheer?

</comment><comment><USER4> WhatsApp is my primary messaging app, time to switch over to something else. It can go fuck itself sideways if FB starts adding ads.

Some years ago there was the option of paying, which was removed around 2016. I understand that not everybody cares about this, but PLEASE give me the option not to see ads. There's enough bullshit advertising in my life already

[] [https://www.theguardian.com/technology/2016/jan/18/whatsapp-...](https://www.theguardian.com/technology/2016/jan/18/whatsapp- drops-subscription-fee-free)

<comment><USER5> Not affiliated in any way, but you should give Signal a try.

The hardest part with any IM service is going to be convincing your friends to join though. I wish someone came up with a good way to overcome this "critical mass" problem.

<comment><USER6> My wife and I tried Signal in the past and ran into situations where messages were lost or sometimes delayed by hours, some showing up well after other messages were, making conversations occasionally very frustrating.

Messaging apps are definitely one of those situations where I expect things to work all of the time, not just most of the time.

<comment><USER7> I've had no issues with Telegram, and I think, although less secure than Signal, it's a great option to replace Whatsapp.

<comment> toper-centage Feature wise telegram is definitely the best challenger right now. Signal is good but not as good. I wish it was better because of privacy. I like telegram too much now.

</comment></comment></comment></comment></comment><comment><USER8> Here's a blog post from WhatsApp in 2012 on why they don't sell ads:

[https://web.archive.org/web/20120619170843/http://blog.whats...](https://web.archive.org/web/20120619170843/http://blog.whatsapp.com/index.php/2012/06/why- we-dont-sell-ads/)

<comment><USER9> I remember when I read that article. It was a great idea. When they sold WhatsApp to Facebook however, I realized that this is potentially the fate of any for-profit business.

<comment><USER10> I agree. That's why I have become a much bigger champion for non-profit businesses.

<comment><USER11> Hey Brian, great to see you on here. Any updates or thoughts as to where Signal is these days? I would love to switch over to it as my primary messenger, but the majority of my non-tech friends haven't heard of it before.

</comment></comment></comment></comment><comment><USER12> > While ads themselves aren't exactly the most welcome inclusion, this will be > a much-preferred method than intrusive banner ads.

There's no reason to believe it'll stop here.

Instagram was ad-free for quite some time. Now every third or fourth post is a big, unmissable ad. Same thing in stories.

<comment><USER13> > Instagram was ad-free for quite some time. Now every third or fourth post is > a big, unmissable ad. Same thing in stories.

Stopped using Instagram because even the "organic" posts are ads or product placement of some sort. It seems like every time someone hits 10k subs or more, their content becomes >50% ads.

<comment><USER12> I follow primarily friends, family, and a few hobbyists in my chosen hobbies (model trains, space/rockets, etc.). It's been no trouble to curate - <USER2> than one "sponsored" post probably means I unfollow you, as do memes. The end result (barring their ads) is a really nice feed of pictures that are either cool or interesting to me personally.

<comment><USER13> Family and Friends post boring stuff for the most part. I was on Instagram for other things like photography, interior design and memes. The first 2 categories will obviously have "sponsor content", but when meme pages started shilling products, it was over for me.

</comment></comment></comment></comment><comment><USER14> It's always funny to remember that the smartest people currently alive are probably in some FAANG office figuring out how to monetize online platforms through whatever means possible.

<comment><USER15> Why do you think they are the smartest people alive, compared to say, a scientist at CERN?

<comment><USER14> I was parroting a classic quote [0], but you are right: my statement was needlessly cynical. To rephrase, I'd say an enormous proportion of the smartest humans alive are involved in zero-sum redistribution games that offer no socially useful outcomes. The costs of being poor and the rewards of being wealthy are each so enormous in our world that I can't blame them.

[0] [https://www.fastcompany.com/3008436/why-data-god-jeffrey- ham...](https://www.fastcompany.com/3008436/why-data-god-jeffrey-hammerbacher- left-facebook-found-cloudera)

<comment><USER16> Without entering into an argument over the definition of smart, I understand what you're getting at. The top graduates of the top schools empty into finance, big law, medicine, and now big tech. Though it gives me some hope that startups are starting to get their share of talent too, now that companies like YC or VFA are basically throwing money at it.

</comment></comment></comment></comment><comment><USER17> Good, that will maybe drive more people to alternate platforms. The only reason I have it installed at all is that my non techie friends insist on using it for whatever reason. It's not like I have a shortage of similarly capable chat & call apps installed on my phone.

E.g. Signal is pretty much there in terms of capabilities to take over. All that's needed is a gentle nudge. Some ads should help for that.

</comment><comment><USER18> Yet another thing consumed by the cancer that is advertising.

<comment><USER13> The real cancer is SV companies growing to an enormous scale without ever figuring out how to get people to pay for it. Once the price ceiling is $0, there is no other way to monetize except by destroying the experience with increasingly intrusive advertising.

</comment></comment><comment><USER9> I use WhatsApp for one single reason: it is not yet blocked in Iran so I can talk to my loved ones. Signal and Telegram for the rest.

</comment><comment><USER19> Why can't they just carry on charging people like they used to. Greed + middle management stupidity.

Someone at Facebook is proud of their smartness and will probably get a title like Senior Manager for messaging advertising.

The trouble with switching IM is that everyone needs to switch as well.

<comment><USER20> > _Why can 't they just carry on charging people like they used to_

They believe they can earn more from ads than they can from paying subscribers.

</comment></comment><comment> vincent-toups Is there any popular web based business that isn't a bait and switch?

<comment><USER21> Not sure if popular, but Librem One is very promising.

</comment></comment><comment><USER22> I would rather pay than see ads and fall prey to all the targeting and data mining. Take my money Facebook, please.

<comment><USER23> I am assuming that one of the reasons they won't let users pay to opt out of ads might be because paying users are the most valuable for advertisers. They wouldn't let their most valuable target pool out of the advertiser's hands.

</comment></comment><comment><USER24> In Europe, they're not going to use data from your FB account to show ads, right?

Given that last year they agreed not to share data [https://www.theverge.com/2018/3/14/17120446/whatsapp-user- da...](https://www.theverge.com/2018/3/14/17120446/whatsapp-user-data-sharing- facebook-uk-privacy-ico-protection-gdpr-europe)

</comment><comment><USER25> Telegram time.</comment>


How much battery storage does a solar PV system need? - <AUTHOR> http://euanmearns.com/how-much-battery-storage-does-a-solar-pv-system-need/ <comment><USER2> Battery storage is simply not meant to cover that kind of gap. It's intended more to cover the overnight period, when you have no sun, or maybe for a few days with bad weather.

You need to spec your system so at the very least it generates enough power on the worst days of the year to cover your needs, and surplus power on good days. You also should have a second means of power generation, wind works nicely as it's uncommon to have a day that isn't either windy or sunny.

<comment><USER3> The OP does not have a single clue about actually using solar. His price per KWH is about 1 order of magnitude off (and then some).

I've used 100% solar for the past 2 years and there has not been a single day that I needed a second source of power.

Also my system is quite modest. Just 500W of panels and about 600Wh of lithium ion battery (lifepo4) energy storage.

The 500W of panels is plenty. Most days I charge my batteries fully before noon.

The 600Wh of batteries is enough to get me through 3 days of heavy cloud weather ( you get about 10% of your maximum generation on a heavily clouded day ).

This system is for two people using our computers and 3g wireless for the entire day. LED lights at night which are bright and warm, water pump, food processor, stereo, iPad, hella gadgets, raspberry pi backup server, etc etc

If I changed something, I'd double the batteries that I use.. going to 24V. You get more of the rated power of the solar panel when using a 24V system. I am considering getting an electric bike & storing extra power there.

The total cost of the system was about $800.

In the summer I can generate about 2 kWh / sunny day -- I only need about 400Wh / day though. You do the math for the cost per kWh. It's damn cheap.

<comment><USER4> > The OP does not have a single clue about actually using solar.

Exactly. It's a total nonsense proposition to offset seasonal swing using battery power. Running a PV system is about conservation first and foremost and some planning second. Your battery is for the day/night cycle and overcast days, _not_ for seasonal variations. Maybe he should run a PV system for a while before writing articles like these.

<comment><USER5> I think the original article was looking at the proposition of off-grid energy use using purely solar, in which scenario seasonal variations matter

From the article "Even with these rough numbers it's hard to see how anyone living any distance from the Equator is going to be able to justify the cost of installing enough batteries to go off-grid with a domestic rooftop solar PV installation."

<comment><USER4> > Even with these rough numbers it's hard to see how anyone living any > distance from the Equator is going to be able to justify the cost of > installing enough batteries to go off-grid with a domestic rooftop solar PV > installation.

If you go off grid on purely solar your backup is not a battery, your backup is a genset.

It's a nonsense proposition leading to nonsense conclusions based on nonsense numbers. Very tiring.

<comment><USER5> I'd agree, I was just pointing out the basis that the author was coming from which was the reason why he was considering seasonal variations in battery calculations.

With that said, from reading some articles about off-grid living, it's not outwith the bounds of possibility that people are looking at pure solar (or pure renewable anyway) off-grid living, for priniple-based reasons , rather than a more pragmatic rationale.

<comment><USER4> Only if they don't care about their lives. Look, I've lived off the grid for a number of years. 99% of the time things work just fine and all your plans come out. And then, in the middle of January there is a 9 day spell without wind and solar and you're going to have to fire up the genset. Tough, but preferable over having all your waterlines freeze due to 'principles'. Principles are nice to have but when you go off-grid out of principle the one principle you don't want to throw overboard is reliability and a good generator is worth gold when everything else you carefully planned out fails. If there is one thing that you can predict about the weather then it is that it is unpredictable.

<comment><USER3> I guess a genset doesn't add much to the final bill?

<comment><USER4> A small one is better than nothing in a pinch and a 2 KW gas powered genset is a few hundred bucks. I went the overkill route (diesel, 6.5 KW) but I also had a machineshop attached to the house and it was nice to run the mill or the lathe without draining the battery in a couple of hours.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> In this hypothetical scenario, instead of investing so much in batteries, why not just double the size of your solar array so you're not storing 6 months worth of power in batteries? That would only cost ~20K instead of the ~500K for batteries.

<comment><USER4> You use the battery to offset the times when the sun does not shine so more solar power does not work. You don't use batteries to offset the summer/winter cycle, you use them to offset the day/night cycle and to store a bit more in case the next couple of days are overcast.

The whole winter/summer storage thing is nonsense, nobody sizes a PV system like that.

<comment><USER5> well nobody apart from people looking for an off-grid lifestyle of course. What I took from the article is that pure solar off-grid is impractical away from equatorial latitudes.

<comment><USER4> If that's what you too from the article then you're right 'pure solar' is impractical (anywhere). You always need a battery and you _always_ need some kind of backup.

But if you're going to think like that grid power is _also_ impractical anywhere, since it too could fail. Power is so important that no single source should be relied on anywhere. In inner cities of course your only chance of getting power is the local electricity company hookup, but if that should fail for any extended period of time such a city would rapidly become a place where you could no longer live, especially at latitudes where it tends to get very cold in the winter.

So, nobody (in their right mind, at least) will do a 'pure' photovoltaic system. There will always be some kind of backup-power mechanism, either the grid, a wind-turbine, a battery to tide you over, a pelton wheel fed from a stream, grid power or any combination of the above.

<comment><USER7> I really liked the article - it will be interesting to see it updated every 5-10 years as Battery Technology (slowly) improves.

In reality, what most people (today) who want to live off grid end up doing is hybrid-systems. Natural Gas/Propane for heating, cooking, cooling, and Solar for electrical use. (computer, lights)

<comment><USER4> People living off the grid tend to use wood for heating. Outdoor woodstoves are the thing, and for cooling they open _two_ windows ;).

</comment></comment></comment></comment></comment></comment><comment><USER4> > 1\. Household consumption is 5,000 kWh/year. (About right for Western > Europe, low for the US, high for most of the rest of the world.)

So, to stick with HN's tradition of making negative comments about articles: This author is totally clueless, that's not at all how you size a PV system (and the battery to go with it). Battery power in a solar system is not used to offset seasonal variation but the day/night cycle and a possible overcast day (or two).

Then the first line listing the assumptions made starts from the average household but a PV system designer that is designing an actual system rather than a theoretical one will start with throwing everything out that you can miss, the household will be anything but 'average'. Electric heat, AC and a whole raft of other big consumers get thrown right out before you even start to think about what your consumption will be. No romantic array of incandescent spots for you, and no baseboard heat. Everything you can save you won't have to generate and store and that's your first gain. This will cut the consumption in half or even better and _then_ you can start wondering about how much PV you need, if you're going to have wind or water to augment that, what size you genset will have to be (in case all of the above aren't available for a longer period) and what kind of storage battery you need. (And of course what size inverter(s) to convert your DC back to AC tied into the distribution panel of your house, you really don't want to run your household on DC)

A good rule of thumb for battery storage for a system that is off-grid and totally self-reliant is to have 5 days worth of consumption leading to 33% or 20% of battery discharge depending on how nice you want to be to your batteries. That's a _whopping_ large battery, most likely larger than what your friendly car company can sell you in one chunk so you'll need multiple units ganged together via some kind of bus system.

When you go off-grid your life can depend on the working of the system, if you're snowed in and you can't get fuel, the sun lets you down and there is no wind then you fire up your trusty genset (preferably a diesel, you might be running it for a week straight in an emergency) to put some much needed charge into your batteries. Of course you anticipated this and you have two weeks worth of fuel stored.

Also, in very cold weather battery capacity tends to be reduced.

So, in short design your house and your life around your energy budget and even then you'll find you need a rather very large battery.

<comment><USER8> He's not clueless, he's intentionally writing propaganda to undermine solar power, to help boost his hobby-horse of nuclear. He has no genuine interest in answering the question posed in the headline.

<comment><USER9> Read the follow up linked here:

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

</comment></comment></comment><comment><USER10> The amount of battery storage required for a household on-grid is much smaller when you can think of the grid as a load balancing device.

Of course we'd need to get away from the huge mismatch between feed-in tariffs and consumption tariffs.

Ideally the difference would be a small spread (like in a currency exchange rate) and a nominal daily connection fee.

In which case a 10KW Tesla powerwall is a pretty handy size.

<comment><USER11> >Of course we'd need to get away from the huge mismatch between feed-in tariffs and consumption tariffs.

Maybe first we could nationalize the whole outfit and run it on a cost-plus basis. There is way too much profit being made from being a monopoly grid operator.

That probably has more to do with why solar is such a good deal than the green energy subsidies do.

<comment><USER9> In the US I'm under the impression that generation and transmission are pretty heavily regulated. Do you have a favorite example company that makes egregious profits?

</comment></comment></comment><comment><USER12> Of course the example is wrong because for most of the places it is resolved by simply having a larger PV array so that even winter generation is sufficient. That will probably not work for 60N, but easily for 40N: an array about the size calculated for 60N, used at 40N, will not require any seasonal storage.

And of course, nobody uses storage like that. Off-grid system must combine solar and wind, wind typically gets stronger in winter, plus about 24 hour worth of energy consumption in storage (a couple Tesla systems), and finally a diesel generator for a few percent of the total generation for the unlucky days when sun doesn't shine and the wind doesn't blow.

</comment><comment><USER13> The usual approach is to take a conventional house design, and then design a solar supply to meet its needs.

This results in a crazy large system due to our appalling wasteful house designs (which in turn are due to historically cheap electricity).

A better approach is to decide how much you can spend on solar, then design a house which will function within that limitation.

To succeeded you will need to change house designs, select different type and size of appliances, and most importantly, make some personal sacrifices.

If you can live within these limits, then yes, you will enjoy having Solar. If not, you would be better to continue with your existing expensive lifestyle.

</comment><comment><USER14> How many 9s of reliability do you want to pay for?

Speaking only regarding residential energy: In North America, other than Hawaii as of a couple weeks ago, solar generation banks credit for electricity exported to the grid. In effect, a 100% efficient, and free, battery. In Austrlia, exported power receives credit only equal to the offset generation -- less than 1/3 of the total price of electricity. In those cases, there is an economic evaluation.

Otherwise, batteries are for reliability. And apparently there are more residential backup generators in the US than there are residential rooftop solar.

<comment><USER4> Going off-grid when the grid is present and reliable is dumb. Even without net-metering being 100% as long as you cover your own use 90% of the time it is still much cheaper than battery power (charge/discharge costs more than what power from the grid costs, batteries have a life-span).

So in that situation you try to cut your consumption when you generate little power or you take the hit by paying for grid power.

The larger chunk of your bill in that case will be the termination fees, the electricity bill typically has two components, one where you pay a fixed fee for the connection whether you use it or not and another you pay per used KWh. The first component can handily outstrip the second making those very expensive KWs, especially when you're close to running of your own power most of the time.

Still, if you think of it as a replacement for both your genset _and_ your very large battery it may make economic sense to do this anyway. It all depends on the location and reliability of the grid. Where I lived our PV system was many times more reliable than the local grid so we ended up ditching the hookup but that's a very exceptional situation.

<comment><USER15> That's what this doesn't take into account. If you install batteries, you use them for only part of the time to make up for times the PV doesn't generate electricity. This offsets costs of drawing from the grid. But when you need to draw from the grid, you do so.

</comment></comment></comment><comment><USER16> You really shouldn't plan battery storage for winter/summer cycle. Batteries are for day/night cycle. If stretched a bit, then maybe batteries will cover "that rainy day, when I need to do laundry" and similar. But not much more, as you've seen yourself - this is prohibitively expensive.

For winter/summer cycle, if you're south of 40° N (and north of 40° S) just oversize PVs. Otherwise, you need a second power source - grid, wind or geothermal.

Not to mention that having a second source is really good if you ever plan for maintenance or emergency repairs.

</comment><comment><USER17> One thing this article shows, is how different solar is on high vs low latitudes. Up to around 40 degrees, solar is practical, and you only need to take the nights and possibly cloud cover into account, at 60 degrees, the seasonal variation is too high to be stored in a parctical way, even with his assumption of flat consumption through the year, which is quite unrealistic with the short days and low temperatures at high latitudes. It means that off the grid solar is unrealistic in Northern Europe, but it can be a possibility many other places in the world.

<comment><USER4> I ran an off-the-grid fairly normal house in Northern Canada, solar was > 70% of our power. Seasonal variations are not leveled by batteries but by properly dimensioning the system and reduced consumption. So off the grid solar is _very_ realistic in higher latitudes, especially if you take into consideration that panels will generate a lot more power when they're cold than when they are warm. The most power I ever saw generated instantaneously was on a terribly cold day in February (but that was exceptional). Sure the days are shorter but you adapt to the reduced energy budget fairly easily.

Off the grid solar is unpractical the world over if you don't adapt your consumption.

<comment><USER3> Wow that is great that you were 70% solar in North Canada. Yes I've heard that panels can output actually more than their rated capacity when sunny & cold.

I think the big problem people have with going PV, is that there isn't a good manual on how to go solar. & much of it is changing and improving as we speak.

<comment><USER4> There may not be a manual simply because every situation is different (and it's a personal thing too), but there is a huge community of renewable energy enthusiasts at [http://www.otherpower.com/](http://www.otherpower.com/) , they have a discussion board at [http://www.fieldlines.com/](http://www.fieldlines.com/) . Collectively they have a huge amount of knowledge about anything related to renewables and anybody considering going off grid could do a lot worse than to become a member and to start reading forum threads. They range all the way from people interested but not actually doing anything to people operating fair sized solar and wind farms and everything in between.

</comment></comment></comment></comment><comment><USER18> The author wrote followup article in which he estimates costs for a more reasonable system that is sized for winter production rather than annual storage:

A Potential Solution to the Problem of Storing Solar Energy – Don't Store It.

[http://euanmearns.com/a-potential-solution-to-the-problem- of...](http://euanmearns.com/a-potential-solution-to-the-problem-of-storing- solar-energy-dont-store-it/)

As commenters here and on the blog suggest, this is a much more cost effective approach (although still prohibitively expensive in extreme latitudes).

<comment><USER8> Across two epically long blog posts, that's a lot of words, numbers and graphs to say "it's sunnier nearer the equator" and "electric grids are handy, don't abandon them for no reason", all delivered with a lot of _attitude_ for no obvious reason.

Is there some context outside of these two posts that makes them reasonable things for someone to have spent so much time and effort on?

</comment></comment><comment><USER15> 5,000kW per year is _low_ in the U.S.?

That is extraordinarily wasteful. In most of Australia the average is about 2300kW per quarter, and even that is probably a high estimate. But if 5000kW is low then I'm assuming the average has to be 6000kW, or 6500kW! That a HUGE amount of power!

What on earth are people in America using?!?

<comment><USER19> You might have mixed per-quarter and per-year numbers there.

According to [http://shrinkthatfootprint.com/average-household- electricity...](http://shrinkthatfootprint.com/average-household-electricity- consumption) the average (in MWh/a) is 11.7 for USA and 7.2 for Australia, both at the high end of first-world countries. It's 3.5 for Germany for instance.

I always wondered why we measure consumption in those units, instead of just using average power directly. 11.7 MWh/a = 1.33 kW.

<comment><USER15> No, not at all. I'd like to know where they got those figures! In NSW, Australia's largest state, IPART (the Independent Pricing and Regulatory Tribunal) who until about a year ago set electricity prices, gives different figures for 2010:

"Households with 1-2 residents use about 1,400 kWh of electricity per quarter

Households with 3-4 residents use about 2,100 kWh of electricity per quarter, and

Households with 5 or more residents use at least 2,700 kWh of electricity per quarter."

[http://www.ipart.nsw.gov.au/Home/For_Consumers/Compare_Energ...](http://www.ipart.nsw.gov.au/Home/For_Consumers/Compare_Energy_Offers/Typical_household_energy_use)

Edit: I must be tired. My calculations are way off. Sorry about that.

</comment></comment></comment><comment><USER11> IIRC the Tesla batteries are actually really pricey for what you get because of the brand. I think you can get something from a 'lesser' brand for about 2/3 the price, possibly even less.

In other news, name brand sneakers are also expensive and probably not really worth it.

<comment><USER7> I'd love to see a citation. All I recall people saying when the Tesla Batteries came out was, "How can they sell the system for so little money?" and that "There was nothing out there at that price point"

[http://www.forbes.com/sites/jeffmcmahon/2015/05/05/why- tesla...](http://www.forbes.com/sites/jeffmcmahon/2015/05/05/why-tesla- batteries-are-cheap-enough-to-prevent-new-power-plants/)

</comment></comment><comment><USER20> Troll post.

</comment><comment><USER21> Let's look at chemical storage with hydrocarbons in the mix, allowing some as- yet non-commercial (air-metal & combined cycle home generators) to make good food for speculation.

A consumer to operate a small gas turbine and store their energy in the form of hydrocarbons. If this is to be sensible, then 43MJ/kg would have to be enough, because that's what they're going to get with kerosene/jet fuel.

Now let's consider lithium. The problem with metal-air batteries has mostly been poisoning by unwanted gases. Let's assume for a moment that a membrane material is developed that only allows high purity oxygen through, but suffers low throughput. This is no problem for our off-grid solution because we're talking about large storage relative to power, similar to some flow battery applications. Using some method of specific ion or biological style solution, such a membrane is not implausible.

Lithium-air weighs in at 40MJ/kg specific energy. How much does it cost? Given that a metal-air battery uses lithium oxide, the lithium carbonate and lithium hydroxide prices are not quite valid guides, but the price of $7/kg is obtainable for the carbonate of "battery grade." If the pure oxide can be the material used in manufacture, then possibly the $7 value is in the ballpark.

Jet-A is $0.45 per kilogram. 1.41 $/gal / 3.78541 l/gal / 0.820 kg/l

Higher efficiency must be allowed because even with combined cycle at high latitudes where it's cold, we're looking at 90% round-trip for a battery vs ~75% for our Brayton cycle + home heating.

There are external costs to a large tank of kerosene and a pile of lithium carbonate. One requires a gas turbine and the other requires a battery & significant manufacturing. Excepting those two things, we're left with a roughly 7:1 factor of cost for the raw material, so a seven year payoff it is.

Lithium might not be the cheapest rechargeable precursor. It might be great for EV's (high power output is a requirement) and maybe something else will show up as the cheapest energy storage without requiring off-grid people to rely on ARES gravity trains.

Perovskites (new paper just suggested that hot-carrier phonons can be used to raise theoretical efficiency to 66%) throw yet another wrinkle into solar. Both energy storage and generation could become quite a bit cheaper.

All hypothetical, yes, but my napkin does tell me not to rule out off-grid, not that I'm sympathetic to off-grid, anti-social Ayn Rand acolytes =D Whatever matters for off-grid matters for a ton of settings, such as places where there is no grid still. It's tough to say definitively that a straight- renewable energy source won't become cost-competitive even in grid areas of high latitude within the decade.

Source on Jet A specific heat: [http://www.exxonmobil.com/AviationGlobal/Files/WorldJetFuelS...](http://www.exxonmobil.com/AviationGlobal/Files/WorldJetFuelSpecifications2005.pdf)

Source on Lithum Air theoretical specific energy: [https://en.wikipedia.org/wiki/Lithium%E2%80%93air_battery](https://en.wikipedia.org/wiki/Lithium%E2%80%93air_battery)

Jet A price: [http://www.indexmundi.com/commodities/?commodity=jet- fuel](http://www.indexmundi.com/commodities/?commodity=jet-fuel)

Lithium Carbonate Price (ev grade): [http://www.globalstrategicmetalsnl.com/_content/documents/40...](http://www.globalstrategicmetalsnl.com/_content/documents/405.pdf)</comment>


The Most Common Jobs for the Rich, Middle Class and Poor - <AUTHOR> http://www.npr.org/blogs/money/2014/10/16/356176018/the-most-popular-jobs-for-the-rich-middle-class-and-poor

<comment><USER2> That really shows how generic the job category "Managers" is. It's one of the most common jobs for every decile of income above the bottom three.</comment>


Richard Feynman Computer Heuristics Lecture - <AUTHOR> https://www.youtube.com/watch?v=EKWGGDXe5MA <comment><USER2> Watched this the other day, good layman's introduction to what computers actually do. Feynman has a serious skill at explaining complex topics in simple terms that anyone can understand.

love to watch Feynman's lectures even if I have a fairly good understanding of the topic, such an entertaining lecturer.</comment>


Node input function is broken - <AUTHOR> It has been 10 years since Node.js first release (according to wikipedia, at least). And it has been a long journey since then. We went from everything asynchronous world to everything async/await world.
but seriously, it time for us to reflect about the basics...
Every normal computer programming language in this planet has a input/output function.
When you're learning every normal computer programming language in this planet, the first thing you do is to create is a 'hello world' to test the output function and some sort of simple calculator to test the input function.
it's really the basics of every normal computer programming language in this planet!
but why node.js is different?
why do I have to do something like this:
var readline = require('readline'); var resp = "";
var reader = readline.createInterface({
    input: process.stdin,
    output: process.stdout });
reader.question("Some question here:", function(answer) {
    var resp = answer;
    console.log("you typed " +answer);
    leitor.close(); });
instead of something like this:
var resp = prompt("Some question here: ")
WHY?
I'm sorry if I'm not been polite and a bit rude. but seriously, if, every time I want to receive a input from the console, I have to google to figure out how to do that, then the problem is not mine, it's the language itself.
I'm really disappointed with node.js. I really love it. but I can't create a simple console app without googling it or importing other library. <comment><USER2> you are saying that everything was from async to sync. not everybody agree. btw you can write a sync if you want. and node is not a language, neither javascript, the language name is ecmascript. the problem is yours, save your own utils, if lowcode is what you want you don't have to code.</comment>


Severe hand kept alive on man's ankle - <AUTHOR> http://www.bbc.co.uk/news/health-25405543

<comment><USER2> Wow. +1 for an actual picture of the severed hand on the ankle, -1 for not showing us the glove/shoe hybrid that this arrangement dictates. Net wash, don't bother.

</comment><comment><USER3> -1 for title typo</comment>


Objective-C literals for NSDictionary, NSArray, and NSNumber - <AUTHOR> http://cocoaheads.tumblr.com/post/17757846453/objective-c-literals-for-nsdictionary-nsarray-and

<comment><USER3> Well, I guess that was long overdue. Anyway, another nice step to bring Objective-C forward.

It seems to develop into a nice combination of low-level, high-performance C and a pretty straightforward, dynamic, object system. In short, I vastly prefer its object system to C++, because it reasonably trades some performance for greater dynamisms and an easier syntax.

It'll be interesting how Objective-C will develop.

<comment><USER4> I completely agree, it's great to see that the language continues to move forward and advance in it's OO design. It's especially nice that these forward steps do not hinder or reduce Obj-C's low-level functionality, leaving available the performance gains from it's use.

<comment><USER5> Exactly, gcd could have been objc but it is just a c extension!!

</comment></comment></comment><comment><USER6> This is for Apple LLVM 4.0 which ships with XCode 4.4.

Also included:

       - Automatic @synthesize
       - NSArray/NSDictionary subscripting, eg id object=MyArray[12];

<comment><USER7> For those wondering: Xcode 4.3 is what currently ships, 4.4 Developer Preview ships with the Mountain Lion per-release, so it only is available to those in Apple's Developer Program.

<comment><USER8> > _...so it only is available to those in Apple's Developer Program._

correction: Apple's _Mac_ developer program. I'm an iOS developer and I don't see Xcode 4.4 in my dashboard.

<comment><USER9> This is the second time (to my knowledge, may have been going on for a while) that an Xcode beta has been made available to only one of the two (Mac and iOS) developer programs. The Xcode 4.3 beta was only available to iOS developers -- despite containing bug fixes and improvements useful to developers on both platforms. Now the Xcode 4.4 beta is only available to Mac developers.

I really don't see the logic in withholding from paying members of either platform.

<comment><USER10> You can't use the beta Xcode / SDKs to build apps for the relevant App Store anyway, so while it contains neat new features it's technically only useful for developers developing that particular pre-release OS (whether iOS 5.1 or OS X 10.8).

Interestingly now Xcode 4.3 is out of beta the iOS 5.1 SDK is still only available with Xcode 4.3 DP3 (although realistically there's not much public new stuff in iOS 5.1 since presumably it's all under wraps for the iPad 3).

</comment></comment></comment></comment></comment><comment><USER11> This is fantastic. Previously I was employing a macro library that offered $dict(k, v, k, v) and $arr(1, 2, 3) and $bool. But the @[] feels much better, and it increases code portability if a class is not dependent upon a separate macro library. It will really remove the verbosity of objc which is oftentimes one of the major criticisms.

</comment><comment><USER12> We've been talking about similar changes to Objective-J for quite some time (we already have JavaScript literals that map more cleanly than C ones). The one thing we've discussed that I don't think made it here is a set literal. It would be nice to have sets treated in a more first class way, considering how often arrays are used when sets would be more appropriate.

<comment><USER13> Indeed. Even [NSDictionary allKeys] returns an array instead of a set.

</comment></comment><comment><USER14> The excessively verbose collection syntax is my #1 pain point with Obj-C. Looking forward to kicking the tires on this one.

<comment><USER15> It's never before fully struck me how cleanly the "Objective-C is too verbose" complaint really breaks down to two separate issues: one of them being that method names are long (which is arguably a plus) and the other being mostly comprised of the stuff that's apparently mostly taken care of with this release. Actually, I suppose there used to be a third, too: (auto)release/retain statements all over the place.

As somebody who loves the long method names but of course wants less syntactic cruft, I'm really happy with their recent progress.

<comment><USER16> ARC in XCode 4.2 takes care of the release/retain business!

<comment><USER17> Kind of. It does not apply to all Cocoa libraries and you need to follow certain conventions, otherwise the compiler will fail to add the release/retain calls.

</comment></comment></comment></comment><comment><USER18> @-prefixed literals for collections are definitely welcome (I won't miss those nested 'dictionaryWith...' calls for sure).

Anyone know how the []-access will work? Is this going to be a special case for NSArray/NSDictionary synthesized in by the compiler, or is there going to be runtime support for a []-operator message a la Ruby, or maybe something related to key-value coding?

I hope this is done coherently, anyway. I worry that too many special cases to overcome problems like verbose collection access could snowball.

<comment><USER19> There are methods you can implement in your own classes to provide setting and getting for both the array and dictionary style syntax.

If you're a Mac developer, check the forums. Else, wait for the info to be non-NDA.

</comment></comment><comment><USER20> ugh. As much as I love the changes that Apple have been making to Objective-C, as someone with a rather large - first-time project undrway, the pace of change is just killing me. In the last three years we have seen blocks (and Grand Central Dispatch) and garbag collection, Automatic Reference Counting, and now this.

These are all good changes (well, except for garbage collection, but hey, they kicked that out with ARC anyway), but it really is hard to stay up-to-date. Yeah, I know, woe is me, my tools supplier is constantly supplying better free tools, but it is daunting having to review each of this evolutions, and determine if it is worth the effort to integrate it into my project.

<comment><USER21> Maybe I'm misunderstanding, but how much effort are you talking about here? Skipping @synthesize on properties or using literal syntax where/when it makes sense wouldn't cause much additional cognitive load and you don't have to convert old code to use the new sugar.

<comment><USER20> It's not as simple as that when you're planning for the long term. Firstly you need to examine the changes and make sure that they aren't going to create any compatability problems, of the type "if you activate this option, then you can no longer link to libraries that don't use this option". Garbage collection in particular had a lot of those sorts of problems.

But even if you can convince yourself that it _is_ just syntactic sugar, you have to have a long hard think about whether or not you are going to adopt the style. Adopting means going back and changing the code you have already written. Not adopting the style is not tenable in the long term - the new syntax is clearly superior to the old syntax, so there will be a lot of pressure to code the new way. This is particularly true when playing in Apple's backyard, as they have a habit of taking a nice new technology that is optional in one release, and then building on that optional feature for a next release.

For me, in this one particular case, I'll probably go with the new syntax, going back through modules that are already written and redoing them with the new syntax each time I have to touch one for a bug fix/feature.

I'm just getting frustrated because my project started about 18 months ago - <USER2> work on it nights and weekends, and I have to keep stopping work on the project and spending time adapting to new tools. The last 18 months or so have been particularly tumultuous. XCode 4 was a _big_ change compared to its predecessors. I started using the garbage collector just to have it more or less replaced by ARC.

None of this is insurmountable, but as a one person, part-time shop with a fairly ambitious project, this is really starting to become painful for me, which is the point I was trying to get across, and I suspect that I'm not the only one to be feeling the pain. Perhaps I would feel better about deciding not to follow Apple on this one if I could be sure that that decision wouldn't mean me finding myself with a big code base on my hands that is unable to take advantage of the new hotness in the _next_ version of Objective-C because I decided to skip _this_ version's changes...

<comment><USER8> I understand what you mean; but in this case, I think it's fairly easy to adopt new syntax in all of you code base. Just search for _NSArray arrayWithObjects:_ , _NSDictionary dictionaryWithObjects:_ and _NSNumber numberWithChar:_ and replace them with new syntax. It wouldn't be this easy if it was a major change (like ARC).

</comment></comment></comment></comment><comment><USER15> Nice! As somebody who's not a member of the Mac Developer Program but whose Twitter feed has been _full_ of people gushing about how nice the new additions to Objective-C are, I'm glad to see what all the hubbub is about.

</comment><comment><USER22> I'm glad to see these additions, but the syntax for an NSArray literal bugs me.

When I want an array literal in C, I'd write ...

      int foo[] = { 1, 2, 3, 4, 5};

... but in Objective-C, for an NSArray literal I'd write ...

      NSArray *bar = @[o1, o2, o3];

Why did they choose '[' over '{'? Oddly enough, NSDictionary uses '{'.

I feel like the syntax for an NSString literal is more natural (as a C developer).

      NSString *baz = @"look, an NSString literal";
      char szBaz[] = "look, a C string literal";

<comment><USER23> I think they chose the [] for arrays and {} for dictionaries as that is the style that seems to be most popular right now. Python for instance uses this.

<comment><USER22> When adding features to something, I tend to be a big fan of "when in Rome"[1]. If these were extensions to Python (or Ruby or JavaScript) then I would totally be for using '[' with arrays. As a C guy though, I would rather have seen them use '{' for NSArray and '[' for NSDictionary. Regardless, I'm glad to see this stuff added.

[1] [http://en.wiktionary.org/wiki/when_in_Rome,_do_as_the_Romans...](http://en.wiktionary.org/wiki/when_in_Rome,_do_as_the_Romans_do)

<comment><USER24> It's already custom in objc to use {} for dicts and [] for arrays when printing them out, unless I'm misremembering. It also matches the use of those characters in JSON, so it seems natural to me.

</comment></comment></comment></comment><comment><USER25> Well this is good news. I have nothing to complain about here, it was even done with the obviously correct syntax following the principle of least surprise. Yay!

</comment><comment><USER26> On one hand, it's nice, and it'll make coding in Obj-C nicer.

On the other hand, it strengthens the coupling between Objective-C the language the Cocoa the framework, and I'm not sure how I feel about that.

I do like it better than the property dot syntax though. (is a simple assignment to a struct member? is it an objc_msgSend of unknown complexity?)

<comment><USER15> Apple's weird in the way they couple things in different ways than the rest of the industry and against the conventional wisdom. Since essentially nobody has an investment in Objective-C-without-Cocoa or Cocoa-without-Objective-C, I don't see any problem with them evolving them together whichever way seems best to them.

Also, there's long precedent with @"…" syntax for embedding NSString literals and most of the changes are really just preprocessor/static analysis-driven syntactic sugar — sometimes _extreme_ sugar, yes, but optional, highly- predictable, purely-syntactic-cleanup nonetheless. So if they ever decide "the future of Cocoa is Ruby!" or something like that, I'd think most of the sugar could be, to mix metaphors, transplanted.

On that note, though: I don't see Apple moving primarily away from Objective-C any sooner than I see .Net moving primarily away from C#. It's "the language" until something huge changes the landscape, in large part because they've been able to so substantially evolve it, just like Microsoft, who also controls the primary framework used with their language, has been able to do with C#.

</comment></comment><comment><USER27> Nice. I wish for ability for function to return multiple values. Is it possible at all?

<comment><USER28> You can use C99 struct literals:

        return (struct x){a,b};

Small structs may be passed in registers. <http://stackoverflow.com/a/3355560/27009>

<comment><USER29> IIRC passing Obj-C object pointers in C structs is disallowed or discouraged by ARC.

<comment><USER30> You have to explicitly bridge them in or out of ARC and indicate the ownership rules. Sometimes, for example when you're interfacing straight C code, you have no other option.

</comment></comment></comment></comment><comment><USER31> Does this come courtesy of a new version of the Objective-C language?

The definition of ObjC confuses me a bit. It's said to be a superset of C - but which C? C89? C99? GNU-C-Something?

<comment><USER32> Obj-C is essentially a preprocessor on top of a C compiler. Whether that C compiler is C89, C99, or C++11 is up to you.

Obj-C also includes the Foundation classes that were originally introduced with the OpenStep SDK in 1994 (NSObject, NSString, NSNumber, NSArray, NSRunLoop, NSAutoreleasePool, etc.).

<comment><USER31> Is it possible to see this straight C translation? Using Clang for example. I'm sort of aware of the "objc_msgSend" business, but would like to see more.

Talking of OpenStep, after seeing some of those NeXT videos on HN the other day, I found a torrent of OpenStep 4.2 incl the dev tools. It's a VMware image and boots and runs just fine. Pretty nifty. Then I noticed OpenStep 5.0 redirects to Mac OS X on Wikipedia!

<comment><USER33> Quick example of calling a method that doesn't take any arguments and returns an object:

      id foo = [self bar];

is the same as:

      id foo = self.bar;

which is also the same as:

      id foo = [self performSelector:@selector(bar)];

or:

      IMP barImp = [self methodForSelector:@selector(bar)];
      id foo = barImp(self, @selector(bar); [1]

and finally:

      id foo = ((id)(id, SEL)objc_msgSend)(self, @selector(bar)); [2, 3, 4]

1\. Because we're calling the IMP, or implementation, directly, we don't need a cast (like we do below, with objc_msgSend).

2\. Casting the function is optional, but, helps to prevent things like endian differences and your return value getting mangled when using the same code on PPC and Intel. Not too big of a deal anymore.

3\. There are actually two other varieties of objc_msgSend, depending on your return type — specifically, floating point calls should use objc_msgSend_fpret and calls that return a struct should use objc_msgSend_stret.

4\. I hope I got this cast right, I didn't try to compile it.

<comment><USER26> Those first two and following aren't equivalent, are they? Wouldn't they compile, respectively, to:

        objc_msgSend(self, @selector(bar));

And:

        objc_msgSend(self, @selector(performSelector:), @selector(bar));

    ?

<comment><USER33> The first two are the same, with a different syntax, yes.

They would both become:

      objc_msgSend(self, @selector(bar));

However, your examples are basically explicitly passing a message (1 and 2), vs dynamically building a message to pass (3).

For the second to work, the objc_msgCall function would really be:

      objc_msgSend(self, @selector(performSelector:), @selector(bar));

(The first example is saying to self to call the selector (method) named 'bar'. The second example is telling self to call the method 'performSelector:' with an argument of 'bar'.)

The runtime may or may not be smart enough to optimize this out. It has never been a bottleneck for me to bother looking into it, and I haven't come across anything to indicate one way or the other.</comment></comment></comment></comment></comment></comment>


Go Object Oriented Design - <AUTHOR> http://nathany.com/good

<comment><USER2> Great article, really enjoyed it! Well structured and example code seems to be good. Will be going over this again tomorrow and adding some of the tricks I wasn't aware of to my toolbox.

<comment><AUTHOR> Thanks very much. Glad it was helpful. ^_^</comment></comment>


US Military Contracts and Defense Spending - <AUTHOR> http://www.militaryindustrialcomplex.com

<comment><USER2> I love that Eisenhower speech, but it's a good idea to read it in its entirety: [http://coursesa.matrix.msu.edu/~hst306/documents/indust.html](http://coursesa.matrix.msu.edu/~hst306/documents/indust.html). It's not a screed against the military-industrial complex, but an urging for balance.

More context for the quote on the front page of that site:

"A vital element in keeping the peace is our military establishment. Our arms must be mighty, ready for instant action, so that no potential aggressor may be tempted to risk his own destruction.

Our military organization today bears little relation to that known by any of my predecessors in peacetime, or indeed by the fighting men of World War II or Korea.

Until the latest of our world conflicts, the United States had no armaments industry. American makers of plowshares could, with time and as required, make swords as well. But now we can no longer risk emergency improvisation of national defense; we have been compelled to create a permanent armaments industry of vast proportions. Added to this, three and a half million men and women are directly engaged in the defense establishment. _We annually spend on military security more than the net income of all United States corporations._

This conjunction of an immense military establishment and a large arms industry is new in the American experience. The total influence -- economic, political, even spiritual -- is felt in every city, every State house, every office of the Federal government. We recognize the imperative need for this development. Yet we must not fail to comprehend its grave implications. Our toil, resources and livelihood are all involved; so is the very structure of our society.

In the councils of government, we must guard against the acquisition of unwarranted influence, whether sought or unsought, by the military industrial complex. The potential for the disastrous rise of misplaced power exists and will persist.

We must never let the weight of this combination endanger our liberties or democratic processes. We should take nothing for granted. Only an alert and knowledgeable citizenry can compel the proper meshing of the huge industrial and military machinery of defense with our peaceful methods and goals, so that security and liberty may prosper together."

The sentence in italics is interesting. Depending on whether you count the VA, the U.S. defense budget is $700-$800 billion. Corporate profits last year were roughly $1.8 trillion.

<comment><AUTHOR> Government accounting is a tricky business, especially when dealing with matters such as this. At one point, DoD couldn't account for over $2 trillion and that was over ten years ago:

[http://www.cbsnews.com/8301-18563_162-325985.html](http://www.cbsnews.com/8301-18563_162-325985.html)

I agree that balance is key, as emphasized in Eisenhower's warning. From my perspective, that balance was lost long ago as no one in the upper tiers of government, the defense establishment or in finance/industry (or the citizenry) paid one bit bit of attention to any of Ike's warnings in that speech:

> "Another factor in maintaining balance involves the element of time. As we > peer into society's future, we -- you and I, and our government -- must > avoid the impulse to live only for today, plundering, for our own ease and > convenience, the precious resources of tomorrow. We cannot mortgage the > material assets of our grandchildren without risking the loss also of their > political and spiritual heritage. We want democracy to survive for all > generations to come, not to become the insolvent phantom of tomorrow. "

<comment><USER3> a light at the end of the tunnel :)

[http://comptroller.defense.gov/fiar/overview.html](http://comptroller.defense.gov/fiar/overview.html)

"Achieve audit readiness of the Statement of Budgetary Resources (SBR) by the end of calendar year (CY) 2014."

and

" Achieving these goals will be challenging, but with the Secretary's involvement, which has elevated audit readiness to an "all hands" DoD-wide effort, the Department's ability to achieve these goals has been significantly increased."

let me repeat :

"...ability to achieve these goals has been significantly increased..."

So it seems that the biggest non-profit in the world can be financially audited somewhere in the next 10 years (for the first time in decades) :)</comment></comment></comment>


ToysRUs Buys Toys.com At Auction For $5.1 Million - <AUTHOR> http://www.techcrunch.com/2009/02/27/toysrus-buys-toyscom-at-auction-for-51-million/ <comment><USER2> Wow...but when it comes down to it people probably don't care about the domain as much as Toy R Us thinks. People find the toys they want, then price compare on Google. Or if they want to skip that step, they'll just buy it from Amazon.

<comment><USER3> Toys R Us owns over 1000 stores, has 97000 employees and does $13.646 billion in revenue every year. Five million dollars hardly registers.

<comment><USER2> Where does your information come from? According to their website they were acquired for $6.6B in 2005. The acquisition was probably at some multiple of revenues...so how did they get up to $13.646B? Besides, earnings are more important than revenues. Look at GM, they lost $20B on revenues of almost $150B. You think it would be wise for them to buy some domain like "cars.com" when they already have gm.com (toys.com just forwards you to toysrus.com)?

</comment></comment></comment><comment><USER4> Another step towards toy monoculture.</comment>


Global Internet Porn Habits Infographic - <AUTHOR> http://www.pornmd.com/sex-search

<comment><AUTHOR> Note that this site is obviously NSFW, even at the top-level domain (main one seems to be some sort of porn search engine).

Interesting data available for both US states and countries as a whole, by region. Would've been nice if they'd linked the dataset as CSV or something for the rest of us to hack on.</comment>