Drop Table "Companies";-- LTD - <AUTHOR> https://beta.companieshouse.gov.uk/company/10542519 <comment><USER2> 2018: [https://news.ycombinator.com/item?id=17003588](https://news.ycombinator.com/item?id=17003588)

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

</comment><comment><USER3> Previous submission:

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

</comment><comment><USER4> :-D

Does "little Bob tables" still affects any site? Isn't this a problem already solved?

<comment><USER5> SQL injection is a problem with well-known solutions, but it still relies on _everyone_ knowing not to do it and not doing it quickly "just to get it working" and accidently leaving it in.

</comment></comment><comment><USER6> missing an '

I assume this is a fake entry to dupe simple scrapers

<comment><USER5> Deliberately so: the company owner didn't want to ACTUALLY drop somone's tables, because that'd be rude (and possibly illegal).

</comment></comment><comment><USER7> Somebody had to try it sooner or later XD</comment>


Moore's Law is dead, long live Moore's Law - <AUTHOR> http://www.extremetech.com/extreme/203490-moores-law-is-dead-long-live-moores-law <comment><USER2> I don't think any of the engineers of these chip companies meant that "progress will end" when they said "Moore's Law will soon be at the end". I think they were specifically referring to the fact that you won't be able to shrink transistors anymore after a certain size (close enough to the silicon atom level). Therefore you won't be able to put _twice as many transistors on the same die size_ anymore (which is what Moore's Law was originally referring to).

But of course computing progress won't end. That was silly to believe in the first place. There are many alternatives already to silicon transistors, but just like with solar panels, before they become useful and practical for the mass market you need to invest many billions in them to make cheap enough solar panels happen. When the silicon transistor and the current way of building chips is dead and buried, chip companies will put their billions into something else.

It does bother me slightly that this "computing progress" will continue to be called Moore's Law though. Why not the Law of Accelerated Returns? Might be a bit longer, but it also more generic and can encompass more than one progress- related idea.</comment>


I Won't Hire People Who Use Poor Grammar. Here's Why - <AUTHOR> https://hbr.org/2012/07/i-wont-hire-people-who-use-poo <comment><USER2> CEO of content generator is a stickler for grammar, not a huge surprise.

That said, I used feel the same way. I excelled at writing when I was a kid and was always super judgmental of those that made grammatical errors, even online. I'm not sure if it was getting older or what, but I started recognizing that I'd make the very same grammatical mistakes that I'd judge others about from time to time.

I don't think all grammatical mistakes are created equal, and the context and audience of the content in question really matters. Poor grammar in marketing material that world will see is really bad. Making a grammatical error while trying to urgently respond to an issue in an internal slack channel is not a big deal. Context really matters.

</comment><comment><USER3> I have hired around 300 people for my company (currently employ 180 full time). I have found spelling and grammar and the ability to clearly express your ideas in writing to be probably the biggest indicator of intelligence. People who are not good writers generally turn out to be not good employees either.

I agree with the article that you need to make an exception for people with English as a second language for spelling and grammar... but you should not make that exception for the clear expression of ideas.

</comment><comment><USER4> May all his applicants use Grammarly and get the hirees he needs.</comment>


Erik Naggum's Perl Rant - <AUTHOR> http://www.schnada.de/grapt/eriknaggum-perlrant.html <comment><USER2> My memories of the 90s were that Perl programmers were helpful and got things done, whereas if you asked a Lisp user anything they would tell you 1. you were wrong 2. everyone else is also wrong 3. you need to study another five years before doing anything, or sometimes 4. you should kill yourself.

Hopefully now that we live in the world of the future we can use him as an example of how not to write mailing list posts.

(There were one or two angry Europeans on the ffmpeg list who got things done, but the behavior and getting things done were both seemingly caused by having lots of free time since they were unemployable…)

</comment><comment><USER3> On the one hand, this rant is 14 years old now, and discusses a version of Perl that is vastly different from what exists today. On the other hand, Perl 14 years ago did have serious problems, as did its competition, and the rant makes some decent points.

For what it's worth, I can do the exercises from SICP ( [https://mitpress.mit.edu/sicp/](https://mitpress.mit.edu/sicp/) ) without much difficulty in modern Perl.

<comment> logan-campbell Brilliant! Can you please share the code? I'd love to see it.

<comment><USER3> I haven't done them all, although it might be fun to do so. A big part of the book focuses on closures and passing functions to functions, which are both supported in Perl.

For the time being, Higher Order Perl might satisfy you ( [http://hop.perl.plover.com/book/](http://hop.perl.plover.com/book/) ). It's only 9 years old now, so it's relatively modern.

</comment></comment></comment><comment><USER4> A good rant should have specific examples for its points. Or maybe even one example for at least one point.

This is not a good rant. It's just a bunch of disparaging assertions.

</comment><comment><USER5> Wow. He can totally rant about how evil Perl is and how good Lisp is (without any data, as cjensen noted), but he can't manage to capitalize the start of his sentences. I'm supposed to take his opinion on which language is good?

<comment> jack-r-abbit > _he can 't manage to capitalize the start of his sentences_

Having no clue who this cat is (well... was) I had to look him up to figure out if I cared about his 14 year old rant against Perl. One thing about him that stuck with me after reading was that he did that on purpose because it was easier to type. But that doesn't really make it better.</comment></comment>


GTA4 Google Map With Street View - <AUTHOR> http://www.gta4.net/map/

<comment><USER2> If only it was done using iCEnhancer <http://i.imgur.com/adKTzcX.jpg>

<comment><USER3> I just wish those kind of mods worked more "nicely" with multiplayer... Although I still think with all the GTA4 graphics mods there are, I still think it should quality for one of the current most realistic looking games (definitely not with the default settings, however).

However... Regarding the OP, a Google Maps of Liberty City is really awesome though. Imagine if someone hacked the cellphone in the game to run off an Android emulator rendered to a screen overlay, and link it with the Google Navigator app (that's a significant modification to the engine though so I don't know if that would be possible, and _especially_ not on multiplayer LOL).

<comment><USER4> Why stop there? Get your modded GTA4 running through WINE on an Android phone, and then you'll have a map inside a phone inside a map inside a phone!

<comment><USER5> Turtles all the way down... ;-)

</comment></comment></comment></comment><comment><USER6> When GTAV comes out they should open source the code for 4! The amount of mods and work people have put into the game is insane. The LCPDFR mod alone could have been sold as a add on pack!

<comment><USER7> I'd say V will still use a modified version of the RAGE engine (GTA4, RDR, Max Payne 3), so it won't (ever?) be released.

</comment></comment><comment><USER8> It's feasible to store the visual input to the player which could be used as a model to base recreate the actual 3d world. The raw visual from many players could be used to simulate a populous with head mounted cameras. It's a potentially large data-set with a known value to test against.

</comment><comment><USER9> Hasn't this site, with street view, been around awhile. It has been awhile since I've last played GTA4, but I remember using these street map views a year or two ago.

<comment><USER10> It has been. It recently popped back up on Reddit.

</comment></comment><comment><USER11> Is there any API for this? Especially for the street view?

<comment><USER3> Right after I read your comment, I realized exactly how useful that might be. From simply helping a friend stuck a particular point to doing entire game walkthroughs/handbooks, his would be a pretty sweet addition to either experience.

<comment><USER12> Like have a walkthrough that's setup like google maps directions?

That would be very cool!

</comment></comment></comment><comment><USER13> The geek side of me is really impressed. The gamer side of me is feeling bad because this was the first GTA game which I could no longer play as my budget machines couldn't keep up with the increasing demand from GPUs in this series.Not that I am complaining.. I was never a serious enough gamer to spend money on expensive GPUs.

I would have loved a map like this of GTA San Andreas.

</comment><comment><USER14> Does anyone have any insight as to how this was created? I've never seen anyone load non-Google data into Street View, that's very impressive.

<comment><USER15> Google have documentation on creating custom StreetView panoramas: [https://developers.google.com/maps/documentation/javascript/...](https://developers.google.com/maps/documentation/javascript/streetview#CustomStreetView)

<comment><USER16> Very cool. And since it's all a 3D model it's a lot easier for them to generate the panoramic files than taking actual photos.

</comment></comment></comment><comment><USER17> Please god tell me this wasn't done manually...

<comment><USER18> According to a thread on the matter,[0] it appears it was done by a script. However, it was not done in a recreated world, but in game.

Which means, they created a script that would walk around the world to specific set coordinates, take screenshots in all directions. Then when done, stitch the screenshots together to form the panorama pictures. Accordingly, this took 140 hours. I am assuming a lack of processing power was influenced by it.

Also, the thread reveals it was done in May 2011.

[0] <http://www.gtaforums.com/index.php?showtopic=476068>

<comment><USER19> So they basically recreated the Google Maps car with a script.

<comment><USER18> Given the screenshots, I don't think the player is actually in a car at the moment, but rather on foot. But in a sense, yes.

</comment></comment></comment></comment><comment><USER20> Wow, just wow. This is impressive.

</comment><comment><USER21> So I have seen these done multiple times for different MMOs, so what seems to be so special about this one from GTA4? I have played GTA4 and I enjoyed it, just trying to get a gauge about why this seems to be so amazing to some? (I admit, certainly could legitimately be just something I am missing, is there something about the game that makes this complicated?).

<comment><USER22> What other games do this? I didn't know there are others that have interactive maps.

<comment><USER23> DayZ - <http://dayzdb.com/map> <http://dayzmap.com/>

<comment><USER24> Doesn't have street view. I thought that was the point of the submission</comment></comment></comment></comment>


How to do arithmetical calculations using only the human brain - <AUTHOR> http://mathema-tricks.blogspot.com/2011/12/extracting-cube-roots.html

<comment><AUTHOR> <http://mathema-tricks.blogspot.com/></comment>


Do plants favor their kin? - <AUTHOR> http://science.sciencemag.org/content/363/6422/15 <comment><AUTHOR> Similar coverage (the original one may be behind a paywall): [https://www.wired.com/2009/10/plant- siblings/](https://www.wired.com/2009/10/plant-siblings/)</comment>


Speech-disrupting brain disease reflects patients' native tongue - <AUTHOR> https://www.ucsf.edu/news/2020/01/416406/speech-disrupting-brain-disease-reflects-patients-native-tongue <comment><USER2> Fascinating, and real work. From TEFL contexts, I am told by my partner the distinct linguistic problems different language groups have with english sounds are notorious and very very culture/language specific: Spanish speakers make different pronounciation errors to Chinese and vice-versa, which I think goes to the same place.

But against that, the commonality of the Chomsky grammer model is strong. Doesn't matter what language you speak from childhood, what you develop appears to be part of a larger (universal) comprehension model. So having brain effects differ by language group is .. interesting.

Not to be confused with the headline-grabber _" she woke up speaking french"_ which is a crap pop-sci take on brain issues affecting speech centres, but is totally NOT becoming randomly fluent in french, and no french speaker thinks is french, it just sounds "frenchy" to the anglo-speakers hearing them (or Russian, or whatever: the point is the headline is always mostly the same: she "speaks" some other language)

<comment><USER3> > the distinct linguistic problems different language groups have with english > sounds are notorious and very very culture/language specific

Absolutely, and not just sounds, but also grammar.

Any non-native speaker who knows a lot of non-native speakers with a similar background and likes paying attention to language will be familiar with specific errors that those speakers tend to make. If we learn the other people's native language, we can often even recognize features of their language that contribute to those errors.

I wonder if there's a standardized database that collects these and explains their origins (which seems like something that would be useful for ESL teachers).

> Doesn't matter what language you speak from childhood, what you develop > appears to be part of a larger (universal) comprehension model.

Even if we suppose that this is exactly right, it's not necessarily particularly inconsistent with this research. If you damage similar parts of the language apparatus, you could expect the damage to show up differently at the surface level as its consequences propagate to the surface.

<comment><USER2> Say your functional brain damage makes the ESSS sound difficult for you. In some languages it would be a huge barrier. In others, it might not be. But in a tonal language like Vietnamese, if you lost your musicality, I wonder if you'd suffer different functional loss in your tonal mis-speaks?

I think I get your point, they aren't inconsistent, but it would be odd if different language groups suffered statistically more problems from brain damage than others. I guess the role of language in survival comes to the fore here, we're all well north of its functional need to say me hungrey you pretty but you would think a language with less error survival for brain damage would have not developed as strongly as one with more inherent survivability (assuming language emerged long enough ago it has genetic roots still)

My spanish speaking friend here, who is super-fluent in english continues to call the chocolate-egg holiday of christians "Easters" because its pluralized in Uruguayan-Spanish. My Chinese friends do many future/past tense mistakes because (I am told) Chinese is essentially time-free and you apply modifier words to a sentence in the present tense... Its a wonderful world out there in language folks.</comment></comment></comment>


API Company Mistakes - Serialization Formats - <AUTHOR> http://www.rdegges.com/api-company-mistakes-part-1-serialization-formats/ <comment><USER2> When developers ask for a serialization format other than what you're providing, it's generally because they're using a particular language that has a parser they like (or is the only parser they're aware of) for that particular serialization format. Moreover, the language they're using might be dictated by their employer and not by personal choice. A combination of those reasons is why SOAP and XML have lived on for so long.

What you should derive from this, however, is _not_ that you need to provide better support for that particular serialization format; rather, if you want to make this particular set of developers happier, you need to provide better support for that _language_ they're using. In general, this means building SDKs for your API in whatever language your developers prefer.

When given the choice between building an integration with an XML API from scratch, building an integration with JSON API from scratch, and building an integration with an SDK that does most of the work for you, developers will generally pick the last option, regardless of how the data is being serialized underneath.

</comment><comment><USER3> > After thinking this through, however, I realized that one of the largest > mistakes an API company can make is to remove previously advertised > functionality (why would developers trust you to provide data to them if > you're so quick to remove functionality?).

It seems to me that when providing a new feature in your API, you should have a latency period at the beginning where it is not guaranteed to continue to exist. Sort of the dual to the deprecation period at the end-of-life of a feature (would this make it an "imprecation period"?)

After that period passes, that's a signal to your API consumers that the feature will _definitely_ be sticking around and receive long-term support. But until then, it could be removed without warning at any time; all code that relies on it should have alternate branches to handle the case where the feature endpoints pop out of existence.

Pre-1.0, all features are implicitly imprecatory, of course.

</comment><comment><USER4> What kind of language and library makes creating an XML document is difficult? I know it's fashionable to hate XML, but seriously, it's a perfectly fine format, especially for serializing simple documents. The closing tags add some overhead; big deal.

I'm not even sure why much of a format was needed at all for this scenario. According to the docs[1], cURL will get a plaintext string, which has to be sufficient for nearly every implementation needing CNAM data. I'm quite sure I created a similar CNAM API in 2006: HTTP GET, return 200 OK and a string, or an HTTP error. Other major vendors' APIs are not difficult to work with, either (although contracts, VPNs, etc. can be annoying).

One reason there are more complicated APIs is for performance. While HTTP is simple, pipelining leaves a lot to be desired, and there is a benefit to being able to just use UDP.

As far as the data returned: I'm not even sure what an application supposed to do with a relative URI for a number after querying for that number? Or the price, which is apparently fixed per account? I cannot fathom why something as complicated as YAML would be needed to deal with such a simple situation: I'd wager customers asking for that are trying to be trendy or something, especially as JSON is a subset of YAML.

Not to be too negative -- OpenCNAM looks like the kind of thing telephony needs: easy, online signup, straightforward pricing.

1: <https://www.opencnam.com/docs/v2/quickstart>

<comment><USER5> XML is a mediocre format ( _the problem it solves is not hard, and it does not solve the problem well_ ), but more importantly in this case, it's a format for serializing _documents_ , and OP was trying to serialize objects. Obviously, we needs to add some core to perform the translation, though with any decent library it shouldn't take a full day.

</comment></comment><comment><USER6> XML is a mistake. There's rarely a practical advantage to a novel XML schema. If you're not using a well known schema (e.g., Atom) then omit XML support.

<comment><USER7> I disagree. XML has a huge advantage over JSON: it can be streamed.

When working with JSON, you must load the whole JSON document before you can start processing it. If the JSON gets big enough, you start having performance / memory issues. One might argue that you can just get more powerful hardware, but that's only half of the equation: you'd solve _your_ problem, but not that of your clients. Are you going to tell every single one of them that they just need to spend more money on hardware?

When working with XML, you can choose to store the whole document in memory, but it's merely convenient, not compulsory. Using a SAX-like parser, you can stream the whole process and get a much smaller memory footprint.

Having never worked with YAML, I don't know whether the same argument applies.

This is more of a personal issue than an actual one, but another problem I have with JSON is that once you support it, people are going to demand you support JSONp - terribly convenient, but a major security hole.

Aside from that, JSON is obviously a great format for small, self-contained responses that can be consumed by both browsers and heavy applications. It just doesn't scale well with large responses.

<comment><USER4> Is there any fundamental reason JSON can't be parsed in a streaming fashion? It seems like you could implement the same kind of one-token-at-a-time parsing you can do with XML. What am I missing?

JSONp is only a security hole for the client, not the API provider. I suppose it puts a bit more pressure on the API provider to not get compromised, though.

<comment><USER7> Well, I _thought_ it wasn't possible to parse JSON in a streaming fashion, but given the number of annoyed answers I got, that was obviously incorrect.

Let me amend that to the more qualified "the libraries I've used so far don't allow you to stream JSON". My point is still somewhat valid - most XML libraries I know offer stream-based parsing out of the box, most JSON libraries I know don't - but it's not the show stopper I made it out to be, since it turns out you can, after all, implement your own streamed based parser.

As for JSONp, you're obviously and entirely right. My point was that, in case something happens on the client side (through an entirely different security hole - and let's face it, people who feel comfortable consuming JSONp are likely to take other insecure shortcuts), I'd much rather not be implicated at all than have to prove I had nothing to do with it.

</comment></comment></comment></comment><comment><USER8> The API should be independent of any serialization format. The serialization layer should take care of it.</comment>


The ancestral flower of angiosperms and its early diversification - <AUTHOR> https://www.nature.com/articles/ncomms16047 <comment><USER2> One cautionary note with this study is that the methods employed (ancestral character evolution) do not permit the inference of trait values that fall outside of the observed range of extant variation. Adding fossils can significantly improve our estimates of the root state but unfortunately in this case there don't seem to be many fossil flowers to parameterize the model.

There's been instances where using only data from extant species can mislead with respect to the hypothesized ancestral state. For one example, see figure 5 in [http://onlinelibrary.wiley.com/doi/10.1111/j.1558-5646.2012....](http://onlinelibrary.wiley.com/doi/10.1111/j.1558-5646.2012.01723.x/full)

</comment><comment><USER3> Recently I found TimeTree ([http://www.timetree.org/](http://www.timetree.org/)). The tool produces both timelines and timetrees (ancestry) of taxonomies. Both tools provide a nice context of the evolutionary environment. If you click through enough, you can usually get to the underlying research for the data as well.

Try searching for taxons Spermatophyta (seed plants) and Magnoliophyta (flowering plants) and to see the common ancestor of flowering plants.

</comment><comment><USER4> Isn't there some kind of egg/chicken (flower/insect) problem here? What's the evolutionary benefit of developing a flower unless insects also develop the eyesight and coordination necessary to find nectar in the flower?

<comment><USER5> * Not all flowers rely on insects for pollination, or any pollinators at all. Many are wind-pollinated or self-pollinating (not that the basal lineage would be asexual).

* Insects do not necessarily rely on eyesight for pollination. Scent, for instance, is a strong attractant.

* Insects need only be driven by a search for food for pollination to work. There is no requirement that they have specialized adaptations for nectar-gathering. Elaborate floral structures that require these adaptations evolved over time, along with their pollinators.

* One common flaw in evolutionary/adaptive thinking is assuming that efficient solutions must be present from the outset of an adaptive trait. Incidental effects that provide only the slightest increase in fitness can easily be fixed in a population.

Most importantly, though, this is really an investigation about structure. This is a common theme in plant development; many plant structures are highly analogous. Understanding the basal state of floral structures informs studies one the gene regulatory networks that control plant shape. For some context, I'd take a look at the well-characterized MADS-box genes. [https://en.wikipedia.org/wiki/ABC_model_of_flower_developmen...](https://en.wikipedia.org/wiki/ABC_model_of_flower_development)

<comment><USER6> I think you're mostly listing ways that both insect and flower could survive before they both developed specific adaptations that aid in their mutual interaction. But I feel like the more satisfying answer is that very gradual changes in both species can eventually lead to two species that appear to be extremely codependent.

In this case, I would guess that even the tiniest proto-flowers that resulted from random mutations could just so happen to be discovered by insects with the tiniest random mutations that led them there.

</comment></comment></comment><comment><USER7> IANAB. It's weird that it's so complex. I was expecting something very simple like [https://en.wikipedia.org/wiki/Bougainvillea](https://en.wikipedia.org/wiki/Bougainvillea) [https://www.google.com/search?q=Bougainvillea+flower&tbm=isc...](https://www.google.com/search?q=Bougainvillea+flower&tbm=isch) that has only three petals that look like colored leaves.

<comment><USER8> This isn't the 'first flower'. This is the first flower that is the most recent common ancestor of all flowering plants. There are a lot of more primitive flowers that lead up to this which are also common ancestors, but not the most recent, as well as a lot of dead ends that didn't leave any ancestors.

</comment></comment><comment><USER9> It looks sort of like a magnolia, which makes sense since those are ancient flowers.</comment>


Call for WPA3 - <AUTHOR> https://github.com/d33tah/call-for-wpa3 <comment><USER2> > That's pretty simple: don't accept DEAUTH packets from strangers.

Doesn't that basically enable stuck sessions? Unless you've got a perfect, proven session recovery system that can work with any amount and selection of dropped / error frames, you'll need a way to say "I don't know what's going on, let's start again". With TCP you simply drop the connection and start again. With Wifi, what's the solution?

> This can be achieved using key derivation functions like PBKDF2 or Scrypt.

Yeah... no. That simply moves the cracking from the "crack the passphrase" to "crack the resulting hash" scenario. We're already at that stage and that's what's currently broken in attacks on the downgrade to RC4. It doesn't matter what the original passphrase was.

> The problem exists because WPA2 has a fatal cryptographic flaw which allows > the derivation of the master key which is shared across all connected peers.

Only in WPA2 personal. At this point I give up. This is not a proposal... It's more of a rant about the current state of things.</comment>


American Vice: Mapping the 7 Deadly Sins  - <AUTHOR> http://www.wired.com/culture/education/magazine/17-09/st_sinmaps??mbid=cnn <comment><USER2> Apparently Kansas is the best of all possible worlds. And look, Wired credits Kansas State U. for the results.</comment>


Apple Is Not Wasting Its Cash Aggressively Enough - <AUTHOR> http://www.slate.com/blogs/moneybox/2013/02/07/david_einhorn_sues_apple_over_its_cash_stockpile.html

<comment><USER2> I am somewhat intrigued by this as an investor.

Simply sitting on the cash is not a very good investment. While having some around is a good strategic move, $72 billion in current assets is probably excessive. Besides, it is not like Apple would have a problem with debt financing if they decided to make a major acquisition (a scenario that I find unlikely, anyway).

What to do with the cash is a bit of a harder problem, though. The default option should be to give it back to the investors as a dividend or share repurchase. I would actually go with the latter as I think Apple is oversold/undervalued at the moment. I was thinking of selling, but now I am thinking of buying, again.

On the other hand, I am not particularly convinced by the "social good" argument of the article; this is business, after all. The author is right, though, that there is certainly an opportunity to try something wild (and huge) which could change the world (and possibly make even more money for the investors). That sounds like a very Steve Jobs thing to do. As a data point rather than a serious suggestion, this is more cash than Robert Zubrin suggested would be necessary for a Mars mission back in the mid-nineties in his book, "The Case for Mars."</comment>


Open-Sourcing Traffic Server: 700k lines of code, 9 months  - <AUTHOR> http://developer.yahoo.net/blog/archives/2010/02/opensourcing_traffic_server_700k_lines_of_code_9_months.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+YDNBlog+%28Yahoo%21+Developer+Network+Blog%29&utm_content=Google+Reader <comment><USER2> LOC is not something you should brag about. That said, it looks like the open sourced version (300K) is about on par with Squid and Apache:

nginx 75,214

lighttpd 84,852

apache 294,002

squid 283,417

(according to ohloh.com)

<comment><USER3> It's worrying just how bloated and large many simple web servers get. Those are some seriously large LOC counts.

<comment><USER4> the vast majority of apache's are in bundled optional modules, not the core.

I am not sure where ohloh is getting its numbers, but here are the directory stats from slocount, for the recent httpd 2.3.5-alpha:

      SLOC    Directory       SLOC-by-Language (Sorted)
      95386   modules         ansic=95095,lex=191,yacc=100
      27977   server          ansic=27977
      11362   build           sh=9980,awk=657,perl=433,pascal=292
      7248    support         ansic=7076,perl=92,sh=80
      3250    include         ansic=3250
      1622    os              ansic=1622
      1094    test            ansic=843,sh=230,perl=21
      159     top_dir         sh=159

If you were to strip out everything 'not needed' for a basic server, I expect you would end up 'running' about 40k LOC, which I think is 'inline' with others like varnish/lighttpd/etc

apache's problem isn't bloat, its architecture and bad sysadmins. it was designed from 1994 for prefork-based systems, and sysadmins have been configuring it since then, or not configuring it. Yes, it will use lots of ram when you embed Python and PHP in it, so don't do that.

mini-rant over, and a disclaimer: i am an httpd committer.

<comment><USER5> Does it really use any more RAM with python or PHP embedded than Apache + out of process Python or PHP would together? Seems to me that the main inefficiency is that the memory overhea for the scripting language is incurred whether or not there is active execution. So, that RAM is still tied up when sending a static file to a client, or when sending the buffered result of a static page. Seems like having an event-driven piece that took over for each prefork process when it came to returning the result and any logging that happens after the result has been sent would be a relatively small amendment to the architecture with a big payoff.

I know people are reverse proxying to Apache with nginx or similar for similar reasons.

</comment></comment></comment></comment><comment><USER6> It's multithreaded, so can take advantage of more CPU mores, unlike squid.

It has total disk cache persistence, so it won't lose any cache if the server crashes, traffic server crashes, unlike varnish.

If you've got cache spread over multiple spindles and one of the spindles dies while in production, it'll just keep on going, skipping that spindle. Squid does this, varnish does not.

It does run on linux. Actually it's what it was built on, originally, IIRC.

I have used TrafficServer (at Yahoo) and I'm willing to bet that it will overtake both squid and varnish as time goes on.

</comment><comment><USER7> Kind of hard to find information out there... The OP link and links off that page don't lead anywhere useful. Googled around and came up with this:

<http://cwiki.apache.org/confluence/display/TS/Traffic+Server>

Which also yields:

<http://wiki.apache.org/incubator/TrafficServerProposal>

<http://incubator.apache.org/projects/trafficserver.html>

The Apache "champion" is Doug Cutting, of Hadoop fame, so it seems to have street cred.

</comment><comment><USER8> Will be interesting to see how this compare to the current king-of-caches, Varnish.

The plugin architecture looks like it'll make it pretty flexible, but it'll have to be pretty special to beat Varnish in terms of performance.

<comment><USER6> (see my post above) :)

</comment></comment><comment><USER9> Definitely worth looking at - will spend my weekend on that, but so far not sure if(and where?) this thing can find own niche in popular deployment architectures.

<comment><USER10> If you do, come join #traffic-server on freenode, the "installation" is still a little rough in the edges.

</comment></comment><comment><USER11> Any takes on how this compares to, for instance, Squid?

</comment><comment><USER12> They mentioned everything apart from the fact that its a web server. Also, have I got this wrong or did they just hint that it doesn't run on linux?

<comment><USER13> What makes you think it doesn't run on Linux? From the article it sounds like it only runs on Linux since they say "contributors outside of Yahoo! can choose to build the code on more modern, non-Linux OSes as they see fit."</comment></comment>


Spec-ulation – Rich Hickey [video] - <AUTHOR> https://www.youtube.com/watch?v=oyLBGkS5ICk <comment><USER2> This is a very thick talk, one Rich's best ever IMHO.

The first point is how we talk about 'change' in software, to center around what things 'provide' and 'require'.

Breaking changes are changes that cause code to require more or provide less. Never do that, never need to do that. Good changes are in the realm of providing more or requiring less.

There is a detailed discussion about the different 'levels' \- from functions, to packages, artifacts, and runtimes, which he views as multiple instances of the same problem. Even though we now have spec, theres a lot of work to leverage it across all those different layers to make specific statements about what is provided and required.

<comment><USER3> I found value in dissecting the different levels of change. For the sake of sanity though, we should do breaking changes. Breaking changes exist because we have limited capacity as individuals and an industry to maintain software. This is especially true for infrastructure that is supported by (limited) corporate sponsorship and volunteers. Breaking changes limit our window of focus to two or three snapshots of code, instead of having our window of focus grow without bound. Our limited capacity can still be effective as a library changes over time.

The most important point of this talk is here: "You cannot ignore [compatibility] and have something that is going to endure, and people are going to value" [0]. Breaking changes provide a benefit for library developers, but it is usually damage done to end users. As consumers we should weigh the cost of keeping up with breaking changes against the quality of a tool, and the extra capacity its developers are likely to have.

[0] [https://youtu.be/oyLBGkS5ICk?t=4177](https://youtu.be/oyLBGkS5ICk?t=4177)

<comment><USER4> Who says you have to maintain old code? We're talking about simply not deleting it and establishing a discrete semantic for the new version as truthfully, a new version is new content which demands a new name to accurately and precisely describe it. If it didn't it would be like saying different content doesn't produce a different hash.

<comment><USER3> You're right, there is no obligation to maintain it. I think that misses the point though. The value in keeping the code is to allow the end user to continue to enjoy improvements in parts of the library that don't have breaking changes without upgrading those that do. You could continue to have security patches installed, for example. That value is much less when you don't do basic maintenance implement bug fixes and security patches.

<comment><USER4> Unless I'm missing something… the answer to that problem is to (a) factor the code sufficiently to then (b) create an abstraction (interface) that backs out the concrete implementation to the specifically desired version/functionality.

</comment></comment></comment></comment></comment><comment><USER5> I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by convention:

Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards- compatible bug fixes.

I got the impression that the issue was maven not being able to handle multiple versions of the same package/artifact, not in the convention.

<comment><USER6> Like Rich mentioned from the point of view of a library consumer it's:

PATCH: Don't care MINOR: Don't care MAJOR: You're screwed

MAJOR is simply not granular enough and MINOR and PATCH are pointless.

Sometimes when I update to a new major version of a dependency it all just works. Other times I've got to spend weeks fixing up all the little problems.

Did you break one thing I didn't even use? Update the MAJOR version. Did you completely change the library requiring all consumers to rewrite Update the major version.

<comment><USER5> Being screwed would be the case if the consumer of the artifact is forced to upgrade. i.e.: if versions cannot coexist in a code base.

Otherwise I think the information that they convey is useful:

PATCH: improvement or correction that does not affect the consumers expectation (safe improvement)

MINOR: additional features that may be useful directly to the consumer or its transitive dependencies (safe to upgrade)

MAJOR: No longer safe to upgrade automatically. The consumer may need to investigate further or stay with the previous MAJOR.

In any case it is useful information being conveyed. The consumer decides how to act on it.

<comment><USER6> > Being screwed would be the case if the consumer of the artifact is forced to > upgrade. i.e.: if versions cannot coexist in a code base.

In theory multiple versions can co-exist in a codebase in js land.

In practice though the vast majority of js libs don't compose well with different versions.

At best I've found it can work as long as you consider them seperate and unrelated libraries (basically the version in js land is part of the namespace).

Edit: I definetly don't think it's as big of an issue in js land as in Java land because of transitive dependency handling.

</comment></comment></comment></comment><comment><USER7> Haven't watched through the entire video, but the first part, analyzing dependency bottom up, and claiming version doesn't work, really reminds me of graphql. We've been doing traditional rest with /v1/..., /v2/.... This sucks for so many different ways. Graphql's solution of providing contract at the lowest level and just evolve the "graph" really feels a bit like what he was talking about in this video. And note that Facebook by not "provide less" or "require more" in their API is how they made their API still compatible with older clients. This talk is very interesting! (note I could be spewing BS here as I've not finished the video)

<comment><USER8> exactly my thought, having dug into GraphQL recently and seen a number of talks about it.

Getting over the annoyance of looking at some initial functionality that is misplaced can be quite hard... It's really tempting to just get rid of those as you're bumping up the MAJOR.

</comment></comment><comment><USER9> Rich Hickey gave one of my favorite talks that I recommend to all programmers no matter which language they code in:

[https://www.infoq.com/presentations/Simple-Made- Easy](https://www.infoq.com/presentations/Simple-Made-Easy)

</comment><comment><USER10> The whole section on "just change the name" fits interestingly in with the way that the kernel is developed. They have been rather strict on this for a long time. A function released to the wild stays. Changes to it require a new function.

<comment><USER11> [http://man7.org/linux/man- pages/man2/syscalls.2.html](http://man7.org/linux/man- pages/man2/syscalls.2.html)

</comment></comment><comment><USER12> This is a worthwhile talk, albeit a bit too long. In this talk RH provides a framework to think about libraries, how they change over time and how we should be communicating those changes. He proposes a way forward in which the changes are communicated in a way that can be dealt with programmatically, a much better framework than versioning schemes (semver gets a beating in this talk!).

<comment><USER13> Video is a high-bandwidth way of delivering information at a low bandwidth. But try watching tech videos at 1.5 speed, it makes them much more engaging. Also works for ponderous anime.

<comment><USER14> Got any examples of ponderous anime? Lain? Akira? GITS?

<comment><USER15> Dragonball. They sometimes charge up one attack over several episodes.

<comment><USER16> The planet will explode in five minutes.

</comment></comment></comment></comment></comment><comment><USER17> I can't get any useful information from videos, it is so slowwwww. Even on 2x (the fastest I can watch), it is still 3 to 5 times slower than I read. Also, I can control my reading, skip the minutiae, or reread important parts or look up some reference — but I can't do that with videos or audiobooks or podcasts. I wonder how people even find it convenient.

Unfortunately, Rich Hickey really loves videos for some reason, so everything he says is lost to me.

(Yes, there are transcripts, but those are linear and unstructured.)

<comment><USER18> Hey, I usually take notes when reading or watching stuff. If you're willing to read through my semi-coherent org-mode notes, it summarizes the talk better than a full transcript.[0]

[0][http://pastebin.com/bmF0xc7y](http://pastebin.com/bmF0xc7y)

<comment><USER17> Thanks!

</comment></comment></comment><comment><USER19> I've revisited this post so many times, I know the number by now: [http://hintjens.com/blog:85](http://hintjens.com/blog:85), "The End of Software Versions". I think it is related to, and similar to what Rich is saying.

</comment><comment> j-pb > Logic systems don't have "And nothing else will ever be true!".

Uuh. Closed world assumption? Everything that is not true is false. Most logic systems do have this. Prologs (not a logic system I know) cut operator even turns this statement into an operation.

I feel like Rich really gets it wrong this time. His request to support all the abominations that you have ever written and keep them compatible with recent changes, might work if you have people pay for using your library and a company behind it. But doesn't fly if you maintain these things out of goodwill in your anyhow limited spare time.

The best example of this style going horribly wrong are the linux kernel file system modules. Different api versions all in use at the same time by the same code with no clear documentation on what to use when.

It's also ironic that the examples he uses to make his point namely, Unix APIs, Java and HTML, are horrible to work with especially because they either never developed good API's (looking at you unix poll), or they, like browsers, have become so bloated that nobody want to touch them with a ten foot pole. One of the reasons why it takes so long for browser standards to be adopted is that they have to be integrated with all the cruft that is accumulating there for almost three decades now.

"Man browsers are so reliable and bug free and it's great that the new standards like flexbox get widespread adoption quickly, but I just wish the website I made for my dog in 1992 was supported better." -no one ever.

Combinatorial complexity is not your friend.

I'd rather have people throw away stuff in a new major release, maybe give me some time to update like sqlite or python do, and then have me migrate to a new system where they have less maintenance cost and I profit from more consistency and reliability.

I think that Joe Armstrong has a better take on this. [https://www.youtube.com/watch?v=lKXe3HUG2l4](https://www.youtube.com/watch?v=lKXe3HUG2l4)

Also even though I'm a fulltime Clojure dev, I would take Elms semantic versioning that is guaranteed through static type analysis anytime over spec's "we probably grew it in a consistent way" handwaving.

<comment><USER20> > His request to support all the abominations that you have ever written and > keep them compatible with recent changes, might work if you have people pay > for using your library and a company behind it

This is generally his focus, on big professional software. I'm also a Clojure dev and I'm on the other side of the fence on this one as well so sometimes I'm disappointed in the enterprise focus but I knew what I was getting into and it is still worth it. Am I crazy to think that maybe other lisps would have done better if they had demanded less purity?

Same with the examples of Unix APIs, Java and HTML. Sure, they are all bloated and horrible to work with. They are also massively, insanely successful. I think they are great examples because at that scale it's impressive that they work _at all_.

This is part of the pragmatism that makes Clojure great, they generally stay away from trying to solve the problem of huge projects being unwieldy and ugly and painful and instead they accept it as a given and work on tools to mitigate the problem. For a lot of people backwards compatibility isn't a choice, it's a requirement set in stone. Even though it always causes everyone to pull their hair out in frustration.

One day maybe one of these other research languages or experiments will find an answer to this, and prove that it works at scale. I will celebrate more than most.

<comment><USER21> The primary advantage of clojure to my mind are the lovely data structures and the interaction with them.

Common Lisp and scheme can implementation them, and through reader macros interact in probably the same ways, but it would always be second or third class.

Second big deal for clojure is the ecosystem.

I'd love a native language like clojure that was driven by a language specification.

</comment></comment></comment><comment><USER22> As I understand it, one of the original problems Go was designed to solve was long compile times at Google.

This talk is fascinating and points out a possible solution space for real world problems in giant codebases and build infrastructures.

What if 80% of your dependency graph can be identified as dead code paths at build time and not require you to actually take dependencies on all that dead code?

<comment><USER23> Sadly then Go went and shot themselves in the foot. Originally (I assumed this hasn't changed), you specified dependencies via git URLs. Sounds great, but then they went and said every dependency always used the head of master. So now you're in the horrific situation of your deps suddenly changing whenever your build decides to pull the latest from the git repos.

(Note: I don't use go, but this was the situation about 3 years ago when I last looked).

<comment><USER24> One of the things Rich talks about in this talk is semantic versioning is fundamentally broken. In fact any versioning scheme that allows removal is broken. In some sense this model encourages Rich's ideas better - since you can't version directly, you either make a new library or maintain backwards compatibility.

Of course the current 'go get' model has a lot of downsides, e.g. Non deterministic builds. I still think it's worth considering building on, rather than trying to fix semver. All that's really missing is a stable monotonic identifier - something as simple as git tree height may be enough.

<comment><USER23> Absolutely, I think the "perfect world" would be adopting some of the ideas Rich proposes but adding (git url + sha) as the dependency management system.

Of course for that to work well you'd also need to protect yourself from people deleting their git hub repos, or rewriting git history.

<comment><USER25> Which is a great use case for something like ipfs, I think.

</comment></comment></comment></comment></comment><comment><USER26> I was surprised by this. (Rich is rigorously perceptive and characteristically peels conflations apart.) Here, he seems to be conflating _linker_ responsibilities with _(unit-module) dependency management_ concerns.

If deployment-unit-A depends on du-B, but system-language level dependencies have additional subtleties, then that is fine, since someone like RH could be looking into code stripping of unreachable/dead-code on linking, and I'd be completely surprised if that hasn't been already looked at extensively to date.

Yes, you would sacrifice some transfer bandwidth/time on artifact acquisition but keep conceptual models local and their implementations simpler. Or, looking at it from another point of view, OP should consider that a 'dependency' is maximally the provider of objects in context of its namespace.

</comment><comment><USER18> When I was listening to the part about breakage vs accretion, I kept thinking back to the Nix pkg manager from NixOS. It does a pretty good job of separating out the artifacts by indexing them by version number and a hash of the username (i.e. artifact-name = sha($user) + $project-name + $semver). There have to be other examples of pkg managers that do this kind of thing too...

</comment><comment><USER27> I think there is a missing piece to this conversation, which is about the definition of namespaces. It's easy to conflate "problems with semver" and "problems with semver+the way my package manager handles versioning".

In npm, or with any package manager that allows multiple independent versions to coexist, the _version becomes part of the namespace_. Multiple different versions of a package can be installed at the same time and referenced from each other. It's no problem if you depend on B1.0 and C1.0, and they depend on D1.0 and D2.0 respectively; you just get all four installed.

In Rich Hickey's vision, we would move the compatibility contract into the package name, so if we want to make a new version 2 of helloworld that does not obey the contract of version 1, we call it helloworld2. In practical terms, this is no different from the above, it's just that we add the version number to the namespace through the package name rather than the package version.

Not surprisingly, this latter strategy is already used by most systems where versions aren't part of the namespace. Debian has python2 and python3. Python has urllib and urllib2 (and urllib3). Unix has mmap and mmap2. It works fine, but it's a bit of a hack.

If your version is part of the package namespace, semver works fine and solves the problem it was intended to solve. If, like in Java, every version has to share the same name, then I agree that semver doesn't really buy you that much. After all, it doesn't help you much to know that your unresolvable dependency tree is semantic.

It's not a coincidence that npm handles transitive dependencies in the way it does; it's the whole point. I'm sure it makes npm much more unwieldy to allow multiple different package versions, but having used it it is exactly one of those "solves a problem you didn't realise you had" moments.

With that said, I definitely agree that more careful API design would allow far fewer backwards-incompatible (ie semver-major) changes, and more tightly defining compatibility (like with this requires/provides concept) is a good way to do that. Many web APIs already say things like "we will return an object with at least these fields, and maybe more if we feel like it", which I think is a good example to follow.

As far as changing package names, there's also an interesting question, not about how computers deal with those package names, but how we do. After all, why helloworld and helloworld2? Why not give it another name entirely? Part of that is because you want to make the connection between these two packages explicit. But if you change your package dramatically, perhaps that connection is not doing a service to your users.

One of the biggest complaints about major rewrites is "why does it have to be the new way? I liked it the old way!" If you genuinely believe the new way is better, why not let it compete on an even playing field under its own name? (And, if you know your new package can't compete without backwards compatibility, maybe don't make a new package.)</comment>


The Unfortunate Rise of Patents in the Startup World - <AUTHOR> http://immad.me/post/55609778589/the-unfortunate-rise-of-patents-in-the-startup-world

<comment><USER3> I don't know if its unfortunate or a change in the kind of startups being created. I worked at a startup that patented its technology. We were (and the company still is) competing in the wireless sector, specifically military radio technology. Our competitors were Raytheon, Rockwell, etc, companies we could never compete against as a product company, because of their manufacturing prowess, deep industry network, etc. So we developed technology and patented it for licensing. A lot of the market dynamics that makes patents of questionable value for software startups were not present. Our technology cost millions of dollars and took years to develop. We had a fairly large (couple of dozen engineers) interdisciplinary team. Capital costs were high (hardware spins are not cheap, equipment is not cheap, testing was not cheap). There was no opportunity to "pivot." It was impractical to protect our IP with copyrights (we delivered firmware source).

I think at the end of the day, there has to be some protection against unfair competition, even if its not the existing patent regime. On the recent story about SpaceX, someone mentioned that SpaceX keeps trade secrets instead of patents because the Chinese would copy the technology via the patents. That's a form of IP and the concern of copying is the same concern patents address. Even if Elon Musk dislikes patents, he also dislikes Chinese companies ripping them off.

As VC moves into more areas, like life sciences, medical technology, energy, etc, you will see more patents. It's unfortunate if it leads to meritless patent litigation, but the VC's aren't interested in people ripping off their portfolio companies either, so I doubt you'll get strong push back from them on the subject of reducing the amount of patenting within the industry.

That said, the amount of litigation has clearly gotten out of hand. Patent litigation shouldn't be more common than say shareholder litigation or antitrust litigation, etc.

<comment><USER4> I'm in a somewhat similar situation (patented wireless technology startup), so I have to ask: were you actually able to get the big companies to license your technology? Did you need to get market penetration to get them to listen to you, or did they never listen at all? I'd love to be able to license our technology to a larger company instead of doing things the hard way. Putting together a startup is not the easy way, although it seems to be easier than trying to navigate the inside of a large company to find the right person to be an internal champion for your product.

Basically, I'm asking, "what does a successful wireless licensing path look like?".

My experience with trying to find the right decision-maker at large companies has been daunting. I mean, I play soccer with about 10 engineers & managers from a large military radio company (rhymes with Paris) and not one of them could even point me to the right division to talk to, much less the correct decision-maker. With companies where I don't know anyone, I don't even know where to start.

So, our startup is aiming to hit niche markets, like amateur radio, just to get a product out there and start some buzz. How did you do it?

<comment><USER3> Why don't you shoot me an email (in profile)?

</comment></comment></comment><comment><USER5> This is not the first time that Silicon Valley has dealt with patents. Gordon Moore:

>Ah, one of the questions that has come out of a number of lawsuits as of recently, that here on the west coast, in silicon valley, we didn't patent circuit designs or Computer Aided Design for that matter. And as a result, we never patented at Fairchild the ROM and the RAM. Intel never patented the microprocessor... and others did. East coast companies or TI in particular, took our work and patented it. How come we never recognized the importance of that... circuit development?

>Well, it was probably a different attitude about patents. One thing that happened in the semiconductor industry... semiconductor processes are a long series of steps and the patents had gotten pretty broadly spread because all of the people working on the technology had some of them. And the net result was in order for any of us to operate we had to be cross licensed so the participants tended to all cross, license one another. So, there was not a tremendous advantage to having more patents... with a couple of exceptions, there wasn't much net benefit from it.

>What we never anticipated, I guess, was a lot of other participants were going to enter the business later on. So, at Fairchild we tended to patent relatively few things, typically the ones that we thought we could police most easily and were the most difficult to get around, you know, the more fundamental things. But, I was responsible for a lot of those decisions. I remember one in particular that, in retrospect, is kind of funny. In the early days of the integrated circuit, Bob Norman, one of the people who were involved there, suggested the idea of semiconductor memory... the whole idea of how semiconductorflip- flops could be used as a memory structure, and I decided it was so economically ridiculous, it didn't make any sense to file a patent on it.

>You recognize that a few years later, semiconductor memory was the basis of...

>Of Intel.

[http://silicongenesis.stanford.edu/transcripts/chronicles.ht...](http://silicongenesis.stanford.edu/transcripts/chronicles.htm)

</comment><comment><USER6> This can be dangerous for company founders, depending on how exactly it plays out. I know of at least one case where a company based on its founders' research went bust, its patents ended up sold off in bankruptcy liquidation, and the founders themselves now have a potential patent problem if they were to use their own inventions in any future endeavors. Whereas in a normal case where your startup fails, it doesn't take your ideas down with it, and you're free to try them again elsewhere.

<comment><USER7> > "Whereas in a normal case where your startup fails, it doesn't take your > ideas down with it, and you're free to try them again elsewhere."

That depends highly on your definition of 'normal'. In non-software startups, there's a combination of patent, trade-secret and (probably) copyright to balance. Part of the value you are creating is in the innovative step/technical advance, which may make sense to write down, defend and assign to the company. For some companies, having the patent is a critical piece not only to _demonstrate_ an innovative step [1] but also for investors who are putting money into the company because of that innovative step (that they know it's part of the company and you can't simply make off with it). It's a tangible asset so yes, it can be sold.

[1] assuming that the patent system is doing it's job properly (which many would argue it's not)

</comment></comment><comment><USER8> One of my favorite podcasts, This American Life, has two excellent episodes concerning patents:

Part 1: [http://www.thisamericanlife.org/radio- archives/episode/441/w...](http://www.thisamericanlife.org/radio- archives/episode/441/when-patents-attack)

Part 2: [http://www.thisamericanlife.org/radio- archives/episode/496/w...](http://www.thisamericanlife.org/radio- archives/episode/496/when-patents-attack-part-two)

I agree that hardware patents seem reasonable, as long as they are technical patents and not design patents, but shortening their length to 5 years sounds like a good idea.

As a programmer, I cannot think of one software patent that I've seen granted which did not appear obvious. I'm sure they are out there, and there are many innovations taking place in computer science, but the kind of programming involved in developing most software-based startups does not warrant protection.

Facebook didn't catch on due to amazing technology, it was amazing implementation. Likewise with Airbnb.

<comment><USER9> > _As a programmer, I cannot think of one software patent that I 've seen > granted which did not appear obvious._

I think this is availability bias. Non-obvious patents don't receive wide publicity for the same reason that "Grandma walks home safely from shops for thousandth time" doesn't receive wide publicity.

</comment></comment><comment><USER10> There's a big difference between innovation in the hardware space and the software space. There's a long history of hardware innovations being ripped off immediately by competitors, or even before you're able to bring your own product to market. The number of cloned technologies springing from China speaks to that.

Hardware patents still seem to work and reward innovation - things like FRAND prevent lockout whilst rewarding the innovator.

Other parts of the world, well really everywhere that isn't the USA, manage to get along fine without software patents but with hardware patents.

In fact a small hardware startup is exactly the kind of company that the patent system is designed to protect.

</comment><comment><USER11> In general I agree with the author. I used to be a patent free advocate but when we started our medical hardware startup that dream sort of came crashing down. In the medical space it is almost impossible to work without patents, there are huge giants who would not hesitate to snap up your idea. I've heard similar stories from others in the hardware space around Brisbane. This coupled with the face that any sort of large scale manufacturing takes a large amount of time and capital makes it very difficult to continue in the hardware (and medical) space without some sort of protection on your idea. Perhaps yes 20 years is too long but I think for now patents still have a place in startups.

</comment><comment><USER12> We are a relatively new company that has technology that is patent pending. The patent has taken a bit of time and may have held us back some. On the other hand, we do have enabling technology and it seems like prior art doesn't hold up too well in this broken patent system. So, being taken down by someone using our own technology would be a horrible feeling.

In the end, I guess only time will tell if our worries were founded.

<comment><USER13> Why did you feel the need to patent your technology?

<comment><USER12> For a lot of different reasons: most of them probably not that good.

To be able to work within the "system". That is, to stop someone from patenting prior art (our technology being only prior art if we didn't patent it) and use that against us. I've personally known of people who have done things like this (find a new usage for an existing very specific technology, patent it and notify the creators of the technology).

To give us the option to open source the technology and not have problems within the (broken) system: specifically intellectual property (Java with Sun Microsystems and Microsoft come to mind though that was resolved through Trademarks).

I was raised in the USA and, at the time we started the patent process, it "felt" like the thing we were supposed to do.

I've invested a lot in R&D and somehow felt that I needed to protect that investment. It took four years to figure out all the kinks in the technology.

<comment><USER14> For number one, and number two, the "Statutory Invention Registration" should do.

<comment><USER15> It looks as though Statutory Invention Registrations were eliminated by "America Invents Act." [http://www.aiarulemaking.com/rulemaking- topics/group-3/repea...](http://www.aiarulemaking.com/rulemaking- topics/group-3/repeal-statutory-invention-registration.php)

<comment><USER14> AGH. I was going to use this to make IP-free drugs.

</comment></comment></comment></comment></comment></comment><comment><USER16> It is interesting to see the electronics/computer science side of the patent debate. On this side of the argument there is a desire for a short duration, very narrowly tailored patents (for some that is even too much) because technology moves so fast. On the biomedical/genetics research side of the argument there is a desire for long lasting, broadly tailored patents because it takes so long to develop medicine, do clinical trials, get FDA approval, etc.

What I find most interesting is that I believe most (not all) members of this side of the debate 1) don't know there is another side and/or 2) don't care about the needs of the other side. This author makes good points, but lacks proper context I believe.

Statements like '20 years was set in the days of horse and carts, does it make sense in the modern age?' are great for pandering to an already complicit audience. However, the point is that for some industries 20 years makes sense, and for some of them 20 years isn't long enough.

I'd be willing to bet Myriad Genetics or Monsanto thinks 20 years is not enough.

</comment><comment><USER17> In my opinion, in the start up world, patents are just another way of "cashing in". I.e, your product might fail but your patent might prevail.

<comment><USER18> This position results from confirmation bias. You know of the big sales of patents, but everyday there are patents filed, generally costing $10,000+ to the filers, that may not even sell at a profit to acquire. Everyday startups fail with ideas that noone really cares about.

</comment></comment><comment><USER19> I've had to navigate these waters while doing hardware development. A long time ago I made the mistake of going to engineering first rather than filing for a patent. As a less experienced engineer I wanted to get a (hardware + software) product built and into the market. It still took over a year's worth of a serious effort to get it done. To me, at the time, filing for a patent seemed like both a waste of money and valuable time. I despised the idea of having to translate my technology into bullshit-ease. Like I said, I just didn't have a lot of experience in that domain at the time.

I finally got the product to market. It hit a nerve and went like gangbusters, selling several hundred thousand dollars in product in the very first quarter. Not a bad launch. Six months later a competitor comes out of the woodwork with a product that was 60% of mine at 50% of the list price. A friend of mine called me thinking that I had licensed the technology because the competing company had even copied my marketing language verbatim. What a shock.

You see, hardware R&D is very expensive. The "R" part can take months, even years. Depending on the field of application and the problem being solved costs can be staggering. One example of this are medical products. If you can bypass the "R" and go straight to "D" you can put out a product for a lot less money. that's exactly what happened to me. Not only did my competitors bypass "R" but they also benefited from the work and expense I went through to identify a market.

That's when you look back and want to kick yourself in the ass for not having taken the time to file for a patent. Lesson learned the hard way.

Many years and lots of mistakes later I emerged with far more wisdom about both engineering and business. One of my observations was that patents are nothing more than necessary weapons of war. Business is war. No question about it. And so, whether you like it or not, if your opponent is using guns you have to have guns as well. Not having patents exposes you to an indeterminate level of danger. As we have seen over the years, both legitimate patent holders and trolls can surface out of nowhere and almost shut you down. Having a granted patent you can point to gives you the ability to say "go away" with some authority.

Years ago I viewed the open culture of web startups with a degree of incredulity. Based on my experiences, I simply could not believe entrepreneurs would put it all on the table for anyone to see. That goes counter what you want to do in the hardware world. Keep it quiet and get it patented or you'll get screwed. That's the winning model.

While small software startups continue with the open philosophy, larger companies like Apple and others file patents at a furious rate. Interesting. Patents are expensive and very time consuming. Perhaps the disparity between small and large companies and what they can do with regards to filing software patents should be reason enough to abolish software patents. The little guys simply can't play the same game.

While I am decidedly anti-patent when it comes to software-only products I have trouble finding fault in the idea of patents for physical or hardware inventions. Don't get me wrong, I still want to see patents only be granted for real inventions. What constitutes a real invention? That's a whole new discussion. That said, the standard of proof should be harder and harder to meet as the years go by. Today it should be nearly impossible to get any kind of patent. Why? Because it is harder to actually invent anything new. Almost every patent I've reviewed (hundreds) are implementations or regurgitations of implementations obfuscated enough to make them look like an invention.

<comment><USER20> If you had gotten the patent, would you have had the $500,000 to take your competitor to court? (The only upside of victory being that they would no longer make the clone?)

Patents don't keep competitors from stealing your work, they just give you access to a (expensive) right to sue them to get them to stop.

<comment><USER9> To sue? Maybe, maybe not. There are companies who finance patent lawsuits.

To negotiate a settlement? Ahhhh, now we're talking. It's the flipside of patent trolling.

</comment></comment></comment><comment><USER7> This post feels unfinished. There a number of places where sentences hang and thoughts don't feel completed. Is it just me?

In general your article seems to be more about _software_ patents and _software_ startups but by omitting those words it comes across an over- generalising (e.g so what if 6% of AngelList companies mention patents? What am I meant to take from that?).

Sure, you do mention 'hardware' startups but you talk about them as though this is something new. The 20 year time period only looks like overkill when your experience is in shipping code on a daily basis. If hardware startups only had 5 years to run, the only innovation created would be large incumbents copying the tech 5yrs after launch (instead of, say, trying to buy the company).

I think software patents stifle innovation but I also see that there are benefits to patents as a whole.

</comment><comment><USER21> The problem is not patents per se. It's patents that cover obvious solutions or even the problem itself, like the famous "one click" Amazon patent. The solution would be change the obviousness test.

<comment><USER22> Okay, I name you Patent Examiner Potentate. Just a few simple questions.

Are wheels obvious? How about a wheel attached to two logs (a cart)? How about fire? woven grass to catch fish in a stream? Taking some seeds from a plant and planting them?

Those completely transformed our lives, yet, for a very long time, were anything but obvious. My point is not to bicker about fire and how a patent process might have treated it, per se, but to illustrate how hard it is to recognize what is obvious or not. If no one else is doing something, in the tech field, is it because it wasn't obvious, or because the tech wasn't quite there yet? I've talked with quite a few (US) patent examiners and they are smart people, and find it anything but trivial to rule on obviousness. I'll say more about that in relation to "one click" below.

The bigger issue, to my mind, is the ease of research and implementation. It doesn't cost years of research to devise 'one click'. After you have thought of it, you can hand it off to a mid-level programmer and it'll be added to your stack in a few days - and a junior programmer could've had a prototype going in 15 minutes. Contrast that to the people rightly lamenting about investing years of work into medical device, only to have it stolen from them by a bigger (or just different) company.

I haven't studied the history of one click, so I could be wrong about its details. If so, please focus on the broader ideas. The argument is simply that if no one else does something for several years when it was possible, then that idea is not 'obvious', except in hindsight.

With that said, I'm not crazy about extending 20 years of protection to such a trivial implementation. But how do we do that without punishing people with years of research, or just a brilliant flash of insight? I'm sure we can come up with a straw man patent (and perhaps one click is that straw man, though I don't think so), but the difficulty is in ruling on non-strawman patents.

<comment><USER21> I'm quite interested in the subject of patents, and read enough about that. From what I've read about US patents examiners, it's not a problem of them not being smart. The problem is that they aren't tasked with assessing if a patent claim is "obvious to a person skilled in the art" \- like they should be - <USER2> only with finding out if there is published prior art.

So, to use your example: Fire shouldn't have been patentable, because it's a natural phenomenon. But if you're the first one to discover how to light a fire faster, using a bow, then definitely you should be able to patent that.

In this context, one-click is neither fire nor a new way to light it. It's more like a situation where everybody is already using fire to cook freshwater fish, but nobody wrote in a recognized publication that you can also use it to cook seawater fish; and now you come and patent that.

</comment></comment></comment><comment><USER23> Patents (and, before that, provisional patents, i.e. "patent pending") are also a ways to capitalize IP, that for a startup represents most of its initial value. The only other way I'm aware of is having research publications, that IMHO is way harder (at least compared to provisional patents).

</comment><comment><USER24> [http://www.contrastrebellion.com/](http://www.contrastrebellion.com/)

       Low-contrast font color and unreadable texts?
       To hell with them!

<comment><AUTHOR> I agree, its the first post on my new blog. I have changed the contrast and its much better now. Let me know if you have any other feedback.

</comment></comment><comment><USER25> Read this first as 'parents'

</comment><comment><USER26> gotta jump on that shit: [http://img.gawkerassets.com/img/18tg6h0u2nds4png/ku- xlarge.p...](http://img.gawkerassets.com/img/18tg6h0u2nds4png/ku-xlarge.png)

(from [http://valleywag.gawker.com/snapchat-had-the-frattiest- creat...](http://valleywag.gawker.com/snapchat-had-the-frattiest-creation-in- startup-history-639615051))</comment>


Plastination versus Cryonics - <AUTHOR> http://www.gwern.net/plastination

<comment><USER3> _> current plastination techniques sufficing to create connectomes, but what does it miss?_

I'm not worried about neurotransmitter levels or electrical activity, there are enough events during a normal lifetime where these can be severely compromised without any long term effects. What I am worried about, though, is the fine structure of "custom" proteins - meaning proteins that have been specifically generated by the brain to modulate the activity of one or more very specific neurons. It's not unreasonable to suspect that these serve an important role in long term memory formation and function.

I strongly suspect digitizing the connectome by itself may not be enough in the same way that saving the structure of an artificial neural network _without_ preserving info about any weights, activation functions, and other parameters is not enough to reproduce the network later.

 _> by copying the digital data to many archives and formats online and offline. No such option is available to a cryonics brain unless it abandons cryonics entirely_

How you judge this depends on what you're trying to achieve with cryonics. In theory, a destructive scan of a cryo-preserved brain should yield more and better data than that of a plastinated one. The question becomes: do we need that additional data or not?

I'd like cryonics to preserve brains until it becomes clear how to scan them adequately. By comparison, cryonic preservation is a relatively gentle process, whereas plastination imposes some heavy chemical changes on the brain to the point where it's entirely likely that too much information could be lost. The promise of cryonics lies not in a biological resurrection at a later date, but in giving researchers enough time to figure out how to actually do an upload. It _may_ well turn out that plastinated remains are a sufficient data source, but contrast that with cryonics where much fewer doubts about the preservation of the necessary information exist.

Of course, cryonics is beyond problematic - it requires constant and costly upkeep. And more importantly, just a few days of political, economical, or technological instability can easily wipe out every cryo-preserved brain in existence. So it's clear this can't be a solution for the next few hundreds or years. It's a solution for the next few decades at best (until the first provider goes bankrupt).

The options, in a word, all suck.

<comment><USER4> >cryonics [has] much fewer doubts about the preservation of the necessary information

Could you say why you think this? Were you convinced by the experiments done by the Cryonics Institute or Alcor? I haven't been able to contact a disinterested neuroscientist willing to take a serious look at that research.

>just a few days of political, economical, or technological instability can easily wipe out every cryo-preserved brain in existence

Political, maybe, if the the legal status of patients changes so that they are required to be thawed. But why economical or technological? I think I read somewhere that it would take like a month or something for the liquid nitrogen to evaporate enough for the patients to thaw.

<comment><USER3> _> Could you say why you think this?_

During my time as a medical research minion I did some work on preserving tissue samples and even whole organs, including plastination and similar resin casts. What you need to be aware of is that, while the finished specimen look very good and life-like, they are radically altered on a biochemical level. All the water and lipids get replaced by resin. That requires soaking them in formaldehyde, acetone, and other chemicals before resin can even be applied. This process absolutely destroys proteins, in fact it relies on that. Also, the whole process takes days to complete, and during that time bio matter is actually being washed out and the whole structure is in motion. There is absolutely no question that information is lost here, in droves. If you believe plastination has a decent chance of preserving people's minds, you're operating under the assumption that the connectome itself will yield enough data for an upload.

Compared to that, freezing is, well freezing. Molecular motion almost ceases, so the most important aspect to gauge information loss in cryonics is what happens to the brain until it's finally cooled down. There are three main problems here. The first is the formation and shape of ice crystals which can (and do) destroy cells. This is a bit more relevant to in-vivo reanimation enthusiasts, because the physical shearing should probably be algorithmically correctable in a scan scenario. The second is the effect of the cryo fluid they pump into patients to prevent said ice crystals from forming, because it's also toxic to proteins. It's not as invasive as plastination, but it's still pretty bad. The third aspect is the time span from asystole to the halting of information loss. This might be a problem, but since current research indicates that a lot of ischemic brain damage is actually a cascade triggered by re-perfusion, there is cause for the assumption that anything up to a few hours might actually be fine.

 _> Were you convinced by the experiments done by the Cryonics Institute or Alcor?_

I have to admit to only a passing knowledge of their in-house research efforts. Alcor's that is, I know next to nothing about CI. The problem is, they - nor anyone else for that matter - are not in a position to make any substantive claims about information fidelity _beyond_ the continuing efforts to preserve the brain as faithfully as possible. A lot of their statements seem to focus on future viability of the tissue, and options for biological reanimation - but these are things I have no interest in (because I think it's both unrealistic and a bad deal). In fact, the last time I visited Alcor's site I couldn't find any reference to uploading at all, maybe I just missed it though.

 _> Political, maybe, if the the legal status of patients changes so that they are required to be thawed._

Yes, I agree. It's a massive taboo, ask any random person on the street and they'll be horrified. It's not difficult to imagine neuropreservation might get outlawed as soon as it looks like it might actually be feasible. In fact, we're seeing the same thing happening now with AGI. One can only imagine the public outcry involving bringing conserved brains back to life will be magnitudes larger than whatever will happen in respect to AGI soon.

 _> But why economical or technological?_

By definition, cryonics companies have to operate on the fringe. That makes them especially vulnerable to disruption from relatively minor events. But even if they were as stable as, say a major bank: well, those fail, too. And if they're not going bankrupt, one might imagine a power outage lasting for months. Or some other infrastructure catastrophe that results in these companies being unable or unwilling to maintain services. Us western countries are kind of operating under the assumption that we're stable and eternal, which is an illusion.

That's why I said it's a solution for the next decades at best. During that time, if we really want to put resources behind it, we could theoretically figure out a destructive scanning -> uploading workflow (simulation can come later in principle). But if we're talking about biological reanimation... there is not even a tenuous time frame imaginable. We could easily talk hundreds of years until our nano tech is sufficiently advanced. And that's too long for two fragile companies to keep afloat in the face of economic crises, religious and cultural disapproval, incompetence and malice, accidents, disasters, and world events - any single one of which can wipe everything out.

<comment><USER4> Thanks for the detailed answer.

>If you believe plastination has a decent chance of preserving people's minds, you're operating under the assumption that the connectome itself will yield enough data for an upload.

Ok I think this makes sense. I doubt that the connectome is sufficient.

>A lot of their statements seem to focus on future viability...

IIRC they talk about uploading issues under the code word "information- theoretic criterion of death", meaning that a preserved brain could be totally non-viable while still containing enough information to be uploaded; you're only dead if that information is destroyed, i.e. irretrievable "in principle" to an observer with full knowledge of human neurobiology and perfect scanning technology.

>future viability of the tissue, and options for biological reanimation - <USER2> these are things I have no interest in

Agree, I'm not particularly worried about viability. Side note: it is a lot easier to pitch reanimation than uploading to most people (not that it's easy either way).

>One can only imagine the public outcry involving bringing conserved brains back to life will be magnitudes larger than whatever will happen in respect to AGI soon

This being mildly hilarious, because the risks from non-human strong AGI are way way larger than those from reanimated humans or even uploads...

>But even if they were as stable as, say a major bank: well, those fail, too.

This isn't clear to me. Cryonics companies have a totally different business plan from banks. Each customer pays a large fixed cost up front before services are rendered, creating an endowment thing that should pay for them indefinitely. Specifically, they could make very conservative investments, such that it would take a world collapse to drive them under. In theory.

>hundreds of years until our nano tech is sufficiently advanced.

Hmmm... I think I would be pretty surprised if it took an unregulated nanotech industry more than 50--100 years to develop near-arbitrary capabilities. The roadblock to biological reanimation would be knowing what to specify to build, not the building part. (I agree that intuitively, scanning, if not actual uploading, should be much easier.)

>And that's too long for two fragile companies to keep afloat in the face of economic crises, religious and cultural disapproval, incompetence and malice, accidents, disasters, and world events - any single one of which can wipe everything out.

This is a pretty complicated question, but how do you think each of these risk factors would respond to broader adoption of cryonics? My guesses:

economic crises: significantly mitigated, because of economies of scale making it cheaper and overall scale making companies less vulnerable to variance. E.g. cryonics companies could build their own liquid nitrogen condensation plants, which are not that expensive at scale, I believe.

incompetence and malice: similar---at scale, companies could afford to defend against these

religious and cultural disapproval: unclear to me; how much of a threat would this be, and how hard would it be to get people to come around?

accidents: not much to do about this. Hypothetically, with extremely wide adoption of cryonics, there could be safety policy decisions made based on the calculation "How many accidents leading to non-cryopreservable brains will this lead to?".

disasters and world events: no help here. At scale, could slightly defend against tamer disasters with underground bunkers or something.

<comment><USER3> > _" information-theoretic criterion of death"_

To be fair, this applies to any type of preservation/reanimation scenario.

> _Specifically, they could make very conservative investments_

As you said, in theory. In theory, so could banks ;)

> _The roadblock to biological reanimation would be knowing what to specify to > build, not the building part._

Exactly. Well, speaking from today's perspective, it's both. But yes, how to repair it and keep it alive would be a huge hassle, not to mention we simply don't have anything approaching this capability yet, even in principle. Not to forget, that at the end of this really long road, the problem has just been deferred by a few decades ;)

> _but how do you think each of these risk factors would respond to broader > adoption of cryonics?_

No, I was talking about the other way around, since cryonics is not yet a factor in anything, it's susceptible to everything that may happen externally! We might disagree about the weight and probability of individual events, but I think we're clear on the fact that for quite a bit of time to come, cryonics is a vulnerable storage facility critically dependent on the infrastructure and benevolent indifference of our civilization - and not a concept that changes the course of anything (yet).

<comment><USER4> >we're clear on the fact that for quite a bit of time to come, cryonics is a vulnerable storage facility critically dependent on the infrastructure and benevolent indifference of our civilization

Right, I agree. I was wondering about evaluating the potential business or philanthropic benefits of interventions on cryonics; e.g. funding research on effectiveness of current protocols or on developing better protocols, seeding larger operations and capturing economies of scale, advertising/PR, lobbying for rights, etc. I haven't properly thought this through at all, but I suspect that there might actually be a pretty good philanthropic argument for some kind of preservation.

Society could save big on healthcare (not to mention the disutility of being kept alive to the bitter end) by preserving anyone whose health is in severe decline; anyone who has brain cancer, Alzheimer's, Parkinson's, etc.; anyone with imminently terminal diseases; and so on, all voluntarily of course. I believe end-of-life healthcare can typically cost tens of thousands of dollars, which is commensurate with preservation costs.

Further, it seems like I'd much rather save one person to live a long life (at the very least, thousands of years), than save two lives to live a standard life of ~50 more years. Though admittedly this depends on what you think your terminal values are, and also on difficult-to-estimate effects, e.g. the instrumental benefits of having more people alive now to help with morale or with doing stuff. And for obvious reasons this is uncomfortable to have to consider, and even more uncomfortable to actually propose as philanthropic policy.

</comment></comment></comment></comment></comment></comment><comment><USER5> Preserving the connectome is probably insufficient for full restoration. Even if you could record the entire structure of the brain at the synaptic level, you're still missing the functional states of the neurons and glial cells that it is composed of. It would be like trying to reconstruct a piece of software solely from its call graph.

</comment><comment><USER6> It's important to realize cryonics/plastination research is not just for people who want to extend their lives. It's going to be a crucial component in long term space flight.

<comment><USER7> I am not convinced that long term space flight will be really interesting, at least _before_ we radically extend our lifespan (you mean interstellar, right?). The space is just too big.

<comment><USER8> A Hohmann transfer even to Neptune is 40 years. In practice I'd expect it would be more like a decade using less efficient orbits but I hope that shows that even within the solar system there can be trips long enough that suspension would be an asset.

</comment></comment></comment><comment> anti-shill preserving information is key...if plastination preserves memory, it is worthwhile.</comment>


12 Founders working on a new idea. 7 days. 1 mansion in Hawaii - <AUTHOR> https://wefunder.com/workaway <comment><USER2> That sounds a bit like Fyre Festival ad...</comment>


How Wall Street Bankers Use Seamless To Feast On Free Lobster, Steak, And Beer - <AUTHOR> http://www.fastcompany.com/1822449/scamming-seamless-how-big-banks-are-getting-taken-for-big-cash

<comment><USER2> And Strippers?</comment>


Why Apple keeps its iPhone 2.0 SDK under NDA - <AUTHOR> http://www.appleinsider.com/articles/08/08/28/developers_question_why_apple_keeps_its_iphone_2_0_sdk_under_nda.html <comment><USER2> _"Another reason for locking up iPhone details behind NDA is that Apple can't seek to patent any inventions after they are publicly published. By keeping the iPhone's details under NDA, it can retroactively seek patent protection for ideas that it discovers are more novel that originally thought."_

I think Apple could ship frozen turds & appleinsider would find a way to spin it. "They're saving on development costs!"

<comment><USER3> "Prince McLean" is a particularly obnoxious Apple apologist. You may also know him as Daniel Eran Dilger of roughlydrafted.com

He regularly posts essentially the same article on both rouglydrafted.com and appleinsider.com, often citing one of in the other, and even defending his alter-ego if he's been called out.

See here:

[http://www.appleinsider.com/articles/08/08/15/inside_mobilem...](http://www.appleinsider.com/articles/08/08/15/inside_mobileme_web_3_and_web_client_server_apps.html&page=2)

Then here:

[http://www.roughlydrafted.com/2008/08/22/is-apples- mobileme-...](http://www.roughlydrafted.com/2008/08/22/is-apples-mobileme- secure/)

I have no problem with writers using pen names, but when you're writing the exact same material on two different sites using two different names, cross- linking between them, and defending _yourself_ under a different name, _thats_ crossing the line.

</comment></comment><comment><USER4> It is amazing how entirely frustrating this is to developers.

We are using a new platform and this is the point that we need access to as much information as possible, and this is the period where Apple is being most restrictive.

</comment><comment><USER5> All hail Jobs, bringer of communicators.</comment>


Why the Megapixel Race Needs to End - <AUTHOR> http://blog.wired.com/gadgets/2008/08/why-the-megapix.html <comment><USER2> I work in computer vision, and there's an entire sub-branch called "computational photography" that aims to do more interesting things with cameras. The idea is that by capturing more information at the hardware level -- perhaps in some 'coded' form -- we can do much more with the captured data. Things like getting better quality images, getting depth information, capturing HDR images in a single image, etc. Many of these techniques require trading off spatial resolution for their benefits, thus making the increasing number of megapixels actually useful (i.e., so that when you lose 50% of your resolution to capture some other information, you're still left with a decent size image).

A good page describing this field is <http://www1.cs.columbia.edu/CAVE/projects/what_is/>

</comment><comment><USER3> Do not conflate orthogonal issues. Pixel count increases, all else being equal, are good. Any visual artifacts caused by that increase are the result of other factors. The author's real problem is with the design of _individual_ sensors, not the _quantity_ of sensors.

"Good enough" does _not_ mean "stop innovating."

<comment><AUTHOR> _Pixel count increases, all else being equal, are good._

The problem is that all else is not equal. Recent pixel count increases have come at the expense of pixel area, since the total sensor area is not increasing. Thus there are fewer photons per pixel, decreasing the per pixel signal-to-noise ratio.

</comment></comment><comment><USER4> Calm down, it'll end like the MHz (GHz) race did.

<comment><USER5> Incidentally, why was the MHz race a swindle?

<comment><USER6> The MHz race wasn't a swindle, when MHz mattered it was a simpler world were you could compare processors without having to lookup meaningless product numbers like T850 or TL-60.

The only thing you needed to remember was the Celeron/P4 distinction (and the AMD equivalent)

Now each chip company spits out new products at higher and lower MHz which makes it even more confusing to consumers. Is a P4 4 GHz chip faster than a Core Duo 2.16 GHz, is a typical question I get from friends/family.

</comment></comment></comment><comment><USER7> Heard of downsampling? There is a reason that HD video looks better on a standard television.

</comment><comment><USER8> That's one damn erotic campfire.

</comment><comment><USER9> they should still have the race for the professional cameras, but for your basic point and click its way overboard.

<comment><USER10> Even when considering professional cameras, it's more about the size of the sensor than raw megapixel output:

"Bigger chips mean so many good things. Big chips mean shallower depth-of- field at equivalent settings. Big chips mean big pixels, which means more light hits each photosite. More light means less gain, less noise per pixel. Less noise means more dynamic range. Bigger chips mean better pictures."

[http://prolost.blogspot.com/2008/07/panasonic-is-my- hero.htm...](http://prolost.blogspot.com/2008/07/panasonic-is-my-hero.html)

<http://rebelsguide.com/dl/sensorSizes_06_cheatSheet.png></comment></comment>


New Study Shows Solar System is Unique - <AUTHOR> http://thefutureofthings.com/news/1295/new-study-shows-solar-system-is-unique.html <comment><USER2> Great... the creationist nut-jobs will be crowing about this for sure.

</comment><comment><USER3> I was going to complain about the use of the word "unique", but it's only in the headline and not in the article itself. It is almost certainly _not_ unique, but I'm prepared to believe it's very unusual.

</comment><comment><USER4> "unique" in a universe with billions of galaxies, each with billions of stars, might still equate to "a $#@!-ton of"...

(Yes, I'm aware of Drake's equation.)

</comment><comment><USER5> I'm unique too :)</comment>