Hacker News new | past | comments | ask | show | jobs | submit | mattrjacobs's comments login

I completely agreed with you until I had kids and then the opposite was true. I don’t think either option is good or bad- just different trade offs.


I grew up in a sort of building style you don't see in America. High rise flats built around a courtyard/park. Lots of room for kids to play in, lots of built-in friends of all ages groups for the kids, flats big enough for families (shared rooms for younger kids is fine). Honestly, if those existed in America I could think of nothing better to raise children in.


The did/do exist as "projects", and developed a horrible reputation in the US for other reasons and there was a backlash against them.


Interesting, so that style was practised mostly in social housing projects? I could see how that could lead to problems especially with drug crime and guns and whatnot. About the worst thing that ever happened where I grew up was a foul on the basketball court.


Yes I believe housing projects were the first/main use of that style here. I know I have an instinctive negative reaction to them (mainly though from TV shows focusing on the horrors of projects).


Very interesting. Thank you for sharing. I live in America too, now, but I haven’t ever actually seen the projects and the ones in The Wire aren’t quite what I was thinking of. Those look ugly and run down.


The most famous implementation of the social housing "towers in the park" model - the Robert Taylor Homes in Chicago - has been torn down. One of the many problems with the project was (in my opinion) that the tower:park proportions were way off, giving the complex an inhuman scale. I blame the influence of Le Corbusier, who does not seem to have ever met a human aesthetic instinct he did not try to subvert.

The mid-rise courtyard+playground styles I see in central and northern Europe today, on the other hand, are pretty much ideal for family life. Just enough density to support a walkable daily life with lots of serendipitous social encounters, eyes on the street, a view on the kids playing with enough proximity to intervene if something goes wrong, and the opportunity for first-floor private garden space and aesthetic personalization throughout.


You can blame the architect if you want, the aesthetic was certainly...austere. But I find a different argument far more compelling. The city politicians knew exactly what they were doing in housing large swaths of the urban poor in a small section of the city.

Not only that they used those projects as a way to punish independent political adversaries in the city government. Everyone who originally conceived of the programs tried to build mixed density communities spread throughout the city that were only partially social housing, but racism & power politics prevented that.

Then the city doubled down & didn’t provide services appropriate for the number of people now densely packed in one place.

The book “Blueprint for Disaster” outlines the history of this very well.


Agree. I certainly don't think the architecture was the primary cause of the dysfunction at RTH, but rather a visible symptom of Chicago's ill-considered, politicized, and often malevolent housing policy.


Every single comment here is about the name “serverless”. Can’t actually think of a better bikeshed example than this.


Just coming to this article, I find my self agreeing with you and the gist of the thread about serverless being a horrible descriptor at the same time.

It was just one thread though, and I could see how it sucked people into its vortex, I haven't even had a chance to read the article yet, and here I am doing the same as everyone else (including you...). Well, worse actually, as we've contributed to a new thread.


Considering that all we have in that shed is a bunch of tools for the county workers maybe it shouldn't be called a bikeshed.


"[T]he English language... becomes ugly and inaccurate because our thoughts are foolish, but the slovenliness of our language makes it easier for us to have foolish thoughts."


I find it easier to live with if you consider it to mean "daemonless". So not about hardware, but what software you don't have in your project.


If you want to understand the impact of an S3 outage (or many other kinds) ahead of time, Gremlin (http://gremlininc.com) has built a tool to run these scenarios on your infrastructure.

Happy to answer any questions about the tool, either here or over email.

(Disclaimer: I work for Gremlin)


I'm interested in the distinction you draw between shipping and finishing. Care to elaborate on what that meant in a Google context?


Vertically integrated web based businesses like Google have a tremendous advantage that comes from being able to prototype something and then instantly have it available to all customers with a simple push [1] out to production.

There were of course different levels of thing, Gmail was a 'big' thing, updates to the calculator one box, were 'small' things. But everything has a certain amount of technical debt [2] associated with it. This was especially true of infrastructure changes as there were often many subsystems that might be affected in one way or another and each of them usually had some sort of 'porting' effort to get with the program as it were.

"Shipping" was getting something running in production without having it be kicked out by SRE [3]. "Finishing" was having everything that was affected by the change that had been in production before shipping fixed and/or updated to run with the new system. As with most large systems I've had exposure too there is a big chunk of obvious stuff that is affected and then it asymptotically approaches zero. People seemed to start leaving at the 3dB [4] point.

[1] "pushing" is the process whereby a new capability is delivered into the production clusters that are customer facing.

[2] "technical debt" is the requirement that additional work is going to be required later (the debt) to resolve issues that aren't show stoppers initially.

[3] SRE see "The Roads must Roll" by Robert Heinlen.

[4] "3dB" is 3 decibels. In engineering or control systems the 3dB point is where the signal has been reduced in strength by 1/2. Also known as the 'cutoff' point for a filter.


For any poker players out there, this is analogous to the Texas holdem preflop matchups JTs, 22, AKo.

AKo > JTs : http://twodimes.net/poker/?g=h&b=&d=&h=Ah+Kd%0D%...

JTs > 22 : http://twodimes.net/poker/?g=h&b=&d=&h=2h+2d%0D%...

22 > AKo : http://twodimes.net/poker/?g=h&b=&d=&h=2d+2h%0D%...


To elaborate on your point a bit, for the non-poker players (I am one, so I understand your analogy, but non-poker players might not quite, at least in this presentation):

Typically, when playing a game of poker, one considers a pocket pair (22, 33, 44, etc.) in a game of Texas Hold'em, vs. two "overcards" (2 hole cards bigger than the pocket pair) to be considered, for quick calculation purposes, a coin toss. However, the pocket pair in a given situation vs. two overcards of a different suit, is a slight favourite overall.

So this problem typically presented - I believe it was originally stipulated by Daniel Negreanu, a professional player, but I could be wrong - is, a knowledgeable poker player challenges a poker player with less knowledge to a speculative bet.

The knowledgeable poker player offers the opponent to choose a hand from the following: AKo, JTs, or 22. Then the player on the up-and-up chooses second - and given their knowledge of the slight advantage in a given situation, chooses the hand with the higher odds.

However slight they may be, of course, the expected value always allows the player choosing second to edge out the person who chose first.

Because they are so similar in odds, an average or below average player may not realize the slight advantage 22 has over AKo, while JTs has the slight advantage over 22. AKo over JTs is of course a larger advantage than the other two situations - almost a 60/40 advantage.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: