The Land of Lisp - <AUTHOR> http://landoflisp.com/ <comment><USER2> This book comes up in #lisp on freenode every so often, and the channel is generally split on whether or not to recommend it. I generally do.

It's fun and lighthearted. Using games as a medium to teach the language is something some people enjoy, and is a lot less dry than most programming books.

It avoids taking sides on the editor war, by just ignoring it altogether and _teaching Lisp_. This is refreshing compared to most books, which hit you with the Emacs cinderblock to the face right in the preface.

It also stays away from ASDF and Quicklisp and even the entire package system in general, which is a lot of extra complexity that can be overwhelming to beginners at first (though they'll eventually need to learn about this if they want to continue using Common Lisp).

The main issue people have with the book is that it uses CLISP-specific code in a few places. CLISP's last release was seven years ago, and because it hasn't really been maintained it's beginning to bitrot. Folks in #lisp generally don't recommend using CLISP these days, instead recommending actively-maintained implementations like SBCL, CCL, ECL, ABCL, etc.

Using CLISP-specific code does allow the book to sidestep the issue of the library ecosystem, which is a plus. But a revamped version (or even a collection of errata) that ported the CLISP bits to a maintained implementation would make it a lot easier to recommend these days.

<comment><USER3> > _The main issue people have with the book is that it uses CLISP-specific > code in a few places._

This makes sense for a tutorial book, since CLISP is easy to install, very small to download (compared to SBCL), and is a fully featured (ANSI compliant) implementation. So i don't think it was a mistake to choose CLISP.

The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer to the programmer, offering more features. Also, code runs very fast under SBCL; although i suspect that CLISP compiles code faster.

(If any is interested, here is a quick overview on _some_ of the Lisp implementations available and their salient features. (Most implementations are free)

        ECL - Embeddable Common Lisp
            allows you to compile Lisp into any
            other system by compiling to C

        SBCL - Steel Bank Common Lisp
            Produces very fast code,
            allows static type checking and other niceties
            a fork from the CMU CL impl.

        CLISP
            Small, easy to install and use,
            includes readline REPL and X11 features

        ABCL - Armed Bear Common Lisp
            Allows you to run Lisp under the Java JVM
            and call Java code, or call Lisp code from Java.

        CLASP
            Compiles Lisp to the LLVM, provides C++ interop

        ACL - Allegro Common Lisp
            Commercial Lisp, fast, feature rich
            includes a Prolog implementation, CLIM GUI
            and other nice stuff.

        LispWorks
            Commercial Lisp, fast, feature rich,
            includes an IDE, Java Interface,
            and CLIM 2.0 implementation, more features.

        ParenScript
            This is a small subset of CL that gets translated
            (in the server) to javascript

        JSCL
            A Lisp implementation that runs under Javascript,
            providing a REPL and Lisp interpretation on the
            browser, for a subset of the CL language.
    )

<comment><USER4> CLASP is for me the most exciting CL implementation right now. Compilation to the LLVM is a huge advantage.

Sadly, it's a one-man thing. And CL seems quite stagnant.

I wish one implementation triumphed over the others, and CL progressed beyond its ANSI standard.

Clojure has many interesting things. So does Racket. The Lisp landscape is too fragmented. And thus libraries are a huge problem.

<comment><USER3> _> I wish one implementation triumphed over the others_

That would be terrible. Part of the nice things of CL is that you can choose the implementation according to what you need. For example ECL if you want to embed your lisp code with C code. ABCL if you really need to call lots of Java libs (or have Java code call your Lisp code easily), and so on. We're talking about mature, proven, tested implementations.

If one implementation triumphed over others, over time we'd be in a position similar to, say, Python or Clojure, where there is only one or two implementations, besides some experimental implementations, and nothing else.

Something that needs to be mentioned is that CL is truly standardized; if you have a code written in Common Lisp, chances are it will compile straight away on most of the implementations (ECL, ABCL, SBCL, etc), with no change needed. So having many implementations does not mean there is any kind of fragmentation in the language.

 _> and CL progressed beyond its ANSI standard._

CL is one of the most extensible languages out there, so it has already progressed way beyond the ANSI standard. The standard doesn't need modification to support new things. There are already many libraries giving you things that are not in the standard (like sockets or threads) but in a portable and standarized way.

</comment></comment></comment></comment><comment><USER3> This book is destined to be a classic programming book, just as "The C programming language", "The Little Schemer" or "Operating systems: Design and implementation".

I would really like to meet Conrad Barski and give him a great hug. And invite him a good beer.

Be sure to read the comic that is on the bottom of the page!!

Now, to be honest, a quicker or more practical introduction to Lisp would be the "Practical Common Lisp" book which is also superb. However, Land of Lisp is a charming book that makes you smile and feel like a nerdy (in a good way) 12 years old kid in 1982 who just got as a birthday present a brand new Commodore-64 and is eager to read the manuals!

<comment><USER5> Thanks for the kind words! Glad you enjoyed my book!

<comment><USER3> Hi doctor!

The comic at the bottom of the web page got me laughing and in tears at the same time, in particular the line: "Back in the 80s we showed you how to program _without ANY bugs_ ". Also, Java as a little tank, C# as a plane, Python as an helicopter... just brilliant. I almost rolled in the floor laughing by looking at that part of the strip.

Certainly it is prophetic, it seems we're almost reaching the point of being enslaved by bugs...

You're a good man, mr. Lisperati!

 _" As you know, we're in the 8th year of the Great Northern Wars against the Haskellers (there are rumors that more of our troops are defecting to the other side)!! Don't be tempted to break ranks!"_

<comment><USER6> > Java as a little tank, C# as a plane, Python as an helicopter... just > brilliant. I almost rolled in the floor laughing by looking at that part of > the strip.

Is there a special significance to the Java / Python / Ruby / C# representations? I feel like I missed the joke here, even though I enjoyed the strip as a whole.

<comment><USER3> Java as a tank - that is, slow (in development time) although resilient and all-terrain

Python as a helicopter - far more manuverable but slower than a plane and easier to take down

C# as a plane, fast and carries more cargo than an helicopter.

Ruby like some sort of convoluted laser beam weapon

Lisp dialects (on the strip) are all spaceships done using "secret alien technology". Even then, the insectoids are harder to kill than back in the 80s! What will the human+lispers alliance do? Read the strip for knowning what happens next!

</comment></comment></comment></comment></comment><comment><USER7> I've read this book, and what I love about it is that it really brings to mind the programming books of my youth, when nobody would argue that programming should be fun.

It's goofy, has bad jokes, and you learn something.

Having said that, the code style seemed quite idiomatic compared to some of the other Lisp I've seen (although I'm no expert), so I wasn't sure how valuable the lessons were.

<comment><USER8> > seemed quite idiomatic

I'm not sure how that would be a bad thing. Did you mean _un_ idiomatic?

<comment><USER9> A common complaint about Lisp code in general is that programmers tend to write code that is idiosyncratic [ED: I previously used the word "idiomatic" here in reply to the OP but was conflating terms, making this post rather irrelevant but at least it provoked a discussion] (i.e. rather than looking like templated design patterns with standard names, the program is heirarchically built of modules in a domain-specific language of the programmer's own design). This is both one of Lisp's greatest strengths to those who like it, and (I think, based on comments I've seen here and elsewhere) one of the greatest reasons it doesn't have more widespread adoption.

<comment><USER10> I know what you are saying, but that is not what is meant by idiomatic Lisp. Not by Lispers at least.

Non-idiomatic Lisp is typically written by beginners whose code looks more like the language they are accustomed to using previously. For instance, leaning heavily on a procedural style. And not just beginners, but also seasoned programmers that write object oriented Lisp more akin to static OOP. In other words, designing class hierarchies rather than protocols (using generic functions).

What you describe is more of a side effect of the Bipolar Lisp Programmer[1]:

> This is a BBM attitude; it works for me and I understand it. It is also the > product of not needing or wanting anybody else's help to do something.

I haven't read Land of Lisp yet, so I can't really comment as to whether I'd consider it idiomatic Lisp or not. (OP meant "idiosyncratic" anyway, it seems.) Not that I'd be a good judge, anyway.

[1] [http://www.shenlanguage.org/lambdassociates/htdocs/blog/bipo...](http://www.shenlanguage.org/lambdassociates/htdocs/blog/bipolar.htm)

<comment><USER11> God, that link and the comic strip for the Land of Lisp are both so great! I might have to try Lisp again.

>Writing in C is like building a mosaic out of lentils using a tweezer and glue.

I cannot describe the memories and associated feelings this evokes....

</comment></comment></comment></comment></comment><comment><USER12> The music video is what really sold me on buying the book several years back:

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

<comment><USER13> I don't even have to click, I remember it after all those years. Something unique in many aspects. Beware.

</comment></comment><comment><USER14> There's also Realm of Racket [https://realmofracket.com/](https://realmofracket.com/) Which maybe is shorter? I don't recall.

<comment><USER15> The real question is whether it has a sequel to Grand Theft Wumpus in it

<comment><USER3> "The most violent programming example ever put on a textbook!"

[http://w3.sista.arizona.edu/classes/ista450/spring15/project...](http://w3.sista.arizona.edu/classes/ista450/spring15/projects/wumpus/figs/grand- theft-wumpus.jpeg)

</comment></comment></comment><comment><USER16> When I discovered lisp several years ago, it was indeed the textbook moment of enlightenment that you've heard about. This book was a part of that introduction for me (along with Practical Common Lisp). After working in C-like languages, I had no idea that programming could work this way as in lisp, the idea of code and data being inseparable, I even had dreams at night about run-time data structures getting expressed as quoted lists! (I kid you not!)

It is now several years later and I have earned my living ever since by working in another lisp, Clojure. And I have indeed learned a lot along the way and what I've learned does indeed translate to how I work in other languages (even C++, which I also love).

However -- it is not all roses and nicely-flavored toothpaste after a savory feast. There is one aspect to lisp programming that, by virtue of its dynamic typing, I still find myself struggling to reconcile. No matter how much I marvel at what I can do in one or two lines of lisp, I do still often find myself making dumb mistakes that a compiler would catch instantly. Without type annotations and checked structured data for everything, it can also be hard to remember what a function does, or what its variables represent, when you read the code later.

One aspect of this that has made a big difference is naming -- how you name things in lisp and dynamic languages is a skill in its own right that helps guide the readability of code in the absence of types. When I look at C++ code I've written, the verbosity of naming is a clear influence from lisp. And it is an improvement.

The other feature that occurs more often is in-line documentation. It is a joy to read Clojure programs (the good ones, anyway) where every (non-trivial or meaningful) function has a little paragraph summarising what it does. This is just good in any language, but somewhat essential in a dynamic one.

Finally, run-time contracts and things like Clojure.spec come about to help fill the void of static typing. The problem I have there is that you add back into your code a fair amount of the verbosity that was removed in the first place by using a dynamic language (just look at Clojure.spec's lengthy annotations for a function signature, and I find myself wondering... why god oh why?). At which point, I then wonder why not just go back to using a static language.

So using lisp taught me perhaps one final, frustrating lesson: there are just great things about both dynamically typed and statically typed languages, and I've learned that the fence is an awkward place to sit.

<comment> default-kramer My first go at lisp was working through SICP. I loved it. But I couldn't see myself using it for a medium-sized project just because static typing is that valuable to me.

Now I'm learning Racket, and Typed Racket feels great so far (despite a few awkward spots). You don't have to sit on that fence; you can switch between typed and untyped code at will.

<comment><USER3> > _But I couldn 't see myself using it for a medium-sized project just because > static typing is that valuable to me._

See my comment above, you can have static-typing in Lisp with no problem: Type declarations are part of the Common Lisp standard[1], and implementations like SBCL (one of the best Lisp implementations out there, and free) will do static type checking.

[1] type declarations: [http://clhs.lisp.se/Body/d_type.htm](http://clhs.lisp.se/Body/d_type.htm)

"the" (type specifier for return values): [http://clhs.lisp.se/Body/s_the.htm#the](http://clhs.lisp.se/Body/s_the.htm#the)

EDIT: a good example here:

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

<comment><USER16> As with my comment about typed racket, I can't really use common lisp in my work, however clojure is very portable and I can use it (as clojurescript) as a first class language on iOS, and Mac, and the web.

</comment></comment></comment></comment><comment><USER17> I was greatly disappointed with this book because none of the 'Game' examples had a graphical interface to them. They are all text based.

Reading further in this thread people are suggesting Realm of Racket as an alternative and it looks like that book has much more visual game examples: [https://realmofracket.com/games.html](https://realmofracket.com/games.html)

<comment><USER3> > _I was greatly disappointed (...) They are all text based._

That's not really a bad thing...

If you want graphical games in Lisp, take a look at the series called "Pushing pixels with Lisp":

[https://www.reddit.com/r/lisp/comments/6d5nht/pushing_pixels...](https://www.reddit.com/r/lisp/comments/6d5nht/pushing_pixels_with_lisp_episode_1_perlin_noise/)

<comment><USER17> I've been following this series and its great! I'm not saying it was a "bad thing" I'm saying it didn't meet my personal expectations for a "lets build games" book

</comment></comment></comment><comment><USER18> This looks great!

 _Why 's Poignant Guide to Ruby_ really got me started in thinking for myself as a programmer. I'm looking at this book and seeing that if I read it I might fall in love with Lisp...

<comment><USER19> Yea, this definitely seems inspired by Why's style. The art is similar, the story is absurd, metaphorical, and fun. Man, I miss that guy!

</comment></comment><comment><USER20> I loved this book! I've always enjoyed retro text-based games and this was a fun way for me start learning a more functional style of programming (and Lisp). It was a nice contrast to my daily C++ work.

</comment><comment><USER21> I'm so glad that this exists. Lisp (Clojure) has really brought the joy of programming back for me after 20 years.

</comment><comment><USER22> "Simple but refined, guaranteed to blow your mind, the land of lisp"

This guy is a genius :D

</comment><comment><USER23> I've learned LISP and Scheme, gained some useful insights, used them on a few random projects, and then dropped them.

I recommend learning them, but then switching to something like Reason / OCaml / F# / Haskell.

<comment><USER24> counter anecdote: I use and contribute to a number of Scheme programs that I use daily and would never want to switch to any static language. Life at the REPL is too good.

</comment></comment><comment><USER25> I am currently working on an interpreter for a Lisp-like language (it's too early to call it a dialect of Lisp) in Go.

I have not used Lisp at all over past couple of years, except for tweaking emacs, and I am beginning to understand that I have subconsciously missed Lisp.

It is amazing how little - if one really wants to - of Lisp one needs to implement in the host language before one can go on and write the rest in Lisp. Efficiency-wise, I expect that I will implement many things in Go for performance that _could_ be written in Lisp.

</comment><comment><USER26> I've read most of it too, but not sure it shows a lot of lisp's strengths. A lot of the programs I read them over and thought that I could do the same thing in significantly less Python code. I'm not sure what should be fixed if anything though.

<comment><USER27> > A lot of the programs I read them over and thought that I could do the same > thing in significantly less Python code.

My racket code is usually many time smaller then my Python code. The nice thing about Racket/Lisp is you can just make your own tools when in Python you copy thousands of lines of code into a one line code.

The real fix that Lisp/Racket gives over Python is deployment.

<comment><USER26> Agreed on deployment.

</comment></comment></comment><comment><USER28> This is the book i give as a present to the most geeky of my friends.

</comment><comment><USER29> I love this book and it certainly deserves some attention, but is there anything new that is newsworthy? Has a new edition been released? Just wondering if I missed something.

</comment><comment><USER30> Nicely explained.

On a side note, I noticed with deep satisfaction that "git" is used as some kind of curse in the land of Lisp.

<comment><USER31> "Git" in British slang roughly means "jerk". See also Linus's joke about naming software after himself, mentioned elsewhere in thread.

The Monkees had a song called "Randy Scouse Git" (after a catchphrase from the britcom _' Til Death Do Us Part_) the title of which was considered so vulgar in the UK that they had to release the song there under an alternative title (I think they actually used "Alternative Title").

</comment></comment><comment><USER32> the cons chain of arrows certainly reminded me of why deep nested structural syntactic sugar is a pain..

</comment><comment><USER33> Wow, new comic?

Previously it was a different one.

</comment><comment><USER34> The dude on the right looks like an older version of Doug Funny.

</comment><comment><USER35> I really enjoyed the book. An awesome intro to lisp!

</comment><comment><USER36> Making good comics is hard.

</comment><comment><USER37> I'll get hammered for this, but there are better books.

I still haven't figured out if this book is a vanity project written by a bored Doctor, or a sincere attempt to convey information.

I do like the Period Table though.

And maybe it's just me? I have the book on my shelf, and it's dusty.

I do feel using a comic book format to convey technical information is the way to go. It should be used more often.

<comment><USER38> Can you suggest some of these "better books" ?

<comment><USER39> Not him, and I adore the geekiness/goofiness of Land of Lisp, but I found Practical Common Lisp much more helpful.

</comment></comment></comment><comment><USER40> I think you want to read the cartoon guide to the computer</comment>


Atlassian loses a lot of people's JIRA data - <AUTHOR> http://www.theregister.co.uk/2012/05/09/atlassian_cloud_storage_outage/

<comment><USER2> Lol. Cloud computing is the future eh?

<comment><USER3> People who don't have data in the cloud also lose data, though probably not as publicly.</comment></comment>


Mushroom-munching poplar-popping Neandertals - <AUTHOR> http://johnhawks.net/weblog/reviews/neandertals/diet/mushroom-neandertals-2017.html <comment><USER2> This is interesting. Terrence McKenna[0] had some crazy theories about how we evolved and one of the involved mushroom of the psilocybin [1] kind. The idea was that these primarily grow on dung of herbivorous mammals. Since dung is used to track the game when hunting, our ansistors might have come across it and consumed it. It's been shown to improve visual perception in very low dosage. He also suggests the cave paintings of half game/half animals to be a byproduct of it. Of course, he had a nice theory but no way to prove it. But stuff like this hints on that possibility. Although much recent, this cave painting also suggests strong association with mushrooms. [2]

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

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

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

[2] [http://erocx1.blogspot.com/2007/12/oldest-representations- of...](http://erocx1.blogspot.com/2007/12/oldest-representations-of.html)

<comment><USER3> I had the same assumption that the article was going to be about psychedelic mushrooms but the article had not a peep about that topic, solely mushrooms as a macronutrient food.

Some mythology, some of which might even be scientific, is that below a certain IQ, generally representing homo sapiens, neither (serious) fishing nor mushroom gathering is possible or safe or sustainable but above a certain IQ those two technologies are incredibly useful. I suppose a good analogy is uranium is pretty useless until at least one culture reaches a certain industrial threshold and then it becomes quite influential in technology and geopolitics.

I wonder how smart neanderthals were, and how long they live if they eat random mushrooms. At some point it becomes evolutionary cheaper to evolve a smarter brain than to have stronger stomachs and livers.

Psilocybin must have been a very interesting experience for pre-historic cultures.

<comment><USER4> > I wonder how smart neanderthals were, and how long they live if they eat > random mushrooms.

A lot longer than if they were eating random plants. E.g. of the 2,000 or so species of mushrooms in North America, there are maybe 10 or 20 that will kill you. And almost all of those are in the same three or four genuses, so you don't need to be able to identify a single poisonous mushroom to species to avoid being poisoned. There are few more in Europe, but not that many more.

<comment><USER3> Its easy to survive a 1% death rate per meal, for one meal. That's a 99% survival rate. But in the real world, you're starving, the kids are starving, thats a mushroom, poisonous of course, but maybe if we split it 30 ways among the entire tribe we'll all feel sick but each gain 10 calories...

The real problem with 99% survival rate per meal is there's about 1000 meals per year assuming about three per day, and (0.99) __1000 is essentially zero survival rate after a year. So just eating everything you 'll be dead in a year. If you screw up the identification 1 time in 10, the survival rate drops to only a third or so. If I did the math estimates right in my head, for only 10% mushroom fatality rate over 70 years you'd need four 9's reliability in mushroom identification. To relegate the mushroom death rate to tribe-size- mythological rarity would take six 9's of identification reliability. As a smart homo sapiens I bet I could do it but sorting mushrooms into piles of "yum" and "gonna kill ya" is definitely the kind of tribal role I'd give to the tribe member furthest on the right side of the bell curve...

This is assuming a "white noise" distribution of toxic and non-toxic mushrooms, and lots of spherical cows. But I think its still a sound mathematical model that "tribes of dumb people" can't live off shrooms but "tribes of smart people" have an acceptably dangerous source of calories at hand, maybe enough to triumph in the long run.

Its very much like fishing. The odds of dying ice fishing once with the boy scouts in 2010s is incredibly low. The odds of dying if you feed your entire tribe all winter long for 70 years from ice fishing is disturbingly high unless you're a really smart fisherman. Dumb people who ice fish will drown and their tribe will starve, dumb people who don't ice fish will have their tribe starve.

I find it fascinating to compare ice fishing and mushroom gathering to today's attitudes toward nuclear power or car culture or aviation or chemical plants. It seems that extremely high stakes gambling in the lifestyle of "do it right near 100% of the time or everyone in the area dies horribly" is an incredibly ancient urge for our species, its hardly industrial or post industrial, a "savage" from 50Kyrs ago would totally understand our tempting fate with nukes...

<comment><USER5> "if we split it 30 ways among the entire tribe we'll all feel sick but each gain 10 calories..."

Probably not as mushrooms are very low on calories ...

</comment></comment></comment></comment></comment><comment><USER6> I have a simpler explanation.

You live in a wide cold and deforested steppe, have weapons with a limited scope and hunt big mammals for living. Your prey lives in ever-watching herds, can see you coming at day and can hear and sniff you at night, can easily overrun you and keep a safe distance at all times, and there is not a lot of places where you can hide and ambush them. Unless you can get closer without being detected and place yourself at shooting range distance, neither you nor your family will survive.

What a serious and committed hunter will do in this situation? They will use dung to mask their scent and adopt the scent of the prey and hunt at dusk or night. Even wolves do it. Dung could also have other uses, like recovering some salts after a strenous journey running non-stop after your wounded prey, and are used in many countries today as fuel source for cooking.

The presence of DNA from a mediocre edible mushrom in the mouth of a primitive hunter is a proof of mushrom contact, but not a proof of deliberately mushrom eating or recreational uses. The mushrom season is short and you could adquire this DNA by other ways. When you literally bath yourself in whooly rhino poo three or four times each month and process 'cow' skin with your teeth to make leather, there are plenty of mushrom spores that will be inevitably transferred from your hands to your mouth.

</comment><comment><USER7> This is an interesting article on many levels. For example, I think it is interesting to see how technology continues to offer us new insights into old scientific conclusions. It was also refreshing to read a scientific article that addressed both sides of the debate with a fair amount of neutrality. To me, this seems to be the wisest attitude to have when walking the path of discovery.

A couple of other things:

1\. Is "neandertals" a misspelling of "neanderthals," or an accepted variant of the word that I'm not familiar with?

2\. "Mushroom-munching" may not be the best phrase to have in a headline. At first, I thought it was a metaphor for prehistoric fellatio. On second thought, perhaps that was intentional. I mean, I read it.

<comment> mh-cx The name of the German valley where the first specimen was found was spelled Neanderthal until early 20th century. But it's Neandertal nowadays.

<comment><USER8> That's understandable, but here they are not talking about the geographic area (in its native language, no less) but about the hominid species. English (and other languages too) typically fossilize nouns. Take Japan, we don't now call it Jahon even tough in the native language p -> h. [nevermind Japanese interchangeably use Nihon and Nippon]</comment></comment></comment>


Ask HN: Karma not adding up - <AUTHOR>

Hi all,
Not sure if this is the right forum for it, but since about last week, I've noticed that my karma points do not seem to be updating correctly, based on a couple of posts and upvotes (no downvotes that I'm aware of).  So far, I can't find any pattern in how it does or does not go up.
Is there anything in the karma system that I'm missing? <comment><USER2> Please send questions like this to email@example.com.</comment>


Show HN: ServeData – Node template for server with users, groups and permissions - <AUTHOR> https://github.com/cris691/servedata <comment><AUTHOR> If this gets to front page I'll put a demo server up</comment>


IPv6 address space layout best practices - <AUTHOR> http://networkengineering.stackexchange.com/q/119/231 <comment><USER2> We've rolled out about 12 million nodes on IPv6, over 300 customer /48 networks, and about 6,000 individual /64 subnetworks. 99% of those have been RFC 4193 Unique Local IPv6 Unicast addresses.

IPv6 is like a breath of fresh air when it comes to setting up address spaces. For the past 10 years as a network engineer, three overriding issues have existed when setting up new networks. (1) Begging ARIN for a /19 or /20 when setting up a major new network, (2) Constantly having to have a CIDR calculator running in my head when trying to figure out where the usable hosts/broadcast/network/gw live for the various /29s, /28s, /27s/ /26s, (3) Dreading having to communicate with a new partner or customer also in RFC 1918 space (because of the odds of an address conflict), and/or adding NATing so that we can do a hand off in public space.

With IPV6 - all of those issues are gone. Every subnetwork is always a /64 - CIDR is basically gone. Also, because RFC 4193 is so large (FC::/7, though, for local assignment, it's always FD::/8) - we for all practical purposes never have to worry about negotiating with partners.

Our "Addressing Strategy" is as follows:

For a new customer, Randomly generate, following the guidance of RFC 4193, a /48. Then, for all of their subnetworks, just increment by one. I.E. A customer might get FDC2:D343:107F::/48, and their first subnetwork in that range would be, FDC2:D343:107F:1::/64

For our own IPv6 space, we occasionally play stupid aggregation games, just to keep our routing tables a little more dense - aggregate on ::/56 boundaries - I.E. If we have a new data center with a bunch of subnetworks in our FD1B:D2C5:6AB3::/48 space, we might assign it to be FD1B:D2C5:6AB3:0100::/56, and then we have 255 subnetworks, FD1B:D2C5:6AB3:0100::/64 - FD1B:D2C5:6AB3:01FF::/64) that we work with.

About the only problem with IPv6, is that they make it difficult for you to get your own provider independent globally routable address space that you can advertise out via BGP. So, for instance, a company can't just (easily) get some address space and advertise it out through the internet - the powers that be want you to get a subnetwork out of your ISPs /32. As a result, we ended up just doing everything in RFC 4193, and, using a relative handful of "globally routable" IPv6 hosts for communicating on the internet from our ISPs /32 space. Our ISP gave us a globally routable /48, and we use about 12 hosts addresses from its possible 2^80 possible addresses. Talk about sparse utilization!

Eventually, as more IPv6 hosts land on the internet, and we want to communicate to them from inside our network, we'll probably just add a IPv6-to-IPv6 Network Prefix Translation (NPTv6), or, more likely, an IPv6 NAT system.

NAT has become so embedded in the Enterprise, and provider independent globally routable addresses assigned to companies so difficult to get, that, the globally routable space will ironically be used for fewer IPv6 hosts in many cases, than it was for IPv4 hosts in many cases.

I realize that this is very controversial, and contrary to what every IPv6 IETF network designer/architect/RFC writer wants to hear, but, in talking with the dozen or so colleagues that I have who are also deploying IPv6, it's seems to be the consensus. NAT has been used for so long, by so many network engineers, that non-routability internal space has become our "goto" strategy for the second layer of defense. (With stateful firewalls, of course, always, always being the first layer)

Indeed, when we tried to move a bunch of our applications to Amazon, they indicated that they were only supporting IPv6 for limited interaction on the internet, and that they weren't supporting IPv6 for their internal networks - really embedding the Proxy/NAT concept for AWS applications. Which is a shame, because we'd love to move a lot of our IPv6 applications into AWS.

<comment><USER3> You've heard it before, but for the sake of balancing your comment on NAT... Sincerly and honestly: _NAT does not solve anything that a firewall (6 lines of ip6tables rules) - or stopping that unecessary service - doesn't_. All it does is create two classes of network devices (and netizens): those that can talk directly and those who depend on a third party. There's no reason not to have a global address anymore, even if you don't expect to use it. Even something as simple as putting a firewall appliance in the middle is the wrong approach. Logic needs to be near the edge, in the host IMHO; by putting any rules in the middle (firewall, NAT, QoS), other than the basic routing, one loses the intended ability to dial direct in unanticipated scenarios tomorrow (for example, to run a new service without touching every hop between A and B because of dozens of attempts to "make it better" at that hop). IMHO NAT really is an example of our eagerness to hang ourselves, given enough rope.

<comment><USER2> Good balance - and certainly it's a common refrain from those who are architecting and writing RFCs. And, keep in mind, 100% of all corporate networks I've seen with NAT, also have (typically very expensive) firewalls with highly restrictive rules. But corporate IT stooges (which I've certainly played the roll of) will say: "Here is what NAT will do for you with IPv6"

#1 - You don't expose any internal hosts addresses to the external world, everything comes from a single external host.

#2 - No route back to the hosts inside the lan. If they can't route to you, they can't attack you. (Not really true, but it does make it more challenging to mount an attack from the Outside -> In. )

#3 - You can change ISPs without any internal renumbering required. Unlike with IPv4, getting provider-independent IPv6 space can be challenging.

IPv6-to-IPv6 Network Prefix Translation (NPTv6) might be a happy middle ground that solves #3, but still leaves you mostly exposed on #1 and #2.

<comment><USER3> I'm still vehement that #1 & #2 are wishful thinking (security through obscurity... better to drop all packets, or simply not use a public address; ULAs are fine IMHO), but perhaps something as simple as a prefix-aliasing notation would allow easier internal referencing and address #3. For example, MY_NETWORK:1. That can be done with shell/environment variable substitutions before using them, but it would be nice to be able to count on IPv6 applications to accept something like that for networks in the routing table... (might require a prefix-naming RFC, so a name can come with a router/prefix advertisement and/or the ability to store name-to-network prefix mappings in DNS SRV, or similar, allowing internal or global users to find the right host on the right network...)

That said, truly global addresses with service registries like DNS/mDNS, etc, remove the need for immutable (staticly-assigned and hard-coded) addresses entirely, albeit at the expense of registration and lookup.

</comment></comment></comment></comment><comment><USER4> <http://networkengineering.stackexchange.com/> is relatively new. I think it only went beta a couple of weeks ago. It's nice to see people already using it to share knowledge.

</comment><comment><USER5> Fascinating... it seems easy enough, basically in that address space is abundant enough to not have to be concerned with much of anything in a local space.

But it reads juuuuust slightly more complex than IPv4 does... it's just that side of difficult to comprehend. I think this is the true human factor behind the lack of adoption.

It's huge, like looking at all the stars in the sky, but bigger. Just the switch from numbers between 1-255 to hex codes and the more of them... it's that much more of a barrier to use and adoption.

Any ideas to simplify my own understanding of IPv6? I took the HE.net certification courses, which are excellent, but it's hard to make it stick. How do we make this intelligible so that everyone can be comfortable using it—and ideally, more comfortable than IPv4, so that it becomes _preferable_? That's the challenge.

<comment><USER6> I think it is just the prejudice about how "easy" things that we already know seem. But I do remember, and have seen many people, struggling to get a grasp of IPv4 subnetting, routing, security, etc. But you practice and over time it becomes second nature. If you put in half the amount of effort into IPv6 that you did when you learned IPv4 you'd probably be set.

<comment><USER7> While I am really looking forward to IPv6, I am slightly dissapointed about global addresses. Granted, globally routable adresses is the main (only) thing that is getting me exited for IPv6, but there is something nice about being able to go into a new network and only need to remember "2.10" for an IP address. (Espessial when all the IPs I care about are set to the low "0.x").</comment></comment></comment>


Ask HN: how to work faster when building a product? - <AUTHOR>

I am building a SaaS product and basically I find a lot of time going back and forth the website, the backend, javascript, and so on.
Even stuff that I thought was completely built and satisfied with ends up changing as I change other bits of the equation.
The most frustrating part is when I can't figure out the wording on a website, or playing with icons that ends up eating up a lot of time (but I gotta have it perfect)
Is this normal or are some people just able to do one thing once, and move on and never come back to it? <comment><USER2> Perfection is a trap during the early stage of a product. Get it out there, in hands of paying customers!

Perfection is the enemy of execution.

Honestly, how proud would perfect icons make you if your product didn't resonate with anyone, and you didn't get any customers within the first month? 2 months? 3 months?

Remember that you can improve week after week after week, once you've launched and you get feedback that indicates what customers want. Then you can improve the right things, which is very important.

<comment><USER3> I keep hearing this, and used to subscribe to the view too. But recently I released a site and the feedback was universal - "Your site looks amateurish and I'd never trust you with payment credentials".

So now I've "relaunched" with a basic bootstrap theme. The praise and feedback has been universal. And yet I personally think I now have a site which looks exactly like every other ..

In conclusion my recent experience tells me that users want both functionality and prettiness - and so in the future I know I'll be in the same situation and I will spend hours and hours and hours juggling where I lay my text, and what theme to choose.

</comment></comment><comment><USER4> In my opinion, this is not a problem. Tinkering with small things is tough but it is the way to go. This tells that you care not only about the big functionality but also small nitty-gritty stuff that makes big difference at the end.

One suggestion that I can give is to give undivided focus to any particular task (say icons) and not worry about time until you get it right. Mind you, you may revisit and change it again.

In case of a doubt, push it to A/B testing.

So, keep calm and carry on :)

</comment><comment><USER5> You might want to change your iteration times.

Try the following:

1\. Define a set of tasks well enough that someone else could do them without asking many questions.

2\. Then, execute a single task without changing it, even if you change your mind midway through.

A "task" is equivalent to an hour or two of work.

When it's all done, do this process again for new features/changes.

This is good for the following reasons:

1\. Separate out the thinking/analysis phase and the coding phase. This forces you to think things through before implementing them.

2\. Modifying something is usually easier once it's already done. Also, you'll likely make few or no redundant modifications.

3\. It makes you more aware of the time cost activities have, since you're splitting them up into several hour chunks instead of hundreds of unorganized several minute actions. You can better manage and prioritize 1-5 tasks rather than "whatever comes up".

This is very similar to Scrum, but for an individual developer.

<comment><AUTHOR> What happens if you get stuck on a task? Should you keep at it until its fixed or should you skip it and work on other tasks?

This is what happens: Fix bug. Something I am lacking understanding of. Ask Stackoverflow, wait for answer, question gets closed for being vague. Go to IRC, ask around, no one is answering. Rage hard. Look at bug again, very small detail I overlooked.

Whenever I get to a time sink bug, I find it completely drains me of my energy. I have a hard time moving on to the next bug because I am very bothered by leaving a loose end.

</comment></comment><comment><USER6> It's ok. Just make sure you plan your changes and stick to the plan: it's too easy to fall in a trap of uncontrolled perfectionism.

Plan features for the next 1-2 weeks and complete them. Then plan for the next 1-2 weeks etc.

Only do things that are important and should be done immediately, ignore all the rest (like important, but can wait; etc).

</comment><comment><USER7> Imo, the fact you're asking this already indicates you're spending too much time on the details (making it "perfect"). Accept that no software project is ever finished or "perfect", you're always going to have ideas on what to improve.

Tip on writing website copy: take your laptop to a different location than where you work (I find a new environment helps creativity for writing), read a few blogs on how to write website copy, and then just finish v1 of the text. Helped me a lot.

</comment><comment><USER8> I can recommend you to check [http://usersnap.com](http://usersnap.com) \- you can get a feedback from your peers on everything and you don't have to be alone in that task. SAAS is all about the community right?

</comment><comment><USER9> I have long todo list. Every morning - I looks thru the top 10 and move 3-5 items to the top. When the top list is < 2, I review the list again.

</comment><comment><USER5> Architecture. The whole point of it is to make it so you can change things in isolation in different layers.</comment>


Announcing Lower, Simpler Pricing - <AUTHOR> https://www.firebase.com/blog/2015-08-19-announcing-lower-simpler-pricing.html

<comment><USER2> I spent a little bit of time examining different options in this space a few weeks back, I found these options:

Firebase

Couchbase Mobile Sync Gateway

CouchDB

PouchDB

Amazon Cognito

Azure Mobile Data Sync

Cloudant

My main issues with Firebase (in order of importance) were:

a) Uncontrollable sync. It seems to always use a web sockets/long poll, and count how many connections you have. Which is not appropriate when data changes infrequently and you're concerned about your users battery life. Mainly, I wanted to be able to do push using GCM/etc.

b) Single unmodifiable conflict resolution strategy

c) SaaS-only

It seems very polished and easy to get started with, but since there was no upgrade path to anything else, the fact that it really wasn't a good fit for my sync needs made it seem like a bad option.

I'm not a huge fan of these systems in general since they have you connecting to a dedicated database that you plug code into (eg as a sync function), rather than exposing building blocks for you to build a sync service.

But I'm still using pouchdb on the client for the moment, and I haven't fully figured out what the backend will be, but at least I have a few options in pouchdb-server/couchbase/couchdb/cloudant.

<comment><USER3> (Full disclosure, ex-Firebase employee and I make my living building Firebase powered apps)

In response to your issues...

A) If you really wanted, you could make HTTP requests to the REST API ([https://www.firebase.com/docs/rest/api/](https://www.firebase.com/docs/rest/api/)) and that would not force you to use any long standing connection or any more battery life than other options.

B) I think this is a matter of preference. Firebase chooses simplicity over power in this case. The vast majority of developers and applications don't call for custom conflict resolution strategies. Firebase lets you focus on your app, not on these fine-grained details.

C) The SaaS-only argument is valid if you have a huge ops team who you can dedicate to running a complicated, stateful, realtime system like Firebase. However, 99% of the time, we don't have this luxury, so we pay the Firebase team to do it. I look at the SaaS-only aspect as a big plus. I know they're running Firebase in an ideal situation on ideal machines and I don't have to think farther than that. Once again, it just lets me focus on my app, not the details.

I can't disagree, if you have very low-level / complex sync needs, Firebase probably isn't a good fit for that app, but in terms of upgrade path, it doesn't have one because it is unique and exceptional. It's a little crummy that there aren't competitors you could hop to if Firebase went away, but Firebase doesn't have many competitors because they do such a good job and blow others out of the water when they pop up.

Regardless, I don't know your app, so it could very well not be a great fit, but it definitely has legions of benefits over Pouchdb/etc/etc in a huge number of situations.

<comment><USER2> If I were making straight HTTP requests I don't see what benefit I would be getting from Firebase at all.

I'm not necessarily thinking of a wildly different conflict resolution scheme, but the fact that it is fixed means that if the behaviour is not quite what I want, I either have to just deal with it, or move to another system. In particular, when there are two conflicting writes to a string field, in scenarios where data loss is not acceptable, I would prefer to tell the user about it than just have the last write win.

I haven't run a sync service before, but I'm not really clear on what makes it require a huge ops team compared to any other high scale system.

Obviously piles of people are using it and are happy with it, it just seems like a pretty narrow solution atm.

</comment></comment></comment><comment><USER4> In my opinion this makes Firebase _way_ more approachable. Previously, their limited number of connections made it very, very expensive very quickly. Storage seems like a much more logical scaling factor.

</comment><comment><USER5> I'm glad there is a simple $5 plan. This makes hacking on my small project ([http://fireform.org/](http://fireform.org/) \- plug) a much more reasonable proposition.

<comment><USER6> What is it supposed to do above Google Forms+Sheets?

<comment><USER5> 1) No Google branding 2) Email notifications 3) Use your CSS to customize the look of your website's form.

</comment></comment></comment><comment><USER6> What is the actual difference between the Free ($0) and Spark ($5/mo.) plans? I see the difference in custom domain, but it hardly matters with a backend service like Firebase, doesn't it?

<comment><USER4> Firebase can host your front-end content on its CDN, SSL supported, via their Firebase Hosting package[0]. This is the reason to use the Spark plan, so you have a custom domain for that, I believe.

[0] [https://www.firebase.com/docs/hosting/guide/custom- domain.ht...](https://www.firebase.com/docs/hosting/guide/custom-domain.html)

</comment></comment><comment><USER7> I just got this email too.

Price jumps from 5 bucks to 50. Still too pricey for me.

I did explore what they have to offer and it is fairly extensive. I'm not sure about performance though. I did not test that.

<comment><USER8> Do you have a proposed model which is sustainable for both parties? What seems both fair and reasonable to you?

<comment><USER7> I can't speak on sustainability because I can't speak to cost to support that much infrastructure.

Just seems a little low on storage and I think AWS's free tier offers more.

</comment></comment></comment><comment><USER9> Are they worried about competition from Apple's CoreData, which Apple developers get as part of their registration?

<comment><USER10> You can't use iCloud as backend for other platforms. If you like to port your iOS app for android you cannot use the same backend. It's a major restriction if you wish to extend your app in other devices.

</comment></comment><comment><USER11> What's the difference between the free plan and the $5 plan? They look exactly the same, unless I'm blind.

<comment><USER12> Paid plan has custom domain support.

</comment></comment><comment><USER13> if only firebase could scale... they have so much downtime

<comment><USER3> I know many people on the Firebase team very closely and they're definitely aware of the downtime issues and they're making it a top priority, I'm sure it will be improving very soon.

</comment></comment><comment><USER14> Summary of what's changed is available on their blog: [https://www.firebase.com/blog/2015-08-19-announcing-lower- si...](https://www.firebase.com/blog/2015-08-19-announcing-lower-simpler- pricing.html)

<comment><USER15> Thanks, we updated the link from [https://www.firebase.com/pricing.html](https://www.firebase.com/pricing.html).

</comment></comment><comment><USER16> Come on guys, this ad isn't even disguised as a wired article.</comment>


NASA's Mars Curiosity Rover Arrives at Martian Mountain - <AUTHOR> http://www.nasa.gov/press/2014/september/nasa-s-mars-curiosity-rover-arrives-at-martian-mountain/ <comment><USER2> Is there any parallel set of videos where they actually convey more than 10 bits of information? I'm not interested in listening to a fun synopsis of next chapter of "The story of Curiosity and the mountain". Is anyone? "We found an important boundary, and the rover is now next to the important boundary." That's wonderful. I was expecting to hear at least 2 words on why it was important but it never came.

These update videos are a chance to also get technical, drill into details and explain the Curiosity mission piece by piece over a long period of time, perhaps in style of minutephysics. Seems to me as a bit of a missed opportunity.

<comment><USER3> All science news releases go through JPL: [http://mars.jpl.nasa.gov/msl/news/whatsnew/](http://mars.jpl.nasa.gov/msl/news/whatsnew/)

But a science planning blog gets posted here: [http://astrogeology.usgs.gov/](http://astrogeology.usgs.gov/)

Also nytimes has a nice tracker. No science, but select raw images: [http://www.nytimes.com/interactive/science/space/mars- curios...](http://www.nytimes.com/interactive/science/space/mars-curiosity- rover-tracker.html?_r=0)

<comment><USER4> Sweet! Just wondering if there is any references to how the A.I onboard works? I have heard that the platform is semi-autonomous, with visual odometry for motion estimation, but could not find anything that describes the techniques in detail.

</comment></comment></comment><comment><USER5> I've been following the wheel-wear issue with some interest. Curious what alternate wheel designs might prove more resilient under the off-road conditions found on Mars.

I'm supposing that any sort of rubber or similar material would prove prohibitively expensive in terms of mass?

<comment><USER3> Also Emily Lakdawalla wrote up a nice article on the wheels for the Planetary Society:

[http://www.planetary.org/blogs/emily- lakdawalla/2014/0819063...](http://www.planetary.org/blogs/emily- lakdawalla/2014/08190630-curiosity-wheel-damage.html)

<comment><USER6> 0.75mm wheel skin thickness? check. Machined out of aluminum? check. Punctures and tears in the wheel? check.

Surprised it lasted this long. I understand weight was a concern, but surely for $2B, there's some exotic, more resilient alloy that could've been used? Or maybe just make those middle wheels 1mm thicker and eat the extra 3 1/3Kg.

</comment></comment></comment><comment><USER7> About time. The nominal mission was one Martian Year which ended in June. The NASA Inspector General recently criticized the Curiosity team for not meeting their main science goals which were based on climbing on Mt. Sharp. There were some interesting diversions like the alluvial fan. And sand dunes blocked a more direct traverse to Mt. Sharp. This not the first time Curiosity has been in the doghouse. They missed their initial launch data, with a 26-month delay, from falling behind on engineering of a new landing method and new power source. That put Curiosity nearly $2B over budget and almost ended the US Mars program.

Most of the instruments and the power source are expected to last ten years. The deteriorating wheels are a concern.

</comment><comment><USER8> Have the rovers ever had access to the kinds of strata shown on the side of the hill/mountain in the video? If not, hopefully there will be some very interesting finds in there.

</comment><comment><USER9> What type of mountain is this? When I think of mountains out here in the North Eastern US, most are not something a wheeled vehicle might easily summit.

<comment><USER10> I'd like a rover sent to snap Olympus Mons.</comment></comment>


Show HN: Pennywise – Open anything in a floating window - <AUTHOR> https://github.com/kamranahmedse/pennywise <comment><USER2> im not sure Node was the best choice here.

the source zip is 562 KB, and the windows release zip is 74 MB?

seems like Go, Rust, C++, etc would be better fit</comment>


California DMV Loophole Allowed Jobs to Drive Sans-Plates - <AUTHOR> http://www.macobserver.com/tmo/article/california_dmv_loophole_allowed_jobs_to_drive_sans-plates/ <comment><USER2> So basically, Steve got a new Mercedes more often than I get new shoes. Now that's what I expect out of a multibillionaire. Good to see he at least kept himself in new-car smell on a regular basis, and certainly kept a local dealer quite happy.

<comment><USER3> Oh, chill out. The article says the car was leased. He probably had to pay some kind of premium to keep his leases down to six months at a time, but it's not like he was buying a new $120k car twice a year.

<comment><USER2> I'm not upset about it or concerned with the financial arrangements, I'm just kind of amazed by the concept.

On top of the self-expression of never having license plates, he got one of the finest cars in the world delivered to his driveway, brand new, twice a year. I'm guessing not only did he never have car trouble, he never needed to take it in for maintenance either.

That's hard to beat as far as perks of being a really rich guy go. Not my personal taste, but I can't deny its appeal.

<comment><USER4> Don't overly idolize the concept. The SL55 is, relatively-speaking, a fairly modest car (brand new, the SL55 was a bit over $100k vs. the SL65, which looked the same but had a bigger motor and was almost _double_ the price). Among car nerds, Jobs' choice of the 55 model showed a lot of restraint.

It's a nice car, but far from one of the finest cars in the world.

And lastly, I'd bet that he didn't actually get a brand new one every six months -- leasing companies generally don't do that without requiring a massive chunk of money up front (i.e. $20k each time), and given the restraint he showed with the car selection, I doubt he'd be so, well, inefficient.

It's MUCH more likely, as another commenter suggested, that the actual loophole they used was for him to "sell" the car back to the leasing company and immediately re-lease it every six months.

<comment><USER5> >>It's a nice car, but far from one of the finest cars in the world.

I'm not trolling and this is a sincere question. Which car would you consider among the finest in the world?

Edit: Thanks for the replies.

<comment><USER6> There are certainly cars that go above this one, but once you cross the $100k threshold, you're basically in the "I don't care what it costs" territory.

(Personal dream cars that cost more than this):

Ascari A10

Koenigsegg CCX

Ariel Atom V8

<comment><USER7> There's a whole class of cars in the 100-250K class (more expensive BMW/Mercedes/Porsche) which are a notch below the 350-450K range (Bentley/Rolls Royce)

That first range is generally for the rich professionals who do care, to some extent, about price. I would say the "I don't care what it costs" territory starts at around 400K

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I guess he'd have a good answer for the "Tell us about a time you hacked a (non-computer) system to your advantage" question on the YC application.

<comment><USER9> Before that, he and Woz used the Blue box[1] the latter had built to make free calls.

[1]: <http://en.wikipedia.org/wiki/Blue_box>

<comment><USER10> I assure you, the telephone network back then was still a computer system.

</comment></comment></comment><comment><USER11> Except there's no loophole. Registering the vehicle at purchase (or at beginning of lease) is required. Cal DMV will then send you plates. At which time your paper stickers expire.

Besides, his vehicle wasn't displaying the temporary plates either.

Look, MacObserver and all the rest of you fanboys: Steve Jobs just decided to disobey the law. There's no loophole. There's just a guy who thought the lines of his car were spoiled by license plates and who decided that, fuck it, he's a billionaire and the laws didn't apply to him.

Jobs was an asshole and a scofflaw. He'll be remembered for doing great things with Apple. Quit trying to whitewash the rest of his life. By the time you people get done with him, his Wikipedia page will talk about how he spent four hours every day feeding puppies and orphans. Sheesh. Knock it off already.

<comment><USER12> Disobeying vehicle registration laws does not equal being an asshole. I doubt anyone actually makes it through a day without breaking at least one law. Quit being an asshole yourself and at least provide a legitimate reason why he was an asshole.

<comment><USER13> Parking in disabled spaces[1][2]. :)

      [1] http://folklore.org/StoryView.py?project=Macintosh&story=Handicapped.txt
      [2] http://www.cultofmac.com/2613/steve-jobs-still-parking-in-handicapped-spaces-the-pictures/

</comment></comment></comment><comment><USER14> Can anyone explain the advantage to driving without plates? It seems that being the Mercedes AMG would be just as easy to identify as the Mercedes with the APPLE1 plate.

<comment><USER15> Anonymity. Silver SL's, even AMGs, aren't exactly uncommon in the area.

Plus, you don't have to worry about red light cameras.

<comment><USER9> Anonymity? How many plate-less Mercedes are there in CA?

<comment><USER16> If I'd had a silver SL55 I would have de-plated it, in the hope that Steve Jobs would have got blamed for everything I did.

</comment></comment></comment></comment><comment><USER15> Approaching 4 years of driving with no plates on the same car here in California. Just leave the paper dealer plate(the one with the dealership name/logo on it) on the car. Cops wont ever pull you over for lack of plates, even if youre missing the front plate as well, as I am.

<comment><USER17> You must not live in SF then. After four fix-it tickets for no front plate, I caved.

<comment><USER18> in chicago the meter maids are strict about no front license plate, so when i moved here i quickly got a ticket for it (which was $50, i think). i had gone 6 years with no front plate and didn't want to put one on.

i had a personalized license plate on the back that i no longer cared about and i discovered that when i told the dmv that i lost the front plate (which was true, since the car had no front plate for 6 years outside of chicago) they gave me a temporary plate while the replacements were being made, which cost me all of about $10.

the temporary plate expired in 6 months, so for 6 months i was able to avoid having a front plate. if i had kept the car for longer, i would have just told them the plates never came in the mail or something, paid the small replacement fee again, and gotten another 6 month temporary plate.

</comment></comment></comment><comment><USER19> I don't really consider this a DMV loophole. It's just constantly driving a new car. It doesn't take a rocket scientist to "uncover" this loophole, it just takes a wealthy individual to be able to afford the the lease premium to do this if they are motivated enough.

</comment><comment><USER20> I'm told by a family friend who was Jobs' neighbor that his license plates were stolen regularly by his fans. This was probably how he chose to solve that problem.

<comment><USER21> For what it's worth, I lived near Jobs' growing up, and not once heard of his plates (or anyone in that neighborhood's) plates getting stolen.

</comment></comment><comment><USER22> His decision to go with the lettering on the car ("SL 55 AMG") seems much stranger to me. At least if you buy the (much cheaper) C-Class you can actually decide whether you want lettering or not. (I don't have a car and don't want one but my dad recently asked me whether he should go with or without the lettering. I told him to go without, that seems much classier and better looking to me.)

<comment><USER4> That's actually not an option from Mercedes. All MBs come with the lettering -- however the lettering is attached basically with a dab of (pretty strong) glue, and to remove the badges requires nothing more than a concentrated heat source, a pair of pliers, and some solvent to clean the residue.

It's more of a "mod" (albeit a simple one) than an option - and most people actually consider _removing_ the lettering to be quite tacky. Why? Because the people who often remove the badges are the ones with the less-expensive model cars (i.e. the SL550 vs. the SL55) and who want others to think they have the more expensive version :)

<comment><USER22> My parents bought the car from an official German MB dealer and it was an option.

</comment></comment></comment><comment><USER23> It states:

 _The permit the dealer provides for display on the passenger side of the front window is valid until the plates and stickers are received by the customer, or for six months from the sale date, whichever comes first._

Assuming he received them a month after purchase, since another clause states that one would no more than 45 days after purchase, how is that a loophole?

<comment> X-Istence He leased his cars ... didn't own them.

</comment></comment><comment><USER24> I wonder if this also applies to used cars; if you don't mind driving a bit of a clunker, you could do this affordably. A twenty year old car does not depreciate in value significantly over six months.

edit: hm, looks like it only applies to cars sold by a dealer.

</comment><comment><USER25> I'm curious to see what options he chose for the interior such as the stitching and leather.

</comment><comment><USER26> that's the most moronic thing anyone can do.

pay extra to the dealer. pay registration of a new car every 6mo. hassle of dealing with it.

i imagine how many iphone prototypes the dealer found in the glovebox of hundreds of returned sl55 over that time.

<comment><USER27> 4 years / 6 months = 8. 8 cars, not hundreds.

<comment><USER26> you paid the 30% 'out of dealer' devalorization, of a SL55 AMG, plus leasing profits which shouldn't have been easy for this kind of arrangement, times 9, to have 4 years of car without plates.

do that math for that, smart guy, and i dare you to disagree it was moronic.

</comment></comment></comment><comment><USER28> Now explain why he liked to use handicap spots and find the DMV loophole for that.

Or how he seeded Apple by selling something that would have landed him in federal prison today.

<comment><USER29> Your first claim is false.

<comment><USER30> [http://www.switched.com/2008/08/26/steve-jobs-is-alive- and-p...](http://www.switched.com/2008/08/26/steve-jobs-is-alive-and-parking- in-handicap-spots/) [2008]

Note that he might have had or qualified for a handicapped sticker, given how sick the cancer made him, though no one appears to know for sure. And I could _definitely_ see him not wanting to put the sticker on his car if he had one.

It appears to be the same car, though, right down to the missing license plate.

</comment></comment></comment><comment><AUTHOR> I think it's beautiful. This let him buck authority _and_ beat the system at the same time. There was a monetary cost involved (and it could be argued that the system beat him out of fresh registration fees every 6 months), but... still. You gotta admire the gusto. ;)</comment>


A Collection of Free Text Analysis Services - <AUTHOR> https://api.blockspring.com/blocks?sort=&filter=text-analysis

<comment><USER2> How about including this context-controllable content summarizer: [http://genopharmix.com/TuataraSum](http://genopharmix.com/TuataraSum)

<comment><AUTHOR> You should add it! [https://api.blockspring.com/blocks/new](https://api.blockspring.com/blocks/new) :).</comment></comment>


Drunk On Licensing Fees And Patents, Microsoft Has Become A Joke - <AUTHOR> http://techcrunch.com/2011/03/21/this-title-is-patented-pay-me/ <comment><USER2> _"How long until Microsoft is making more money on patent licensing than from their mobile unit? Serious question. Maybe they already are."_

I'd imagine there's an _excellent_ chance that they already are. Sounds much cheaper to keep a stable of lawyers around than hundreds of engineers, testers, support staff, and marketing folk.

If you think the margins on selling software are high...

<comment><USER3> The latest trend in business: make money by creating no value whatsoever!

Actually, in my experience this is the MBA ideal. From the pure bean-counting perspective, the ideal business would be something that just made free money. No staff, no overhead, etc.

</comment></comment><comment><USER4> Is it an industry requirement that in order to write about patents you have to not know anything about them? In particular, the author seems to not understand that a plaintiff claiming that their patent is being used by defendant to accomplish X does not mean plaintiff is claiming that their patent covers all possible ways to do X.

</comment><comment><USER5> It's not all that different from when MS used to license OSs to vendors by the number of machines sold, _total_ \--- not the number that had windows on them.

Parasites.

<comment><USER6> Like ESPN licenses it's channels (and even ESPN3) based on the number of subscribers, not the people who actually tune into them?

<comment><USER7> If you're subscribed to a package that includes ESPN*, then ESPN gets its share of that subscription revenue. If you're not, they don't. The analog for MSFT's licensing practices would have ESPN getting a cut for every subscriber, whether or not their package included ESPN.

<comment><USER6> ESPN gets a cut for every Comcast internet subscriber, that's why I get to enjoy ESPN3 (their streaming service). They also tend to do things like mandate that ESPN be available in the lowest level cable packages. Have you ever had to pay extra to get ESPN? If you buy more than the local channels, ESPN comes along.

It's obviously not exactly analogous, but volume licensing based on the number of consumers/seats/etc is pretty standard. We grant people a monopoly over their IP and it turns out they want to extract as much value as they can from it.

</comment></comment></comment></comment><comment><USER8> Before we derail too hard on this article, I would like to take a moment to point out that there's an article ranked higher about how Apple's suing Amazon over the term "App Store"... not like they've sued Microsoft over the term, too. (Also on HN somewhere.)

So, it's not just MS who sues -- but lest we forget, TC needs to be provocative and incite us to be persnickity. That's some high-quality bloggin'.

</comment><comment><USER9> Siegler is surprised that MS is doing something greedy and underhanded? Is he even aware of MS's history from not even 10 years ago?</comment>


Fragment: Collaborative Spectral Synthesizer - <AUTHOR> https://www.fsynth.com <comment><AUTHOR> Fragment was updated today with a new web audio synthesis engine which allow near perfect audio output on Chrome and related browsers, there is also much improvements for Firefox, i am still working on all the performances issues related to the web audio part of the application so there is many more things to come!

There is also a live logarithmic scale spectrum of the output :) and many other fixes.</comment>


Death to Filesystems - <AUTHOR> http://shoptalkapp.com/blog/2010/1/18/death-to-filesystems

<comment><USER2> This is like saying that we should get rid of TCP because all we use is HTTP. Which, if it even made sense, would be a pretty bad idea.

What exactly is this guy arguing for? How is the OS supposed to "make higher- level APIs like these"? It seems like he hasn't completely thought through his suggestion: he's saying that we should move the filesystem into the OS and then hide it. Ok that's probably fine if you're not doing anything serious and all you need are ints and dicts. But what about a database? The only way the OS can provide a database abstraction is by taking over database functionality from applications.

And I'm pretty sure that exactly _not_ what we want, and why the original designers decided to go with flat byte streams rather than structured data on disk. Yes, maybe you don't work at the level of abstraction of files and bit streams. But someone has to! The author is suggesting making that impossible except inside the OS...?

I think instead of "Death to Filesystems", the author should have made the claim that we should produce and standardize an abstraction level above the FS, and then everyone should start using it (which is a valid and very justifiable suggestion). As is, this post has come off as unreasoned.

</comment><comment><USER3> Sounds like he wants to just make the filesystem less transparent and handled solely by the application that uses it.

It's nice, and user friendly, until you want to switch. One of the reasons the Mac vs. PC debate is almost moot is because of how easy it is to move from one to another. A JPEG is a JPEG, no matter where it is. A folder of JPEG files can move back and forth no problem. But moving from iPhoto to Picasa on a PC? Not so easy, esp since you may need to write a specific routine to handle each programs individual "filesystem".

</comment><comment><USER4> I think that the current set of filesystem ops is a nice base. The "everything is a sequence of bytes" actually works very well given the access methods on a low level. However I think there are two separate things that need some serious addressing.

First is lack of metadata intrinsic to the system. A lot of filesystems have such capability, but there are no standard APIs to access it. I think that if a standards body (cough POSIX cough) were to distill out a minimum set of searchable metadata functionality, a lot of fun could arise.

The other part is the file metaphor itself. This leads to a lot of focus on moving, and putting, and copying. There is a largely under-utilized bit -- linking. We tend to associate filesystem trees with their paper counterparts, hence the above focus. However, with ln, you can create multiple hierarchies for the same set of files, organizing them different ways. Similarly this doesn't allow for easy reasoning about things like unionfs.

All that being said, I don't thing this calls for a removal of the stream of bytes notion of files, in the end, such a thing pretty necessary. A good api/file format on top of the stream of bytes solves the problem just as well.

<comment><USER5> We should also add transactions to file systems. Reiser4 also had some interesting ideas, like having aggregators, so that you could interact with e.g. /ets/passwd as one single file, or as a directory, where each record is one file. In a transparent manner.

</comment></comment><comment><USER6> Ignores the obvious benefit of the classical filesystem, which is that all data inherits an _enormous_ amount of generic functionality from it: organization, interop, sharing, backup, versioning, etc.

File systems don't need to die, they need to grow up and provide the things that apps always have to implement over top of them:

\- user-centric interface that shows data in a way that makes sense to them: documents, apps, messages, contacts, etc.

\- non-hiearchal structure, views based on search, filter, sort

\- database-like performance and semantics e.g. indexes, transactions

\- structured data that is trivial to load/save from any programming language

I believe that all this can be had while preserving the benefits of flat files, but it's an enormously ambitious undertaking and the only sort-of- attempt that I'm aware of (WinFS) never even shipped, let alone caught on.

<comment><USER7> The original Palm Pilot had no file system. There were databases, which you could open and read/write records to/from. I feel it worked pretty well, but soon newer devices came out with so much more ram that it devolved into unusably long lists of databases.

Current filesystems and their hierarchical folder structures give an easy-to- understand layer of abstraction without a whole lot of complications.

For improvements on the hierarchical part, the expansive list of filesystems using FUSE ([http://sourceforge.net/apps/mediawiki/fuse/index.php?title=F...](http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FileSystems)) has some interesting filesystems.

Maybe the author can find some likable ideas there?

<comment><USER6> The hierarchical filesystem was invented back when UI and API were the same thing and it hasn't moved past that.

You wouldn't tolerate a UI that was full of dangerous "system buttons" labeled with user-hostile jargon. You wouldn't use a user-entered mutable title field as an indexed unique key in a data schema.

FUSE is great but it abstracts the back end, not the interface. That's a seperate issue.

Platforms like J2ME with object persistence solve half the problem. Fast access to structured data is a breeze, but the user has no control.

All data is meaningful to the user at some level, even if it's as shallow as "Settings for the Blah app" or "The entire Blah app". If an object persistence platform forced all data to be wrapped in a user-meaningful container, which the user could manipulate atomically but not look inside, that would give you the best of both worlds. It would probably also encourage more modular and interoperable data design.

</comment></comment></comment><comment><USER8> There is a lot of history to this sort of discussion. Windows 95 was supposed to have an "object file store" as was NeXTStep v4.0 ... I think the basic idea was you would have what we now call "tags" for each document you worked on; everything would go into a datastore similar to what we now call "NoSQL". A "soup" where you just pull out the document(s) you care about.

Earlier discussions on this subject usually got into ideas like "pointer swizzling", virtual memory management, mmap'ing such files, etc. as the way to actually implement such a document store was considered.

<comment><USER9> Newton had soups:

<http://en.wikipedia.org/wiki/Soup_(Apple_Newton)>

<http://www.dadhacker.com/blog/?p=948>

</comment></comment><comment><USER10> _You interact with your music via iTunes; iPhoto manages your photos. They can't trust third party apps to do the same, however, so they have the catch- all Documents directory. In fact, they can't even trust themselves. Apparently the iWork team doesn't talk to the iLife team much; iWork still uses the old school model: browse the filesystem to open a file and pick a folder and a name to save a file_

when you add music to itunes, you keep it around for a long time and it doesn't really move out of itunes. when you add pictures to iphoto, you import them from your camera and they stick around forever.

when you work with word documents and spreadsheets, they don't stick around forever. they're stored on a network drive at work, or a usb drive, or opened once from an email attachment, and are gone as soon as they came.

surely some "favorites" or "bookmarks" can be made to reference documents used commonly (which these applications and file open dialogs already support), but i'm sure the usage patterns of these "work" applications dictate keeping the filesystem hierarchy. i'd rather apple stick with what is appropriate rather than change it just to unify everything.

</comment><comment><USER9> Counter-point

[http://diveintomark.org/archives/2006/06/02/when-the- bough-b...](http://diveintomark.org/archives/2006/06/02/when-the-bough-breaks)

<comment><USER11> Counter to a different point entirely. You can stop making users deal with hierarchy without being closed.

</comment></comment><comment><USER12> Another one of those disorganized people wishing the world can become disorganized as well so they can live in it.

Face it, hierarchical file systems have been around for decades, and if this proves anything, it proves that hierarchical file systems are successful and are the way to go. If there is anything we need to change in file systems then it's things under the hood, i.e. speed it up, prevent fragmentation, etc.

</comment><comment><USER13> The problem is that adding structure to the default data means specialized APIs to access them. This is why a generic, object oriented data store would be very complex to maintain.

While fundamentally necessary, files are not the answer to everything. There are designs such as file attributes to cater for file metadata. I suggest reading on ReiserFS ideas.

Filesystems have to be there though. They are complex and have done a good job at hiding the complexity such that people like the original poster may even start to think they're unnecessary.

</comment><comment><USER14> The author is right that the filesystem is not always the best solution.

There is a reason, after all, that *nix has shipped some dbm variant basically forever. Or that SQLite is pretty popular nowadays.

</comment><comment><USER15> the article he links to on "horizontal organization": [http://www.structuredprocrastination.com/light/organization....](http://www.structuredprocrastination.com/light/organization.php)

this is absurd. "horizontal" should be replaced with "no".</comment>