Design Review: Key-Value Storage - <AUTHOR> https://mozilla.github.io/firefox-browser-architecture/text/0015-rkv.html <comment><USER2> The page writes that LMDB "is exceptionally fast for our kinds of load", and then links to an in-memory microbenchmark: [http://www.lmdb.tech/bench/inmem/](http://www.lmdb.tech/bench/inmem/)

Aren't they interested in persistence of the key-value data? In my experience, once data is persisted to disk or SSD, LMDB is way slower from alternatives because it needs to operate in synchronous mode to avoid corruption (effectively flushing to disk after after every transaction committed). If operated in the non-default MDB_NOSYNC mode (which is the mode chosen in the above benchmarks), then there is a high probability to be left with an unreadable database file after a crash, thus losing all your data.

It is not fair to compare with other databases in sync mode, since they might operate safe but faster in async mode. For example sqlite with PRAGMA journal_mode=WAL and PRAGMA synchronous=NORMAL can operate in semi- asynchronous mode (fsync()ing sporadically) without fear of corruption in case of crash, because it keeps a WAL journal and is able to properly roll-back after a crash. This should be much faster than LMDB's default-and-safe synchronous mode, that msync()s on every value written.

<comment><USER3> We have only ever compared LMDB in synchronous mode to other DBs in synchronous mode, and LMDB in asynch mode to other DBs in asynch mode. Come on, that's too obvious.

And LMDB beats the crap out of SQLite, in any mode. [http://www.lmdb.tech/bench/microbench/](http://www.lmdb.tech/bench/microbench/)

Replacing SQLite's Btree engine with LMDB makes the SQLite footprint smaller, faster, and more reliable too. [https://github.com/LMDB/sqlightning](https://github.com/LMDB/sqlightning)

<comment><USER2> It's not that simple. What you mean by saying "(a)synchronous mode" is very different from database to database. See my above comment. Is SQLite synchronous or asynchronous if you configure it as journal_mode=WAL and PRAGMA synchronous=NORMAL?

For my purposes as an application developer, I care about comparing databases operating in _safe_ mode i.e. a system crash should never cause total data loss. According to my experience SQLite's safe mode is many times faster than LMDB's safe mode, with a write workload. While LMDB is thrashing the disk and achieves only a handful of write transactions per second.

<comment><USER3> SQLite's safe mode is not comparable to LMDB's; SQLite is vulnerable to silent data loss in a crash.

[https://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.p...](https://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf)

LMDB is not.

<comment><USER2> Isn't this from the paper "all filesystems are not created equal"? [1] If you search the tables for "sqlite-wal" you will see that it shows zero vulnerabilities.

[1] [https://www.usenix.org/system/files/conference/osdi14/osdi14...](https://www.usenix.org/system/files/conference/osdi14/osdi14-paper- pillai.pdf)

<comment><USER3> Ah, the earlier result was for SQLite-rollback, their default mode. IMO any DB should default to its safest mode.

</comment></comment></comment></comment></comment></comment><comment><USER4> Didn't they review badger from dgraph.

[https://github.com/dgraph-io/badger](https://github.com/dgraph-io/badger)

Here is the comparison back in 2017: [https://blog.dgraph.io/post/badger-lmdb- boltdb/](https://blog.dgraph.io/post/badger-lmdb-boltdb/)

It supports concurrent ACID transactions with serializable snapshot isolation (SSI) guarantees.

</comment><comment><USER5> Hopeful this goes better than WebSQL. WebSQL ran into standardization problems because they started with an existing implementation (SQLite) instead of a spec as their base implementation--meaning anyone making a greenfield implementation would need to implement all the quirks of SQLite to be compatible with other implementations. Sadly it died as a standard and we were stuck with either local storage or indexdb.

<comment><USER6> There is no intent to standardize this or expose it to the web. This is purely for use internal to Firefox. Of course that may end up meaning that it is used as the internal storage for some web feature.

<comment><USER5> The first sentence on that page says "We propose the standardization of a simple key-value storage...usable from JS, Java, Rust, Swift, and C++"

I assumed this meant an API callable from webasm/js. Did I miss something?

<comment><USER5> Ah, found my error:

"Not-yet or never goals for this proposal are:

Standardization via a standards body as a web API."

So this is "internal" stuff I guess.

<comment><USER6> Poor wording perhaps. There are a bunch of places in Firefox that use key- value stores, this proposes standardising on one type of store.

</comment></comment></comment></comment></comment><comment><USER7> I'm really surprised LSM trees didn't get more commentary. 'All are targeted at server workloads' \- sure, but they're also incredibly popular and appear to be as close to the 'one-size-fits-all solution for storage' as we've found.

<comment><USER8> Also typically more complicated and require a separate compaction process. They're good for writing lots of data, but not so great for random reads.

<comment><USER9> Author of Badger here. Our design of separating keys and values has gotten us incredibly fast writes, while still keeping the read latencies neck-to-neck against B+ trees. Worth checking out: [https://github.com/dgraph- io/badger](https://github.com/dgraph-io/badger)

<comment><USER10> Badger looks nicely done! Did you end up needing to change much in implementing Badger from what was described in the WiscKey paper?

</comment></comment></comment></comment><comment><USER11> In case someone involved in this reads this thread: the document does not specify which LMDB version you tested. I suggest you run your tests with the `mdb.master` branch, i.e. the work towards a future 1.0, and not the stable 0.9 branch. The answers to several of your interrogations will depend on that: with `mdb.master` you can use the VL32 mode which greatly improves usage on 32 bit platforms, and Windows support is much better.

Regarding NFS: I have recently started testing LMDB on NFS v4 and had no issues so far, but with a single process using the database. AFAIK the warning at [http://www.lmdb.tech/doc/](http://www.lmdb.tech/doc/) is only for multiple processes using the DB concurrently. I am still not entirely sure there won't be any mmap-related issues, but so far so good.

Regarding "being careful": this is a very important point. The LMDB API does not hold your hand, it lets you do dangerous things which will result in corruption of your database, which you will discover too late. I suggest writing a wrapper around the API to ensure you are using it correctly. (I wish there was a compile flag like LUA_USE_APICHECK [1] for LMDB, which could help detect problems like this, but there isn't.)

[1] [https://www.lua.org/manual/5.3/manual.html#4](https://www.lua.org/manual/5.3/manual.html#4)

<comment><USER3> The main reason for that warning about NFS is that people will try it, see that it seems to work, and then get careless and try to use the same DB from two different hosts at once. It's inevitable when you're working on files living on networked filesystems, and it cannot work. NFS doesn't offer any cache coherency guarantees, and the mutexes used for synchronizing writers only work on the host that created them.

Not sure what you're talking about re: the API letting you corrupt your database.

<comment><USER12> If we're using lmdb for something that's largely or entirely read only, how viable is using it on NFS with (shudder) lock files or something like that?

<comment><USER3> If it's 100% read-only, you could probably use it safely. Make sure its filesystem on the NFS server is mounted read-only, and obviously all the clients' NFS mounts must also be read-only. As for "largely read only" \- if there are any writers at all, all bets are off.

LMDB automatically detects read-only filesystems, and turns off its locking in that case, so it should perform as well as anyone could expect NFS to perform.

</comment></comment></comment></comment><comment><USER13> I have a layman question if somebody could please answer. I have never in my entire life seen databases fail. But db failures and issues seem to be brought up all the time. Now I understand that part if this maybe the cost function associated with them. But I'm sure there's also something that I have no clue about. So my questions are:

1) what kind of problems do databases actually face.

2) what kind of scenarios create those problems.

3) how does a programmer go about testing them?

<comment><USER14> The easiest scenario to imagine is a hardware failure or power outage. The database was in the middle of doing something, and then was prevented by a hard drive dying or the lights going out. One way to test such a thing is to literally unplug the computer to see how it handles the failure.

So, let's say you have a client/server application... the client is telling the server (database) to write some records to the database. In the middle of the write, you pull the plug. Some questions you'd want to know: what does the database look like when it restarts? Can we read it? What is the current state? Did any of the new data get written? What does the client think was written? If there was an uncommitted database transaction, was the database left unaltered?

It's just as important to test the client in these scenarios. While the server may have crashed, what does the client think happened? Was it waiting for an ACK or "OK" message? Did it get the message? If the update failed, what does the client do in that situation?

Things can get even more complicated if you're thinking of replication across different servers. If one of the servers fails, how does the replication work? Do sessions fail over to other servers? How many servers are required? If there was a corrupted record, did it propagate or was it scrubbed?

<comment><USER13> Thank you for explaining so well and clearly!

To you and others, are there any other scenarios too that happen in production?

<comment><USER15> Enough material here to scare anyone about databases

[https://jepsen.io/talks](https://jepsen.io/talks)

</comment></comment></comment></comment><comment><USER16> This doc says LevelDB has no transacion, thats not true, they have batch writes and LEVEL-DB is not implemented in Go. Its implemented in CPP

<comment><USER17> Transactions let you perform any series of SQL commands with various expectations around data safety and locking guarantees depending on isolation level.

Batch writes provide a tiny subset of the full possibilities of transactions. While sufficient in many cases, that cannot be generalized to "LevelDB supports transactions".

<comment><USER18> That's just your pet definition of transaction. That is not universally accepted.

<comment><USER19> I would love to see an example of someone actually knowledgeable about databases who has a different definition for transaction.

<comment><USER20> Atomicity, consistency, isolation, durability.

[https://en.wikipedia.org/wiki/ACID_(computer_science)](https://en.wikipedia.org/wiki/ACID_\(computer_science\))

But that's just like, the industry's opinion, man.

<comment><USER19> Maybe I completely misunderstood the parents description of a transaction, but that was exactly what they were saying.

</comment></comment></comment></comment></comment></comment><comment><USER21> This is a great example of how to conduct a technical design review.

</comment><comment><USER22> I see their have some questions (like how good is the windows and android support) that are not answered? or only internally? I think will be good to see what them found.

<comment><USER3> Windows and Android are fully supported, have been for years. As are iOS and MacOSX and all the BSDs.

<comment><USER22> Thats great to know, and I suspect that. But what I'm saying is that them ask some valid questions but where are the results of their findings?

Because if I read this, I could conclude LMDB could have troubles in that areas...

</comment></comment></comment><comment><USER23> Curious about how this compares to TiKV...

</comment><comment><USER24> It really sounds like they should take a look at this:

[https://github.com/LiveAsynchronousVisualizedArchitecture/si...](https://github.com/LiveAsynchronousVisualizedArchitecture/simdb)

"One appealing aspect of LMDB is its relative ease of use from multiple processes, above and beyond its basic capabilities as yet-another-fast-key- value-store."

simdb is only lock free and thread safe. While LMDB is benchmarked at around 10k writes, this should be able to do millions of mixed reads and writes with 4 modern cores. LMDB seems to use a separate lock file to sync multiple threads/processes. The only catch here is that the keys aren't sorted, which doesn't seem to be a requirement of theirs.

</comment><comment><USER25> LMDB is awesome, can't tell how many times I've wished to have access to it from the browser...

</comment><comment><USER26> How does this compare to Redis?

<comment><USER27> Redis isn't embeddable, but a standalone server application, and thus it's not really the same space.

</comment></comment><comment><USER28> Bring back Mork!

 _ducks_

<comment><USER29> Mork actually sucked even as a key-value store. It's only decent if your requirements are a) only lookup on a fixed, autoincrement integer ID, b) the only operation you're likely to do is load an entire record or store an entire record at once, and c) parallelism is not in your vocabulary.

Disclaimer: I'm one of the last people to make functional changes to mork.

<comment><USER30> That's not a "Disclaimer". It's actually the polar opposite... a "Claimer"? ... I think "Source" is the best word to use there.

<comment><USER31> Welcome to the war, majewsky.

[https://news.ycombinator.com/item?id=17607457#17618288](https://news.ycombinator.com/item?id=17607457#17618288)

<comment><USER30> Hah! :) I've been meaning to call out other misuses of "Disclaimer" vs. "Disclosure" before, but I usually don't because it's just tedious.

</comment></comment></comment></comment></comment><comment><USER32> Seems like an instance of reinventing the wheel ...

<comment><USER33> From the article:

"We propose 'buying', not building, the core of such a solution, and wrapping it in idiomatic libraries that we can use on all platforms.

We propose that LMDB is a suitable core (see Appendix A for options considered): it is compact (32KB of object code), well-tested, professionally maintained, reliable, portable, scales well, and is exceptionally fast for our kinds of load. We have engineers at Mozilla with prior experience with LMDB, and their feedback is entirely positive."

</comment></comment><comment><USER34> Why do they make this proposal? What does that mean?

<comment><USER6> It's a proposal for making use of a new storage engine to store Firefox internal data.

</comment></comment><comment><USER35> I thought that the issues like this would be blocking:

[https://stackoverflow.com/questions/44407659/how-to- force-64...](https://stackoverflow.com/questions/44407659/how-to-force-64-bit- lmdb-to-generate-a-32-bit-database)

Who knows how it should work on 32-bit systems?

And isn't endianess also a problem? And doesn't SQLite solve both problems by default? And isn't also possible to configure SQLite to be very fast, if one know what he's doing?

Btw I'd expected that the "notes here" [https://docs.google.com/document/d/1bwbpqPb58a0GcEyB4W424pyf...](https://docs.google.com/document/d/1bwbpqPb58a0GcEyB4W424pyftPFiZBSvxxp_0uuN-z0/edit) are conclusions, but the document seems to be not publicly accessible.

<comment><USER36> According to @hyc in [https://monero.stackexchange.com/questions/2606/are-the- lmdb...](https://monero.stackexchange.com/questions/2606/are-the-lmdb-files- cross-platform-compatible/2607#2607), "As of v0.10.0, yes the LMDB files are cross-compatible between 32 and 64bit architectures. They have always been cross-compatible between OSs. They are still byte-order dependent but almost everyone uses little-endian CPUs these days so it's not much of an issue."

<comment><USER35> So the endianness answer is, from your link: "They are still byte-order dependent but almost everyone uses little-endian CPUs these days so it's not much of an issue." Which just means "we solve the problem by ignoring it completely."

And what about the limitations on the 32-bit system? Isn't there also needed to use memory space of RAM for the complete size of the database, that's how that database works if I understood? Which makes LMDB effectively unsuitable for 32-bit systems:

[https://stackoverflow.com/questions/52862176/lmdb-open- large...](https://stackoverflow.com/questions/52862176/lmdb-open-large- databases-in-a-limited-memory-system)

"your user will need to either enable PAE on their system, or upgrade to 64-bit CPU. If neither of these is an option in your application, then you cannot use a memory mapped file larger than your available address space"

In short it still looks that LMDB is designed effectively only for one- endianness and only for 64-bit systems, which is still limiting for many use cases.

Again, it seems that for LMDB is again "solving" the problem by ignoring it. Which is OK if it fits your use case... But shouldn't Firefox work properly on 32-bit systems? Or did they completely decide that they don't want to target any 32-bit platform anymore?

Moreover, there are use-case scenarios where the memory mapped file approach can suffer from problems of unnecessarily reading the page that will anyway be completely overwritten. My conclusion is... if LMDB "works for you" fine, but do properly your research first. I still believe SQLite covers much more use cases and is safer starting point for many of them, including Firefox use cases, until I read that they really decided to reduce these.

<comment><USER37> The last issue is merely one of performance, not capability.

I've successfully used LMDB in 32-bit land, though it takes some effort. I had to scan available virtual memory for the largest contiguous chunk and use that.

Bigger issues are growing the database size and performance in low memory. No transactions can be running to increase the map size, which is usually hard to coordinate.

Also, in low memory situations, LMDB's performance suffers tremendously. It can be 100x slower, and commits can take seconds. You won't run into it unless you are really hammering it, and the developer usually won't notice because they usually have lots of RAM.

<comment><USER3> Fwiw, we've benchmarked on Raspberry Pis with slow SDcards. You want to talk about low RAM situations and slow I/Os. The reality is still the same though - every other DB engine is many times slower under the same conditions.

Even when the DB is 5x or 50x larger than RAM... [http://www.lmdb.tech/bench/hyperdex/](http://www.lmdb.tech/bench/hyperdex/)</comment></comment></comment></comment></comment>


Promoting Health and Longevity Through Diet - <AUTHOR> http://www.cell.com/cell/fulltext/S0092-8674(15)00186-5 <comment><USER2> Definitely a lot more research required here but I think the intermittent fasting research is pretty interesting and promising. Particularly with the result that dietary restriction achieved by nutrient dilution rather than fasting didn't extend lifespan (Solon-Biet et al., 2014). Easy to imagine that our ancestors didn't have access to food all the time and our metabolisms are geared to fast periodically.

In the mean time I'll probably stick with the Michael Pollan approach to diet - 'Eat food. Not too much. Mostly plants.'

<comment><USER3> If looking into the state of intermittent fasting, the work of Valter Longo is probably a good starting point. His group is presently trying to get intermittent fasting past the FDA as a part of cancer treatments, which means he is doing more rigorous and more human-focused studies than most other groups I'm aware of.

[http://michelsonmedical.org/2014/12/26/igf-1-fasting- discuss...](http://michelsonmedical.org/2014/12/26/igf-1-fasting-discussion- valter-longo/)

</comment></comment><comment><USER4> I'm disappointed that the dietary interventions did not include a ketogenic diet as there has been recent evidence that such a diet is competitive with caloric restriction in terms of life extension (and would not suck so bad to actually practice).

[http://www.the- scientist.com/?articles.view/articleNo/42273/...](http://www.the- scientist.com/?articles.view/articleNo/42273/title/Nourishing-the-Aging- Brain/)

<comment><USER5> For all we know, calorie restriction is effective _because_ it is ketogenic almost by definition. It wouldn't be surprising considering how much overlap there seems to be between the benefits of ketosis and calorie restriction in general.

[http://www.amazon.com/Principia-Ketogenica-Compendium- Litera...](http://www.amazon.com/Principia-Ketogenica-Compendium-Literature- Carbohydrate-ebook/dp/B00N0KGKNI)

</comment></comment><comment><USER6> Could somebody summarize this into a diet description that anybody could understand?

<comment><USER7> This paper seems to be a hodgepodge of anything that might have potential to extend life, but mostly calorie restriction. My take is that I'd rather not eat only 1,000 calories a day for the hope of living 2-5 years longer. Its just not worth it to me, especially when you understand the typical quality of life during those last couple years.

Interesting how there's so little discussion nowadays about dying with dignity, but tons of spilled ink about living longer. Quality of life is often dismissed totally or just seen is irrelevant to the research.

I find the teen and twenty-something crowd being big on this, but the 40 and over crowd being pretty lukewarm toward life extension. I imagine the latter crowd have seen their own parents and other close relatives reach end of life and pass away, and want nothing to do with extending those last few years.

<comment><USER8> It seems that dietary restriction can also improve quality of the final years. From the paper: '[Dietary restriction] can produce substantial benefits with, for instance, 30% of DR animals dying at old ages without gross pathological lesions, compared with only 6% of ad-libitum-fed controls'

<comment><USER7> Lesions are one thing but cancer, Alzheimer's, Parkinson's, bone loss, hip replacements, limited mobility, limited cognition, limited memory, limited hearing/sight, chronic pain, etc are whole other things.

<comment><USER3> Lesion means any tissue damage at any scale in this context.

</comment></comment></comment></comment></comment><comment><USER3> HTML rather than PDF:

[http://www.cell.com/cell/fulltext/S0092-8674(15)00186-5](http://www.cell.com/cell/fulltext/S0092-8674\(15\)00186-5)

<comment><USER9> Thanks; changed from [http://www.cell.com/cell/pdf/S0092-8674%2815%2900186-5.pdf](http://www.cell.com/cell/pdf/S0092-8674%2815%2900186-5.pdf).

<comment><USER10> Can you also change the title to "An Error Occurred Setting Your User Cookie"?</comment></comment></comment>


Theory and reality for storing personal information - <AUTHOR> http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=320272 <comment><USER2> I have a friend at UCI who got bitten by this.

The problem is that the financial burden of identity theft too often seems to hit the affected rather than the companies responsible. If UnitedHealthcare had to pick up the full tab for resolving the problem, then they might see the value in investing in a better system down the road.</comment>


Turning the Optical Fiber Network into a Giant Earthquake Sensor - <AUTHOR> https://spectrum.ieee.org/view-from-the-valley/at-work/test-and-measurement/turning-the-optical-fiber-network-into-a-giant-earthquake-sensor <comment><USER2> >A single interrogator can cover some 40 kilometers of fiber, Biondi says, and monitor a virtual sensor every couple of meters.

Earthquake engineer here. This is the cool part. We've got plenty of data to detect and locate any given earthquake occurred. And we have maps that show approximately how hard the soil is under any given site. But the intensity that any building sees is still only known to +-50%, mostly due to variation in the subsurface conditions that we don't have enough resolution to model.

<comment><USER3> Would higher resolution detectors also help us develop better models for prediction?

<comment><USER4> We're not currently able to predict the actual earthquakes at all, only probabilities of likelihood on very large timescales. I could see it being useful to predict future damages to certain buildings/areas based on existing data, assuming an earthquake happened.

</comment></comment></comment><comment><USER5> I've heard that internal buses in high performance aircraft also use time- domain reflectometry such as this to detect wiring faults before they interrupt service.

<comment><USER6> Every now and then I get a bit cynical about technology. Then a phrase like this appears and I am in awe again.

</comment></comment><comment><USER7> > _An "interrogator" installed at one end of the line sends pulses of laser > light into the fiber and monitors the light that bounces back—the > backscatter. Changes in the timing of backscattering occur when the fiber > stretches and contracts—something that happens when the ground moves during > an earthquake._

Ping-based earthquake detection? Could ping jitter of existing optical networks be used for this purpose?

I had never thought about thermal and mechanical expansion of fiber optics - it's in the same vein as LIGO/VIRGO - could we one day see a fiber optic network used for both data transmission and gravity wave detection?

(I once ran fiber about 200 feet through a welding shop, to connect an ancient PlasmaCAD to a null modem. But we couldn't get the fiber in a spool of less than 500 feet, so it was mostly a spool in the office.)

<comment><USER8> Ligo/Virgo uses a number of extraordinary means to cancel out things like earthquakes or rumblings, local vibrations and so on. But I wonder if you had 1000's of mile of fiber in disparate parts of the world if it would be possible to cancel out the noise and see gravitational waves? Probably not, shrug. But still I find it a fascinating thought. Also, cool idea to measure earthquakes.

<comment><USER7> One team's signal is another team's noise?

</comment></comment></comment><comment><USER9> Fiber-Optic Intrusion Detection Systems (FOIDS) are often used in physical fenceline security [0], with permanent installations using hardened conduit or impromptu setups of kevlar-jacketed fiber, zip-ties and concertina wire. It's only natural that longer runs of fiber can be used for similar vibration measurements.

[0] Examples at [https://fibersensys.com/product/fd322](https://fibersensys.com/product/fd322) and [http://senstar.com/products/fiber- optic/](http://senstar.com/products/fiber-optic/)

<comment><USER10> No only that protection of pipeline use the same method of monitoring existing fibers for communication with system like this [http://www.rbtec.com/products/Pipeline-Protection- Security-S...](http://www.rbtec.com/products/Pipeline-Protection-Security- System/RaySenseLeakDetection)

</comment></comment><comment><USER11> What happened with this HDD-based solution? [https://www.newscientist.com/article/dn10037-hard-drive- wobb...](https://www.newscientist.com/article/dn10037-hard-drive-wobbles- track-earthquake-spread/)

<comment><USER12> Everyone switched to SSDs ;)

</comment></comment><comment><USER13> Seems like the possibilities are endless. When Skynet takes over, this is how they will hear us coming to switch them off.</comment>


Cities giving criminals a basic income reduces crime - <AUTHOR> https://www.washingtonpost.com/local/dc-politics/cities-have-begun-to-challenge-a-bedrock-of-american-justice-theyre-paying-criminals-not-to-kill/2016/03/26/f25a6b9c-e9fc-11e5-a6f3-21ccdbc5f74e_story.html <comment><USER2> This might be another reason to try basic income for all in specific cities to see how it works out.

I know a few good people that had to resort to crimes simply because it pays. When you're down to nothing and you're hungry, you're just going to do whatever you can to survive. We need to work on the source of the problem, not the symptoms.

</comment><comment><USER3> Well of course. Danegeld worked as well, for a few years.</comment>


Techzing 38 – Pete Michaud / Retired at 25 - <AUTHOR> http://techzinglive.com/?p=187

<comment><USER2> Can people please stop boasting that they are retiring at 20, 25, etc.?

If you drop out of work and start your own business, you have not retired. Achieving financial independence and not working for other people is great. Retiring is not about financial independence, it's a mindset - not undertaking anything else in your life. If you retire at 25 you are just lazy.

<comment><USER3> This is covered about 32 minutes in. He's "retired" in that he doesn't have to work, but he still does; he just didn't work hard, from his perspective.

</comment></comment><comment><AUTHOR> In my opinion, one of the best Techzing podcasts to date. Well worth a listen.

</comment><comment><USER3> So is his name Pete Michaud or Paul Michaud? They say "Paul" in the title but "Pete" everywhere else, so I'm assuming that it's "Pete".

<comment><USER4> It's peter according to his HN profile: <http://news.ycombinator.com/user?id=pmichaud></comment></comment>


Fresh logos for your startup - <AUTHOR> http://logo-house.co/ <comment><AUTHOR> This design agency gives you discounts on custom logos depending on how much they like your startup idea.</comment>


The One-Time Pad and the Index of Coincidence - <AUTHOR> https://mice.cs.columbia.edu/getTechreport.php?techreportID=1576

<comment><USER2> Friedman's original paper is well worth the read, and toy Vogel implementation if you have time! [0]

[0] waring, pdf: [http://math.boisestate.edu/~liljanab/MATH509/IndexCoincidenc...](http://math.boisestate.edu/~liljanab/MATH509/IndexCoincidence.pdf)</comment>


Great Presentation on MetaProgramming. Talks about pg/ycombinator/lisp/ruby. [video] - <AUTHOR> http://mwrc2008.confreaks.com/03bowkett.html The speaker summarizes Paul Graham's theories on Lisp and startups with the following statement:<p>"Skilled programmers can write better programmers than they can hire"<p>I really enjoyed watching the whole video. Very interesting stuff. Highly recommended. <comment><USER2> You know, I couldn't understand that Lisp code snippet he presented either. He converted this Ruby:

      code == data

to this:

      (eq (code (data)))

What? OK, let's translate that to syntax non-Lispers can understand. That means:

      eq(code(data()))

What? Maybe he was trying to write

      (eq . (code . (data)))

Which is just a horrible, never-used way of writing

      (eq code data)

which in that other syntax would be written

      eq(code, data)

Yet another person bashing Lisp as impossible to understand without making any effort whatsoever to learn what the extremely minimal syntax means.

Another thing. He says that Perl and Lisp have a lot of power, but nothing in the way of simplicity. I take issue with that. Whereas Perl is overcomplex, Lisp is about the simplest you can get. He seems to think that "simple" means something along the lines of "understandable by people experienced in commonly-used programming languages". To that, I says pleh, and also blub.

</comment><comment><USER3> Is Giles saying that with the help of Rubinius you can do Lisp-style code generation in Ruby? I don't know much about Rubinius but this doesn't sound right. Lisp macros let you manipulate the program's AST in compile time very easily because the AST is made of sexp's, just like the program code itself. This is due to the peculiar Lisp syntax. Lisp code generation seems quite different from the monkey patching techniques demonstrated in the presentation. Am I missing something?

<comment><USER4> I didn't take that to be his main point, but yes, I think so. Though I think it would be more accurate to say "Lisp lets you manipulate the program's AST trivially because the AST _is_ the code".

This is basically Greenspun's 10th Law again. There's no magic in Lisp that's computationally impossible in another language, but it might be simpler to just write a Lisp in that language first. Rubinius did something even tougher: they wrote a Ruby. The advantage of this is that it's backwards-compatible with all their existing code, while upgrading to sexps would not be.

I think the monkeypatching corresponds to only the front half of Lisp macros. The macroexpand part comes from making the monkeypatches log Ruby code, and then running the log.

</comment></comment><comment><USER5> It was amazing when they showed a shot of the audience. A quick count revealed 17 macs, and 1 machine that I don't think was a mac, although it may have been a black macbook.

I didn't realize macbooks had become so pervasive in the ruby world.

</comment><comment><USER6> Pretty awesome how tons of really smart people just won't get over their fear of parentheses even when they know the power that's behind them.

As peculiar and different as lisp is, the difficulty of learning it is highly overrated.

<comment><USER5> A quick disclaimer: I'm really a Lisp / Scheme noob, but I'm learning them both for academic purposes.

That being said, at first the parens bugged me a little bit, but as I got to developing more applications, the more I really grew to LOVE the parens. To me, they introduce a certain purity to the programs that I write; it's like every s-expr is a single thought and every function is a train of thinking. Beyond that, an additional benefit that I've found is that I can hold MUCH more of a program in my head when they're organized this way. I think it has to do with the chunking theory of memory - I don't have to remember the particulars of each chunk; just what each chunk did.

Anyways, it's a big enough attraction to me now that I regret not having them available in my day-to-day languages.

<comment><USER7> Yes, parentheses are beautiful. I don't actually like to look at code without them anymore.

</comment></comment></comment><comment><USER8> "great programmers can write better programmers than they can hire"

good talk.

<comment><USER7> You know John Carmack? I wrote him.

<comment><USER9> Did he write back? ;)

</comment></comment></comment><comment><USER10> that example with the audio generation could be done by keeping track of the random seed

<comment><USER11> That's what his example was. Instead of saving 12 hours of generated music, he's logging the data that generated it as instructions on how to generate it.

<comment><USER10> that's still more data than just saving the seed. though maybe he was talking about saving basic things (seed,etc) and when you want to reconstruct them into audio, you basically generate a program instead of an mp3. not really much different than just saving the basics, except it's more shareable and takes up more space

but it didn't sound like that. it really sounded like it never occurred to him to just store the random seed(s) because he said when you hear a great piece in randomly-generated music, it's gone forever, even though the seed is a fundamental and controllable aspect of that

[edit]he said it would generate a log of code which would point back to the generating/generated code. i can't really tell what he was effectively storing though. to reproduce the music well, the seed would have to be in there somewhere, unless it's only in charge of choosing a few discrete items

</comment></comment></comment><comment><USER12> fizzbuzz, oh my!

</comment><comment><USER12> Jessica Alba and monkeys!</comment>


Facebook Buys Parse for $85M - <AUTHOR> http://techcrunch.com/2013/04/25/facebook-parse <comment><USER2> this was from April 2013</comment>


Code-signing without Mac..for FREE - <AUTHOR> https://blog.codemagic.io/automatic-code-signing-for-ios-that-doesnt-require-a-mac/ <comment><USER2> Really interesting, but I'd be wary of putting my apple developer username and password out there like that.</comment>


Google got it wrong. The open-office trend is destroying the workplace - <AUTHOR> http://www.washingtonpost.com/posteverything/wp/2014/12/30/google-got-it-wrong-the-open-office-trend-is-destroying-the-workplace/ <comment><USER2> This article has been discussed several times, mostly [https://news.ycombinator.com/item?id=9404006](https://news.ycombinator.com/item?id=9404006) and [https://news.ycombinator.com/item?id=8815065](https://news.ycombinator.com/item?id=8815065).

</comment><comment><USER3> One facet that never comes up in these anti-open office articles is that it is 100% impossible to design the perfect office for you as an individual, for every other individual, all while designing an office that is perfect for the organization.

Many people here advocate private offices, which are great, but as soon as you start putting up walls, you've totally restricted access to natural light in the interior of the building. Access to natural light and breaking down the hierarchy that came with private offices (exterior for high-level employees, corner for the highest) are partly responsible for creating an environment where open office are desirable alternatives.

With all of condemnation for open plan office happening, I'm excited to see what the next swing of the pendulum back toward privacy will bring us. Hint: It won't be private offices.

Some of the things I'm excited about in this regard are:

-Activity-based working office designs

-Increased working from home/telecommuting arrangements

The most important part of office design is to consider your company's culture, and then develop an office that will best support it rather than jumping onto what types of designs have worked for the unique cultures of other companies.

<comment><USER4> As Joel Spolsky noted, getting natural light to a large number of small rooms is basically a solved problem: how many hotel rooms do you see without a window? Sure, private offices are smaller than hotel rooms, but offices generally have large numbers of meeting rooms, labs and common areas that don't need windows.

Of course, that means that you need to build office buildings more like hotels; you can't so easily retrofit existing office buildings.

<comment><USER5> Hotels can do that because their revenue is directly dependent on the quality of their rooms. No hotel can sell rooms without windows, so every hotel has to invest in architecture that gives every room a window--either through exterior convolutions, or a giant hollow atrium to soak up useless interior space.

This is not true of other businesses. A software company makes no money at all from its architecture, so it can gain a competitive advantage by making more dense use of its available office space.

Also: who wants a meeting room or common area with no natural light?

<comment><USER6> Offices should do that because their revenue is directly dependent on the productivity and happiness of their employees. Likewise, no office builder should be able to sell offices without windows.

After all, you'll spend more conscious time in the office than in a hotel room.

</comment></comment></comment></comment><comment><USER7> SAP star building in Germany headquarters are a good example of what to do with office spaces:

[http://2.bp.blogspot.com/_gOgdHlT33Jo/TQ7zXFqaxjI/AAAAAAAAAJ...](http://2.bp.blogspot.com/_gOgdHlT33Jo/TQ7zXFqaxjI/AAAAAAAAAJA/zS6O1oE5zSU/s320/IMG01473-20101217-1045.jpg)

[http://www.mz- web.de/image/view/2012/4/23/17117282,16301136,...](http://www.mz- web.de/image/view/2012/4/23/17117282,16301136,dmData,maxh,480,maxw,480,SAPZentrale+%25281334258355914%2529.jpg)

[http://www.donfeidner.de/assets/images/P1000400_SAP_Star_Bui...](http://www.donfeidner.de/assets/images/P1000400_SAP_Star_Building_2.jpg)

The wings have offices which can sit 6 to 8 people and at the center there are the meeting rooms, restrooms and lunch area.

<comment><USER8> Group spaces are quite prevalent in Germany from what I can tell. It makes total sense, in Germany. There is a bit of a difference in the USA though, where employers think you get productivity out of surveillance. We are not a very deeply thinking society, so it makes sense on the face of it that if you can see people working they are being productive. What we miss though, is that all the surveillance and lack of protections and benefits leads to massive amounts of squandered energies and effort on busy work. Busy work is work that is noise which serves a couple different types of purposes. It can make you look like you are working because you are working on something; whether it is relevant, important, or useful is totally irrelevant though. It can serve to make the system as inefficient as possible in order to assure job security. There are other purposes but those are some of the most prevalent.

At the core of the problem lies a misunderstanding of the problem that open plans are/were meant to address and can also be tied back to our problem with management models and incentives in our corporations and society.

It's a complicated matter that I can't do justice here, but if you have incompetent management trying to satisfy abusive demands from "investors" aka Wall Street, incompetent management leads to believe the problem of gaining ever more "productivity" out of a corporation and workers is solved by squeezing ever harder to get that last drop out. Which incompetent management and incentives lead them to believe can be done by putting everyone in a big open space so they feel surveilled and monitored and will do what they can to appear like a good worker by doing busy work and staying longer doing. This is largely all due to a system without employee protections where anyone in the 99% can be fired at a moment's notice because some executive screwed up or needs to be paid more.

It's more obviously presented as exercise metaphor, but the following post about "Why Productive People Always have Time to Exercise"[http://riskology.co/sharpen-the-saw/](http://riskology.co/sharpen- the-saw/) also applies to these types of circumstances.

On a side note: Why the hell doesn't HN support markdown? The site's already kind of embarrassingly styled, it's shameful that you can't even link somehow.

<comment><USER9> > _The site 's already kind of embarrassingly styled_

That's kinda subjective; it looks fine to me, although I do miss contextual linking and collapsible comments (a la reddit) - although, this is something they're working on.

<comment><USER8> I'm referring to the fact that it's not responsive and does not scale without zooming.

</comment></comment></comment></comment><comment><USER10> They should switch to libreoffice. Fixed everything for me.

<comment><USER11> lol

</comment></comment><comment><USER12> The first 2 startups I worked for back in the early 2000's were open offices, though there were only 6 of us in one room at the first startup, and 3 at the other.

At the first startup, thankfully, customer service was in an open office in another part of the small building. Couldn't imagine having to work next to those conversations.

In the first company it wasn't so bad, we had all our computers circled and pointed toward the center (mostly) which afforded us a little bit of privacy at least, but it was awkward looking up to have a thought and making eye contact with a fellow coder across from me. Though sometimes it was funny. I think the hardest part was the distraction of being the end-point for anyone's conversation at any time they felt like talking to me - no matter how good a coding groove I was in. Or maybe it was having to listen to 2 other coders figure out a problem together in the same office where I was trying to work. Hmm. Either way, I prefer private offices.

At the next startup I went to, the computers faced the wall in the office. It was designed this way so the management could look over our shoulder all day long. Needless to say, I quit within months. Constantly being questioned why I was working in a certain file, or viewing part of the project's website that the boss didn't understand made me cringe. I'd go home grumpy everyday. I'd eat in my car at a creepy park across the street just to get away from the place. It was awful.

Worked for myself ever since. In an office.

<comment><USER13> I do wonder sometimes, if all the startups that followed Googs lead into open offices have been pranked, much like the interview folks who blindly followed Googs wacky and wanky interview questions, which have also been shown to be a useless idea. There is probably a pranks team in Goog that publicises the ideas to see who will blindly follow.

</comment></comment><comment><USER14> I truly dislike open offices. The constant sound of mechanical keyboards clacking really gets to me, and I'm not sure why. I wear headphones listening to loud music to cancel out the sounds of these damn keyboards.

<comment><USER15> Then there is the open plan office, combined with the clean desk policy. That way you have to endure the inane yacking going on around you and god forbid you try and figure something out on a piece of paper while you're working and go grab a coffee without locking said piece of paper in a drawer or it's a written warning.

I hate the modern corporate office environment. HR should just be upfront about what open plan offices are about: saving money. It lets you cram in as many people in as small an area as possible. That's it. Nevermind if they're productive or not. We're SAVING MONEY!

<comment><USER16> This idea that open plan offices are about saving money needs to go in the bit bucket. If it was really about money, they'd have people working from home, which offers far greater cost savings. It's not about money, it's about power, the visible display of subservience.

<comment><USER17> I'd say it's both. Starting with the constraint: Employees must be in the office, so I know they're working, the cheapest option is an open plan.

</comment></comment></comment></comment><comment><USER18> I fully agree. I currently work for a startup and after we moved into a new office last month our management had the glorious idea of putting the programmers next to the customer support team in an open office :/

It's horrible - I have to endure the customer support calls the whole day long and can't find even 5 min. in silence, in order to concentrate on the programming tasks I'm supposed to do. I tried putting on headphones and listening to white noise etc., but that doesn't cut it either. I need silence to work efficiently and it's been that way ever since I cam remember. My productivity has absolutely tanked in the open office and coming this Friday, I will quit the job and spend the coming weeks getting back into self- employment and working from home.

<comment><USER6> Have you at least provided feedback to the managers? Like cold, hard feedback "I cannot work like this, I and my colleagues are going to quit and you're fucked when we do" kinda feedback.

<comment><USER19> No one ever does this, unfortunately. Getting a group to band together and threaten collective action is something few people even consider - most people I know are scared of entertaining that idea.

<comment><USER20> It's not about making a collective threat, it's letting management know that the new conditions are making you consider options "up to and including departure", and that you think the other devs may be in the same boat.

<comment><USER21> Just make sure you don't talk for other people (for example naming your peers). Otherwise i strongly agree.

</comment></comment></comment></comment></comment><comment><USER22> Everybody needs a balance between productive alone time and creative brainstorming time. Most companies I've seen achieve this with an open space and plenty of WFH for all employees.

Basically we meet 2-3 times a week to organize and share ideas, and spend there rest of the week heads down at home, coding in whatever pace and setting we like.

Closed private offices enable people to slack at work and pretend to work 80h week while actually dozing off most of the day. I'm not saying everybody does that, but it's certainly a possibility and something I have observed few times. Once I was tasked with "doing something about" a manager who played competitively StarCraft at work.

In reality that's a symptom of a larger issue, where we are (consciously or not) evaluated on how long we stay at the office over how productive we are. IMO it's nobodys business if I play StarCraft at work, as long as it helps me, or doesn't prevent me from achieving my objectives.

<comment><USER23> I would argue that if you cannot restrain yourself to be productive in a closed office, why would you be it from home?

That said, I agree, evaluating on time at the office is the wrong metric, but for the vast majority of managers, they have no idea how to evaluate it otherwise because they do not understand the tasks at hand.

<comment><USER22> At home nothing prevents me from not working and I often don't. The difference is, at home you can spend your time with a book, cooking, with kids or spouse - which all is refreshing and in general will improve your performance once you get back to work.

In the office not working constitutes mostly of playing dumb games or reading hacker news, the latter being kind of ok, but certainly it doesn't leave me refreshed and willing to go back to my not-so-hip-after-the-latest-js- framework code.

I don't think it's realistically possible to put a metric on one's performance, that would allow us to break from time-based evaluations completely. That being said, I see how my colleagues are progressing with their work and it has nothing to do with which are working from home, which from office and there is also no clear time-value correlation either. It has more to do with how motivated they are, what internally drives them and how skilled they are.

I have a friend at work who believes deeply in software craftsmanship principles and it's a privilege to see how he works. He stays at home more than most of us, but provides a steady and consistent stream of small, high- quality pull requests, all day, every day. I watch how not slacking at work can have a great impact on the project and on the team morale. It has very little to do with an open space, WFH, what kind of laptop you work on and what blend of coffee you are given. I grew to believe those are just excuses I (and others) are giving themselves to not fully focus on work. Once I admitted that to myself, I decided to spend my slacking time in a way that improves my performance later. I hope one day it will go away completely, or I will get organized enough to be consistent in my output regardless of interruptions.

</comment></comment></comment><comment><USER24> The author's argument is basically "I don't like open offices, so they're bad." Yawn.

I would have liked to see some studies on actual productivity level fluctuations based on these moves.

Otherwise, it's simply another variation of "I'm not used to it, so it's bad."

<comment><USER25> Study after study show that open distraction office plans are bad for productivity, and increase stress and sick days -- even among those who like open office plans.

<comment><USER26> Your links to the studies aren't clickable.

<comment><USER27> It's kinda tiresome, on HN there's is this rabid pro-open plan brigade, even though all the studies show otherwise.

It's the same as the "I can work 60 hours productivly" brigade. All the studies, for over a century (yes, century, not decades) have shown otherwise. They are studies that show that people delude themselves into thinking they are more productive than they are. And yet, no matter how many articles and papers you post, nope.

HN insists.

They are ingrained memes on HN that won't, despite all the evidence you ever post, go away.

So why bother? You can google it yourself, and then promptly ignore all the professional studies and still believe in open plan offices. It's simply not worth the effort.

<comment><USER28> It's a conspiracy, and you have proof of this. But are reluctant to show us as we wouldn't believe you anyway.

Interesting.

<comment><USER27> It's not a conspiracy, what tend to happen is you post a bunch of articles and then the parent starts picking at 1 point in 1 article as if that invalidates all of them and you get drawn into this long tiresome discussion with what is nothing but a crackpot using loads of anecdotes or worse, blog posts, against large scientific studies. And quite often it's nonsense any way, they just misunderstand it.

For some reason working conditions and working hours are incredibly emotive subjects, similar to women in tech, that tend to bring out the irrational side of otherwise lucid HN posters.

</comment></comment></comment></comment></comment></comment><comment><USER29> We get it, HN is majority introvert, and really likes logical optimization using data.

But some things aren't easily measurable. Is it a coincidence that companies who pioneered the open office plan are also some of the most successful in the world? Show me how you'd even begin to disprove that and I'll show you a dozen confounding variables making it silly to even try. What is the true impact of an open office on a culture of collaborative interaction? And what's the impact of that type of interaction on success? Hard to measure.

Sometimes we look at the things we can easily make into numbers and assume they describe the whole truth. Not always so.

"The most important things are unmeasurable." —W. Edwards Deming

<comment><USER30> Surely you don't actually need to measure anything. Just ask people what they prefer.

And to be fair, I've met people, online and off, who legitimately like open offices or would prefer a hybrid. But I've met roughly an order of magnitude more people who don't like them at all and just want a quiet, personal space.

And you're right, there _are_ a lot of confounding factors when you look at companies like Google. For instance, I'm sure the prospect of getting filthy rich was pretty enticing for early employees, who probably found the work conditions nearly irrelevant in comparison. Same thing goes for Facebook. There's a well-known notion that some companies are just so successful so fast that they can basically do anything in terms of office dynamics and it will work for them. This is commonly applied to Valve's management strategy (or lack thereof).

Also, you could fairly easily argue that both Google and FB met with the majority of their success _before_ they engineered massive open office farms. You could also fairly easily argue that both have been doing a pretty mediocre job lately, with some successes but lots of failures, mostly just maintaining their status (especially Facebook, in my humble opinion).

I'd imagine that the more upside there is for employees, and the more empowered the employees are in general, the more they'll tolerate and perform well in an open office on average.

<comment><USER31> I've found asking people to be notoriously unreliable. Folks want quiet and comfort, sure. But is that the best thing for productivity?

Ok, in this case, probably. But standing desks are apparently a good thing, and the vast majority of us eschew them. And so on. Anything that seems like an inconvenience gets demonized as a rule. So just asking is a minefield.

<comment><USER30> I get what you're saying, but I think there's an easy solution: just ask people who've experienced both. That way you're not experiencing the classic but very real problem of people not knowing what they want until they've got it.

At my workplace, for instance, not once in the history of the company has anyone with an office _ever_ given it up, under any circumstances, to move into a cubicle again. Likewise, someone with a cubicle next to a window has never, in my tenure at the company, moved to a cubicle not next to a window.

As for standing desks, I didn't realize that people actively eschewed them. My impression is just that they're impractical for a lot of people to actually obtain. If your workplace doesn't provide them and won't on request, your options get sort of limited. I have a coworker who made a makeshift standing desk but it's not very ideal. I imagine a ton of people are in this situation.

Ok, but let's suppose that, by some ingenious study, you're able to determine that nobody prefers the open office, everybody prefers private offices (quite strongly), and yet productivity for the company is better with an open office. That's pretty counter-intuitive, but the world is filled with counter- intuitive things. Does that mean that companies should all switch to open offices?

Should a company do something _just_ because it can be shown to increase productivity? I don't think that's necessarily the case. For instance, it might be that the productivity gain is somewhat minimal and that over the years a number of great employees are lost (or not able to be hired) due to the office layout. So in that case the illusion of temporary increased productivity will lead to a long-term net decrease in productivity.

<comment><USER29> That was my point. There are a lot of things that we measure (eg: productivity) when we should actually be looking at larger goals.

In this case, an open office creates a certain type of culture and work environment. That might be desirable for the company as a whole, even if it's suboptimal for some individuals, and even if certain measurements at a low level are against it.

<comment><USER31> I buy that, for some companies. As a developer, I can tell you that my productivity is shot/reduced 90% by a noisy open environment. So I always find a company that needs my skills, and houses me appropriately to capitalize on those skills. If I'm a low-level measurement that the company can do without, so they put me in open plan anyway, I'll leave.

</comment></comment></comment></comment></comment></comment><comment><USER32> Just a different opinion here. I have never worked in a single office space. I honestly can't imagine such a thing. But I do know how incredible good I am at distracting myself at home.

Just having someone around, who are working on a different piece of the same puzzle is a major motivator.

<comment><USER33> Apparently you indeed have never worked in an office space. Because it's approximately 10% "working on a different piece of the same puzzle", and approximately 90% "talking about 'Age of Ultron' at top volume for hours straight".

<comment><USER34> Yep more distracting that having executive jet engines being tested out side your office (I used to work on campus at cranfield)

Though being able to go and watch the spitfire they rebuilt being demoed was really cool.

</comment></comment></comment><comment><USER35> Not to mention the situation in a startup where the tech team is sitting next to the sales and marketing teams who are constantly on the phone.

</comment><comment><USER36> At my current workplace, we have a shared room for the developers and designers (5-9 people depending on the day and time), while the rest (~20 people) are spread in other bigger open spaces. I find that it works well, because we are mostly stationary and focused on a specific task, while the rest (sales, marketing, customer development, etc.) are constantly moving around, in meetings, visiting customers.

In a mostly-tech company I couldn't imagine not having some compartments so that you don't suddenly find yourself 1 among 30 people in the same room - I'd go completely insane.

</comment><comment><USER37> Is this open office = for work of a highly creative and collaborative nature, the team owns their own workspace, which they customize as they choose, and folks on the team are in physical proximity?

Or is this open office = packing everybody into one huge area like sardines no matter what their job role or what their team is doing with little or no account for ownership?

I find we lump a huge amount of stuff into the category "open office", much of it crappy, then stand outside and throw rocks at the entire concept.

Let's not do that.

</comment><comment><USER38> There are worse things than open offices. One of the new trends is open _lab space_. Chemistry labs at UNC made the transition a few years ago.

Did someone, anywhere on the floor, open something that produces hazardous vapors? Why contain it to one room when you can expose 1/3 of the building?

The University of Michigan's Biology program currently has a building under construction with the same "feature", and I am sure there are others.

</comment><comment><USER39> "Meanwhile, "ease of interaction" with colleagues — the problem that open offices profess to fix — was cited as a problem by fewer than 10 percent of workers in any type of office setting."

Here it is the other way around, the open office parts of the building are very quite, nobody dears make too much sound. It is much more social to walk into an office for a quick chat, only disturbing 1, 2 or 3 others.

<comment><USER40> Just imagine how "ease of interaction" is not a problem if you don't mind not to interact at all. That's another problem fixed forcefully by open offices. I like not being alone in my office, having the whole team of a dozen people in my reach. I don't like loud discussions either, but I can mute those with my ear plugs. I cannot unmute a solo office box.

</comment></comment><comment><USER41> After 14 years working remotely in a home office I worked at Google in 2013 in an open office. It was an adjustment but I enjoyed it. I shifted my work hours to 6:15am to 4pm for a few hours of quiet work time everyday. Also, there were many places to work away from my desk. Most managers seemed to have more private work spaces.

</comment><comment><USER42> The best working environment I was ever part of in terms of productivity was set up with private offices, but at the team level. We'd have a team of people who were all working on the same component (five or six people) in a room with each other, but otherwise insulated from the bustle of the office. It was hugely helpful to be in a room with all of the people who were relevant to your work, and no other distractions. That may have just been due to having a good team, but I have a lot of good memories from that time.

</comment><comment><USER43> Lots of people in our organisation equate non-open offices (in our case, cubes with high walls) with a we've-always-done-things-this-way attitude. And with a lack of transparency, the desire not to share 9and so remain vital) etc. However in our UK office we have the opposite - our development room is like a 1980s trading floor, impossible to focus for more than a few minutes at a time even with sweaty decent headphones.

Work-from-home is the way forward - LINQ combined with trust mean I can work in my pyjamas. Win!

</comment><comment><USER44> A small amount of friction in communication is a good thing. People become intellectually lazy if they can ask questions of anyone they want, at will.

</comment><comment><USER45> Is it really that black and white? I prefer a nice combination where the workplace is relatively open, but people still have space for privacy. It's not like Google throws all their engineers into a room...

> If employers want to make the open-office model work, they have to take > measures to improve work efficiency. For one, they should create more > private area

Many companies already split up like this, breaking teams down and giving all the members ample space and privacy. The truly open model that I've seen work the best is sales teams, where it has a "sales floor" feel and employees can be energetic making sales.

</comment><comment><USER46> Articles about how X doesn't work tend to use examples of where X is really badly implemented. In the case of this article, it seems the office she was working had a really toxic culture, with micromanaging managers, coworkers judging you when you leave, excessively noisy people, etc.

I've always worked in shared offices, ranging from 3 people to, currently, and entire department of 40 or thereabouts. Never seems to be a problem. But with large rooms, you do need to consider acoustics of course. And letting managers keep a close eye on people is a terrible reason for anything.

</comment><comment><USER47> Agree with all of it except the end. Don't fall for the "work from home" bit. Sure there is privacy, but it's also isolating and destroys the primary barrier to working around the clock.

</comment><comment><USER48> How is this Google's fault? Google's name is used in the article title, but then it is basically not mentioned again apart from in a list of equally well- known companies?

<comment><USER49> I don't think the article is blaming Google. Just har-har'ing with attitude that Google maybe isn't as smart as its cracked up to be.

<comment><USER3> The title was probably chosen because the editors believe adding something about Google will generate the most views and sharing.

</comment></comment></comment><comment><USER50> My preference has always been a shared workspace with the option for coders to pick up their computer and head outside to a coffee shop or unoccupied conference room or something to hack away in the zone when they felt like it.

This worked especially well when our startup was based out of a coworking space that had lots of temporary private spaces for individuals aside from the per-company office rental, when we were just four people.

</comment><comment><USER51> Peopleware (by Tom DeMarco and Tim Lister) must be a mandatory read for anyone working in a team and office environment.

</comment><comment><USER52> Every few months there's an opinion piece on HN about open offices. Then everyone gets into the same debate over whether they like the open offices or not.

What I'd like to see are new STUDIES about open offices, not the rehashing of personal experiences and anecdotes.

<comment><USER53> > What I'd like to see are new STUDIES about open offices

The article we're discussing mentions multiple studies...beyond that there's a great New Yorker article[1] from last year that references a number of studies. This blog post[2] links to a couple others and addresses costs/alternatives.

A "study of over 40,000 survey responses collected over a decade has found that the benefits for workers are quickly outweighed by the disadvantages"[3]. A Washington Post article[4] on office furniture designers realizing (citing multiple studies) "open-plan spaces are actually lousy for workers." And a TIME article[5] highlighted decades of research that associated open layouts with "greater employee stress, poorer co-worker relations and reduced satisfaction with the physical environment."

[1] [http://www.newyorker.com/currency-tag/the-open-office- trap](http://www.newyorker.com/currency-tag/the-open-office-trap)

[2] [http://nathanmarz.com/blog/the-inexplicable-rise-of-open- flo...](http://nathanmarz.com/blog/the-inexplicable-rise-of-open-floor-plans- in-tech-companies.html)

[3] [http://theconversation.com/open-plan-offices-attract- highest...](http://theconversation.com/open-plan-offices-attract-highest- levels-of-worker-dissatisfaction-study-18246)

[4] [http://www.washingtonpost.com/blogs/on- leadership/wp/2015/04...](http://www.washingtonpost.com/blogs/on- leadership/wp/2015/04/22/office-designers-find-open-plan-spaces-are-actually- lousy-for-workers/)

[5] [http://ideas.time.com/2012/08/15/why-the-open-office-is-a- ho...](http://ideas.time.com/2012/08/15/why-the-open-office-is-a-hotbed-of- stress/)

</comment></comment><comment><USER54> I'd further add that "agile" workspaces reminds me of sweatshops in India. It makes other "open" office plans look appealing. It puts the open concept on a gradient much to your point.

</comment><comment><USER55> If you don't like this, why not go start your own company or find a new job? There is nothing forcing you to stay in this job. I for one have to agree that the communal aspect of working in an open office has its benefits and downfalls. But if one day I came in and didn't like it to the level you described - I'd quit and go find a job where I can get right with myself.

<comment><USER56> I think this is a good suggestion. I've given up on 'contracting' these days, solely because I hate open plan, and just consult freelance. I rent my own office to work in and it's lovely.

I get lonely though! I miss the technical and social conversations we used to have in the kitchen or round the coffee machine.

What would be ideal is if I were to rent an office inside the company I'm working for. I would actually be quite happy to pay my client to rent a bit of their space if it's ever a possibility. After all rental costs are chickenfeed compared to developer compensation.

<comment><USER57> You could find a coworking space in your area and set up shop there. They exist to provide that kind of atmosphere to freelancers.

<comment><USER56> I'd love to, but they're all bloody open-plan

</comment></comment></comment></comment><comment><USER8> Very good piece. I am sure the Author is quite a pleasant person and all, but I really hate her just for going to the Beats store. She got what she deserves.

</comment><comment><USER58> This conversation again?</comment>


A GPDR Compliance Guide for HR Team - <AUTHOR> https://blog.truework.com/gdpr-compliance-guide-hr-teams/ <comment><USER2> The article is a bit shallow but this is an interesting topic.

The GDPR is in a sense modeled after the German Data Protection Act (Bundesdatenschutzgesetz, BDSG) and in many respects very similar. So it might be interesting how candidate data has been and is handled in Germany. The following are my personal takeaways from when I did hiring for a small business. I'm by no means an expert so take them with a grain of salt:

1\. If you can outsource the hiring process, do it. It will save you a lot of headaches.

2\. Keep correspondence with applicants separate from your other business correspondence. The reason is that data retention rules are very different for both types of correspondence. As a rule of thumb: Ordinary business mail has to be archived for at least 10 years in Germany.

3\. You cannot keep applicant data at will. You need a reason. Valid reasons are:

\- the data is needed for the application process

\- the applicant has given you consent to keep the data

At any point in time you have the applicant data you need _one_ of those reasons, you don't need both. At first you are covered because you need the data to conduct the hiring process.

Consensus is that you can keep application data for a maximum of six months after the application process has ended. The end of the application process is determined in most cases by the date of the rejection letter.

The six months isn't arbitrary but determined by the maximum of various periods for filing suit. If I remember correctly the anti- discrimination law (Allgemeine Gleichbehandlungsgesetz, AGG) is the determining factor.

You can ask your candidate in the rejection letter for consent to keep their data for a specified amount of time and I've heard that some companies do this. We decided against this because keeping track of the additional deadlines for deletion would have been to complicated for little benefit.

Deletion of application data means erasure of all personally identifiable information. This includes backups.

One last thing. The original post states the following question:

> Can you quickly and efficiently respond to an employee's data subject rights > request?

I think this is misguided. Yes, sure, you should be able to respond to this request, but in practice it will never happen. As long as the candidate is in the application process (plus 6 months) they will never ask for their data and even if they did it would be easy to answer. After that you have no personally identifiable information of the candidate and the answer is also easy.</comment>


Ask HN: Do you think there's a need for simple file sharing service? - <AUTHOR> Thinking of making a simple site for sharing files. As easy as imgur, you drag-drop, upload, and get a link you can share. But with a twist - you can only download once, preventing most DMCA takedowns and illegal activities (movie sharing). <comment><USER2> That limits the transfer to 1:1. Unless it is linked to from a popular site, I think you might find not many people will use it.

I created a couple of sites that let people upload any large file, all server side code, no javascript and people rarely use it. I've also created public anonymous sftp servers, but people don't use them. "too difficult".

Nowadays folks mostly use discord for chat and small images and box for bigger files because of the integration with their desktop and other clients.

</comment><comment><USER3> [https://www.justbeamit.com/](https://www.justbeamit.com/) That's pretty much what you described

<comment><USER4> [https://send.firefox.com](https://send.firefox.com) is another one.

</comment></comment><comment><USER5> What would the use case be?

How would you monetize?

<comment><AUTHOR> You want to send a file to a friend, maybe a word file, maybe a movie. So probably up to 4GB in size. Something that could be too big for email, or too large for imgur to not compress it (images).

I'd advertise my other products, so it would be a loss leader for me.

</comment></comment><comment><USER5> I'd probably make people register.

<comment><AUTHOR> Such a simple service does not require registration. Assuming you're mentioning this for reasons of logs/security/liability reasons, I'd probably just throttle. Maybe auto delete after 1hr after upload complete and no download attempts made, so server is always clean.</comment></comment>


Gates Proposes Radical Overhaul of Pentagon Arsenal - <AUTHOR> http://blog.wired.com/defense/2009/04/budget.html <comment><USER2> "Troops and low-cost tools to fight insurgencies and terrorists are in. Gold- plated weaponry for tangling with another superpower are out."

Really? The NYT article on the same topic said Gates was buying more F22's. You can't get any more 'gold plated' than those babies. And that's not to say I don't love the F22, the 'running up the score' they're talking about is fine by me when you're talking about American lives at stake. I don't want to 'just win' in Iraq, I want a blow out, every time, 1990-Gulf-War style.

And yes, that means on the ground too not just in the air which means we need more robots, high tech toys and more soldiers to connect with the local populations.

<comment><USER3> From his statement[1]: "We will end production of the F-22 fighter at 187 – representing 183 planes plus four recommended for inclusion in the FY 2009 supplemental."

[1][http://www.defenselink.mil/speeches/speech.aspx?speechid=134...](http://www.defenselink.mil/speeches/speech.aspx?speechid=1341)</comment></comment>


History of Ball Bearings (1981) [pdf] - <AUTHOR> https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19810009866.pdf <comment><USER2> During my visit to Venice I found a museum with interactive exhibits by Leonardo da Vinci. It's actually hard to appreciate full scale of his genius unless you actually try out each of the devices he created by your own hand. Most of these devices are very minimal and simple, something even you could build in half a day with right tools, but just magical. Even more importantly, what I learned was that he didn't just pulled them out his brilliant brain in one stroke. He meticulously studied how extremely simple things like gears, pulleys, levers, wheels & axle, inclined planes, friction, and screws behave and why do they behave that way. Then he started studying how lot of medieval machines that were already in existence simply be viewed as composition of these simple elements. Then he studied newer ways to compose them to build ever more complicated machines. So after years of such studies he was able to create these magical devices which worked without electricity, steam and such way back in 1500s. One of the device on display was ball bearings he had made and he was generally attributed as his inventor.

</comment><comment><USER3> I opened it looking for my favourite bearing, and it is indeed there.

Page 34, Section 1.7.1 The Bicycle Bearing

"The demand for large numbers of steel balls... provided the ideal commercial conditions"

When I get a puncture, I glue a patch onto the inner tube and pump up the tyre again. When the handlebars wobble, I tighten them with an Allen key. When the brakes fail, I can adjust the cables to tighten them or realign the pads. I can always keep the half-broken bicycle moving.

But when the rear bearing is broken, my bicycle simply won't move. Taking apart the wheel takes a lot of work. The fastest, cheapest way I've found is to replace the whole rear wheel with one from a scrapyard.

I think it's not an exaggeration to say that the rest of the bicycle is just an accessory to the ball bearings.

<comment><USER4> I've discovered, at various points in my cycling career, that rim splits, broken cranks, and broken chains also tend to severely limit the functionality of a bicycle. Though yes, the role of bearings (found in wheels, bottom brackets, and headsets, BTW) is surprisingly crucial.

<comment><USER3> You've experienced a lot! Thankfully I never had a rim split or a broken crank.

I had a broken chain on 自由路 (meaning Freedom Road), when listening to a song with the lyrics "every chain is broken".

I could still use it like a velocipede and scoot forward with my feet to the nearest metro station, though.

The back bearings probably break on me more often because my bag's heavy.

</comment></comment></comment><comment><USER5> All the figures are at the back of the book, if you happen to start reading and were wondering where all the pictures they were referencing were.

</comment><comment><USER6> TIL "Tribology": the study of friction, wear, lubrication, and the design of bearings; the science of interacting surfaces in relative motion.

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

<comment><USER7> Or as Coulomb said in 1785 "Theorie des Machines Simples, en ayant egard au frottement de leur parties, et a la roideur des cordages," See: [http://gallica.bnf.fr/ark:/12148/bpt6k1095299](http://gallica.bnf.fr/ark:/12148/bpt6k1095299)

There are 22 pages of references, besides the 48 pages of actual article text. This is a great post, I wish the references could be hyperlinked.

<comment><USER6> I wish I could read French. I sure didn't expect such a distinguished work to have a four page advertisement starting on the second page! Although that's better than a paywall. ;)

</comment></comment></comment><comment><USER8> In Hogan's Heros the bombing of ball bearing factories in Düsseldorf was often a plot point. Iirc.

<comment><USER9> While the bombing succeeded in destroying the factories, the Germans simply transferred bearings from machines where they weren't particularly needed to where they were.

<comment><AUTHOR> I'm pretty sure that sooner or later you run out of places where the bearings aren't particularly needed, not to mention the extra work in transferring makes the system slower. I think the destroying of the factories was successful in its objectives.</comment></comment></comment>


One of the most amazing physics engines I've ever seen - <AUTHOR> http://vimeo.com/13457383 <comment><USER2> Rather than sharing a blog post about a cool thing, why don't we share the cool thing directly?

The video is at <http://vimeo.com/13457383> \- you can get to this page by simply clicking the Vimeo logo on the embedded clip. From here, you can click on Thiago Costa's profile <http://vimeo.com/thiagocosta/> and have a look at all of his 48 videos, and find a link to his website (which looks pretty interesting): <http://thiagocosta.net/>

The CrunchGear article doesn't really add anything, other than a layer of indirection.

Having said that, the video is awesome and thanks for sharing :)

<comment><USER3> OTOH, the submitter might not have found these cool videos without TechCrunch so some appreciation via sending them traffic seems reasonable.

<comment><USER4> Showing appreciation by putting them between us and the beef is a bit like tipping a waiter with the cash of the people that ate with you, without asking them.

</comment></comment></comment><comment><USER5> If you like physics simulations, there were some very cool papers at this year's SIGGRAPH:

<http://www.youtube.com/watch?v=KMsc48e41AQ> (A Practical Simulation of Dispersed Bubble Flow)

<http://www.youtube.com/watch?v=GyfB_vQHMAo> (Physics-Inspired Topology Changes for Thin Fluid Features)

<http://www.youtube.com/watch?v=7Who8EpbvCY> (A Multiscale Approach to Mesh- based Surface Tension Flows)

<http://www.youtube.com/watch?v=nHH8N_lNZzI> (Rigid-Body Fracture Sound)

<http://www.youtube.com/watch?v=gx80u6hJT6o> (Efficient Yarn-based Cloth with Adaptive Contact Linearization)

<comment><USER6> Whats the deal with the rabbit that keeps popping up? Is it the physics simulation's Lena?

<comment><USER7> It's the Stanford Bunny.

<http://www.cc.gatech.edu/~turk/bunny/bunny.html>

It was preceded by the Utah Teapot. There's also the Cornell Box, for global illumination testing.

So, yeah, like Lena.

<comment><USER8> > It was preceded by the Utah Teapot

Teapotahedron, please. It's the sixth platonic solid.

<comment><USER9> I also vaguely remember one of the popular 3d software packages having a bald eagle as one of the primitives.

</comment></comment></comment></comment></comment><comment><USER10> Interesting... but not all that amazing, really. There's a rather glaring error, repeated many times, which many engines suffer from. Twitchy, spontaneous motion:

1) at ~23 seconds, look at the top-1/3, left-1/4 location. Chunks of particles _literally_ spontaneously accelerate towards each other. Towards the top-most corner of the top platform, there's even a little snake-like thing that starts inch-worming around for no apparent reason, and a blob that leaps into the air at _far_ higher velocity than it is made of.

2) with the 8-second cloth clip, note the twitching as the cloths try to find a stable resting point. Remind you of stacked objects in the Source engine[1], perhaps? Jump on top of them and it's like walking on an earthquake.

3) note how long the left block at ~2:40 takes to settle (almost, it doesn't actually), and the weird thrown-on-top chunk that twitches up and down a couple times, and then gets a burst of energy right when it starts fading out, moving _up_ , and _faster_ than the pieces it's touching, and without any visible ripple which could account for it.

If it's done by _one person_ (Thiago Costa?), yes, very impressive job, that's a _lot_ of work. But overall... more of the same.

\---

[1]: chosen only because it's a relatively modern engine, and one many are familiar with.

</comment><comment><USER11> The article seems to have the wrong idea about what that engine is.

While impressive, it was developed using ICE - a rendering package addon for Softimage, and is probably not able to be calculated in anything remotely resembling real-time.

So no, you won't be able to tell what religion Kratos is unless it's during a cutscene.

<comment><USER12> Actually, it shows in the first video that you can interact with the materials in real time in the 3D graphics package, albeit with less accuracy. So it shows the use of the mouse to drag a data point and stretch a squishy, gummy object that breaks and snaps back. That was real time interaction. Of course it didn't have nearly as many data points as the high res renders at the start, but I was still very impressed by that real time use of the engine.

That means that if can surely be used for 3D games as well.

<comment><USER11> Maybe, but I doubt it.

Those real-time versions for modelling packages tend to be really rough approximations using the same code, and not worth the time it would take to optimize for a real, resource-restricted environment like a gaming console.

<comment><USER12> For a standard modern game rough approximations of the quality shown in that video are more than adequate for something simple like a loincloth. It might not do for approximating an entire lake or body of water, but for simple things it would work just fine.

Even gaming consoles are limited by the number of polygons they can render, so the physics engine, if running in a game, wouldn't have to consider all the approximation points that were used to generate the high res renders at the start of the video for instance.

</comment></comment></comment></comment><comment><USER13> If this isn't real time, then this isn't that impressive. This type of fluid rendering has been possible for almost a decade:

<http://graphics.stanford.edu/papers/water-sg02/>

That said, if it is realtime, then yay.

<comment><USER14> No way this is real time, not even close. There's a frame rate counter visible in a couple of the videos (see <http://vimeo.com/7455632>, for example), and it's going at about 3-4 fps for the lowest detail models, which only have somewhere around 1000 points. The highest detail ones have millions, and probably took hours if not days to render.

</comment></comment><comment><USER15> Anyone out there from Pixar? How does this compare to what you guys have? I still gape at The Incredibles, especially the fine hair animation. But what I saw in the demo here of the cloth looks like something Pixar would want to have. Let me caution everyone, however, I haven't seen UP!, so perhaps Pixar has this or surprassed it.

<comment><USER16> Based off Pixar's recent movies, and a quick retrospective look at their older movies, I suspect they are sticking to their current level of realism as a matter of style, and only making slight subtle tweaks and improvements. If you compare their old movies to the newer ones, primarily you notice textures and objects are sharper, clearer and more detailed, movements of characters are more natural, and faces are more lifelike.

</comment></comment><comment><USER17> Does charcoal really act exactly like water?

<comment><USER18> No, the particles are bigger. Duh.

To be fair it looked a little different than water.

<comment><USER17> Actually, I think real charcoal would have more dust sized particles.

</comment></comment></comment><comment><USER19> The friction seems a bit off, but it looks great.

</comment><comment><USER20> Funny, this reminds me of all those old 2d mass-spring engines. I believe there was a cool one like asteroid where you could shear off one of your engines making your ship spin around. It was open source too. Can't remember the name.

EDIT: Ah, found it: <http://www.alecrivers.com/physical/overview_physics.htm>

There is even a older one that was an form-based application for windows where you could edit particles and connections. Pretty fun.

<comment><USER21> I was thinking the same thing regarding xspringies...

 _edit_ Your link reminds me of Phun <http://www.phunland.com/wiki/Home>

</comment></comment><comment><USER22> Definitely impressive. I can't imagine the framerates with this engine being practical though.

</comment><comment><USER23> Pretty incredible! Now I'd love to see them take high quality video inside/outside a demolition of a building and compare that to the simulator. For video games and such though, this would be incredible already. Is this sort of engine used to design cars and such?

</comment><comment><USER24> This stuff always has a warm and fuzzy feeling to it, but imagine the pain of implementing a full game with such physic effects, setting all the particles...

<comment><USER25> What do you mean by "setting all the particles"?

<comment><USER26> I'm guessing "describing the material and construction properties of every object such that it can be moved, collided, broken, and deformed convincingly." "Convincingly" typically isn't quite what you want either, you usually want "spectacular" which means hand tuning for all breaking/deforming events of interest. Movie effects, for example, start with pure simulation, but nearly always have lots of knobs for artists to play with to give the intended effect (e.g., the last page of this article [http://www.wired.com/entertainment/hollywood/magazine/16-01/...](http://www.wired.com/entertainment/hollywood/magazine/16-01/ff_animation) ).

<comment><USER27> I'm sure APIs would be implemented which would provide games developers with programmatic 'knobs' for fine-tuning.

<comment><USER28> The problem is that the fine tuning only works for one particular situation. In a game, it has to work for every situation the user can create.

<comment><USER25> Then just don't bother with manual fine tuning. Level designers are using object libraries even now, where they just take a pre-made chair, instead of constructing them out of basic polygons every time.

</comment></comment></comment></comment></comment></comment><comment><USER29> Man, I am so proud to be a Montrealer right now. This is an amazing example of the Creativity + Talent + Technology = Innovation that exemplifies this city.

Vive le Montréal! Oh and kudos to Thiago Costa. This is just awesome!

<comment><USER30> Thiago costa is brazilian...

<comment><USER29> Living in ...

</comment></comment></comment><comment><USER31> On the negative side, the potential use of an engine as advanced as this in the world of 3D porn will almost certainly result in more furry sex.</comment>


Report and Analysis from 107 Bootstrapped Startups - <AUTHOR> http://www.founderspeak.com/

<comment><USER2> It would have been nice to seen which startups were surveyed. I don't need to know there answers, but it's great to know who else is trying to make this work.

</comment><comment><USER3> hey guys..

yep, this is anonymous survey

I created different options for bootstrapping to see the participants behavior, remember this is a general survey to see general responses

everyones approaches are different, the order is different depending on the person

</comment><comment><USER4> Maybe I'm a little mixed up, but OP and I must have very different definitions of "bootstrapping". I am really confused by 3 of his graphs.

 _Support for start-ups_

      1. Savings              - 33%
      2. Savings + Consulting - 41%
      3. Consulting           - 15%
      4. Angel Investment     -  5%
      5. Friends & Family     - 15%

Category 1 sounds like they're true bootstrappers. Categories 2 and 3 sound suspiciously like service businesses and side projects. Categories 4 and 5 are not bootstrapped.

 _I define a start-up as having about 6 different stages I define them as follows:_

      1. Early Stage Concept  -  7%
      2. Developing Prototype - 32%
      3. Pitching             - 13%
      4. Finish Prototype     - 15%
      5. Start Selling        - 29%
      6. Scale Up             -  8%

Why isn't "Start Selling" first? Better yet, why isn't "Find Out What People Want and Will Pay For" first? Why are so many people building stuff that may not even be wanted?

Why not:

      1. Find Out What People Want
      2. Show Them a Prototype
      3. Collect Deposits
      4. Build It
      5. Find Other Instances of Those People and Convert Them

_What is holding you back?_

      1. Prototype not ready             - 28%
      2. Prototype needs to change       -  9%
      3. Can't find customers            -  9%
      4. Not enough time (consulting)    - 12%
      5. Need cash injection to scale up - 37%

It sounds like most of the companies either (a) haven't sold anything or (b) haven't sold enough to keep bootstrapping. Are these start-ups or are these side projects?

I wonder how many of the 107 companies raised the same questions I did. _That's_ something I'd really like to know.</comment>


Apple's iPad Smokes Past the iPhone 3GS in Speed Test - <AUTHOR> http://www.pcworld.com/article/193597/Apple_iPad_Smokes_Past_the_iPhone_3GS_in_Speed_Test.html?tk=rss_news

<comment> matthew-wegner They screwed up the MB/GB suffix--wow:

 _Vronko based his opinion on the 256GB of system memory that the iPad contains. "That was a pretty big surprise," he said last Saturday after finishing his iPad teardown. "I expected 512GB or more. The 256GB shows that it's a single-core processor [inside the A4]."_

</comment><comment><USER2> In other news, my new SSD's are faster than the platter drives I bought a year ago.

</comment><comment><USER3> They actually wrote an article on this? They might as well have wrote one on how the iPad is bigger too.</comment>