The Vimes Boots Theory: Further Reflections - <AUTHOR> https://siderea.dreamwidth.org/1477942.html <comment><USER2> Louis CK has a fantastic bit about this:

"When you're broke, the bank starts charging you money... for not having enough money. If you have a lot of money, they give you money. Because you have a lot of money! You have so much money that we should give you some! Because you have a lot, you should have more! Here, take more money! Take this guy's $15, fuck him, you should have it!"

Like the article says, class boundaries are also knowledge boundaries. Because you don't know of any alternatives, you bank at the local BoA and get taken advantage of to the tune of $15/month in perpetuity with a low balance, or even pay a percentage at the corner check cashing place. Or you can get free banking and around 3% APY today if you have savings, know how and where to bank and how to structure a 12-month CD ladder. It's expensive to be poor!

<comment><USER3> I have never paid for banking in my life. I lived for thirty years in England and then moved to Norway where I have been for 32 years and have had accounts with several different banks. The only charges I have ever had to pay are in Norway where I have to pay an annual fee for a credit card from my bank (I have several other credit cards that cost me nothing).

As far as I know this is normal in the UK and Scandinavia, not sure about the rest of Europe though.

So how do US banks justify USD 15 a month?

<comment><USER4> As a Norwegian with no affiliation, a huge shout-out to Sbanken (earlier Skandiabanken) for providing _anyone_ with no setup fee (at least when I got mine almost 20 years ago), free unlimited accounts, no credit or debit card fees (even abroad!) other than a standard yearly renewal fee, and all-round fantastic service. Their "secret" is so simple it's ridiculous: they are online only - all services are through their web site. They also enforce multi-factor authentication using any one of several services, most of which can also be used with other banks and government websites. I've many a time longed for something like it while living in various other Western countries, but for some reason (regulation, inertia?) there seems to be nothing like it elsewhere.

<comment><USER3> Yes, that's my bank, they're brilliant. So much better than the account I have with Santander in the UK. But even DNB (former Postbanken) is better than banks in other countries and has been for a very long time. I had online banking with the Postbank even before I had Internet.

</comment></comment></comment></comment><comment><USER5> Heh, last year I bought expensive boots explicitly because of the Vimes' theory, but I have to say in _my_ case it didn't work out.

Maybe this comes from what the post says about "knowing _what_ to buy", but I bought boots made by a 2nd generation shoemaker constructed out of leather carefully prepared here in Chicago. They're recraftable so I figured after the bottoms wore out I could fix them. But here I am a year later and the inside sole is coming up and squeaks with every step. I'm going to have to take it in to get it repaired, for probably $15-$20. From a consumer waste and natural resources perspective, I'm still happy with my purchase, but I'm pretty convinced that shopping every year or two at Walmart would leave the average person ahead, cost-wise.

More generally, I wonder to what extent the Vimes theory is true. Richer people buy higher quality items and generally have a more _luxurious_ life, but I'm not sure that it's cheaper overall. Or at least, there's a point where it's obviously the case (c.f. the T ticket vs Charlie card point in the post), but I think it happens pretty early on in wealth.

Case in point, I bought a nice 2 year old Chevy from a dealer with low miles for $12,000 a few years ago and haven't had a problem with it. I can imagine _that_ paying itself off quite easily vs. making do with a $3,000 beater that keeps falling apart and needing service. But from a purely _cost_ perspective (not luxury), I don't think beyond maybe $15k or so, more money in a car will save you in the long run.

So, I still kind of get Vimes' theory, but I only think it applies from, say, poverty to lower middle class level. Beyond that, I think upper class people spend more money on stuff, and get a sweet life because of it, but not as a cost saving measure.

<comment><USER6> Insole can probably be glued back easily enough.

With things like these though, it's important to know if you are paying for quality, luxury/prestige, or some combination thereof, as these are different things that may be considered worthy of paying extra for. With things that are not (strictly) utilitarian, it could be far more of the latter than former. Shoes made of leather from the butt of a baby purple dragon would be quite expensive, but that leather isn't necessarily as strong as your run of the mill cowhide.

Gets even worse/more complicated if the maker used to be known for quality but starts taking shortcuts and quality goes down, but price doesn't.

As some anecdata, I have a couple of leather belts that are if not older than I am but certainly pushing 40, worn very often. Still look as good as new, but I am sure they were very expensive when originally purchased. Another belt is a few years old, from a brand that's known for making quality luggage (or used to be), not worn too often, and wasn't cheap. Leather's already cracking. On the other hand, really cheap ones look terrible even sooner, so the law still holds as a general rule.

<comment><USER7> The indicators used to appraise the quality of something have a big part to do with the overall successful application of Vimes theory.

Consider a merchant has 2 classes of boots: TypeA that cost $100 and last 5 years, and TypeB that costs $60 and lasts 2 years. Both boots are made by the same merchant, and TypeA has better materials than TypeB, which is primarily why it lasts longer, not necessarily due to the merchant's craftsmanship ability. In such case, if someone could afford the TypeA boots, we can make sense of Vimes theory because it comes out to be cheaper over the life of the item due to better quality of materials, since quality of craftsmanship is basically the same.

Of course, this is pretty idealized. There's many other factors that influence quality and how it's perceived.

OP could have paid a premium to a longstanding brand traditionally known for quality that has cut corners over time and now uses cheaper practices.

I think there's a lot of cases similar to OP now, where people pay a premium for a TypeA item expecting better quality construction and durability for the price, yet end up getting something not that different than a TypeB item.

Marketing also has a lot to do with this. It's particularly frustrating when buying from a brand that _used_ to make good stuff, and now sells stuff way worse under the same name (I'm looking at you Pyrex). I also hear a bunch of watch fans calling out the formerly high-end watch brands for cheapening their construction quality while still keeping the price high because buyers pay for the label not the actual quantitatively measured useful quality of the item. Once brands get to that level, they know they can basically put out mass manufactured expensive garbage and people will still buy it because they associate the brand with former traditional quality construction (much like many fashion brands of today that are made in similar overseas factories with similar textile suppliers).

<comment><USER6> Exactly. I remember when HP printers were built like tanks, too.

The problem, too, is that apart from goods that are tested for durability, there aren't many signals a layperson can use to judge if say boots are well- built and made of quality materials.

Then, of course, "quality" is multi-faceted, too. Type A boot could cost more because it is better-looking, light, flexible, comfortable, and made of thin, soft, supple leather as smooth as baby's bottom. But because of that, it will fall apart as quiclly as WalMart boot for $20; you'd just enjoy wearing it more.

</comment></comment></comment></comment><comment><USER8> Taken further we find the problem of bottlenecked economic throughput or market participation due to the poor's access to capital. Markets thrive on distributed inputs to arrive at a consensus on value - the more participants participating, the more throughput of information being supplied to our markets. More participants is more information which allows healthier markets which provides more opportunities for growth.

So what's the cost of a loan or other financial products? Of course there's utility in providing upfront capital in exchange for time-spread payments and interest (buy the $200 boots today), but what of the macro-cost of decreased market participation for the duration of the payments? The loan payments with interest is money that could've been used by an individual participating in the market that is instead piped to the financing provider who, by definition, is already richer.

Given the rich, or a rich organization, has different buying habits and participation in the markets (different perspective = different information), how much economic flow, throughput, and growth are we losing from financial mechanisms which go from poor -> rich? In this sense wealth concentration is a problem of bottle-necking economic potential by depriving our markets of participants and diverse perspectives.

</comment><comment><USER4> Related is something which bug me about online ratings: there is just no way to know which of the people who voted on a category of products have anything like the same idea of "quality" as you do. I've certainly bought absolutely awful stuff online which had a 90%+ positive or better than 4/5 star rating. What ends up happening is that analysing the ratings of hundreds of thousands of customers is very often _less valuable_ than chatting to a single person who has had a good experience with a single product. This is how flawed online ratings are.

<comment><USER6> There's also the selection bias -- people who think the product is OK, but nothing special probably will not spend too much effort posting a review. But of course even if they do bother posting a review, ratings often do not have anything to do with the quality of the product.

</comment></comment><comment><USER9> My personal shoes where €40 models that would last a few months at most. I bought more expensive ones, and they would also last a few months at most. Both me and my mom are known in the family for being total shoe disaster zones. So I'd given up that particular fight.

Then one day my wife and me ended up in a small, local shoe shop. No customers there, just the owner. We weren't even looking for shoes. The owner was getting pension-aged and would close his shop in a few months.

He told about how some company would make great but expensive shoes, and build a name for quality. After a few years, a big company would buy the brand, raise the price, lower the quality, and coast on the perception for a few years. He told this cycle goes on and on. He stopped selling the shoes as soon as he know the quality went down. Shoe salesman kept trying talking him into selling these shoes as it was easy money, and he kept throwing them out of the shop. He was getting very pissed off at this point.

He talked me into buying a pair for about €160, which isn't the most I've paid for shoes, but more than I would give for that specific pair - they looked like my normal €40 models. Now these shoes lasted for about 7 years, which basically obliterated any personal record.

Unfortunately, the shop is gone now, and the only shoe shops left are the big chains. I am still willing to spend the money, but I have no idea what I should buy.

</comment><comment><USER10> I suspect the accuracy of this theory is very, very market/area dependent. Sometimes paying more will get you a better product sure, but sometimes you'll have markets where the free/cheap solutions are better or where prices are mostly the same for the same quality products across audiences.

Software is the obvious example of the former (with open source software often being as good or better than paid alternatives), but information/journalism/research/whatever could count to some degree too. If you know where to look, there's free content on par with some of the best newspapers and journals, especially now with the internet and passion projects/people using Patreon or donations to fund their work. They're the channels I feature in some of my underrated channels lists.

For fields where you can't really pay more for a better service, well entertainment usually comes under that. That CD or DVD or video game or book will cost roughly the same regardless of who buys it and what shop they get it from.

The idea works pretty well for clothing and appliances, struggles when it comes to software and is virtually irrelevant for movies or games. Then again, I guess you could say software is a field where at a certain level, the only thing that even remain are opportunity costs. Get skilled enough, and every buying decision becomes a question of whether you want to buy/download to save time or rebuild it yourself over the next few weekends or so.

</comment><comment><USER11> This is a pretty incomplete metaphor. If the rich person bought the cheap boots, they could invest the remainder of their capital in the market at say, a 7% annual return, over the long period they're not actually saving money by buying the more expensive stuff, most of the time.

</comment><comment><USER12> Since neither the OP, nor the comments give them, I'd like to have a few examples of high quality expensive shoes ... If anyone has suggestions, please enlighten us.

<comment><USER13> I bought a set of Lowa Renegade boots 1.5y ago: [https://www.lowaboots.com/mens/hiking/renegade-gtx-mid- sepia...](https://www.lowaboots.com/mens/hiking/renegade-gtx-mid-sepia-sepia)

Originally for hiking, but they have also seen daily service as winter boots. Been very pleased with them for both purposes, and they're still as good as new. (As a student, this was a pretty big investment for me, but I'd definitely do it again!)

</comment></comment><comment><USER14> Off topic, but is dreamwidth.org a Livejournal clone?

<comment><USER15> Sort of, it's started from a fork of LJ code and has been developed since. I can't remember why exactly the fork was made though because LJ has shot itself in the foot basically every two years since it started.

<comment><USER16> IIRC, Dreamwidth was forked off LJ after one of LJ's great fandom purges (probably either Strikethrough or Boldthrough). Basically, they cracked down on ton of fandom communities for adult content, and the fandom communities said, fine, we'll just make our own then, and did.

</comment></comment></comment><comment><USER17> The thing I don't like about Vime's theory is that it postulates only two price points.

That being said, I buy 200 dollar boots.

<comment><USER18> I don't think it _postulates_ two price points, it just uses two for the sake of argumentation.

<comment><USER17> The essayist doesn't but Vimes world character arc requires that he see the issue in black and white, top and bottom.

I'm sure that was an allusion by Prachett: you're not supposed to think like Vimes. His books always have layers of meaning.

<comment><USER9> Leave of the white. I'd say he sees issues in black. He's a stark cynical copper who has seen anything. A lot of his internal monologue talks about how he wants to unleash 'the beast' but can't because his inner watchmen won't let him.</comment></comment></comment></comment>


Energy Outlet - <AUTHOR> https://energyoutlet.com <comment><USER2> Only provides service in DFW and Houston. Currently, anyway.</comment>


Show HN: Get Visibility for Your Project - <AUTHOR> https://launchpropeller.com/#/submitplaces <comment><USER2> Some (not all) of the services listed seem like they could be very useful but I am verging on the sceptical side. Perhaps clarifying these points will ease my doubt:

1) Who is behind this? I can't find this information easily on the website.

2) How and where from are the testers acquired?

3) Do I receive any demographic data about each tester? I.e.: location, age, etc...

4) Has anyone here tried using any of these services?

<comment><AUTHOR> Good point, I'm going to add more contact information. I have a list of beta testers that is steadily growing, its a good mix of people from reddit and similar sites. I cannot give you demographic data but in the past I've had testers fill out surveys and asked them for their twitter handle (but only optionally if they were OK with it). So we could include that question in a survey for you.

<comment><USER2> Thanks for considering it. I have bookmarked your site; I am not ready for beta testers just yet but will definitely need something soon and this seems very neat.</comment></comment></comment>


The Rust language: memory, ownership and lifetimes - <AUTHOR> https://www.youtube.com/watch?v=gfCtbGiHcg0&feature=youtu.be

<comment><USER2> Great talk! Excellent introduction to the language and a must see for anyone wondering "why Rust?".</comment>


Preparing for 'project manager' interview with prominent Silicon Valley company - <AUTHOR>

I applied for a 'product manager' position at a prominent tech company in the valley, and they responded by asking if I would be interested in an 'IT project manager' position instead.
I have since had a screening with HR, and they've invited me back to interview with various product team members.
My question has to do with whether anyone else on HN has had experience working in project management at a large tech company in the valley.
QUESTION: Does the PM role tend to be more technical (assisting with development of products) or broad-arching management (keeping multiple product teams on schedule and organized)? <comment><USER2> Project managers, depending on the company, can be the project leads or the project scape goats. At well run companies the project manager is in charge of coordinating all the groups, running the project meetings and updating executives on progress (sometimes also called Program Managers). Poorly run companies use project managers to hide flaws in their internal processes and people.

A great way to tell the difference is to ask them about the position and processes. If they are well defined and clean then they likely have their act together. If they are wishy-washy I would steer clear.

Note that project management is VERY different than product management. Project managers are the tactical field commanders to the strategic generals that are product managers. If you really like product management then project management might not be for you.

Feel free to ask more specific questions if you'd like.

<comment><AUTHOR> I appreciate the insight, thanks.

HR didn't share too many specifics as the position is for a new IT department, and so therefore the rep felt she couldn't tell me anymore than that. She gave me the same answer when I asked why the position wasn't advertised...

I have experience leading projects successfully at small to mid-size companies, but I've never held the official title of 'project manager'. Nonetheless, the role is very fitting to my past work experience and personality. I just want to be prepared when I speak with the product team members.

I imagine they could ask me anything from 'describe a time you led a project' to 'brain teasers' to 'writing code' and back around to 'how would you deal with a team member who is slacking?' Are these typical PM interview questions?

<comment><USER2> In my admitted limited experience (I've worked with and hired PMs but never been one myself) typical questions can include:

1\. Describe a project you have managed that went wrong and how you fixed it. 2\. What process do you use to ensure a project is on track? How do you monitor it? 3\. Employee A is behind schedule and Employee B can't move forward with their work until Employee A is done so they are falling behind. What is the best approach to get the project back on track?

And the like.

As you mention, it's very likely they will ask you some subject matter questions about managing IT projects. If they do ask you to write code I would be highly concerned since it would signal to me that they really have not defined the role of "project manager" very well.

Good luck!</comment></comment></comment>


Mugr -- face recognition and search startup enters private beta - <AUTHOR> http://blog.mugr.com/archives/2007/10/30/mugr_enters_private_beta/

<comment><AUTHOR> We're a Phoenix startup doing face search and recognition. We just released Mugr on Monday and would love to hear any feedback you have.

<comment><USER2> Hey MC, the service sounds pretty cool! I'm in the process of learning as much as possible about recognition techniques.

According to the FAQ, you're not performing face detection (you ask users to crop their photos). Did you find that the process was too computationally expensive?

EDIT - after completing the registration process I was given an error page. But the process must've completed, since I can log in and use the site just fine.

I have some additional comments (for instance, when cropping my user photo it'd be nice to see an example of a "good crop" so I know how tightly to focus the box around my face, without having to click through to the guidelines page). Is there an email address I can contact you at?

<comment><AUTHOR> Hey Ed. Thanks for signing up. For the initial registration process, we decided it was easier if we let our users crop their profile images. Later on this week we'll see a post with an example of our software doing face detection.

Thanks for the suggestions. For my email address, check out my news.ycomb profile.

<comment><USER2> Great! Just FYI, you have to put the email address in the "about" text area. I guess the email field is only used internally by YC.

While I've got you here, I'll just my initial reactions:

\- 100KB photo limit is waaay too small. Restrict image dimensions, if anything.

\- Error messages on the side of the page (on the mugshots upload page) are not very visble

\- What kind of things would I put in the "tags" box? Are they comma or space delimited?

\- "The person may be from the orient, but they aren't oriented toward the camera." - This joke is in poor taste...

\- Connections page is empty?

\- I don't really know what to do after I've registered...

\- Problem with links (I see <http://http://> \-- you gotta standardize your inputs!)

\- I uploaded a photo to search, and am returned all users in the network? This page is confusing!

\- In order to limit the number of returned users I cropped just my face and uploaded the photo for search. It seems like I was returned everyone but myself!

<comment><AUTHOR> Ed, thanks again for the feedback.

One of the reasons we're doing a limited beta is to give us time to find and work out stuff like this. Also, it takes a little while for your profile images to get indexed. Thanks for being patient with us.

</comment></comment></comment></comment></comment><comment><USER3> So this is for web 2.0 collaborative mugging then? If I put up a pictures of myself plus relevant details of the valuables I'm likely to be carrying then potential muggers can check me out before hand and decide whether or not it's worth it.

Awesome

</comment><comment><USER4> Wow, looks like Nicholas Carr picked up on the launch:

[http://www.roughtype.com/archives/2007/10/mugr_from_faceb.ph...](http://www.roughtype.com/archives/2007/10/mugr_from_faceb.php)

</comment><comment><USER5> So if I send you a pic, you will search your whole database to detect who is on that photo?

How can I as a person keep you from putting me into your database?

<comment><USER6> We'll be supporting web, email and mobile-based searches to identify people via headshot, however, we don't crawl the web or search photo album sites for subjects. The only way we'll actually store (and thus be able to search for you) is if you have profile on Mugr.com.</comment></comment>


7 Good Rules to Log Exceptions - <AUTHOR> http://www.codemonkeyism.com/archives/2008/12/16/7-good-rules-to-log-exceptions/ <comment><USER2> Decent article overall (fairly short and not particularly controversial though).

One item I would argue with is the second half of this: > You need to decide what critical means for you (most often it means losing money).

Just because you're losing money doesn't make it critical, at least not for any site that operates at scale. If you log as critical everytime you knew you're losing small amounts of money, you'll also have log files full of tiny taxes you've paid. "Can't reach US credit card payment provider" probably sounds critical, but isn't all that critical if you can place that order into a stored state and retry it with the provider later. Sure, that loses money because some of those payments will fail, and some users won't retry after an email prompt, but that doesn't make it critical.

In my experience (on the dev side for years and now on the operations side), developers log errors at one level more severe than is actually warranted. ("Divide by zero" is almost never a fatal error from the perspective of the site operations team. :) )

<comment><USER3> One usefuyl criteria is that which will affect a group of customers rather thank a single person.

</comment></comment><comment><USER4> I think a good approach might be:

Log _everything_ , and then filter out the information you know won't be interesting with rules. The remainder is what's interesting (if it isn't, add to your rules to filter it out).

This way, if later on you're trying to track something which requires information you usually don't find interesting, you just update your rules and you have all you need.

</comment><comment><USER5> _If you log everything you will probably get too many log entries to have a meaningful reaction to exceptions in your log._

In theory, this makes perfect sense. In reality, you will almost always wish you had logged more. Having good detailed data will enable you to discover patterns when you can't recreate problems.

Disk space is cheap. Log it and archive or dispose it later. You can't see what you don't save.

<comment><USER6> Generally you're right. To know what will be helpful for debugging you have to know what will go wrong, and if you know what will go wrong you may as well fix it now instead of after it affects a user. Also, in any sufficiently stable system errors become _very_ hard to reproduce so you may not have the luxury of reproducing the error before finding the root cause of the problem.

Large log files don't scare me for I have The Shield of Grep, and The Sword of Awk.

The only issue I've seen with logging _everything_ is that some file systems have troubles with files larger than 2gigs, and changing file systems may not be an option. Depending on how quickly you rotate your logs you can hit that limit and stop logging messages or cause errors elsewhere. With a log rotation period of 1 hour I've hit this limit, and it's rather annoying.

<comment><USER3> Why not rotate log files based on size?

<comment><USER6> A better idea may be to not log to file. If you were to log to a database you could record things like date/time, session_id, service_name, module_name, and a generic message and do clever SELECTs on your database of events/messages and it would be easier to answer questions like 'Is this exception clustered with time?' or 'is module X ever called in a session that results in an error between noon and 1pm?'

Cleaning old messages is potentially easier as you can remove lower priority messages first, or simply delete any message older than X.

Of course, if you're logging to another remote service (like a DB server), how do you record low level events in communicating with that service, or how do you record events when the db server is down?

<comment><USER7> Log critical/connectivity errors to a local disk.</comment></comment></comment></comment></comment>


Polymer breakthrough reveals unprecedented alternative to battery power storage - <AUTHOR> https://www.surrey.ac.uk/mediacentre/press/2018/scientific-breakthrough-reveals-unprecedented-alternative-battery-power <comment><USER2> _" The test results from the new polymers suggest that extremely high energy density supercapacitors could be constructed in the very new future."_ Not "We have a demo model working". More on the actual chemistry, from 2017.[1] Seems they announced this before, in June 2017.

Even if this doesn't turn into a big energy storage thing, maybe they can replace ordinary electrolytic capacitors. Least reliable component in electronics.

[1] [https://chemical-materials.elsevier.com/new-materials- applic...](https://chemical-materials.elsevier.com/new-materials- applications/ultracapacity-polymeric-supercapacitors-viable-alternatives- batteries/)

<comment><USER3> As of 2018 it's tested:

> By using small single layer cells charged to 1.5 volts for two to five > minutes and then run demonstration devices, including a small fan.

> By using a three-cell series stack that is able to be rapidly charged to > five volts and operate an LED.

[https://www.surrey.ac.uk/mediacentre/press/2018/alternative-...](https://www.surrey.ac.uk/mediacentre/press/2018/alternative- traditional-batteries-moves-step-closer-reality-after-exciting)

(Link first posted here by BugsJustFindMe. Also says "if these values of capacitance can be achieved in production, it could potentially see supercapacitors achieving energy densities of up to 180whr/kg - greater than lithium ion batteries.")

<comment><USER4> [https://en.wikipedia.org/wiki/Lithium- ion_battery#Performanc...](https://en.wikipedia.org/wiki/Lithium- ion_battery#Performance)

Wikipedia shows 100-250whr/kg for lithium ion. Not familiar enough to know which is right.

<comment><USER5> I think you stumbled on a wiki turd. Citation for the x-250 number is [https://web.archive.org/web/20111107060525/http://www.panaso...](https://web.archive.org/web/20111107060525/http://www.panasonic.com/industrial/includes/pdf/Panasonic_LiIon_Overview.pdf), which has the volumetric density in kG/L but not the specific density.

</comment></comment></comment></comment><comment><USER6> The 2018 version of this is [https://www.surrey.ac.uk/mediacentre/press/2018/alternative-...](https://www.surrey.ac.uk/mediacentre/press/2018/alternative- traditional-batteries-moves-step-closer-reality-after-exciting)

I'm not sure why the 2016 release was posted instead.

<comment><AUTHOR> Honestly, I'm not sure how that happened either. Thanks for posting the new one!

</comment></comment><comment><USER7> They claim 4F / cm² between smooth surfaces, which seems impossibly high. Even if the dielectric is only 5 Å thick, that corresponds to a dielectric constant of 2.2e6. The highest dielectric constants materials I know of are around 2e4.

<comment><USER8> There are lots of things which are publicized like this but never go anywhere.

</comment></comment><comment><AUTHOR> More details at [https://www.theengineer.co.uk/supercapacitors-battery- techno...](https://www.theengineer.co.uk/supercapacitors-battery- technologies/) \-- hard to find an actual paper, though

</comment><comment><USER9> Anyone have a link to the actual paper? Some polymers are known to have extremely high dielectric constants.

</comment><comment><USER10> (2016)</comment>


White iPhone conversion kits land teenage entrepreneur in hot water - <AUTHOR> http://www.tuaw.com/2010/11/17/white-iphone-conversion-kits-land-teenage-entrepreneur-in-hot-wa/ <comment><USER2> That is after the teenage kid from New York made $130,000 by converting black iPhone 4s to white !</comment>


5 companies grab 70% of your online dollars - <AUTHOR> http://www.cnbc.com/2015/11/05/5-companies-grab-70-of-your-online-dollars.html <comment><USER2> So much for the internet killing the middle man (and the advantage of economies of scale) in practice (as opposed to "but anyone can sell directly now" platitudes).

</comment><comment><USER3> Google and Amazon account for 57% of all online revenue.</comment>


Ask HN:  Do "Copy Cats" ever get funding? - <AUTHOR>

I don't think I'm actually interested in doing this, but I'm just curious to see if funding would be possible if I did.
Basically my company sells Egnyte - http://www.egnyte.com to a lof of our clients and we've recently stopped selling it because Egnyte doesn't live up to the expectations of our clients.  I'd really like to build something like Egnyte, but build it so that it actually works.
Don't get me wrong, I'm not just trying slam Egnyte and I actually gave it a chance, but it just doesn't cut it. <comment><USER2> If you do it better then yeah. There's always room for improvement.

For the copycat thing... Think groupon and living social; both have funding.

<comment><AUTHOR> I guess I didn't really think of it that way, but that makes sense.

Unfortunately I definitely couldn't pull that type of thing off on my own.</comment></comment>


Google Plus is down - <AUTHOR>

Is anyone else having fetch problems with their G+ on iPhone? <comment><USER2> Confirm. 404 for post URLs.</comment>


Surface Hub, by Microsoft - <AUTHOR> https://www.microsoft.com/microsoft-surface-hub/en-us <comment><USER2> Is there something new recently? These were announced early 2015.

[https://www.theverge.com/2015/1/21/7867585/microsoft- surface...](https://www.theverge.com/2015/1/21/7867585/microsoft-surface-hub- announced)

<comment><USER3> They released the Creators Update for it last week [https://blogs.windows.com/devices/2017/05/31/surface-hub- pow...](https://blogs.windows.com/devices/2017/05/31/surface-hub-powerful- windows-10-creators-update/)

</comment></comment><comment><USER4> Is there a reason jamboard and surface hub appeared simultaneously here?

<comment><USER5> [https://en.m.wikipedia.org/wiki/Twin_films](https://en.m.wikipedia.org/wiki/Twin_films)

<comment><USER6> But these products have both been out for a while though, right?

<comment><USER4> That's what I thought. So I'm just curious why OP posted 3 competing smartboarda at the exact same time.

<comment><USER6> The AI controlling that account is stuck in a loop.

<comment><AUTHOR> Ha. Was just curious which of the three would gain the most traction here.

</comment></comment></comment></comment></comment></comment><comment><USER7> Price: Contact Us

Really? I get its an enterprise product but come on

<comment><USER8> just under $8k for the small (55" diagonal) version. around $22k for the large (82"), from memory.

They don't come with anything to mount onto, so if you want it on a wall, you have to buy the mount kit. MS conveniently sells them. If you want it on wheels, you have to buy that mount kit. MS sells that, too. The 82" version isn't supported on the rolling mount, I believe.</comment></comment>


Before-and-after photos show California storm's insane impact on water levels - <AUTHOR> http://www.sfgate.com/news/article/before-after-storm-California-flood-ca-drought-10851105.php <comment><USER2> This is a poor article.

First of all, its numbers are way off. I plotted last Tuesday's data ( [http://cdec.water.ca.gov/cgi- progs/products/rescond.pdf](http://cdec.water.ca.gov/cgi- progs/products/rescond.pdf) for current levels) and the total reservoir levels added up to be 101% of typical years (ranging from well below at New Melones, which is still low, to abnormally high for some of the smaller ones like Folsom. The total water level was still less than 2/3 total capacity (actually 63%).

This is exciting but doesn't get us out of the woods. Those historical levels have of course been trending down due to low water levels. Just look at those pictures of the floating docks on Folsom: all that grassy, treeless area around the lake is empty reservoir! We don't want them completely full since there would be no buffer for later filling. What you want is full for a given point in the season.

There are two other problems. One is that we have another reservoir system: the snowpack. We just got a couple of meters of accumulation which is great, but it was preceded by a rain that washed a lot of water out of the snowpack and into the reservoirs. We depend on that snowpack to modulate the water release into the year for two reasons; one is it's a free buffer. The other is that as it trickles down rather than gushing down it percolates into the aquifers, which are historically low.

Some of them are irrecoverable (under the Central Valley the water was laid down 20,000 years ago; when it is sucked out the ground sinks so the water can't be replaced) but many are also natural reservoirs that need to be recharged. If we get an earlier sprint and overall warmer conditions that water will rush across the land and into the sea rather than into the ground.

So this is great news, no question, but that article doesn't tell a useful story.

</comment><comment><USER3> I felt scared for the pedestrian crossing the bridge in second 0:28!

<comment><USER4> Me too. Those trusses don't look like they were designed for that kind of lateral force.

I'd be interested to hear a civil engineer's take.</comment></comment>


Pugachev's Cobra - <AUTHOR> https://en.wikipedia.org/wiki/Pugachev%27s_Cobra <comment><USER2> F-22 performing Cobra [https://www.youtube.com/watch?v=FUdt6ZSWUsI](https://www.youtube.com/watch?v=FUdt6ZSWUsI)

But the cobra is not the definition of supermaneuverability:

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

Su-37 Kulbit [https://www.youtube.com/watch?v=dZg0jZfI6Cg](https://www.youtube.com/watch?v=dZg0jZfI6Cg)

F-22A Kulbit (@1:25) [https://www.youtube.com/watch?v=GrBx6G2O6A4](https://www.youtube.com/watch?v=GrBx6G2O6A4)

America does the formation stuff very well, but the Russians are in different league in terms of single-aircraft demonstrations. See below @1:16 for some variations on the cobra. [https://www.youtube.com/watch?v=M_wc04VQXCM](https://www.youtube.com/watch?v=M_wc04VQXCM)

<comment><USER3> That the kind of move that makes a opposing pilot go "Oh Fuck!" right before getting a face full of ordnance.

Interesting to note that the MiG-29 can apparently pull that one, even though it has no trust vectoring.

<comment><USER4> The Mig-29 listed in that wiki is the MiG-29OVT. A thrust vectoring prototype.

<comment><USER3> Well that explains quite a bit...

</comment></comment></comment></comment><comment><USER5> [https://www.youtube.com/watch?v=1EpJ3KoUNmI](https://www.youtube.com/watch?v=1EpJ3KoUNmI)

</comment><comment><USER6> "I'm gonna hit the brakes, and he'll fly right by."

</comment><comment><USER7> I raise you a Lomcovak [https://en.wikipedia.org/wiki/Lomcovak](https://en.wikipedia.org/wiki/Lomcovak)

<comment><USER8> i'll see you and raise you [https://en.wikipedia.org/wiki/Crazy_Ivan](https://en.wikipedia.org/wiki/Crazy_Ivan)

</comment></comment><comment><USER9> Its like an airplane wheelie!

</comment><comment><USER10> Now more than just an insanely strong beer. [http://www.beeradvocate.com/beer/profile/16843/76206/](http://www.beeradvocate.com/beer/profile/16843/76206/)

</comment><comment><USER11> I saw Patty Wagstaff do one in her 300S aerobatics plane..</comment>


Ask HN : Which opensource project for beginner python developer - <AUTHOR>

I like python and consider myself at beginner level. I've never contributed to an open source project, hence not sure how things go. But want to start now.
Need some advice on the below points -
1.) What are the projects available at my level. If you know one from the top of your head, great !
2.) Apart from my own interest (algorithms, frameworks, monitoring systems). What should I be looking for in an open source project ?
I checked github, the number of projects out there are huge, to say the least. Need something to start/get my feet wet, then I can dive full force in a month.
Thanks for any suggestions you have. <comment><USER2> Work on an open source project that you actually use so you have some motivation to improve the codebase and know what improvements to make.

</comment><comment><USER3> PyPy is looking for contributors: <http://morepypy.blogspot.com/2011/01/pypy- wants-you.html> (via <http://news.ycombinator.com/item?id=2127461>)

<comment><AUTHOR> This sounds interesting. Thanks

For others in my boat, who didn't know what exactly pypy was -<http://rayli.net/blog/2010/04/what-is-the-purpose-of-pypy/>

</comment></comment><comment><USER4> The way I started out was contributing small patches to the Reddit (social news website) code base. The source code _can_ be pretty daunting at first, but once you spend some time with it then it's pretty easy to learn.

Reddit has several of your interests in common. Algorithms regarding voting, built on the the Pylons framework, monitoring systems to make sure the services are up and running. For me, as someone who is still relatively new to Python, Reddit has a good combination of technology I know about and technology I want to learn about. I'd really recommend checking it out.

There are also subreddits such as <http://www.reddit.com/r/bugs> and <http://www.reddit.com/r/ideasfortheadmins> that can give you an idea for features, suggest bugs that may need fixing or even just enhancement requests.

Provided that you're nice, the community is very welcoming and open. The admins are all fantastic guys, as well, which is a real bonus.

<http://code.reddit.com/> \- take a look.

</comment><comment><USER5> Find a project that you already use or that you like that supports plugins. Write one plugin and learn by looking at other plugins.

On the top of my head: deluge (bittorrent client) emesene (MSN client) XBMC (media center)

If you're a Gnome user, most applications support Python plugin (Nautilus, GEdit, ...)

Shameless plug on my part, you could make a plugin for my open source project called periscope. It downloads video subtitles from various websites <http://code.google.com/p/periscope/>

<comment><AUTHOR> This also is a pretty good idea. I know django supports plugins. I've written some for my site.

</comment></comment><comment><USER6> I'm learning python as well and would benefit from an answer to this question. A friend suggested building a web scraper, which sounds reasonable, but I'd also want to work on a larger endeavor (but not too big).

</comment><comment><USER7> <http://github.com/facebook/tornado> is a pretty simple, useful project. You could set up ab and try to make it faster!

<comment><USER8> I have to disagree. The IOLoop is not trivial and could lead to some major confusion.

</comment></comment><comment><USER9> Mincemeat.py (<http://mincemeatpy.com>) is fairly simple, only uses standard libraries, and definitely welcomes contributions.

(I am the maintainer of mincemeat.py)

<comment><USER10> Agreed. Quite simple to use, and provides a good foundation for learning about Map/Reduce with little initial overhead.

I'm working on a fork (<https://github.com/pjkundert/mincemeatpy>) which enhances the robustness of the asyncore/async_chat based networking code (in addition to adding a Client to Server back-channel, to allow Clients to schedule Map/Reduce tasks), for use in a shipping product.

</comment></comment><comment><USER11> You could subscribe to the project's mailing list or join the IRC channel and answer any questions that newbies have. This is probably a softer introduction to contributing to an open source project than committing code.

For example, I know the Django mailing list is pretty active and there are a lot of questions that can be answered.

</comment><comment><USER12> I have a relatively simple project: <http://code.google.com/p/tracshell>

There are some outstanding issues that still need looking into. It's also not feature complete (but there is enough done that it's usable, I eat my own dog food) so there are enhancements to work on as well.

It just started off as an afternoon hack and a few people have added things to it over time. You'll get some experience with core library modules as well as third party modules. You can work with terminals, RPC, etc. Nothing terribly hard, but challenging to a beginner in many areas.

</comment><comment><USER13> Hello there,

<http://www.djangoproject.com/>

The Django project is one of the best frameworks for Python Programming. If you would like to contribute to the visit this link:

[http://docs.djangoproject.com/en/dev/internals/contributing/...](http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs)

This page explains how you can contribute to the project.

You can also contribute to few popular desktop Python programs such as Miro and Blender.

Good luck!

Karl

</comment><comment><USER14> I have an API for the World of Warcraft Armory which almost certainly broke after they updated when Cataclysm was released.

It's not brilliant code (particular shame for the testing, or lack thereof) but it should be fairly readable and does what I think is a cool thing :) You'll learn some stuff about SQLAlchemy/ORMs and web scraping along the way.

<http://www.github.com/lewisham/wowspyder>

</comment><comment><USER15> Port a Pyhton 2.x library to Python 3.x. Take PIL (Python image library) for example, this is a great image processing library that seems to stagnate in the 2.x world for a few years.

It will be fun and you will learn a lot.

If this seems too difficult, then take a good introductory book like "Invent Your Own Computer Games with Python" and implement by yourself all the include projects.

</comment><comment><USER16> Twisted seems like a good option. Here is a good question on stackoverflow with some comments: [http://stackoverflow.com/questions/117561/what-are-good- open...](http://stackoverflow.com/questions/117561/what-are-good-open-source- projects-in-python-for-which-i-can-be-a-contributor) Although, you should try to find something you have a personal interest in as well.

<comment><USER7> Twisted is kind of notorious for being difficult to pick up and use, even for experienced Python programmers..

</comment></comment><comment><USER17> I'd like to learn more about HTTP, web servers, etc... Which open source project should I start with?

<comment><USER18> Django? Flask?

<comment><USER17> I think Django would be too complicated for me. Hadn't thought about Flask before. Thanks!

<comment><USER19> I've had great experiences with the django source code. It is very readable, well-commented, and has tests for everything.

I'd suggest reading the tests for django.forms, and then reading the source code. From there, one can then dive into other sections of django.

</comment></comment></comment></comment><comment><USER20> libcloud - a unified interface into the cloud - <http://incubator.apache.org/libcloud/>

Since you're into monitoring, check out what we're up to - <https://github.com/cloudkick/>

</comment><comment><USER21> I am interested in contact/list management-type projects based on Python. Does anyone know of one?</comment>


Italian court finds seismologists guilty of manslaughter - <AUTHOR> http://www.nature.com/news/italian-court-finds-seismologists-guilty-of-manslaughter-1.11640

<comment><USER2> The title is missleading. I didn't see anywhere in the article that pointed to the "real reason...".

<comment><AUTHOR> Some news sources have consistently misreported this as saying that they were being tried for "failing to predict the earthquake". That would, of-course, be nonsense as no-one can predict when an earthquake might strike. However, that is not what the prosecution said - their case was based on the scientists failing to communicate risk properly. Quoting the source: "The verdict was based on how they assessed and communicated risk before the earthquake that hit the city of L'Aquila on 6 April 2009, killing 309 people" That was the real reason.</comment></comment>


How many startups raise (or don't raise) their next round? Here are the numbers - <AUTHOR> https://mattermark.com/startup-graduation-rate-surprisingly-low/ <comment><USER2> Would be really interesting to combine this with failure rate data. What fraction of companies not raising another round is due to failure vs. No longer requiring additional venture funds. The long term goal of a business is not to raise more rounds...</comment>


Thoughts and a crazy prediction on ipv6 - <AUTHOR> http://www.semicomplete.com/blog/geekery/thoughts-and-a-crazy-prediction-on-ipv6.html

<comment><USER2> While the article sounds really crazy, I can really see something like this happening, even though possibly over a longer time frame.

For one, the time where ICANN can't hand out any more address blocks isn't the same time as when providers will be unable to hand out addresses. Many providers keep large unused pools and will just continue to sell addresses from those.

Once these get scarce, public IP's for dialup customers are the first thing to go. Then follow public IP's for smaller server customers (you can in theory do reverse nat based on the Host:-header. Of course this _really_ breaks SSL, but we don't need that anyways - see firesheep).

Whatever happens, we won't see IPv6 adaptation.

Scarcity of IP addresses is extremely beneficial to the current players who already have their addresses as it

a) puts an end to unloved services as P2P, VoIP and some kinds of streaming or at least makes it incredibly hard (once you put your customers behind NATs)

and

b) gets rid of competition (by not handing them out IP addresses)

The glorious time where everybody with a bit of time and skill could design and implement a working product are going to be over as you'll just not get the address you need while the existing big services have stockpiled their addresses.

They will become the gatekeepers. If they like your service, they buy you and provide the needed addresses.

If not, you are screwed.

Or you get one of those IPv6 addresses which will be unreachable for a majority of internet users because it's totally not in the interest of ISPs to provide V6 connectivity.

I'm telling you. This isn't going to end well. It'll take longer than what's predicted, but it'll end up badly.

Please - give me arguments why I'm wrong and why we'll have large scale IPv6 deployments in the near future.

<comment><USER3> IPv6 gets adopted when the ever-dropping cost line meets the ever-rising cost line of IPv4, and not sooner. (And IPv4's cost line has only really twitched upwards; unfortunately due to the nature of this sort of rigid supply/growing demand situation with market forces being suppressed by the supplier ignoring them you tend to only see the price spike at the end of the supply. If we were being really rational about this we'd be raising the price on IPv4 blocks already.) Once that happens it becomes difficult to predict exactly what happens next, because as people marginally transition to IPv6, that causes the cost of IPv6 to further drop as people iron the problems out (making it easier), but the costs of IPv4 drop too as IPs become more available again. I suspect IPv6 will win if for no other reason than momentum, though; the perceived costs of not transitioning will become higher as it becomes the "in" thing to do.

The hands have been wringing over the past decade as people have overestimated the costs of IPv4 and underestimated the costs of IPv6, by quite a lot. But I suspect this will not be the exception that breaks the simple principles of economics.

Incidentally, some blame can be laid at the feet of those who designed IPv6 and took the opportunity to jam every wishlist item into it they could think of (to a first approximation), thus raising the price of IPv6 through the roof and causing the lines to fail to cross until quite late. Had IPv6 been an incremental improvement over IPv4, with a larger address space, the costs would have been much less (though still large and easy to underestimate) and the cross-over would have come much sooner. Perhaps it would not have come yet, but it would have been sooner and more graceful (since, after all, a global price curve is only an approximation, what matters are all the local ones).

A lesson for next time we need to redesign one of the Internet's core protocols: KISS doesn't stop mattering just because the problem is big! (Quite the opposite, really.)

<comment><USER4> Actually, most of these "wishlist items" are not relevant for the core IPv6 protocol (as in subset that needs to be understood by routers) and deal mainly with end hosts. But what is relevant to cost of migration is exactly the larger address space, most high-performance routers do almost everything in custom hardware.

Most important part of this cost-wise are FIB lookups, with FIB being typically implemented as specialized content addressable memory chip, which due to it's nature is pretty expensive (it is one of things that you cannot reasonably implement in programmable logic) to redesign for larger address space (and impossible to upgrade without throwing out whole router). On the other hand, header decoding are usually implemented in some programmable logic or directly in software so, that can be field-upgraded with relative ease. So in the "Carrier grade" and "L3 switch" categories you get things that are new and capable of IPv6, things that simply cannot be upgraded and devices that can be upgraded to do IPv6 routing in software (at great performance overhead)

<comment><USER3> Routers aren't the only cost source. I've seen some coworkers work on moving IPv4 end-user appliance products to IPv6, and just the act of managing IPv6 addresses on such appliances, to say nothing of interacting with the other IPv6 issues that may not be part of the "core protocol" but you better support if you're going to claim IPv6 compliance, was a surprising amount of work.

I thought I knew what IPv6 was, but man was I ever wrong. It's significantly more complicated than IPv4. Which I don't necessarily even mean as a criticism, some of the bits of complication are actually fixing problems with IPv4, while I'd say other things are just wishlist items. But regardless of how right or wrong it is, it is definitely more complicated.

As expensive as routers can be at the high end, broadly speaking, router costs in dealing with the core protocol do not seem to me to be what is holding back adoption. The costs are dominated by all of the _other_ things that need to speak IPv6 before you can transition at all, _let alone_ entirely eliminate IPv4. Maybe I'm wrong, though, it's hard to tell.

<comment><USER4> I focused on costs to organizations deploying IPv6, not costs to manufacturers/developers (which may or may not be reflected in increased equipment prices).

And as for all the other things that need to speak IPv6, I was actually surprised that for more than year any random new piece of network attached anything that I have seen supported IPv6 out of the box and just worked.

</comment></comment></comment></comment></comment><comment><USER5> ICANN is already preparing for secondary markets to appear where people can auction off unused IP space. It's inevitable and they know this. Eventually everyone will migrate to IPv6 simply because the addresses will be free.

There will never be a day when you cannot get a new IPv4 address. But there will come a day when you don't feel like paying for one.

<comment><USER6> They aren't QUITE free. ARIN charges yearly fee of $1,250 for a /40 of IPv6 space. Of course, that's theoretically 309 SEPTILLION addresses (2^88), as much as organization will currently need. $1,250 for up to a /20 of IPv4s, which is a paltry 4,096 addresses.

</comment></comment><comment><USER7> "Week 8: Cloud proviers, thanks to CFO-profit-center drives, now start charging for public IP addresses."

I don't think cloud providers will stop giving out public addresses 'for free'. I think their default will be public ipv6, and charge a premium if you want ipv4. Or maybe they'll frame it as a "discount" if you want to use ipv6 only.

</comment><comment><USER8> Not everyone needs public-facing IP addresses. It's also possible to write network/web applications that work through NAT, or that don't need routable clients.

Considering the transition to IPv6 will take at least a decade, do your apps need clients with public routable IPs?

</comment><comment><USER9> We already have IPv6 deployed on our ~10,000 node network. It was pretty simple to set up (after learning the basics of IPv6), and since the latest versions of Windows and Mac OS X default to IPv6 over v4, most of our internal traffic is v6 (most of our servers are Windows, and they reg AAAA recs in DNS).

DHCPv6 is still a bit of a mess (at least on the Cisco end), though.

I'm sure there will be many operational issues, but I get this feeling the fear is a lot like it was for Y2K.

</comment><comment><USER10> I have always been under the impression that the limited nature of ipv4 is very detrimental for creating infrastructure in poor parts of the world. This might actually make large corporations (and more so governments) interested in preventing competitors from rising in foreign lands.

You can afford fiber and all of the hardware to get an isp working? Great. Too bad you still have to pay your tithing for the artificial scarcity of addressing.

<comment><USER11> _I have always been under the impression that the limited nature of ipv4 is very detrimental for creating infrastructure in poor parts of the world._

It's not. IPv4 is approximately free today; it's the smallest part of the cost of running Internet infrastructure.

 _This might actually make large corporations (and more so governments) interested in preventing competitors from rising in foreign lands._

Yeah, the only thing stopping Africa from kicking the US's butt in technology is a lack of IP addresses...

<comment><USER10> Well, I was talking out of my ass then. I was under the impression that places that had a large set of ip's (such as a few universities and corporations) would make a bundle leasing those to other people when there was more contention for addresses.

<comment><USER11> That _will_ happen _after_ the free IPv4 addresses run out in the future, which is why ISPs in developing regions should get as many addresses as they can now while they're free and prepare to adopt IPv6 if it turns out to be cheaper than buying IPv4 addresses.

</comment></comment></comment></comment><comment><USER12> Alternate future history: IPv4 forces most ISPs to put ordinary household subscribers behind NAT rather than give them internet addressable IPs. A few things stop working for some people, some folks grumble, the spread of internet worms slows down considerably.</comment>


MongoDB on AWS: a whitepaper from Amazon - <AUTHOR> http://d36cz9buwru1tt.cloudfront.net/AWS_NoSQL_MongoDB.pdf

<comment><USER2> I built my startup using this _exact_ outlay, so it's wonderful to have this guide in hand for when we need to scale Mongo across multiple EC2 instances. This presentation from Jared Rosoff of 10gen was extremely helpful on the first go, and it's satisfying to see that the AWS paper corroborates the content.

[http://www.10gen.com/presentations/mongosf-2011/running- mong...](http://www.10gen.com/presentations/mongosf-2011/running-mongodb- cloud)

Couldn't be happier with the performance so far.

</comment><comment><USER3> How is the pricing for Mongo on EC2?

The absolute minimum would be single server w/ journaling running on a 64-bit instance. I am assuming the 64-bit micro is to IO bound, so the Large instance is the next minimum viable instance. At $0.34/hr, just in instance fees it's ~ $245 a month. Am I correct in assuming this is the entry level Mongo setup on EC2?

<comment><USER4> Kinda sorta, yes. You can commit to using that instance for 1 or 3 years and prepay for a discount... $164 per month if you reserve for a year, $126 per month if you reserve for 3 years. Really you also need to factor in the data transfer fees, and the storage and IO fees of a RAID array of EBS disks.

Last time I used EC2 to run a large database, the IO fees for EBS were almost as much as the EC2 fees... so take your estimate for the instance and double it. The real cost of running an active Mongo instance on one EC2 instance with a 2-disk EBS RAID might be closer to $400 per month than $245.

EC2 is _not_ price-competitive if you don't need to be able to launch and terminate instances on the fly on a regular basis. For small deployments, get a VPS, for larger ones, dedicated servers. I used to run most of my sites on Amazon services. I later moved (back) to renting servers from Softlayer. I was maxing out most of my servers at both providers -- I don't have extra money to blow on capacity before I need it. For every ~$350 EC2+EBS+Transfer instance at Amazon, I only need a ~$160 physical server now.

</comment></comment><comment><USER5> What's with the [scribd]? Shouldn't it be [pdf]? I know what scribd is, but why use it as a tag linking to a pdf? It's misleading as scribd used a flash applet, right?

<comment><USER6> All PDFs, Docs, PPTs etc submitted on HN have the [scribd] link by default[1]. It's a way for people to view the document on their browser without having to download it first (there are still browsers out there like Firefox on OS X that do not have an in built PDF viewer)

[1] - [http://www.scribd.com/doc/50406482/Hacker-News-Integrates- Wi...](http://www.scribd.com/doc/50406482/Hacker-News-Integrates-With-iPaper- Scribd-Blog-3-11-08)

<comment><USER7> Scribd also requires logging in before being able to download, so it's accurate enough.

</comment></comment></comment><comment><USER8> I wish they'd just wrapped it up as elastic mongo like they did with mysql, oracle and memcache.</comment>


The unspoken truth about managing geeks (2009) - <AUTHOR> https://www.computerworld.com/article/2527153/opinion-the-unspoken-truth-about-managing-geeks.html <comment><USER3> The point about Respect is something I struggle to appropriately convey and convince my non-technical friends.

In any technical team I've been part of, implicitly, respect and competence were far more relevant than organizational authority. Any technically competent person I've met, upon meeting a new lead or manager, will consciously or subconsciously evaluate "Does this person know their stuff?". If yes, they'll work for & with the lead. If not, they'll route around them - most IT Pros are surprisingly skilled at "Upward management".

<comment><USER4> I like your comment; I liked the Humility, Respect and Trust Framework from "Debugging Teams" a lot as well.

However, what I also found is: geeks don't care about the value they are creating/not creating all too often.

If you are on the "other side of the table tasked to extract value from an engineering/science team" the amount of disrespect that you are facing from geeks is sometimes almost unbearable.

As much as I hear things like "education or opinions do not matter - but facts and data and demonstrated competency" this only lasts as long as the people saying it feel it's a waiver to demonstrate some "tolerance and openness as long as it means they got to do what they want".

What a lot of geeks don't understand: yes, management also figures out "who is more results and product driven" and will shy away giving the "most impactful tasks" to the condescending folks...

A lot of managers would enjoy their work more having a bit more technical expertise; but the same is true - and even more so - for geeks.

<comment><USER5> "geeks don't care about the value they are creating/not creating all too often."

This is a two way street - mostly you don't actually want to hire someone who cares about the business, because they're not as easily exploited. I'm saying, yes, not caring about business value is a negative from one perspective, but culturally organizations have adapted to that and the person best suited to being plugged in to a position is someone who will work tirelessly on whatever you give them without caring one way or the other about the big picture. If they actually are interested in value, then they are going to be demotivated on a doomed or dysfunctional or immoral project.

<comment><USER4> This sounds like a dysfunctional company to me.

If somebody is a kick-ass programmer AND understands what value he is adding - he will be very successful at the company I am working right now. If he disagrees with his manager AND is right even more so.

But the experience I made is that the "feedback and speaking" up is more driven by personal preference and "what do I want to work on" instead of business and customer need.

<comment><USER5> "This sounds like a dysfunctional company to me."

Well, I hesitate to call something "dysfunctional" if it works. It becomes a subjective value judgment.

Different companies have succeeded in different ways.

<comment><USER4> This does sound dysfunctional in a way that decision making is obviously happening more compartmentalized and individual ownership is severely limited.

There is a reason why many super successful companies have values/culture: shift ownership and decision making as much to the people at the forefront as possible to avoid "managing them from the top".

Empowering engineers and scientists to develop a sense and say in product priorities is great, extremely difficult but speaks for a company that values contributions beyond a "specialization/niche"

</comment></comment></comment></comment></comment></comment><comment><USER6> I especially liked this point:

"IT pros always and without fail, quietly self-organize around those who make the work easier, while shunning those who make the work harder, independent of the organizational chart."

</comment><comment><USER7> I strongly agree with the author about the importance of having a mentor/manager who is a great technical sounding board. I need the help understanding what the business direction is, or else I will spend my energy working on a problem that the business doesn't care about. I want to know that if I figure out an improvement for area X that area X is important enough to merit work. And getting to the end of a project only to discover no one in the business cares about what I did is the most frustrating thing.

<comment><USER8> Srrong echo, my 2019 was full of good work that wasn't valued, despite email chains and postings. It's frustrating and detrimental to ones career to have a bsd manager.

</comment></comment><comment><USER9> This feels a little dated as I suspect only the most clueless execs today would not recognize the value of well-run IT (whether it be back-office or product), but it serves as a pretty good explanation of the unspoken rules of a culture which white collar management and leadership might not be inclined to understand. Software engineers and IT folks are more akin to craftspeople and blue collar professionals in the sense that their competence directly translates to outcomes, and thus their reputation is based on more concrete observations versus middle managers where it can be pretty hard to attribute either success or failure directly to their actions.

</comment><comment><USER10> Discussed at the time: [https://news.ycombinator.com/item?id=813368](https://news.ycombinator.com/item?id=813368)

</comment><comment><USER11> The relation b/w Respect and competence is correct. I had started on wrong foot with competent people and when they tried to demonstrate their competence, I show off my skills as a competition, but surprisingly it turns out in to mutual self respect and we get along well. I have been on both sides as showing the competence and being challenged and it always amazes me how it always turns in to mutual respect.

</comment><comment><USER12> Not mentioned in the article: most of the time you have to change management, no amount of management training will fix things.

</comment><comment><USER13> Lots of hogwash words.

People who don't IT are unable to contribute, don't understand business is now IT, and often sacrifice good for org for selfish gains.

People who do IT should contribute every day, need to learn the business domain every day and stop playing victim to random authority of the week.

<comment><USER14> You just made the author's point about respect...

<comment><USER15> I'd say OP swiftly took the air out of the author's argument, which is that geeks are wonderful to work with once you know how. What OP did was essentially say geeks are better than everyone else and management can fuck off, not exactly making geeks seem like team players.

<comment><USER16> Not sure, they both seem to be saying the same thing to me.

I inferred OP essentially saying: business _is_ IT. They're synonymous - <USER2> I'd largely agree with this.

All businesses deal with managing information, be it storing financial records, IP info, or transmitting data amongst users or employees. The I in IT is "Information", and all businesses deal with information/data.

Anyhow, the article starts out saying management often views geeks as being business challenged, which such a viewpoint is questionable given what IT is. Arguably, geeks are better at business (i.e. information handling and problem solving) than non-geeks. Hence, the point about respect in the article. IT Pro's won't simply respect someone because they're the boss. They respect those who are competent at solving business (IT) problems, regardless of demeanor or hierarchal rank.

As so, this bottom-up respect speaks volumes as to success of a team (as the lack of it indicates the leaders are charlatans).

<comment><USER15> I feel like this is a much more subtle way of reframing what OP said.

> Arguably, geeks are better at business (i.e. information handling and > problem solving) than non-geeks.

Do you believe there's something that geeks aren't better at than non-geeks (when it comes to being an employee)? Because OP's point, as I read it, was that geeks are superior and should be running everything and was incredibly dismissive of non-geeks being useful.

I agree that respect is earned, not given. But if you just immediately dismiss what someone has to say because they aren't part of your geek tribe, you are beginning the relationship from a hostile standpoint. Why would non-geeks look at this as anything other than geeks being antagonistic?

> Anyhow, the article starts out saying management often views geeks as being > business challenged, which such a viewpoint is questionable given what IT > is.

I read the article differently. It was much less about geeks being business challenged and much more about geeks being elitist, such as OP's bellicose comment.

If neither side is willing to work with the other side, the fault almost certainly lies with everyone.

<comment><USER16> >I read the article differently. It was much less about geeks being business challenged and much more about geeks being elitist

I think the article could have been about anyone being elitist, it just so happens to be about IT teams. Just remove geeks and non-geeks out for a moment. Think the nature of hierarchy in general.

A stable hierarchy has the best people as its leaders, which is when society benefits the most and teams work together best. If however, the leaders are charlatans, then more competent underlings will stop respecting or listening to the leaders, and/or may challenge the leaders. Typically life is worse off (for society as a whole) under bad leaders than good leaders.

This is why bottom up respect speaks volume to the success of a team. The article speaks a bit on this in the section about respect, and suggests favoring competency as a solution.

Anyhow, I don't think OP's point necessarily is at odds with this as the 2nd poster pointed out. OP argues that IT folk act elitist, because perhaps they actually are but find themselves following "random authority figure of the week", (rather than the best authority).

Whether or not that's true is subject to debate. I'm sure it is in some cases and others not, but I largely agree with the part of his argument about business being largely synonymous with IT.

>Do you believe there's something that geeks aren't better at than non-geeks

Sure, everyone is flawed. No one is fully aware of everything. As so, some may need help with understanding the scope of things, other people's viewpoints, and problems. Some may have trouble communicating novel ideas, or solutions, and need help in deploying them. Think people skills. I think this is why technical people say it's helpful to have a manager who acts as a sounding board.

<comment><USER5> "I think this is why technical people say it's helpful to have a manager who acts as a sounding board."

You are saying the usefulness of a manager is the same as, say, a stuffed octopus. I think this is illustrative of a cultural gap. Someone else might claim that all of the interesting and challenging problems in business are _management_ problems that technical people as such don't even acknowledge.

<comment><USER13> Instead of using straw-men, assumptions about where/who argument is from or downmodding, other strategies would be more constructive.

<comment><USER5> What? I didn't say anything about any of the above. "Someone might claim" is a euphemism for _me_ , not a straw man.

A stuffed octopus is indeed something people (techies) use as a sounding board - and it works. You can explain your problems to anyone or anything and get surprisingly good results. I _have_ used my manager this way. However, that's not the limit of what a manager can do.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


What developers should know about TCP - <AUTHOR> https://robertovitillo.com/what-every-developer-should-know-about-tcp/ <comment><USER2> What they mostly should know: TCP provides a bidirectional stream of bytes on the application level. It does NOT provide a stream of packets.

That means whatever you pass to a send() call is not necessarily the same amount of data the receiver will observe in a single read() call. You might get more or less bytes, since the transport layer is free to buffer and to fragment data.

I have seen the assumption of TCP having packet boundaries on application level being made too often - typically in stackoverflow questions like: "I don't receive all data. Is my OS/library broken?"

<comment><USER3> > What they mostly should know: TCP provides a bidirectional stream of bytes > on the application level. It does NOT provide a stream of packets.

> That means whatever you pass to a send() call is not necessarily the same > amount of data the receiver will observe in a single read() call.

Yes, this. For god's sake, listen to them.

I had to fight a coworker on this. I had quickly created some client code just to validate that the server was working. Due to some quirk, all the messages were arriving in full in every read call. He told me to ship it.

I said no! "I need to check if there's more data and if so add a loop to read again" "But it is working, release it". That went on for a while, to no avail. Wouldn't look at documentation either.

Eventually he head to leave for the day, and I took the time to implement it correctly.

I started including basic TCP questions on interviews. Not many people even get past the TCP handshake (if they even know about that).

<comment><USER4> Stupid question: why would you be writing code that works at the level of TCP? Don't you usually want to use the OS's (or some popular library's) TCP software stack?

<comment><USER5> It seems to me GP is talking about using TCP, not implementing it.

<comment><USER4> Right, I mean I thought that the TCP protocol implementation itself handled that issue, and your calls to such a library abstracted away from that.

<comment><USER6> No, it does not, by design. When you use any standard TCP implementation the abstraction provided at both ends is just a stream of bytes. The guarantee TCP makes is that the bytes received at one end will be in the same order as the bytes that were sent at the other end.

If you want to use TCP to implement some (higher-level) message-based protocol, you need to parse those out for yourself.

<comment><USER4> The original question didn't refer to such issues of parsing, just checking for whether the full message was received, which, I would think, would be handled by the TCP library read() (or whatever) call. It sounded like the OP (outworlder) was delving into lower-level TCP details that should have been abstracted away -- my thinking is that the TCP caller shouldn't have to concern itself with details about checking whether the full message has been received, at least not as a separate step. That is, it just wouldn't return anything until the full message is received, or would include some data structure that indicates it's not complete. Does that make sense?

Edit: On second thought, I guess OP meant that all of the results were coming back "complete" which doesn't obviate the issue of needing to do a check that handles the "not done" case.

<comment><USER6> > _the TCP caller shouldn 't have to concern itself with details about > checking whether the full message has been received_

The caller absolutely must concern itself with this crucial "detail". If you do otherwise, your code is broken, full stop.

You can implement a higher-level protocol on top which handles this kind of thing internally and presents a higher-level interface (e.g. not passing any partial data along to _its_ caller until a full message has been received), but if you are just working with TCP directly, what you get is just a stream of bytes. The guarantee you get is that the bytes will be in order and without any gaps.

If you e.g. send UTF-8 encoded text, you must be prepared on the read side to have your stream of bytes cut off arbitrarily in the middle of a character.

<comment><USER4> Let function A call TCP read() and pass back a struct that includes the bytes it's received and a flag that indicates whether it's read to the end of the message.

Let function B call TCP read() and never return anything until it's received all the bytes of the message.

Both of those seem (IMHO) like functions you could have in a TCP library. Neither seems (IMHO) like a higher level protocol.

<comment><USER7> The reason that this function doesn't exist is that even if the sender sent a "message" in a single API call, there is no guarantee that the networking code will send it in one IP packet (or one layer 2 frame). We don't want to couple the message size with the lower network protocol, the type of network equipment and so on, and also want to allow merging of messages for more efficient use of the network (If we have a large window size it allows better throughput).

So the job of separating the stream into messages is left to the application layer. (unlike for example in UDP, but then you have to worry about dropped messages)

<comment><USER4> What is that responding to? Of course TCP can split a message across multiple packets of the lower level protocol; that has no bearing on the concepts TCP works in and whether it can indicate end-of-message.

If your point is just that TCP doesn't have a concept of a "message" (a bytestream with a clear beginning and ending), then that's fair, but, as I said elsewhere [1] the original comment took for granted that TCP does have a well defined notion of "you've reached the end of the message", or at least, "there is no further data to receive". No one seemed to have a problem with that there, and I was just working off that assumption.

As before, I haven't checked whether this is true (I can't quickly verify from descriptions of TCP).

And, interestingly enough, there's this comment [2], which says that what I described _does_ exist, but isn't the default. So ... I'm at least not getting a consistent answer to my question, and people who think they know what they're talking about are inconsistent with each other.

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

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

<comment><USER6> > _the original comment took for granted that TCP does have a well defined > notion of "you've reached the end of the message"_

No, the original comment was complaining about a coworker who didn't understand (and refused to listen when told otherwise) that there is no such notion in TCP. It was a response to another comment complaining about people on the internet (e.g. Stack Overflow) too often making the same mistake.

You're more or less playing the part of that coworker here. It's unclear why.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> When I first started working with computer networks, I just thought of TCP/IP as "low-level stuff" and I focused instead on the higher level stuff. After I kept running into incomprehensible errors seemingly over and over again, I finally broke down and picked up a copy of Richard Steven's "TCP/IP Illustrated". Hands down, the best investment in time I've ever made. If you deal with distributed systems (hint, you do), you _need_ to understand how they actually work.

<comment><USER9> Great I thought I'll take a look. Three volumes each over 1000 pages? Any other suggestions? Did you mean all 3 books?

<comment><USER8> Hehe - I did end up reading all 3, and enjoyed them all, but I'd say I got 90% of the value from volume 1. Volume 2 walks through the BSD implementation of TCP/IP, which is fascinating, but way more detail than you'd ever need to know, and volume 3 goes off into some esoteric topics that seemed promising at the time but mostly ended up being abandoned (along with a brief discussion of HTTP as it was around the 90's).

If you're going to read it, though, find a used copy of the original Stevens' first edition, not that terrible desecrated second edition.

<comment><USER10> What is wrong with the second edition?

<comment><USER8> It was rewritten by a different author (the original author, Richard Stevens, died in a car accident in the late 90's). I guess the new guy tried his best, but he just doesn't have the writing skill that Stevens had.

</comment></comment></comment></comment></comment><comment><USER11> Something worth knowing: TCP checksums should not be relied upon. If you aren't using TLS, your application needs to do its own checksums. A 16 bit 1's complement sum over a packet is not sufficient, especially given modern switch ASIC design. They take really fast signals off the fiber and turn them into slow moving, parallel signals within the ASIC. Often these signal buses are nice even numbers of bytes wide, 204 in this example. When there is something flawed in the chip in the slower moving internal pipeline, it will hit the same bit position every 204 bytes. If it is borked enough to flip two bits within the packet, those flips will be in the same bit position a multiple of 204 bytes away, meaning the same bit position in the 1's complement checksum. If one flips up, and the other flips down, it passes! In my case it ended up corrupting data in a BGP session's TCP stream, executing the world's most confusing route hijack in our network.

<comment><USER12> One of our favorite troubleshooting stories was "3% of TLS connections fail on this particular frontend IP address. HTTP works."

Turned out our cloud provider's networking gear had a bug that disabled ECC and there was a bit flip happening. Convincing the provider's support that we had found faulty hardware in their datacenter was an interesting journey.

</comment></comment><comment><USER13> A very important point every develeper should know: successful write(2) syscall doesn't not grantee that the data received by a remote application. TCP is described as a protocol which grantees packet delivery and this often misleading.

write(2) syscall returned without a error means that data has been placed in OS kernel buffer. OS kernel then will try to send it to a remote host. If couple packet will be lost it's not a problem - kernel will retry a few times. But if power will be lost shortly after a write, data may never hit the wire. Then there is possibility that network link will be broken for a long time. OS will retry, but for a limited time and then will give up. Also remote host can crash at any time before remote application actually will read the data.

So if you need reliable delivery you need acknowledgement on application protocol level despite the fact that TCP already have acknowledgements.

</comment><comment><USER14> When I used to do networking tech support for some networking equipment the guy's who sat next to me supported the load balancer product.

I swear a high percentage of their calls were questions about how the load balancer wasn't working and sending all the traffic to one server and then after some investigation we discover all traffic is in fact directed to that lone server... because the client code has the IP of that server hard coded. A tedious discussion would then ensue about how that is not how to do it.

The next week? Same angry call...

Partly that is what inspired my decision to change careers. "Man if these developers can't figure out basic networking, maybe I could be a developer...?"

<comment><USER15> I have the same tedious discussion every time a new box is replaced. It goes in the lines of "no, changing a box will not make your application behave differently, fix your dawn thing".

</comment></comment><comment><USER16> Just enough information to be dangerous? Article attributes behaviors of loss- based congestion control schemes like Reno and Cubic to TCP itself. In practice, the congestion control scheme is not really part of the protocol (there is, for example, BBR). There's also ECN, showing that loss is not the only way to discover congestion.

<comment><USER17> the RTT discussion was a little misleading. its true that slow start rates are entirely dependent on RTT...but eventually the sawtooth should reach the same steady state.

there is work that shows that higher RTT connection do statistically suffer a smaller fair share, but that's a subtler if related issue. actually, I really wish the author would have shown the sawtooth.

<comment><USER18> At some point, with increasing bandwidth and increasing RTT, you end up with your effective bandwidth capped by receive windows and/or send buffers. Cross country high def video might not be quite enough to hit that, but intercontinental high def video would be.

Being closer means faster initial 'slow start', but also faster 'slow start' on congestion, which is why you get a bigger share.

<comment><USER17> sure. but thats really just a window being under the bandwidth delay product. the discussion makes it seem like you suffer an outright linear performance hit

</comment></comment></comment></comment><comment><USER19> > _But what about large files, such as videos? Surely there is a latency > penalty for receiving the first byte, but shouldn't it be smooth sailing > after that?_

So the articles (unstated) conclusion seems to be that, as long as there isn't network congestion, it _is_ smooth sailing after that.

But that congestion reduces bandwidth. But of course, that applies just as much to a national backbone as to last-mile.

So I'm curious: where _does_ most packet loss occur? Is it last-mile, at your ISP, or along major backbones? Because that has major implications as to whether caching video content closer to users actually results in higher- quality video (e.g. supporting 1080p instead of 720p) or not.

<comment><USER20> > where does most packet loss occur

Here's an interesting paper from SIGCOMM (it won best paper at the conference in 2018, FWIW) that attempts to figure out what links are congested without direct access to ISP networks: [https://www.caida.org/publications/papers/2018/inferring_per...](https://www.caida.org/publications/papers/2018/inferring_persistent_interdomain_congestion/inferring_persistent_interdomain_congestion.pdf)

</comment></comment><comment><USER21> Why doesn't the congestion control part of TCP prevent buffer bloat[1]? Is it because ISP throttling of the internet connection doesn't touch the TCP packets themselves?

I recently started doing off-site backups, which requires my entire internet uplink to be used for uploading said backups for about a week at a time. The internet basically becomes unusable because all the packets end up in a buffer on the router and latency spikes to 5000ms.

[1] [https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_d...](https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/)

<comment><USER22> Your router is holding ("buffering") packets in the hopes that they can be sent soon. Your measurements indicate that the router is "bloated", holding about five seconds (5,000 ms) worth of data.

This gives the sending TCP algorithm the wrong impression. It's waiting to hear about a dropped packet to indicate that there's congestion. When your router holds on to those packets (instead of dropping them), the TCP algorithm doesn't get any feedback, so it keeps shoveling data into the connection.

This leads to the bad state you're seeing. And that's where the advice on "What can I do about Bufferbloat?" comes in.

There's no benefit to having more than one packet buffered by the router. (Hanging on to more than one packet per connection only causes the latency/lag you're seeing.)

There are routers that actually check the time the router has held packets. If packets have been queued for "too long", the router discards them immediately, giving the vital feedback to the sending TCP. Those routers use the technique known as SQM (Smart Queue Management) and the fq_codel, cake, PIE algorithms to keep the queues within the router short - typically less than 5 msec.

To solve your problem, investigate getting a router that implements one of those SQM algorithms. They're listed on the "What can I do..." page. I am a fan of OpenWrt (use it at home), but have installed a bunch of IQrouters and Ubuquiti devices for friends.

<comment><USER23> TCP has its own buffers too. In a media application I had to use UDP because I could know how deep the local transmit buffering went. TCP just swallows the packets and maybe sends them, maybe buffers them. Adding to the problem.

</comment></comment></comment><comment><USER24> The article just explains some details but not the main concept behind TCP i.e. _TCP is a connection and stream based protocol of bytes_. All it takes is to explain the idea of _Counting bytes with a Sliding Window_ and almost everybody will "get" TCP. Never talk about _packets_.

</comment><comment><USER25> The RFC is useful as well.

[https://tools.ietf.org/html/rfc793](https://tools.ietf.org/html/rfc793)

TCP state machine diagrams can be useful too.

</comment><comment><USER26> Single biggest TCP issue I have had to debug and fix numerous times is about not doing connection reuse properly leading to tcp port exhaustion and causing seemly random delays causing timeout failures at higher level protocols, usually http. This one single issue has taken down multi-billion dollar production systems.

So, I hope people learn to check their http client/server implementations to have proper connection handling. Client should have a thoughtfully sized bounded connection pool with reasonably large idle timeout. It shouldn't close the connection after every application request (say, http request). There shouldn't be sockets in TIME_WAIT state accumulating at the client end.

Server should accept thoughtfully limited number of connections per client. Server should never close the connection except when it is shutting down.

There should be tcp keepalive messages to keep the connection alive with intermediate hop stateful firewalls (connection tracking table entries in firewalls expire when the connection is idle for too long) and to detect stale connections and re-establish them.

All of these things can be verified by analyzing at a packet capture. You can get a manageable sized pcap file by filtering on client/server ip/port-range pairs for at least 330 seconds.

Knowing tools to understand/debug tcp issues is an essential skill. sock stat command - ss, wireshark/tshark with Lua scripting is super useful. Knowing higher level application protocols like TLS and http is essential too.

</comment><comment><USER27> The biggest issue with TCP is that it can randomly freeze and you have to restart it in pretty much any network. You CAN NOT rely on socket closing on any side, you have to maintain connection by yourself.

I am super puzzled why something like websockets not solving this problem, simple heartbeat could solve the problem, but no one implements it.

<comment><USER28> You can use keepalives at the protocol (TCP) level.

<comment><USER27> In 99% of cases you don't have an api to do so.

<comment><USER28> That's not the protocols fault. Besides, the OS usually does this, not your program.

SO_KEEPALIVE is available on all relevant OS.

<comment><USER29> Default keepalive time of two hours is also quite long, in some situations, where you would expect to get the notification just a bit faster.

<comment><USER28> Yes, default values are not sane for most connections.

</comment></comment></comment></comment></comment></comment><comment><USER30> I loved this area when I was at university. At the end of Computer Networking course I brought a project on based on [https://www.isi.edu/nsnam/ns/](https://www.isi.edu/nsnam/ns/)

It was really fun expecially because it allows you to understand better all networking layers.

I did some tests about network topology to minimize lost tcp packs as possible, given different network traffics

</comment><comment><USER31> This reminds me of an issue I had to debug over a decade ago. Our product had its own protocol written atop TCP, but its handshake was written in a way such that it was much slower than it should have been due to delays caused by the Nagle algorithm.

Turning on TCP_NODELAY was a quick-n-dirty fix, but the real fix was to rewrite the handshake to be more compatible with the inner workings of TCP.

</comment><comment><USER32> Back in the day I remember learning about TCP and other systems subjects through Beej Guides! [1]. Is there other material recommended to review network programming? I know about the Stevens' books but they look so bulky and dry...

1: [https://beej.us/guide/](https://beej.us/guide/)

</comment><comment><USER33> EDIT: Sure wish I could delete this post.

Wait, this isn't TCP, this is protocol level above TCP, right? TCP doesn't shape traffic by itself through rate limiting and congestion analysis, does it? I thought the layer above it used TCP to send/receive the buffer size, and that has nothing to do with TCP.

Am I wrong?

<comment><USER34> TCP definitely does congestion control itself: [https://en.wikipedia.org/wiki/TCP_congestion_control](https://en.wikipedia.org/wiki/TCP_congestion_control)

</comment></comment><comment><USER35> So the video example here, does it indicate that UDP is more suited for video transmission?

Does http3 fix this?

</comment><comment><USER36> Unrelated: does anybody know the tool used to make those diagrams ?

<comment><USER37> It looks like excalidraw.

<comment><USER36> Yeah, it's so good and it's open-source !</comment></comment></comment>


24 days until death - Blog d'un condamné - <AUTHOR> http://translate.google.com/translate?sl=fr&tl=en&js=n&prev=_t&hl=ro&ie=UTF-8&u=http%3A%2F%2Funcondamne.tumblr.com%2F

<comment><AUTHOR> I know it's been posted when he had 30 days until death. Not he has only 24 days...</comment>


The Atlas of the Real World (pics) - <AUTHOR> http://www.telegraph.co.uk/travel/picturegalleries/3109042/The-Atlas-of-the-Real-World.html <comment><USER2> Fun to: guess what the map was representing, then scroll down to see if I was even close.

</comment><comment><USER3> Pretty cool, but I'm not sure I understand all of the distortion. Perhaps if they are using much smaller territories than the color coding, for example each state of the US, that would give rise to some of the shear.

<comment><USER4> France & Spain do OK from tourists huh? Australia, Africa & the US get sucked off the map.

</comment></comment><comment><USER5> If you liked that, you will REALLY like <http://www.gapminder.org>

</comment><comment><USER6> Funny to see the Netherlands appear on a worldmap for a change :)</comment>


MIT Unveils Working Artificial Leaf That Creates Fuel From Sunlight - <AUTHOR> http://inhabitat.com/mit-unveils-artificial-leaf-that-creates-hydrogen-fuel-from-sunlight/

<comment><USER2> Blogspam.

Actual article: <http://web.mit.edu/newsoffice/2011/artificial-leaf-0930.html>

Source Paper: [http://www.sciencemag.org/content/early/2011/09/28/science.1...](http://www.sciencemag.org/content/early/2011/09/28/science.1209816.full.pdf)

<comment><USER3> It's damn near plagiarism in places too.</comment></comment>


New blood pressure guidelines say half of adults have high blood pressure - <AUTHOR> https://www.washingtonpost.com/news/to-your-health/wp/2017/11/13/blood-pressure-of-130-is-the-new-high-according-to-first-update-of-guidelines-in-14-years/ <comment><AUTHOR> Why do I have a feeling that this is driven by pharma to increase drug prescriptions to lower blood pressure?

<comment><USER2> Although the WaPo article isn't a primary source, it seems to say the opposite and cites primary sources:

> Much of the data to support the update came from Systolic Blood Pressure > Intervention Trial or SPRINT trial, a large-scale study of more than 9,000 > people sponsored by the National Heart, Lung and Blood Institute

And regarding the proposed treatment:

> But the report's authors predicted relatively few of those who fall into the > new hypertensive category will need medication. Rather, they hope that many > found with the early stages of the condition will be able to address it > through lifestyle changes such as losing weight, improving their diet, > getting more exercise, consuming less alcohol and sodium and lowering > stress.

Here's the primary author's home page, though the report isn't on it: [https://med.virginia.edu/endocrinology- metabolism/research/e...](https://med.virginia.edu/endocrinology- metabolism/research/endocrine-labs/robert-carey/)

Update: here's an analysis of the number of people affected by the lower threshold: [http://circ.ahajournals.org/content/early/2017/11/08/CIRCULA...](http://circ.ahajournals.org/content/early/2017/11/08/CIRCULATIONAHA.117.032582) ("Compared with the JNC 7 guideline, the 2017 ACC/AHA guideline results in a substantial increase in the prevalence of hypertension but a small increase in the percentage of U.S. adults recommended antihypertensive medication.")</comment></comment>