Ant colony discovered in an abandoned Polish nuclear weapons bunker - <AUTHOR> http://arstechnica.com/science/2016/09/bizarre-ant-colony-discovered-in-an-abandoned-polish-nuclear-weapons-bunker <comment><USER2> Actually, two ants have escaped the pit by climbing out.

One was only but a child ant. The other, much later, had its back broken before being thrown into the pit. That ant eventually healed and it too amassed the willpower to climb out.

<comment><USER3> I think we're missing the clear Antman/Batman crossover opportunity.

</comment></comment><comment><USER4> Reminds me of [https://en.wikipedia.org/wiki/The_Void_(Star_Trek:_Voyager)](https://en.wikipedia.org/wiki/The_Void_\(Star_Trek:_Voyager\))

<comment><USER5> Literally the first thought I had too. Talk about a void in the real world, but for ants.

</comment></comment><comment><USER6> If the ants have nothing to eat, and they don't have a queen to breed with, then what do the workers work at, exactly? Do they all just convert to scouts, spend their lives looking for food that doesn't exist, and die?

<comment><USER7> Based on the article it seems that they're just endlessly maintaining their nest. Waiting for their Queen who will never come...

</comment></comment><comment><USER8> Ants starving in the dark, damp pit of an abandoned nuclear bunker. Sometimes I love the cyberpunk dystopia we live in.

<comment><USER9> To be fair, it doesn't say they're radioactive. The 80s would be disappointed.

<comment><USER10> Why would it be? It's a bunker _against_ radiation and fallout. I would not expect the builders to put radiation in it, that would quite defeat the purpose.

</comment></comment></comment><comment><USER11> Just wondering. Why can't they climb back up through the pipe? I've seen ants walking in the ceiling. And if there's a passageway to the outside (a researcher squeezed in) wouldn't the ant eventually find the way out?

<comment><USER12> They don't really operate with the concept of "climbing back" or "way out".

<comment><USER11> Ants do explore. If one finds more food somewhere that is outside or closer to outside, the rest will follow. It's not technically impossible for ants to climb up the ventilation pipe either, but I don't know if their instincts would desire to reconnect with the old colony should they stray back up there.

</comment></comment></comment><comment><USER13> It will be interesting to see how this might change in the decades to come. Will they find a way to evolve into a "real" colony? Will they find a way to sustain without reliance on "new arrivals"?

Semi-off-topic, those pictures will haunt my dreams.

<comment><USER14> There are no queens. Therefore, all the ants are from "outside" and there's no chance for a mutation to develop for this pseudocolony to become a real colony.

</comment></comment><comment><USER15> Interesting read, although I'm slightly disappointed that there were no giant mutant ants after the "nuclear weapons bunker" tease in the headline.

</comment><comment><USER16> "The continued survival of the 'colony' through the years is dependent on new workers falling in through the ventilation pipe. The supplement of workers more than compensates for the mortality rate of workers such that through the years the bunker workforce has grown to the level of big, mature natural colonies."

For heaven's sake someone hide this article before Jeff Bezos reads it :)

<comment><USER17> i have no idea why, but this comment just made my Friday

<comment><USER18> It made mine because I laughed so suddenly and violently that I spat coffee onto the screen.

</comment></comment></comment><comment><USER19> So i wonder if some kind human soul would just throw a solid rope, long enough to reach the bottom from the surface to help poor species?

Ants are like "WTF humans! F __* your studies, help us already! "

<comment><USER20> Wouldn't the ants just eat the rope? They don't have the intelligence to know not to eat it and that it is more valuable to leave intact for climbing back up later after falling.

</comment></comment><comment><USER21> This is spartant

Do not really qualifies as colony, only as an accumulation of doomed individuals. I wonder if is even really disconnected from the other members. Ants can climb easily a rusty suface, can fit in any crevice and can dig.

Or maybe ... to take a look to the same big fat exit that humans used to enter in the bunker.

</comment><comment><USER22> Does anyone know why they can't climb back out? The fourth picture shows them crawling on the walls and ceiling around the pipe. The third picture shows that the pipe isn't smooth inside, so they could conceivably climb it. Zooming in on the fourth picture doesn't seem to show a gap between the ceiling and the pipe, but that is the only reason I can think of as to why they couldn't climb back out.

<comment><USER23> I would guess the problem is they don't even know they need to climb it to begin with. I don't think ants have enough consciousness to realize "this is the way I fell down, so this is where I have to go to get back", and the pipe wouldn't have any pheromone trails or anything to signal them. It's a long way to climb when you don't specifically realize that's what you need to do.

<comment><USER24> My guess is that some do climb out, randomly, but not enough to be statistically significant.

Hell is not knowing that you're in hell and should get out.

<comment><USER25> Or was that open-plan office?

</comment></comment></comment></comment><comment><USER26> I see a Pixar movie in this somewhere as they free themselves. Though all the death is not ideal.

</comment><comment><USER27> So what would happen if you ate one of these ants?

<comment><USER28> You would die.

</comment></comment><comment><USER29> I see an impactful animated film, like Watership Down, or VR experience where the reveal is you're one of these ants.

</comment><comment><USER30> This is probably the only article where I thought the photos would be better off as gifs.

</comment><comment><USER31> Reminds me of Star Trek Voyager episode.

</comment><comment><USER32> Researchers should end this madness and free the ants. I don't think that those ants are happy :/ :(

<comment><USER33> Exactly. This is not a colony, it is prison for ants, where they basically starve to death. They should just lower some wire through the shaft and free them, anything else is cruel.

<comment><USER34> [http://www.peta.org/about-peta/contact-peta/report- cruelty/](http://www.peta.org/about-peta/contact-peta/report-cruelty/)

</comment></comment></comment><comment><USER35> sounds like the beginning of a superhero comic book

</comment><comment><USER36> I don't understand why they can't climb out? You would think after a few days one ant would find the ceiling and climb back up the shaft?

<comment><USER37> Yes, it happens, but that one ant then is apparently too selfish to go back again for the others.

<comment><USER38> Or too dumb to have the intelligence to know that he has to go back.

</comment></comment></comment><comment><USER39> It's interesting that given the collective problem solving skills of ants, that they are apparently unable to figure out not to fall into a hole.

I wonder if they just fall through by random chance, or if there was some ant at some point that left a "hey guys, there's food down here" pheromone trail, and all the ants that came after just reinforced it into an ant super-highway. If no one ever comes back to say "actually, there isn't any food down there, just an inescapable pit", then I guess ant logic says there must still be something good down there.

<comment><USER9> If everyone who falls down into the hole is never heard from again, would they even be conscious of the hole?

My understanding of ants is limited, but as far as I know most of their communication is scent or contact-based, neither of which could provide communication past that first step. As far as they're concerned, it's effectively a black hole...

</comment></comment><comment><USER40> The link is pointing to the comments section of the article.

<comment><USER41> Yep. Please mod remove "?comments=1" from the end.

</comment></comment><comment><USER42> Can't believe I'm the first person in this comment stream to say it, but: doesn't this piece feel like a real-world Dwarf Fortress?

<comment><USER9> I feel like concrete-walled bunker is an even more difficult biome than glacier!

</comment></comment><comment><USER43> Trickle down economics in the natural world.

<comment><USER44> Or conversely the lack of upward mobility is a suitable reflection of the socialist environs.

<comment><USER43> Touche :)

</comment></comment></comment><comment><USER45> It's almost poetic how from the ruins of the collapsed human socialist era, other species are creating a truly communist colony.

<comment><USER46> Ha, the queen doesn't see it that way.

<comment><USER47> They have no queen.

<comment><USER48> Who would have thought that an ant colony would end monarchy before the UK?!

<comment><USER47> The colony has a queen. The workers trapped and waiting to die in the bunker do not.

</comment></comment></comment></comment></comment><comment><USER49> Entirely female population?

This sounds somewhat familiar. Life finds a way.....

<comment><USER50> I thought ant workers were typically females, or am I thinking of bees...?

<comment><USER51> Applies to both bees, and ants. (And related species, wasps, hornets, et. al.)

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

</comment></comment></comment><comment><USER52> _It 's possible they have figured out how to eat the creatures who feast in their cemeteries, essentially making them cannibals at one remove._

In that case, all living things are cannibals at several removes: animals -> decomposing bacteria -> plants -> animals

<comment><USER53> Yeah. Like I'm a second-hand vegan. I eat animals that eat plants :)

<comment><USER54> reminds me of Erlich Bachman in Silicon Valley, who is a pesca-pescatarian. "I only eat fish that eats other fish"

<comment><USER55> That doesn't sound like a good idea, unless he _wants_ chronic low-grade mercury exposure.

<comment><USER56> It's the cost of being an Apex predator!

</comment></comment></comment></comment></comment><comment><USER57> Now there's an excellent "penal colony gone horribly wrong" sci-fi story there.

<comment><USER58> So it's Australia, for ants!

<comment><USER38> What does Australia have to do with this? I wanna know.

<comment><USER59> Australia was a British penal colony. According to Wikipedia, 20% of of today's Australians are descended from British convicts. [https://en.wikipedia.org/wiki/Convicts_in_Australia](https://en.wikipedia.org/wiki/Convicts_in_Australia)

<comment><USER60> Australia per se was never a British penal colony. Australia was six British colonies, and while the first of them (New South Wales) was largely founded as a penal settlement, for others (e.g. South Australia, Victoria, Western Australia) penal transportation played a minor or absent role in the colonisation process.

Why did the British establish penal transportation to Australia? The American Revolution had meant they couldn't transport convicts to their North American colonies any more - the US would no longer accept them, and they were too worried the Canadians might rebel as well to send any more there. I'm not sure whether it is true or not that 20% of Australians are descended from convicts (Wikipedia makes that claim but provides no source for it), but whatever the true percentage is, some portion of Americans will be descended from British penal transportation to America as well.

</comment></comment></comment></comment></comment><comment><USER61> So, how are they reproducing? I was under the impression that only the queens are fertile; are ants just long-lived enough that they can maintain their numbers through the periodic addition of ants falling through the hole?

<comment><USER53> RTFA

<comment><USER61> Ah, so it is 100% maintained by new ants falling through every year. I had no idea individual ants could live for over a year!

<comment><USER62> Workers live from 1 to 3 years. A queen ant can live for up to 30 years! I guess less down in that environment though.

<comment><USER61> That's incredible. I always thought it would be on the order of weeks for a worker, and maybe a few years for a queen.

I feel extra bad for killing these little guys as a kid.

<comment><USER63> Well they have to survive the winter somehow, so it must be at least several months.</comment></comment></comment></comment></comment></comment>


How Will America Deal with Russia's Interest in Afghanistan? - <AUTHOR> https://intpolicydigest.org/2019/09/07/how-will-america-deal-with-russia-s-interest-in-afghanistan/ <comment><USER2> I like Durso's "silo" model of politics and USA special interest groups halfway into the article:

"Americans 'silo' every issue, such as Afghanistan or Syria, as interested executive branch functionaries, Capitol Hill staff, journalists, think tanks, ethnic interest groups, campaign fundraisers, and politicians coalesce around it. A politician like Vladimir Putin thinks horizontally and will offer a concession on, say, Syria, in exchange for an American hands-off in Venezuela or Donbas. The losing silo will erupt that America is trading away the legitimate democratic aspirations of the unspellable or unpronounceables in a dirty deal. Someone will use the M-word – Munich – and it will be all downhill from there."

"You are conservative about what you know best, so policy practitioners will fight to protect their silo, especially if it might be traded away 'because of a quarrel in a far-away country between people of whom we know nothing.' Trump is a threat to the silos as in his mind everything is related to everything else all the time and he doesn't respect the silos – or their future earning potential."</comment>


Where To Put Your Money Right Now (Mark Cuban) - <AUTHOR> http://blogmaverick.com/2008/10/15/where-to-put-your-money-right-now/

<comment><USER2> I agree, but:

1.) Why does Mark Cuban's blog entry have to look so much like a damn spam scam?

2.) I'd hope that folks investing in the stock market are smart enough not to have credit card debt in the first place. Probably misplaced hope, but seriously...if you're carrying a credit card balance, how/why do you have spare cash on hand anyway?

</comment><comment><USER3> >You cant afford to pay 9pct, 40pct or more. Both are far more than you can expect to make in the stock market, or any market. If you have gotten here to this point, and you just tore up your credit cards, YOU HAVE JUST EARNED A GREATER RETURN ON YOUR MONEY IN THAT PERIOD OF TIME THAN ANYONE ON WALL STREET COULD EVER EARN YEAR IN AND YEAR OUT.

Joel Greenblatt has exceeded 40% over a long span of time. Lynch, Buffet, Pabrai, the Gardener brothers and many other value investors have far surpassed 9% and done so for decades.

Heck, even _my_ performance over the last 5 years tops that modest level.

<http://www.stockalicious.com/portfolio-performance/1937>

</comment><comment><USER4> In other words, don't hold debt.</comment>


What Write Skew Looks Like - <AUTHOR> http://justinjaffray.com/what-does-write-skew-look-like/ <comment><USER2> Well written and detailed comparison of snapshot and serializable isolation levels.

From the article:

 _A more concrete reason than "nothing else makes sense" is a question of local vs. global reasoning. If a set of transactions must maintain some kind of invariant within the database (for instance, the sum of some set of fields is always greater than zero). In a database that guarantees serializability, it's sufficient to verify that every individual transaction maintains this invariant on its own. With anything less than serializability, including Snapshot, one must consider the interactions between every transaction to ensure said invariants are upheld. This is a significant increase in the amount of work that must be done (though in reality, I think the situation is that people simply don't do it), a point made by Alan Fekete in this talk[1] on isolation._

This bears repeating. In any non-trivial transactional application, the combination of concurrency and non-serializable transaction isolation levels is a serious bug farm. Most app/service backends fall for this trap.

Unfortunately, most OLTP database systems have incredibly poor implementations of the serializable isolation level. Postgres is a notable exception, and it's nice to see some newer database systems--like CockroachDB--making progress in this area.

[1] [https://www.youtube.com/watch?v=IP- S_RHlsEQ](https://www.youtube.com/watch?v=IP-S_RHlsEQ) (Thanks for the link; I hadn't seen this talk before.)

<comment><USER3> >If a set of transactions must maintain some kind of invariant within the database (for instance, the sum of some set of fields is always greater than zero). In a database that guarantees serializability, it's sufficient to verify that every individual transaction maintains this invariant on its own. With anything less than serializability, including Snapshot, one must consider the interactions between every transaction to ensure said invariants are upheld.

this is a difference between practice and theory. The invariant mentioned above is of theoretical interest. On practice such invariant would look like "sum of some fields is always equal to the value in that field of that row". (left as an exercise to the reader to see that that former theoretical invariant, and actually any other, can, without loss of generality, always be implemented as the practical invariant with the target field :) As basic Read Committed still means serialization of write access to that "sum" target field, it is enough to verify only that each transaction writing to any of those fields is also writing to that "sum" field and that it does uphold the invariant. There is no need to pay the huge performance price of serializing those transactions with all the rest of transactions in the system. This is why Read Committed is veriafiably enough for correct execution of so many applications (i.e. for any application whose invariants are implemented in that "practical" form). It is basically like multi-thread programming with correctly implemented synchronization of access to shared data.

<comment><USER4> > it is enough to verify only that each transaction writing to any of those > fields is also writing to that "sum" field and that it does uphold the > invariant

This is a good try at a theory of when you can use weak isolation. But as stated, I believe it is false. If the invariant is A+B=C, I think this sequence is permitted by READ COMMITTED:

T1: read A=1

T2: read B=1

T2: write A=2

T2: write C=3

T2: commit

T1: write B=10

T1: write C=11

T1: commit

Now A=2, B=10, C=11

More to the point, invariants aren't always local to a row, and people don't usually even fully articulate them.

> There is no need to pay the huge performance price of serializing those > transactions with all the rest of transactions in the system

Serializable execution can be made very very fast when there aren't actually a lot of conflicts. And then when there are you can do the hard work of trying to prove that something weaker will work. The failure mode in the other direction is silent corruption of your data.

<comment><USER3> What i was talking about in its most simple (though not most performant/scalable as it would be more complicated, so we wouldn't go into it now) implementation would look like this - the transactions involved with an invariant should start with locking of the "target" field of the invariant, the field C in your example:

T1: lock C

T2: attempt to lock C - blocked until T1 completes.

I.e. we have these 2 transactions serialized between themselves without unnecessary extra serialization with all the rest of the transactions in the system. The "target" field just plays the role of the mutex associated with the invariant (and this is why any invariant can be converted to that form just by having a mutex, ie. a "target" field, associated with it). From the theory of multi-threaded programming with mutexes we just know that everything can be implemented correctly in such a model. I.e. any application can be made correctly with READ COMMITTED isolation if required set of "mutexes" and their acquire/release is correctly implemented.

>Serializable execution can be made very very fast when there aren't actually a lot of conflicts.

not exactly. Serializability by itself is pretty expensive global invariant and your application would be paying for it in performance and scalability even though it may not really need it.

<comment><USER4> > any application can be made correctly with READ COMMITTED isolation if > required set of "mutexes" and their acquire/release is correctly implemented

This is true, but it's "a big if." And the result might be faster than a good implementation of serializable isolation (since the latter is working to maintain some invariants that you don't actually care about), but it could _easily_ be much slower: very broad invariants will require very broad locks which cause much more "serialization" than is required for serializability.

Let's say you want the same sum invariant but across rows: all _users '_ balances must sum to zero. The straightforward application of your reduction is to essentially have a global mutex for all balance transactions, but this is nowhere near the most scalable solution. Whereas a good serializable database will handle this situation scalably, safely, and automatically.

</comment></comment></comment></comment></comment><comment><USER5> I like Jim Gray's simple explanation (as always) of the difference.

A database has two white marbles and two black marbles. Transaction T1: Update all white to black. Transaction T2: Update all black to white.

A serializable database will ensure that the transactions happen in some serial order. At the end of performing them one after another, either all marbles are white or all black.

In snapshot isolation, T1 updates only the white marbles, T2 updates only the black marbles. So they are not seen as conflicting. The end result is that the database contains 2 black (formerly white) and 2 white marbles (formerly black),because the two transactions are working off a snapshot and not conflicting.

</comment><comment><USER6> If you are interested in a similar discussion of consistency levels, write skew, and how FaunaDB allows indexes to opt-in to serializability, this blog post covers a lot of ground, but brings up index write skew toward the end: [https://blog.fauna.com/acid-transactions-in-a-globally- distr...](https://blog.fauna.com/acid-transactions-in-a-globally-distributed- database)

</comment><comment><USER7> Url changed from [https://www.cockroachlabs.com/blog/what-write-skew-looks- lik...](https://www.cockroachlabs.com/blog/what-write-skew-looks-like/), which points to this.

<comment><USER8> Pictures are now 404 for me @justinjaffray.com, so while the crdb link might not be canonical it right now is bit more useful.

<comment><AUTHOR> Sorry, that was my fault! Should be fixed now.</comment></comment></comment>


Ask HN: Does anybody use a bug tracker for their personal lives? - <AUTHOR> Or a variant? Though I don't have much experience with issue trackers (except for the occasional issues raised on github, etc), could an issue tracker could be used for one's own personal lives? <comment><USER2> I'm hoping the Human 1.1 patch resolves these defects:

Bug #12: Memory leak causes occasional "enter room and forget why" state

Bug #57: Buffer overflow of extra hair in non-standard locations

Bug #98: Motivation module randomly fails to load

<comment><USER3> The fact there were almost hundred reports before the third you mention tells us a lot about how little we know about _that_ specific module.

</comment></comment><comment><USER4> I tried using a paper Kanban board (sticky notes on a whiteboard), but it didn't last.

Some technical issues (the sticky notes kept falling off and we literally "lost" work) and some social ones (we didn't secure buy-in with the household before we adopted the system; not everyone was on board with the idea of writing down every significantly sized chunk of work).

We still have some TODO list items that have been backlogged for a year or so but succumb to lower-pri, higher-urgency issues. Oh well. They'll be a little higher-stress to fulfill as the deadline approaches, but not a big deal.

<comment><USER5> Sounds like me at home too, though with a digital version. I remember making a list of things to do around the house before we were due to host a party. Found the list a year later and about half the items still hadn't been done. Had to laugh at myself for that.

I've seen it said that if you don't get something done before the sticky note loses adhesion and falls off, it's clearly not important enough to you to bother with!

I wonder if something like this - home to-do lists - is solvable with an app for those that have failed to stick with something to date. Is it the person or is it the app?

</comment></comment><comment><USER6> Not bug tracking, but I've use a combination of todo lists and 'life logging' software (there are tons of apps available).

I used to be a compulsive todo list maker but overtime I'm moved into a workflow that uses todo lists _only_ for tasks that absolutely need to be done on the one hand (ie: calendaring stuff), and recording tasks that I really _ought_ to be doing or doing more of, on the other hand. (tools: Gtasks[1] and aTimeTracker[2]).

I've realized that, for _me_ , to ^fix bugs^ in my lifestyle, the goal setting type of approach (which would fall in-line with the bug-tracking, todo, GTG ...etc) does not work as well as recording an action when I do something about it and then looking at that record as a motivation to do better.

Maybe not what you were asking for but thought I'd pitch in since I've had this question before mysel.

[1] [https://play.google.com/store/apps/details?id=org.dayup.gtas...](https://play.google.com/store/apps/details?id=org.dayup.gtask) [2] [https://play.google.com/store/apps/details?id=com.aloggers.a...](https://play.google.com/store/apps/details?id=com.aloggers.atimeloggerapp)

</comment><comment><USER7> I use a Git-tracked text file to-do list for both. I also shove random notes into it. It's a pretty effective system, and it never becomes obsoleted or loses my data.

<comment><AUTHOR> Oooh that's sounds interesting. Would you mind describe your workflow? I'm a bit on the OCD side and really like my textfiles and so on all nice and tidy.

<comment><USER7> \- Add item to to-do list at bottom of file

\- Do task (eventually, maybe)

* Replace dashes with stars to indicate 'done' and move to the 'done' section under the day I did them.

\- Commit once in a while

</comment></comment></comment><comment><USER8> I've been using Trello for various aspects of my life for some time. Anything that has a flow, concept of "on deck", or a repeated list of items tends to make a good home for it.

Example: My learning (labels represent sources of learning, I have an on deck list and I stick to whatever I'm on currently -- or at least try to). I pick the most relevant thing to do next.

Another example: Vacation packing. I have lists of "Master List", "To Pack", "Staged", and "Packed". Whenever I take a trip, I move the applicable items from the master list to the "to pack" list. Haven't forgotten something on a trip in a long time. Bonus: organize labels by type of thing, and now I know exactly what I'm putting in which bag.

Trello is also great for organizing goals. 5 goals per year / month / week / day, in a way that bubbles up, is very appealing to me, though I haven't tackled this one yet.

Also, any software project I do usually has a board. Lists: Formation / Future / Waiting&Hold / Backlog / In Progress / In Dev / In Test / Ready for Prod / In Prod. Labels for issues, features, questions, ideas, high priority, and low priority items.

</comment><comment><USER9> My wife and I use Google Sheets pretty often. List all the tasks, strikethrough them when done.

I also use Sheets as a bugtracker for my software projects, and it's been pretty effective. It's so low-overhead that I'm not spending all my time filing bugs, it's quite satisfying to see a full spreadsheet where everything has been checked off, and I can define functions for severity, time estimates, etc.

<comment><AUTHOR> Sounds interesting. Do you have a screenshot or something lying around? I'd love to see it

<comment><USER9> Here's one from my wedding:

[https://lh3.googleusercontent.com/DsXCelK18poubuiGCBCoH2k-92...](https://lh3.googleusercontent.com/DsXCelK18poubuiGCBCoH2k-92cNclapGjKd2zJc6bg3eJ- ijvqyLyt3uJfTDGKNCi5sDA=w2322-h1128)

And the bugtracker for my first app:

[https://lh3.googleusercontent.com/gZXKhR_AIm5eN3T9zBc2FqTIfd...](https://lh3.googleusercontent.com/gZXKhR_AIm5eN3T9zBc2FqTIfdvhE_p8ExqwtYgVZaGKzOec1TyprPUkUSl1cyqn3qWDJA=w2322-h638)

Being Google Drive direct links, these'll probably expire in 24 hours or so.

</comment></comment></comment><comment><USER10> I have written a daily journal since the early 90's, on paper. It was one if the best decision I ever made. However, I am on the verge of moving my journal to digital format, probably as a private blog. Also, I see the need to clearly define and integrate my basic concepts and principles and I am thinking of starting a personal, private wiki for that purpose.

<comment><USER11> Much respect for the diligence necessary to continue with such a project.

 _To think, you have to write. If you 're thinking without writing, you only think you're thinking._ \- Leslie Lamport

</comment></comment><comment><USER12> Short answer is negative.

Everyone has a system to manage their personal lives, even if it is only in their head or as simple as pen and paper.

I sense you are trying to gauge a market demand for "a to do" app with the bug tracker formula infusion.

I don't think people think of their lives as software with bugs.

Even software engineers who fix bugs do not think of issues in their life as bugs. It doesn't feel as natural to whack your issues (ex: lose weight, due 2 hours :), P1).

For "real life" stuff, I found people categorize their lives. "Home", "Work", "Personal", "Professional", "Hobbies" ...

And each category has its own evolving set of tools. Ex: Fitness contains a plethora of tools. Work contains tools in sub categories...

<comment><AUTHOR> ahahaha nice try but, I'm not an entrepreneur :)

I was just fascinated by issue trackers and wondered if it could be applied elsewhere. Nevertheless, your comment does provide interesting insight as well. Thx!

</comment></comment><comment><USER13> Me and my wife use wunderlist's shared list feature for todo items.

</comment><comment><USER14> I've seen people use project management software for their personal lives. Trello and the ilk, as example. I've attempted it, but never manage to maintain it very long.

</comment><comment><USER15> I set up Redmine for my wife, who is an attorney. She uses it to communicate with her clients and manage projects, and also for some personal stuff. She really likes it.

</comment><comment><USER16> I've used Trello. Project management seems like a more appropriate model than issue tracking.

</comment><comment><USER17> Asana is pretty awesome for managing projects both at work and at home. Relatively easy to use/learn and if you're ok with cloud based software convenient as it syncs with your phone and can share with family members or team mates.

<comment><USER18> Asana has great UX and is simply fantastic for _shared_ task lists and projects among various people. Plus, it runs only $21/month (billed yearly) for total 5 friends/family. (If they went IPO, I'd snap up their arms off.)

</comment></comment><comment><USER19> I am using a Trello board to organize my life. The flexibility to define lists freely and quickly add issues is a big win. The lists on my board are: Today's task list, Task list, Friends & Family, Project ideas, Client work.

</comment><comment><USER20> I have a nice big whiteboard (well, glassboard) stuck to my office wall: Calendar section, issue section, undetermined future setting.

Also great for illustrating things when people visit.

</comment><comment><USER21> There seems to be a common theme of people using some form of task management for home but the systems not being very effective. I've experimented a lot myself and have a few thoughts on the matter that might help someone.

The most essential factor is buy-in and commitment: both buy-in with those that you live with (wife, roommates, etc) and, perhaps more importantly, buy- in with yourself. You'll need to really commit to any system for it to be effective.

A successful general productivity strategy is in learning the signs of tasks that will never get done versus ones that will.

The key attribute of a task that seem to sit in the todo list forever is when a task is actually a project in disguise. Many times we have something like "Plan vacation", "Build deck" or "File taxes" in our todo list which are all projects rather than tasks. When you notice this, put the project on your list of projects and then define the next immediate task that you can do to make progress on this project. For example, for "Plan vacation" a task might be "Schedule dates for trip" or for "Build deck" a task might be "Make measurements of deck". Focus on the most minimal next step to push the project forward. This forces you to think of the project in stages that are all independently easy to reason about and schedule.

The current incarnation of my at home todo list is as follows:

4'x3' metal board (galvanized Steel from hardware store) and magnetic whiteboard squares (find them on Amazon as sheets and cut up to size) representing tasks. These adhere very well and are reusable (less in the landfill).

I break my board into 4 kanban board style columns that should sound familiar to most: icebox, backlog, today and done.

Icebox holds items I'd like to do but don't have immediate plans on. Often things are a bit vague at that stage or they are projects waiting to be turned into tasks.

Backlog has tasks that I'm committing to do for the current sprint (one week long, from Monday to Monday). I don't allow any new items into backlog unless truly critical until the next sprint. Each sprint I sit down and prioritize my goals for the week and look at my icebox. I try and choose a combination of things I am excited about and things I'm not excited about. I take any tasks that are vague and break them down into something I can do within 30m-1hr. If the task is too vague/big I know I probably won't do it.

Once my backlog is filled for the sprint, I plan what I'm doing each day of the sprint in the morning. I take into account work priorities, meetings, etc and put items I'm committing to do today into the list.

I attempt to work in a pomodoro style with 25m working and a 5m break. I make sure to take a real break, usually some quick meditation or exercise/stretching. The key is to step away and clear your mind. This prevents getting stuck in a rabbit hole with a given task.

I record a tick on each card for every pomodoro I do against it. As I resolve items I move them into done. If I move things into done that have a lot of ticks on them (eg they were big tasks) I see it as a sign that I didn't plan sufficiently and need to break things up more effectively in the future.

At the end of the sprint I recap on what I've done and not done and make any mental notes of things to change. Perhaps most importantly I go through the list and celebrate all that got done. This is effective in having a healthy perspective on the progress I've made.

This system has been very effective in making real progress on things I typically procrastinate on including home repair, side projects and chores. This system has been so effective I actually do it for personal and work items and mix the two together throughout the day (I work from home so this is easy for me to do).

The key to making any system like this work is to commit to enforcing the process in yourself and to be constantly aware of when you're slipping and make adjustments. Also, it's important to see any such process as a living, breathing thing that will always need changes and tweaks to be optimally effective.

One last bit that you could throw in the mix is to plan to release one thing every sprint to the world. I've been focused on launching one of my side projects each week and so far I've actually launched things that have been on my wish list for months.

</comment><comment><USER22> I use Pivotal Tracker for my personal life. I haven't been able to get my wife to use it, though.

</comment><comment><USER23> I use Task Warrior sometimes for personal stuff but not religiously. For that I use paper and pencil.

</comment><comment><USER24> i use google calendar's "task" for it but sometimes procrastination takes over and the old tasks don't show up.... Recently started trying Trello, hopefully it sticks

</comment><comment><USER25> Met one person claiming he enjoys using mind mapping software.

<comment><USER26> My wife, who is into graphic design swears by mindmap.

</comment></comment><comment><USER27> its called a calendar. A well organized calendar.

</comment><comment><USER28> I think you mean "Feature Tracker".

</comment><comment><USER29> Yes. Emacs org-mode.

</comment><comment><USER30> You could use github</comment>


Why I haven't applied for YC - <AUTHOR> http://sathishmanohar.com/why-i-havent-applied-for-yc/

<comment><USER2> Just build cool stuff, not products you feel will appeal to investors or customers. As both groups are unpredictable but at the same time you shouldn't have to try to pander to what they're looking for. You need to have an interest in what the product is and be flexible to pivot.

If you're building something for someone else you aren't very agile and can very easily become stuck as a company.

If you don't get into YC giving up is the worst thing to do, you should apply to YC for the experience not just for YC.

Otherwise will you just stop doing the startup after YC? These are questions people will have in their minds.

Good luck, interesting piece and some very valid and great points in there.

<comment><AUTHOR> Thanks for the kind words :)

Problem with building cool stuff for me is, I'm the idea guy, I usually get lot of ideas in different fields, I figured that is a problem, more than a asset. I found a way around this, I archive all ideas, and wait. Some ideas seem stupid after sometime or after some discussion, example: <http://news.ycombinator.com/item?id=3116788>. I only choose to work on ideas that appeals to me even after 6 months. Actually, I'm building both products for me, 1. Project management tool ( sure! not basecamp copycat ) and 2. News Website with an interesting twist. I desperately need both and I hope the world will come to love it.

Edit: that is not to say, I don't build cool stuff. I built an astrology site that updates itself ;) <http://rasi-palan.com> (Its ugly, but it works ;) built in a day)

My first YC application was a mistake, I was in a mindset like, "What will I build if I get money?". My current mindset is "What will I build, regardless of money".

Since my first product will be SaaS Application, it will survive by itself. I'm still worried about the second product, since its a consumer application like youtube, twitter, I thought I might go broke running it. Now, I think if a consumer product gets that amount of traction, then It may very well attract investors.

Anyway, We'll get our MVP online first. We'll see from there. :)

</comment></comment><comment><USER3> Title was very confusing...'wait, he _has_ applied and was rejected? what?' - felt like a headline trap. Should have been, 'why I didn't apply to this round of YC'

<comment><USER4> You'll find answer at the bottom of article.... I guess.

</comment></comment><comment><USER5> Well yeah, it's a smart decision to have a product before applying. However, the question now is "Why don't you have a product yet?". You had several months to do that after the primal rejection, and yet you still don't have it. You just shifted the deadline forward. I'm currently doing the same and beating myself for laziness.

<comment><AUTHOR> Earlier this year I only knew PHP, not ruby or rails. Then I stumbled upon Rails, It seemed clearly superior, I stopped everything in favor of Rails. Because, Rails development seemed a lot faster than PHP development (for me). I think it is a good decision as well, Since development with RoR can be much faster, We'll actually be ahead in product sometime in the future, even if we had started with PHP earlier. Hope that makes sense. Note: I built prototypes using Rails in hours, which might have taken days in PHP.

<comment><USER5> Understandable, but not acceptable ;)

</comment></comment></comment><comment><USER6> I agree that's the way to go. Building something under limited resource is a must for an entrepreneurs.

The real advantage over Idea & Budget is the same as agile over waterfall. We can expand our own narrow worlds only by moving ahead.

And I think the learning through such executions is the "insight" that YC mentions.

</comment><comment><USER4> I fully agree with idea to build your product as long as possible without 3rd party's help. As for me, I don't think that's the bad idea to apply for this YC round. Why not to try? Valley is briliant place for startup to be, for meeting with awesome people.... why not?

</comment><comment><USER7> It's not applying without a working product that would put people off, rather that the founders aren't agile enough to produce new ideas fast. Flexibility is key here.

</comment><comment><USER8> Every no gets you closer to a yes. That's one rule of all new ventures. Persistence is key.</comment>


"DBus is seriously screwed up" - <AUTHOR> http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1939166 <comment><USER2> This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice.

Quotes are taken out of context, used by people who lack the required technical understanding, which then reach the ears of managers, who will promptly act on overblown concerns. All of it somehow backed by Linus' word, even when he doesn't actually mean it.

I've started a stopwatch to see how long it will take for some of my former coworkers to contact me with concerns about DBus. We used it pretty heavily.

As for DBus itself: guys, it is useful. It works. You can count on it being there and working in most distributions, you can talk to most things nowadays. Its easy to use (for most use cases), language bindings are everywhere.

So, turns out is slow. It's so cool that we have identified that. Let's fix it.

Even if the slowness doesn't seem to bother many of its use cases.

<comment><USER3> So totally this; it's what I've said time and again. Is Linus abrasive? Yes, he can be. He usually has reason. But people seem to rarely read the whole thread, and even if they did, they are usually outsiders who lack both the technical chops to make valid criticisms, and they aren't familiar with Linus' management style. I for one count myself as one of the former as I've been outside of kernel land for quite some time. I'll say this though: the N900, with 256MB of RAM and a single core 600MHz ARM chip from 2009 had DBus, and it didn't seem to suffer too much from it. Hell, it's kind of impressive to be able to make phone calls from the command line, say over SSH:

[https://wiki.maemo.org/Phone_control#Make_a_phone_call](https://wiki.maemo.org/Phone_control#Make_a_phone_call)

Can improvements be made? Probably. Should they be? Why the hell not? Should clickbait headlines stop distracting us from real work? I only wish they would.

<comment><USER4> Strigi desktop search and NEPOMUK semantic desktop extensively relied on D-Bus. The D-Bus background daemon often hung and NEPOMUK itself was known to be slow and wasteful on hardware resources. Maybe it wasn't D-Bus fault at all, but the years long problems lead to a bad impression. [http://en.wikipedia.org/wiki/Strigi](http://en.wikipedia.org/wiki/Strigi) , [http://en.wikipedia.org/wiki/NEPOMUK_(framework)](http://en.wikipedia.org/wiki/NEPOMUK_\(framework\))

Comparing a PPC (WinCE), iPhone1 and N900 with the similar hardware specs - there was no clear winner.

</comment></comment></comment><comment><USER5> It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that.

Heck, I have worked on an algorithmic trading platform that in the limit of 5us receives market data, dedups it (multiple multicast streams for redundancy), uncompresses it (fricking zlib), parses it, analyzes it, sends to multiple algorithms which decide if current market situation matches certain rules, decides and fills market order, the order gets inspected by independent mechanism to stop the algorithm if it malfunctions, and only then it gets sent to market, over TCP, which is another form of IPC.

All in the span of fricking 5us which is _40_ times less than the benchmark suggests for this simple task. Granted, the algorithmic trading world goes to great lengths to avoid overhead including kernel overhead any kind of task switiching, branch prediction fails, etc. But still, come on, guys...

<comment><USER6> > It blows my mind how such a simple operation as passing messages from > process to process can baloon to waste the measured half a million CPU > cycles. People manage to have full-blown HTTP servers service a request with > less than that.

You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.

<comment><USER7> Nothing obvious about it.

If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in- memory cloning. You certainly don't mean to imply that both are the only way to implement a "security policy driven message bus" software, do you?

<comment><USER6> > If you look at the Linus's trace, it's all heap and mutex operations. That's > just sloppy internal design full of concurrency bottlenecks and lots of in- > memory cloning.

Far from it. One of the core designs of kbus (which dbus cannot do because it's not in the kernel) is that you can seal the payload buffer from the sender so the receiver and use it safely concurrently without having to clone anything.

There is obviously a lot of general inefficiency in the userland libraries but not in the design of it.

<comment> vezzy-fnord You're talking about memfd, I think? That has nothing to do with kdbus in particular. It's an independent syscall that replaces many use cases for splice/vmsplice, even though it was introduced as part of the kdbus project - it's still a separate thing.

<comment><USER6> > You're talking about memfd, I think? That has nothing to do with kdbus in > particular. It's an independent syscall that replaces many use cases for > splice/vmsplice, even though it was introduced as part of the kdbus project > - it's still a separate thing.

That was created for KDBUS but has more use than than being used for KDBUS exclusively. It still was written for KDBUS.

<comment> vezzy-fnord And so it was accepted and merged. That something good came out of kdbus is excellent, but that's no justification to merge in the whole package. A ton of proposed kernel additions end up like this - a few good ideas refined and accepted, and the rest thrown out.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I can make two observations and hypotheses from the profiling results, which agree with Linus' conclusion of "bad user-level code":

\- Memory allocation/deallocation are taking the most time.

\- All the percentages for each function are very small.

The former is a characteristic of code which heavily abuses dynamic allocation. It's surprising to see how many programmers are not aware of the overhead it adds and would malloc()/free() frivolously when something simpler would suffice. This is also often accompanied by copious amounts of unnecessarily copying data around. I've worked with small embedded systems where every use of dynamic allocation would need to be justified thoroughly in code reviews; perhaps these developers would benefit from being put through the same process.

The latter is a phenomenon which arises from "excessive modularity": the functionality of the system has been split into so many little pieces that the time each function contributes to the overall total is tiny. Instead of seeing an obvious "80% of the time is being spent here" that could easily be targeted for optimisation, that 80% is scattered amongst several dozen functions each taking 1-2% each. The bottleneck isn't concentrated in one area --- the whole system is uniformly inefficient. It's extremely difficult to optimise a system like this because nothing in particular stands out as being optimisable. I've had to optimise some large Java applications that were like this, and the solution was basically to remove most of the code and rewrite it to get rid of many chains of indirection.

<comment><USER9> Frequently the second problem is exacerbated by cache misses. Every operation becomes (much!) slower, but nothing stands out.

Not a popular opinion here, but excessive modularity like that is practically the definition of bad, hard to follow code though IMO. Ignoring performance issues, everything happens somewhere else, and large changes now take several times longer, since the changes are not local to a function. The code is several times longer than it otherwise would be due to all the function declarations...

Its a nightmare. It tends to be the kind of code you feel productive while writing ("I'm cleaning up this 200 line function"), but is really just making the codebase worse (is there a general term for this kind of false productivity? It's a common problem I see).

<comment><USER10> > Its a nightmare. It tends to be the kind of code you feel productive while > writing ("I'm cleaning up this 200 line function"), but is really just > making the codebase worse (is there a general term for this kind of false > productivity? It's a common problem I see).

This issue is pervasive when Desktop/Web developers try to improve embedded software. I've achieved a thousandfold increase in performance by converting an embedded data logger from using printf to using a dedicated formatting function (most of the time was spent on parsing the format string and performing allocations).

<comment><USER11> The compiler doesn't do the parsing for printf at compile time for the common cases? That's semi-surprising.

<comment> TD-Linux In fact it does.

[http://stackoverflow.com/questions/19499618/gcc-printf- optim...](http://stackoverflow.com/questions/19499618/gcc-printf-optimization)

<comment><USER12> Or rather: compilers exist that do. The embedded world has a lot of strange toolchains

</comment></comment></comment></comment></comment></comment><comment><USER13> Linus is just being Linus. He's brusque, non-chalant. He's inflammatory to get people to listen. His thesis here is that bad DBus performance isn't due to context-switching overhead or buffer copies (which can be solved by moving the daemon into the kernel), but instead it's due to malloc-intensive / utf8-parsing-intensive marshalling.

Secondly, he's saying that if performance is being used as an argument for kdbus, then that's an invalid argument.

He's totally right by the way. In this pure message-passing benchmark, where the message-passing overhead is the majority of the work, the slowness is not in kernel-scheduling/system-call/kernel-buffer-copies. People confused a potential impossible-to-overcome bottleneck as the most relevant bottleneck.

But that doesn't mean there isn't a reason for kdbus. Kdbus allows for much better authentication than UNIX sockets do (you can authenticate with pid, pgid, uid, gid, kdbus token, etc.). Also it allows for message-passing security policies to live in the kernel which is crucial for security applications. The tangential performance benefits are nice too, even though the bottleneck wasn't in the kernel to begin with.

<comment><USER14> Responses like yours are why I enjoy to visit Hacker News.

Sorry for going meta - I'm just a bit disappointed because your tone used to be the normal thing on HN, even when there were just as many disagreements. People were able to keep it friendly. Today not as much; I find HN has become too mainstream and "reddity", and the tone in general too emotional and aggressive, about who or what is right.

This wasn't unexpected, but still, it is good to see not everyone has moved into that direction.

</comment></comment><comment><USER15> Some form of notification publish/subscribe functionality is necessary in modern Linux. But dbus isn't very UNIX-y. It's also strangely opaque. With pipelines, you can see how the plumbing works. With dbus, programs can interact in nonobvious ways. Even worse is polkit, a poor replication of Windows Group Policy.

The most unixy solution is buried at the bottom of this thread, from Plan 9: [https://news.ycombinator.com/item?id=9450988](https://news.ycombinator.com/item?id=9450988) ; but if that's not popular, then I think what people actually want for desktop purposes is an equivalent of the Windows PostMessage system.

<comment><USER16> Plan 9 in no way _implies_ performance. Just because you can make it look like a filesystem, doesn't mean it actually is going to achieve anything special performance wise.

<comment><USER17> And in fact the performance of Plan 9 tended to be extremely poor when compared apples-to-apples with Linux.

It's just that everything was so simple it _felt_ fast, even if your filesystem throughput was crap.

</comment></comment></comment><comment><USER18> It all started with a microbenchmark:

[http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...](http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937442)

DBUS implementation aside (which seems to leave a lot of room for optimization), my initial reaction was that the gain was _rather_ minimal compared to the claims of the systemd folks.

<comment><AUTHOR> That was my first reaction as well. But to be fair, the kdbus people always said the real speedup will be seen for large packets.

However, the real issue is how slow overall DBus seems to be according to those numbers. As Linus says earlier in the thread: "No way should it take 4+ seconds to send a 1000b message to back and forth 20k times." This is indeed rather shocking.

<comment><USER19> So what's the use case for sending large packets of data over dbus where the performance gains warrant integrating the dbus server to the kernel? Are they planning to migrate the X server to dbus?

<comment><AUTHOR> IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.

<comment> semi-extrinsic So: if DBus was suddenly fast enough to stream media over, what applications would be using this feature, for what sets of streaming endpoints?

<comment><USER20> KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.

<comment><USER21> If the point is to have Android style IPC, why not just pull a version of Binder into the mainline kernel?

<comment><USER22> Android's Binder was already merged into the Linux kernel (not just "staging", the real thing) since 3.19... half a year now.

[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=777783e0abae3cab7555bb182776f9ffaa35631a)

But not many people are aware of that; since neither systemd nor Lennart Poettering have anything to do with it, the usual armchair architects did not paste their, uhm, well considered opinions about how much it sucks and is the end of the UNIX philosophy all over the comment threads when it happened.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> He's not saying DBus as a concept is bad, just that the implementation sucks. If he's right, that's something that can be fixed relatively easily (compared to a major architectural change).

<comment> TD-Linux I agree, the OP title is a bit misleading.

I use dbus every day on my laptop and it works totally fine - I don't notice its existence. I'm all for improvements, but I'm quite patient and quite happy to wait this one out.

<comment><USER24> I made a silly desktop app some time ago and it used DBUS to get notifications from NetworkMonitor when the system went online/offline. Nothing too fancy, very few lines of code.

When I was implementing that, I managed to get several segfaults from my Python code. All together seemed a little bit fragile to me :(

That was 5 years ago, things are probably better now (to be fair, I don't know what was causing the crashes; NM was 0.8 back then), but when I read Linus comments I can help to think he's probably right.

This is an anecdote and all, but my point is that until I had to use it... DBUS was pretty good and was working fine :)

<comment><USER25> Were you using threads? Python really should not crash, but combine it with library imports implemented in c and threads, and you get really subtle race conditions which result in segfaults. I have myself been force to debug why Python segfaulted, and it was a standard library call which internally used threading, and that caused a conflict with a c library that was not threading safe.

<comment><USER24> Sorry, it wasn't Python. It was a system component that crashed as consequence of my Python code using DBUS.

</comment></comment></comment></comment></comment><comment><USER4> > Since then I'm convinced that people who are inventing RPC solve non- > existing problems.

Many RPC solutions ultimately failed, because they were slow and overdesigned/complex. (e.g. CORBA, Network OLE/DCOM, Java RMI, XML-RPC/SOAP and other XML-based protocols, etc.)

Whereas e.g. REST (if you call it even RPC) is just very simple and enough for most purposes.

It's more like the concept of Component Object Model failed. For example OLE (the base technology behind DCOM) doesn't fly beside the legacy Office usage. It goes without saying that binary based implementations of such Component Object Model are faster than XML based ones - a fade of the last ten years.

The component format (if you call it that way) that just works is HTML5.

Edit: okay, it seems it's a controversial topic (My comment used examples which were DCOM and OLE 1+2 (the original MS Office thing "Compound document") - [http://en.wikipedia.org/wiki/Object_Linking_and_Embedding](http://en.wikipedia.org/wiki/Object_Linking_and_Embedding) and [http://en.wikipedia.org/wiki/Compound_document](http://en.wikipedia.org/wiki/Compound_document) , not COM directly)

<comment><USER26> You do realize that pretty much whole of Windows is, underneath, based on COM, including most of the .Net-exposed system API's?

I'll agree that COM and DCOM are... hairy, if you're implementing COM objects 'by hand'. But there's a reason for all of it, and I have yet to see an easier _and_ more flexible way to write cross-language components. I could write a COM object in C++, call it from VBScript in a very simple command line program, as well as use it directly in a Web application in (here it comes!) _1999_! That's _15_ years ago! And while COM is universally reviled now, and none of the cool kids will want to be seen within 100 feet of it (actually, the 'cool kids' don't even know what COM is any more, it's so 2005 to hate on COM...), for those who spend 6 months on understanding it, it worked very well, and has been supported for close to 20 years now (on Windows, that is).

<comment><USER27> COM is indeed an interesting beast and very useful. Being able to integrate other programs into yours, relying on COM to do so is very helpful. I don't know of a way on Linux or OSX to embed a word processor to work on documents but never show the user (but this might be due to my lack of knowledge about those systems - I would welcome being enlightened). I once wrote something that processed a plethora of Word documents using Word via COM to extract data from them and shove it into a database.

I can't fully remember how I did it but I recall type libraries, including generated headers etc. but I remember being impressed by it.

And as you state, all calls within Windows rely on COM. Stop the RPC service and observe as your system becomes unusable.

<comment><USER28> LibreOffice uses UNO, which is their own version of COM: [http://en.wikipedia.org/wiki/Universal_Network_Objects](http://en.wikipedia.org/wiki/Universal_Network_Objects)

<comment><USER4> Mozilla has its own XPCOM too: [http://en.wikipedia.org/wiki/XPCOM](http://en.wikipedia.org/wiki/XPCOM)

Read the Criticism section:

 _" XPCOM adds a lot of code for marshalling objects between different usage contexts (e.g. different languages). This leads to code bloat in XPCOM based systems. This was one of the reasons why Apple forked KHTML to create the WebKit engine (which is now used in several web browsers in various forms, including Safari and Google Chrome) over the XPCOM-based Gecko rendering engine for their web browser.

The Gecko developers are currently trying to reduce superfluous uses of XPCOM in the Gecko layout engine. This process is commonly referred to as deCOMtamination within Mozilla."_

But my original top comment was about RPC and the compound document format (OLE as example), not about COM.

Apple had a compound document format too (death since 1997): [http://en.wikipedia.org/wiki/OpenDoc](http://en.wikipedia.org/wiki/OpenDoc)

 _" OpenDoc's flexibility came at a cost. OpenDoc components were invariably large and slow. For instance, opening a simple text editor part would often require 2 megabytes of RAM or more, whereas the same editor written as a standalone application could be as small as 32 KB. This initial overhead became less important as the number of documents open increased, since the basic cost was for shared libraries which implemented the system, but it was large compared to entry level machines of the day. Many developers felt that the extra overhead was too large, and since the operating system did not include OpenDoc capability, the memory footprint of their OpenDoc based applications appeared unacceptably large. In absolute terms, the one-time library overhead was approximately 1 megabyte of RAM, at the time half of a low-end desktop computer's entire RAM complement.

Another issue was that OpenDoc had little in common with most "real world" document formats, and so OpenDoc documents could really only be used by other OpenDoc machines. Although one would expect some effort to allow the system to export to other formats, this was often impractical because each component held its own data. For instance, it took significant effort for the system to be able to turn a text file with some pictures into a Microsoft Word document, both because the text editor had no idea what was in the embedded objects, and because the proprietary Microsoft format was undocumented and required reverse engineering.

It also appears that OpenDoc was a victim of an oversold concept, that of compound documents. Only a few specific examples are common, for instance most word processors and page layout programs include the ability to include graphics, and spreadsheets are expected to handle charts. [...]

But certainly the biggest problem with the project was that it was part of a very acrimonious competition between OpenDoc consortium members and Microsoft. The members of the OpenDoc alliance were all trying to obtain traction in a market rapidly being dominated by Microsoft Office. As the various partners all piled in their own pet technologies in hopes of making it an industry standard, OpenDoc grew increasingly unwieldy. At the same time, Microsoft used the synergy between the OS and applications divisions of the company to make it effectively mandatory that developers adopt the competing OLE technology. In order to obtain a Windows 95 compliance logo from Microsoft, one had to meet certain interoperability tests which were quite difficult to meet without adoption of OLE technology, even though the technology was largely only useful in integrating with Microsoft Office. OpenDoc was forced to create an interoperability layer in order to allow developers to even consider adoption, and this added a great technical burden to the project."_

And there were others too: [http://en.wikipedia.org/wiki/Compound_document](http://en.wikipedia.org/wiki/Compound_document)

</comment></comment></comment></comment></comment><comment><USER29> The Linus profile is mostly a red herring here, because it is 1) a bad benchmark with a bunch of blocking round trips and 2) mostly profiling the gdbus bindings which are just one binding.

For a more in-depth performance discussion of dbus, check out [http://lists.freedesktop.org/archives/dbus/2012-March/015024...](http://lists.freedesktop.org/archives/dbus/2012-March/015024.html)

Above noted on linux-kernel here: [http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...](http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1939533)

<comment><USER30> The PDF link is sadly dead... (The ml message references heavily to the PDF)

</comment></comment><comment><USER31> And [https://lwn.net/Articles/636997/](https://lwn.net/Articles/636997/)

But, let's stop bitching and come up with alternatives, solutions, or closure. I'm tired of hearing about KDBUS (all love to gregkh) and DBUS.

<comment><USER8> _alternatives, solutions, or closure_

The link you posted has what I think is the right one:

 _The problem is that probably this code is not needed at all._

To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives.

<comment><USER32> _To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives._

Then you need to read and reread and reread Havoc Pennington's posts on why he wrote d-bus in the first place:

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

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

D-Bus provides a service discovery system that lets you not only send messages to named endpoints, but also monitor whether there's something on the other end of the endpoint, and if necessary, request that it be started before you send the message in a non-racy fashion.

It also provides a common, typed, structured, discoverable, auditable serialization layer which is necessary for doing API-style IPC, and a benefit besides since when you "just use sockets" you have to do all the serialization and deserialization yourself, leading to possibly buggy code.

Oh, and it also does multicast, which no other commonly used Unix IPC can do.

People who say "I don't see the problem that d-bus solves" aren't looking hard enough and/or are ignorant of the issues of how software gets developed in a modern environment. D-bus solves _many_ problems with IPC under Linux, and makes developers' lives a whole lot easier when they have to connect with other applications or services.

<comment><USER33> Is there a document that explains the why's and wherefores of dbus? Aside from those posts.

<comment><USER34> You can probably find it here:

[https://wiki.freedesktop.org/www/Software/dbus/](https://wiki.freedesktop.org/www/Software/dbus/)

<comment><USER35> Is there a paper/article that discusses and categorizes the differences between IPC mechanism? Their pros and cons etc. What mechanisms are there? What is used on Windows? OS X/iOS? QNX? BeOS? Android? Solaris? etc.

The Wikipedia article on IPC [https://en.wikipedia.org/wiki/Inter- process_communication](https://en.wikipedia.org/wiki/Inter- process_communication) is really incomplete.

<comment><USER36> this article compare kdbus (and thus dbus) to android's binder: [http://kroah.com/log/blog/2014/01/15/kdbus- details/](http://kroah.com/log/blog/2014/01/15/kdbus-details/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER37> The Linus' explanation is here:

[http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...](http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937442)

"Just to make sure, I did a system-wide profile (so that you can actually see the overhead of context switching better), and that didn't change the picture."

"The real problems seem to be in dbus memory management (suggestion: keep a small per-thread cache of those message allocations) and to a smaller degree in the crazy utf8 validation (why the f*ck does it do that anyway?), with some locking problems thrown in for good measure. "

</comment><comment><USER38> I still fail to see why we need DBUS in kernel, so please correct me and clear my lack of understanding. It is claimed userspace dbus performance is bad, but people want to use it in a much larger scale, so what I deduce from that is there is nobody using dbus on that scale right now, since its performance sucks.

Reason for getting kdbus into kernel, and not a generic ipc but specifically kdbus, is because user space that depends on dbus will continue to work with kdbus.

What I still don't understand is, what is the point of keeping compatibility of currently non-existing userspace, if software that depend on dbus right now doesn't need performance enhancements and can just keep using regular dbus, and software that need high performance bus doesn't even use dbus since it's slow? Under these circumstances, why they insist on making kdbus strictly a dbus implementation but not a more generic ipc mechanism?

</comment><comment><USER39> Now is the time for Linus to disappear for a few days, and re-emerge with a sane IPC design that both binder and dbus can build on.

Bootstrapped in itself, of course :) (I have no idea what that would even mean in this context. But hey, it's all wishful thinking, right?)

</comment><comment><USER40> But this doesn't benchmark systemd's userland dbus implementation. That one is much better, right?

<comment><USER41> I hope so, but no one except systemd is using it yet. Last time I checked the sd-bus.h header isn't installed with systemd yet due to the systemd folks concern that that API for sd-bus wasn't finalized yet.

It would be very interesting to benchmark it against the glib implementation (which most people, even if they aren't using glib directly, are using these days).

</comment></comment><comment><USER42> Can someone point out where the quote comes from? I'm not a DBus developer but I'd like to know why the subject is what it is, and not something like "Issues with capability bits and meta-data in kdbus" or "Kdbus needs meaningful review".

<comment><USER29> It's Linus being hyperbolic. Read follow-ups in the linux-kernel thread to see more specifically what these benchmarks mean.

</comment></comment><comment><USER43> What's potato, as said in the mailing list?

<comment><USER44> Internet slang for a device, often a camera, of poor quality or outdated technology.

[http://www.urbandictionary.com/define.php?term=potato&defid=...](http://www.urbandictionary.com/define.php?term=potato&defid=6321730)

</comment></comment><comment><USER45> Let's talk about the elephant in the room.

This is quite obviously the NSA adding massive additional attackable surface area to the Linux kernel.

They did it to SSL/TLS, they did it to many others, they are now doing it in earnest to Linux.

First systemd, now kdbus. Keep this up and OpenBSD, or something else, is going to kill the Swiss cheese that Linux is becoming. I love Linux, so it is sad to see this happening.

<comment><USER46> systemd, kdbus and pulseaudio - wow r00t lol. kthxbai /nsa.

Seriously, its already a huge mess to administate a GNU/Linux with systemd and dbus and polkit already as it is. Its the only parts of my system where I feel I cant really inspect its inner workings. Its a black box.

<comment><USER45> I absolutely agree it is a mess for other reasons as well; but let us attack it on all angles, and I think security is the most important one these days.

</comment></comment></comment><comment><USER47> Should be rewritten in Erlang or Go, if you'd ask me.

<comment><USER48> Are you missing '/s'?

</comment></comment><comment><USER49> Another great Linus quote:

"The people who talk about how kdbus improves performance are just full of sh*t."

[http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...](http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1939166)

<comment><USER50> You are not quoting the part where he shows his benchmark results, analysis of the problem, and suggested solution. I don't necessarily agree with Linus' tone or choice of words, but what you are doing is far worse. I'm not even sure if you are trying to be sarcastic, but that does not even matter: You are not contributing anything either way.

<comment><USER49> I have made an observation from Linus comments which is sad specially to people who worked on KDbus all this time. If you think your comment helped anything maybe you should consider making them when you see comments like the next one:

quote: """ amelius 3 hours ago

Should be rewritten in Erlang or Go, if you'd ask me. """

otherwise you are full of sh*t. :)</comment></comment></comment>


Why AlphaGo Is Not Such a Big Deal - <AUTHOR> http://www.somatic.io/blog/on-alphago-intuition-and-the-master-objective-function <comment><USER2> Maybe the next goal for AI should be comprehensive learning when we master deep learning. AlphaGo is still an encouraging progress though.

</comment><comment><USER3> So many machines in behind, of course AlphaGo would win.

</comment><comment><USER4> I think AI will be the next revolution!

</comment><comment><USER5> Cool!</comment>


The Elements of Drawing: John Ruskin's Teaching Collection at Oxford [video] - <AUTHOR> http://ruskin.ashmolean.org/education/8989/9033 <comment><USER2> John Ruskin was a prominent art critic during the late 1900's who held in great esteem the academic art of the period. His works are a good illustration of the generally held attitudes of that period, but he was on the wrong side of the notion of abstraction that began to take root in Paris. Further reading: [http://www.tate.org.uk/whats-on/tate- britain/exhibition/turn...](http://www.tate.org.uk/whats-on/tate- britain/exhibition/turner-whistler-monet/who-what-when/ruskin-v-whistler)

<comment><USER3> Nice try, calling it the "wrong" side. For more on that side, check out Art Renewal Center: [https://www.artrenewal.org/articles/Philosophy/TheReal19thCe...](https://www.artrenewal.org/articles/Philosophy/TheReal19thCentury/thereal19thcentury.php)

<comment><USER4> Being on the wrong side of a movement just means the losing side, nothing objective.

<comment><USER3> I had considered that, but still detected — perhaps incorrectly — a whiff of implied denigration in the choice of what to say about Ruskin and how to say it.

My comment was an attempt to establish a neutral balance by linking to an argument in favor of the wrong side. If anyone has a good argument for the right side — for why abstraction rules and traditional drawing, painting, and sculpting skills are worthless — I would love to read it. Hopefully, it amounts to more than "because we have photography now".

I may disagree with what I perceived as the tenor of the original comment, but I saw no reason to downvote it. I see no reason why mine should have been downvoted, either.

</comment></comment></comment></comment><comment><USER5> I liked how he challenged our edge-detection NN in lesson 3. With a gray paper, it is possible to use a dark and white pencils, making 2D looks like 3D. He does it again in lesson 8, drawing some leaves.</comment>


Software Engineer Salaries - <AUTHOR> http://www.glassdoor.com/Salaries/software-engineer-salary-SRCH_KO0,17_SDAS.htm

<comment><USER2> The information it's showing me for the NYC area is basically worthless. The listed companies have only 1 or 2 salaries reported, the numbers on the salary range bars for each company don't match up with the labeled axis at the top of the list, and nothing is actually sorted as far as I can tell.

<comment><USER3> Same with the Los Angeles salaries. It also won't let you sort unless you sign in with Facebook or sign up. As far as I'm concerned, this is essentially a spam entry on HN.

<comment><USER2> I signed in with Facebook and it still didn't make any sense.

</comment></comment></comment><comment><USER4> Lots of managers and contractors on the first few pages of that list. Guess that's where the real money is... not software engineering.

<comment><USER5> Contractors get paid more for the same job as a salaried employee to make up for the fact that they're not getting any benefits and don't have any guarantee of long-term employment. Unless they're taking this into account somehow, comparing contractors to salaried employees isn't an apples-to-apples comparison. It's likely that contractors are getting paid more on average anyway, but not nearly to the degree that it looks like based on this data.

<comment><USER6> Unless we are talking about the hourly wage paid to an agency. This can often double what the contractor is being paid.</comment></comment></comment>


One to Zero: 21st century to the Dark Ages - <AUTHOR> https://medium.com/@haseebj/one-to-zero-890f1008257f <comment><USER2> Hey good luck. I am from the same part of the world and agree 100%. I should point out though that there is widespread use of UPS and generators. Not sure if people will go completely off the grid, but initially you are definitely a 'cheaper generator', if cheaper. Like you said its a cash-based economy, and people don't like to put a lot of money up front even if it means savings in the long run, so how will you combat the high initial investment? I do think this is the viable solution. Also you should look into transmission losses. I have heard power lines there are between 30% and 50% lossy.

<comment><AUTHOR> Thanks, all really good points. Initially I'll be targeting the high end residential and commercial market to get cash flow going and sustain the business. Residents in major cities such as Karachi, Lahore, and Islamabad purchase their houses for US$500k+ with cash. The goal is to sell them on solar electric systems ranging from US$5k to 15k with the promise they can completely or mostly eliminate their electric bills, and get their ROI in 5-7 years while getting uninterrupted electricity for 25 years. The market is ripe and I have seen residential installations worth US$35k with upfront cash.

Generators and UPS are current alternatives. However Generators, very loud and expensive to purchase, are dependent on fossil fuel (dirty) prices, which are very low at the moment but fluctuate routinely. UPS devices produce square wave outputs that damage appliances permanently. Convincing the market to go solar instead because of these reasons is the eventual sales challenge for sure.

Transmission losses (including electricity theft) are part of the sales pitch. They are a big reason why Supply doesn't meet Demand and Load Shedding has to be enforced.

<comment><USER3> I would focus on incremental systems. Something like 10$ cellphone, 100$ for lighting, 1,000$ for PC, 10,000$ for AC.

Also, midrange UPS don't output square wave, I fact solar systems include a UPS for night time power. So, you could sell a ~3k, UPS system with bult in solar hookups where people can add pannels over time.

<comment><AUTHOR> Thanks and completely agree. I'm going back home with an open mind. There's lots I will learn on the ground and will fine tune my approach according to the realities. I reckon Energy Efficiency will also play a big part in my approach down the road. Wanted to initially target a high end market segment with the least barriers to entry.

</comment></comment></comment></comment><comment><USER4> An opportunity I see is retrofitting a low voltage power distribution system within homes as part of the retrofit. Solar and batteries are already direct current and that's what digital electronics use...wall wart transformers are a kludge, directly plugging in the USB cable that charges my phone makes more sense.

At the extreme end, a system with solar cells and batteries that only serves digital electronics might be the MVP for the One to Zero market.

<comment><AUTHOR> Thanks. I agree the MVP you mention is going to play an important role for the larger market segment (mid to low income).

<comment><USER4> To me, it looks like the place where there is a strong potential for early mover advantage: i.e. it's a zero.

Solar system installation is a commodity market inside a larger commodity market of general power systems. Residential sales are individual and high touch (even higher touch at the higher end). Construction projects have long timelines and often substantial local regulatory overhead, especially for electrical power systems at the scale of buildings.

On the other hand, low voltage power for digital devices can scale outward from small partial installations, e.g. one solar panel, one battery, one outlet. Low voltage power already has DIY components for applications such as landscape lighting. And it's not directly in competition with Seimens, Caterpillar, GE, and the local power company. And it can be delivered via DHL or UPS or the local retailer.

After 25 years in the industry, I don't believe that construction scales except for linearly. Of course that may be your goal and it's a good one.

</comment></comment></comment><comment><USER5> I'm curious if there are other distributed generation techs which could make sense -- 1KW windmills, thermal/stirling/etc.

Solar economics might make it win over everything else, though.

Also might be fun to subsidize solar by selling data. In exchange for hosting/keeping clean/etc. the solar panels, you get most of the power, and a small amount of data, which is then provided as commercial data service to the nearby area.

<comment><USER2> Terrorism is too real in that part of the world unfortunately as you already know. A 1KW windmill will turn into a 3 ton pile of smoldering scrap metal if the right mouths aren't continuously fed. Also the idea is de-centralizing power generation to skip the transmission step where all the leakage exists.

<comment><USER5> Oh, I think of 1KW as household size (for a water pump or something, and a large household, true)

<comment><USER2> Oops, sorry, read that as 1MW for some reason.

</comment></comment></comment></comment><comment><USER6> Random anecdote while reading this: I used candle light few years ago after being forced off grid for a few hours at night. It was marvelous. If it wasn't for fire hazard I'd use it every night.

<comment><USER7> My kids and I love LED candles. They look like 3-inch diameter cylindrical candles, complete with a wax exterior (which is, I admit, really frustrating at times), and have an LED inside that provides a flickering light. As a bonus, the batteries seem to last nearly forever since it's basically one LED and a small circuit.

<comment><USER6> I have to test them. A guy even made real candle spectrum analysis to control a LED one making it 'realer'.

<comment><USER8> Link?

<comment><USER6> My pleasure [https://cpldcpu.wordpress.com/2016/01/05/reverse- engineering...](https://cpldcpu.wordpress.com/2016/01/05/reverse-engineering- a-real-candle/) (but not my blog)

</comment></comment></comment></comment></comment><comment><USER9> > _One to Zero : from the 21st century to the Dark Ages, instantly. This is > life for billions in the developing world, connected to aging electric > grids. One minute you're in Islamabad watching Netflix while facetiming on > your iPad. The next instant, the power goes out. Your Wi-Fi router, > lighting, wall mount TV, fridge, air conditioner are off. It's 115 F. > Welcome back to the Dark Ages._

Most people in the "developing world" don't have neither wifi, nor air conditioning. In fact almost a billion lives in shanty towns, in make-shift "homes".

<comment><USER10> I think saying most people in the developing world don't have wifi or air conditioning is an overgeneralization.

I've lived in Ghana and currently in Zambia and people do have WiFi, 4G and airb conditioning. Granted there are large populations that don't have great homes, the need for electricity (hospitals) is great.

For example, at the teaching hospital in Lusaka, there isn't even running water.

I wish OP best of luck and will be rooting for him.

<comment><USER9> > _I 've lived in Ghana and currently in Zambia and people do have WiFi, 4G > and airb conditioning. Granted there are large populations that don't have > great homes, the need for electricity (hospitals) is great._

That's only in the bigger cities, and the circles expats are commonly associated with. And not even there for a sizable majority. And Ghana is one of the most developed (and less war-torn) parts of Africa.

</comment></comment></comment><comment><USER11> What is the origin of the title "One to Zero"?

<comment><USER12> It's a pun on [http://zerotoonebook.com/about/](http://zerotoonebook.com/about/)

<comment><USER13> The book's description is ridiculous:

> The next Bill Gates will not build an operating system. The next Larry Page > or Sergey Brin won't make a search engine. Copying others takes the world > from 1 to n, adding more of something familiar. But when you do something > new, you go from 0 to 1. Tomorrow's champions will not win by competing > ruthlessly in today's marketplace; they will escape competition altogether, > because their businesses will be unique.

Both Gates and Brin "copied" existing ideas and improved them. CP/M and Altavista (I think?). So both examples are of people going from 1 to n, not 0 to 1 as they seem to be suggesting.

Going from 0 to 1 brings you a lot of praise for being a pioneer or innovator, but rarely money. Going from 1 to n seems to at least as hard and it's where the money is.

<comment><USER14> This doesn't fit as well in a blurb, but a more precisely-stated version of Thiel's thesis is that, since truly competitive markets tend to drive down profit margins, you want to have some big advantage that's hard for competitors to duplicate. MS-DOS's big, hard-to-duplicate advantage was the IBM PC, and Google's advantage is that their search engine was just so much better than others in the early days -- it had a much better ranking algorithm and didn't bloat up its pages trying to be a "portal". For another example, consider Facebook: its advantage is that approximately everybody's friends are on Facebook, and not on, say, Google Plus.

Does that sound more reasonable?</comment></comment></comment></comment>


Mark Guzdial's Amazon Blog: Being surprised by media computation Permalink - <AUTHOR> http://www.amazon.com/gp/blog/post/PLNK21TULH19DR1MI <comment><USER2> Before soundcards came out, all there was available (for PC) was the PC Speaker.

Some games emerged that had digitized sounds/speech which played via the PC speaker, with only CLICK and UNCLICK as options.

<http://en.wikipedia.org/wiki/Dark_Seed_(computer_game)>

You too can have this effect on your home Linux computer:: <http://www.linuxlots.com/~dunne//lj.pc_speaker.html>

</comment><comment><USER3> Guzdial seems to hint at applications to audio compression, but my mind turned to speech synthesis and recognition. I'd like to maximize a handful of audio clips of human voice and look for patterns.</comment>


Here's Why Twitter Apps Are Such Lousy Investments - <AUTHOR> http://www.businessinsider.com/heres-why-twitter-apps-are-such-lousy-investments-2010-9?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+typepad/alleyinsider/silicon_alley_insider+(Silicon+Alley+Insider) <comment><AUTHOR> "if your company's name includes the words 'tweet' or '140' in it, you're f--- ed."</comment>


A HFT's Response to Michael Lewis' Flash Boys - <AUTHOR> http://www.amazon.com/Flash-Boys-Insiders-Perspective-High-Frequency-ebook/dp/B00P0QI2M2

<comment><AUTHOR> I thought this would make a good counter point to Michael Lewis' popular Flash boys book.

It's written by someone who has actual market understanding and I found it to be a pretty devastating rebuttal to Lewis' book.

Not surprisingly it has a U shaped review curve with people either giving it 5 stars or 1 star much like the beloved book SICP.

If you'd like both sides of the story then I'd recommend reading this, it can be consumed in an evening!

<comment><USER2> Not so much U shaped as you say. 19 5star reviews, only 2 1star reviews and no other reviews as of right now. Kinda seems like the author had his buddies review it on amazon at this point. But this could be a good book; I didn't read Flash Boys, but if I do or did, I would want to read something like this as well.</comment></comment>


Why Do We Have Blood Types? (2014) - <AUTHOR> https://mosaicscience.com/story/why-do-we-have-blood-types <comment><USER2> TLDR: nobody knows. Blood type arises from variations on a single gene called ABO. But it's always hard to infer "why" from genes, genetics is not a source of just-so stories.

Hypothesis given: "So it's possible that each strain of norovirus has proteins that are adapted to attach tightly to certain blood type antigens, but not others. That would explain why our blood type can influence which norovirus strains can make us sick."

<comment><USER3> There is no purpose or planning behind evolution, so blood types could just be a random genetic mutation that does not reduce the chances for individuals of having offspring that survives long enough to have children. Just like curly vs flat hair or blue vs green eyes.

I'm not a biologist so I might very well be wrong about that, but it seems that one possible explanation is that the question has no meaningful answer.

<comment><USER4> Given your hypothesis you also need an explanation why there aren't thousands of blood types.

<comment><USER5> Actually there's quite a few, if you count all the subtypes and antigens [https://en.wikipedia.org/wiki/Human_blood_group_systems](https://en.wikipedia.org/wiki/Human_blood_group_systems)

</comment></comment></comment></comment><comment><USER6> I think the theory at the end of the article sounds quite plausible.

Namely that blood types are playing rock-paper-scissors against bacteria / viruses. Pathogens can learn to target a single blood type if it's predominant (just like you can learn you should play Paper if your opponent usually goes for Rock). So it's better to have a population of mixed blood types, and anytime it starts to get out of whack, disease exerts a force that disproportionately takes the newly popular blood type out of the gene pool, pushing back toward equilibrium. Just like the Nash equilibrium RPS strategy is rand().

How to test this experimentally? I'm no molecular biologist, but maybe let viruses reproduce in an environment where one antigen is present for enough generations for them to mutate to have increased effectiveness attacking it (maybe you can determine this from an increasing viral reproduction rate?), then a testable hypothesis that would confirm the theory is the mutation also caused the viruses to lose efficiency at attacking another blood type's antigen.

</comment><comment><USER7> Genetic variety does not need immediate purpose. Where slight changes to gene make no real difference to survivability one should expect changes to arrise and be maintained in a populations. Perhaps one day that gene will matter more. The population will then be ready for the test because it has already fielded a bunch of options. Being more ready to evolve as needed is itself an advantage.

Random mutation is a cornerstone of evolution. Where those mutations are not being naturally selected the randomness builds into a greater number of types. If we didn't see that, if genes not tied to survivability were homogeneous, then we would need to reevaluate core theory.

</comment><comment><USER8> Fascinating.

This is an example of a non-tech-related article that's perfect for HN because of the "intellectual curiosity" guidelines.

</comment><comment><USER9> I tested out the blood type diet for a few months. I am a type AB+ and I followed it very closely. I will say I slept better, had more sustained and balanced energy levels, and better focus. I also didn't get that faint, dizzy feeling if I couldn't eat right on schedule. I don't have any hard evidence for the diet, but my results were intriguing enough for me to think there is something to it. However, given what we know about placebo I wouldn't be surprised if I was just releasing everything I needed based on belief.

TLDR: Who knows...

</comment><comment><USER10> Very nice article. Also about the Bombay Blood Type

</comment><comment><USER11> most easily digestible explanation of blood types I've seen

</comment><comment><USER12> tldr someone ? :D

<comment><USER13> "More than a century after their discovery, we still don't really know what blood types are for. Do they really matter? Carl Zimmer investigates."

</comment></comment><comment><USER14> Quick rant about websites that continually bug you about cookies, even to the point of having a page that describes how they track you across sites using their cookies, for your benefit of course. I miss the pre-corporate web. Geocities sites and all.

<comment><USER15> Blame Europe. :)

[https://www.cookielaw.org/faq/#WereoutsideoftheEUareweaffect...](https://www.cookielaw.org/faq/#WereoutsideoftheEUareweaffected)</comment></comment>