Google Docs vs manual typewriter - <AUTHOR> http://tommorris.org/blog/2009/12/31

<comment><USER2> I have respect for the pen, due to its portability, convenience for quick notes and use for making sketches, diagrams, and free-form documents. The type writer, on the other hand is idiotic. It's rigid, even worse than computer documents. It's also completely incapable of handling Chinese, which makes up a large part of what I have to write. On top of that, a typewriter weighs more than a backpack with a laptop inside.

What's next, _Mass production vs personal forge_?

</comment><comment><USER3> Admittedly I couldn't stand to read the whole article. His obsession with typewriters seems to have influenced his taste in font size and family.

My question to others based on what I read is how many people here, without looking, can type quickly and accurately but choose to not follow the homerow practice? I type very quickly, and hardly ever need to press backspace. I usually only look when I type in 16 character passwords with alternating caps.

<comment><USER4> On most keyboards it is very hard to touch-type while programming. Seriously, I just can't enter a curly brace while keeping my hands on the home row. It hurts :) And once you move that hand, repositioning it takes time.

The other reason I never learned to type properly is that I just get bored. I tried several times, and always gave up. It just feels like a waste typing fjfjfjfjfjfj when I could be entering code.

Finally, the productivity of a coder isn't how fast he/she can type. It's how well they think, which is mostly inversely related to WPM.

<comment><USER5> >It's how well they think, which is mostly inversely related to WPM.

That's an...interesting claim. Why do you think typing ability is negatively correlated with intelligence?

<comment><USER6> I, for one, can type almost 80wpm and am dumb as a rock. I can never solve logic puzzles, and struggle with debugging when writing one-page scripts in Python.

<comment><USER7> Upvoted, for making me chuckle.

But I'm pretty sure that typing speed and programming ability are not- correlated, most definitely not _inversely_ related.

<comment><USER4> "Correlation does not equal causation"

Also, I really should learn to type better. This though got me googling. I found some discussion on the topic:

<http://news.ycombinator.com/item?id=952745> <http://news.ycombinator.com/item?id=510087>

Also, I seem to remember someone posting a webapp typing tutor. Does anyone remember the name?

</comment></comment></comment></comment></comment></comment><comment><USER8> Sorry, I had to close the page after reading: "I'm not sure that it's possible to know how to code in as many programming languages as I do"

tldr: It's painfully apparent the author is getting too old to Keep Up and is taking that frustration out on newer technology. Retire already. No one uses gopher or typewriters anymore (for serious work), nor will they ever.

<comment><USER9> You should have at least finished the sentence before concluding that it makes no sense. "I'm not sure that it's possible to know how to code in as many programming languages as I do, own an iPod, three laptops, two mobiles and be able to quote verbatim from some W3C/IETF specs and consider oneself a Luddite unless one significantly bends the definition of Luddite."

<comment><USER8> Perhaps you're right. I just felt it didn't make any sense. How is owning gadgets and quoting specs some kind of "anti luddite" badge? Seems like he's in some serious denial.

<comment><USER10> Agreed - One who is a "Luddite" is not, by the very definition of the word, opposed to technology, per se, but instead are opposed to "technology change" - the author does seem to be opposed to technological change - but does make some good reasons as to why he is.

I think the article may have been written half tongue in cheek - I expect if I was British, instead of just Canadian, I might have more fully appreciated the humor. Hints were as follows:

" If a burglar enters your home, you can drop your typewriter on them from above"

"To get the most out of Google Docs, you must use an arcane device known as a mouse. "

But, if you read the article all the way to the end, there are actually some parts that cause you to think about the (particularly for the ADHD among us) issue of using Google Docs as our principal text entry / editting tool (as opposed to something like "Pages" in Full Screen mode)

<comment><USER11> I'm somewhat surprised - but gratified - to read my post on Hacker News. I posted it mostly as a sort of very dry, tongue-firmly-in-cheek public memo to various people I know who are always telling me why I really need to "get with cloud computing". The idea was to prompt said people into seeing that those of us who don't immediately respond with excitement when told about online services like Google Docs and hurriedly jump on the bandwagon might actually have some relatively sound reasons for it. Lots of people I know seem to get very excited about stuff because it's new, and seem to be on automatic optimism mode about all new technology. The attitude I think is much healthier is a bit of guarded scepticism or realism. The Luddite would refuse new technology flatly - they want the world to stop so they can get off. Instead, I was hoping to push my readers (mostly my personal friends IRL) through a rather absurd example to try and step back from the Digg/TechCrunch/Twitter- driven hype and try to ask themselves "do you really need it?".

As for the earlier suggestion that I should retire, I most certainly would like to, but I'm in my twenties (it is perfectly possible to have used a typewriter frequently as a child and now be in one's twenties). Old school doesn't equal old. I'm a programmer in my spare time and do independent development projects to pay my way through philosophy grad school. I think Google Docs has a perfect use - I use it a fair amount for planning (the podcast I'm involved in uses it, and we used it quite a lot to plan a vacation). I'm not advocating using a typewriter instead of Eclipse or instead of whatever you use for word processing. What I'd like is if some of my geek friends would learn the lessons of technological history and maybe try some of the old tech they think desperately needs to be deprecated in order to bring about some technological paradise. It's not all bad.

I'm not opposed to technological change. I'm opposed to people thinking technology is automatically good because it is new and automatically needs to be made obselete because it is old.</comment></comment></comment></comment></comment>


Dark Caracal: Good News and Bad News - <AUTHOR> https://www.eff.org/deeplinks/2018/01/dark-caracal-good-news-and-bad-news <comment><AUTHOR> As much as distributing apps outside of centralized apps stores helps to promote decentralization, I have admit the Moxie Marlinspike refused to do so for reasons just like this.</comment>


Data visualisation, from 1987 to today - <AUTHOR> https://medium.economist.com/data-visualisation-from-1987-to-today-65d0609c6017 <comment><USER2> The topic is interesting but unfortunately the article lacks on "data visualisation" examples. Although interesting to know how it was before computers, more like art than data science, it would be good to see how it evolved on computers from 1987 to now.

<comment><USER3> This article could be considerably longer, I agree. As such, it is merely an interesting introduction.

</comment></comment><comment><USER4> For even older data visualization, I recommend Willard C. Brinton, "Graphic presentation" (1939) a book freely accessible on [https://archive.org/stream/graphicpresentat00brinrich#page/n...](https://archive.org/stream/graphicpresentat00brinrich#page/n0/mode/thumb).

It is fascinating to see that people repeat the same simple errors that were considered errors almost 80 years ago.

</comment><comment><USER5> Foundational principles from scholars such as Tufte and Bertins have helped influence data visualization over the years from a presentation perspective, but software improvements, such as D3.js, have tremendously assisted in the implementation piece of data visualization. Further, computer improvements and the advent of languages like R and Python have also allowed us to clean, process, and present a much greater volume of data than could have been achieved in the 80s and 90s.

</comment><comment><USER6> Displaying data in graphical is nice but do you have any recommendation for guidelines in making tables? So far I have find [https://www.inf.ethz.ch/personal/markusp/teaching/guides/gui...](https://www.inf.ethz.ch/personal/markusp/teaching/guides/guide- tables.pdf)

</comment><comment><USER7> No discussion of data visualization history is complete without mention of Edward Tufte's _The Visual Display of Quantitative Information_.

[https://www.edwardtufte.com/tufte/books_vdqi](https://www.edwardtufte.com/tufte/books_vdqi)

</comment><comment><USER8> Re: the Florence Nightningale reference in the article

[http://www.florence-nightingale-avenging- angel.co.uk/?p=462](http://www.florence-nightingale-avenging- angel.co.uk/?p=462)

</comment><comment><USER9> > Our spelling deteriorated almost overnight as the pressure of making > mistakes was removed.

Some things never change :-)</comment>


You can't just rename your IT Ops team and call it DevOps - <AUTHOR> https://www.datree.io/resources/devops-definition <comment><USER2> How is such a thin article upvoted? That was basically a verbose tweet.

<comment><USER3> Because really you're supposed to click the link in the article and listen to the interview.

<comment><USER4> If TFA contained a transcript it might have been worth an upvote...

<comment><USER5> Looks like there's a transcript here: [https://softwareengineeringdaily.com/wp- content/uploads/2019...](https://softwareengineeringdaily.com/wp- content/uploads/2019/02/SED771-Datree.pdf)

<comment><USER6> Can we replace the original link with either this or the audio?

</comment></comment></comment></comment></comment><comment><USER7> DevOps is a horribly misapplied term. I recently referred to a client systems administrator as a "sysadmin", because they were doing sysadmin things: provisioning and configuring production hardware, networking, backups, databases, etc. I was chastised by the [much-younger-than-I] CTO, who said he "hadn't heard the term sysadmin in 20 years" and that they were the DevOps team.

No, sorry. They were sysadmins. DevOps is valuable role, and I'm glad there's a focus on supporting developers and their needs, and in empowering developers to manage their own build and deployment infrastructure. In a larger organization, having a dedicated person or team working closely with developers on software build, test, and deployment automation is great.

But if your job is maintaining production hardware, network, operating system, DNS, SSL certificates, firewalls, backups, etc., then you're a sysadmin. It's not a pejorative term. In a small organization, or within a team, that may be combined with a DevOps role. You may even have one person who maintains all your infrastructure for production and development, and even doubles as a developer. That still doesn't mean you label the entire role DevOps.

<comment><USER8> "DevOps" = "sysadmin that can code scripts".

Whatever your conceit, that's in fact what the term means in practice.

<comment><USER9> The job description of a sysadmin always required knowing at least one interpreted and one compiled programming language.

Programming is a subset of skills within the sysadmin role.

<comment><USER8> > The job description of a sysadmin always required knowing at least one > interpreted and one compiled programming language.

You'd be surprised. A large chunk (say, more than 50%) of the sysadmin job market are guys that can set up a Windows LDAP and/or some Cisco and Wi-Fi equipment, but no more.

It's why the 'DevOps' moniker was invented, to differentiate the old-school Unix sysadmins from the LDAP-and-Exchange guys.

</comment></comment></comment></comment><comment><USER10> You also can't just rename your Dev team DevOps...

Ops people come from a background favoring stability, security, and connecting components.

Developers come from using new and great tools... Writing the connections between their own systems, and following API docs of their partners.

Ops people usually have less CS training, and developers frequently don't understand security aspects of running systems or containers. You should merge the teams, not drop additional responsibility's on one side or the other that are outside their training/experience

<comment><USER11> Please be careful with the prejudices here around the CS knowledge of operations professionals. As a computer scientist who builds software for operations automation, I often find that developers work in interpreted or virtual execution environments and have little understanding of the underlying execution infrastructure or even the compiled environments that execute their code. The ops team understands throughput,

I agree that cross-training and shared responsibility for both success and support are critical for success -- regardless of labels put on people and teams.

</comment></comment><comment><USER12> If you can rename "statistics" to "machine learning" and "data analyst" to "data scientist" [1], I don't see why you can't rename "IT Ops" to "Dev Ops".

[1] If you haven't heard it, there's a joke:

Q: What's the difference between a data analyst and a data scientist?

A: The data scientist lives in San Francisco

<comment><USER13> The distinguishing factor between those two roles that I have noticed is data scientists build predictive models and use statistics somehow, while analysts are relegated to the 'grunt' work like cleaning data, building reports, etc. Analysts are typically working to become data scientists. I only have 5 years of work experience at 2 companies, so I'm sure results vary. I make sure not to make any assumptions when I hear either title, however, I've met incompetent 'data scientists' and brilliant 'analysts'.

</comment></comment><comment><USER14> There is no DevOps role. There is no DevOps team. Devs doing Ops != DevOps. DevOps is about tearing down silos (Dev and Ops), not creating new ones.

<comment><USER15> I'm glad I'm not the only one who thinks like this. Every time I read someone referring to, "a DevOps," I wonder what they think they're referring to. No one person is going to be everything you need for effective development and operations combined outside of small, extremely focused scope. DevOps is about avoiding the, "Just throw it over the wall," mentality, not making one person handle the whole thing.

<comment><USER16> >I wonder what they think they're referring to

This and

>DevOps is about avoiding the, "Just throw it over the wall," mentality, not making one person handle the whole thing.

this are why it's now part of my interview process when I'm interviewing for a new role "how does your company/team define DevOps?" and I listen very closely for things that sound like 'over the wall-Ops'. Admittedly having the fortune at this point in life to be quite judicious about the answers given.

Ostensibly, if I'm applying for a 'DevOps' role, I shouldn't _have_ to do this if the job description is written well enough, yet even then this has become a learned behavior even when coming across the rare well-articulated job req.

</comment></comment></comment><comment><USER17> I had this happen to me from the other end. I was the lone programmer (and my title reflected that). After a new hire, I was told that I was some kind of engineer because my title had changed to that and that we are now DevOps, hooray! Not coincidentally, this was to be my final awful Agile experience.

The thing is, I am not gifted in the area of system administration. I am not too shabby at it in Windows, quite pathetic in Linux, but being a sysadmin was a role I had escaped for a _reason_. And suddenly I am back in it. I am a very low-tooling programmer. Just let me stick my hands in the data and go away. I have great respect for people who are system administrators but it is a job where my talents lie below my meager skills, and my inclination far below that.

Meanwhile, the _true_ system administrators, who had been doing that for quite some time, had been denied the actual title for some time, were going to be moved over just as ... bodies, I guess, to elsewhere. All just ... DevOps now or whatever.

What a trainwreck.

</comment><comment><USER18> Of course not, you need to install Jira as well, so your now Agile..

I was going to use a sarcasm tag, except that is pretty much what my last employer did...

<comment><USER19> I've had "here is an install of Jira, go play" with no configuration done or any admin existing too.

My greatest achievement in that job was making production a git repo so that we could regards against production before pushing. A sufficiently low bar you'll trip over it.

</comment></comment><comment><USER20> My recent experience in interviewing candidates is that they have all heard the word "DevOps" but what they understand by it is highly variable, and ranges from from a way of working, to a build pipeline in Azure to ... yup, a renamed Ops team.

It's pretty sad.

<comment><USER21> It's a pretty good progression from before.

The most common name used to be sysadmin. That could be development or operations or anything down to running a Windows Active Directory or HelpDesk.

At least with DevOps, there is no doubt that it's about Linux systems and automation.

<comment><USER20> > At least with DevOps, there is no doubt that it's about Linux systems and > automation.

Is that what you understand by the term "Devops" ? That "it's about Linux systems" ? Really??

That definition is a new one on me, and you very much should doubt it since "it's about Linux systems" is neither necessary nor sufficient. The confusion is even worse than I thought.

<comment><USER21> Are you trying a joke on Linux vs Unix? in reference to companies using Solaris or FreeBSD maybe? (there aren't many left of those).

All the DevOps roles I've ever seen are Unix based. In my experience sysadmin roles were more likely to be a windows administration or a helpdesk role than that.

I think it's pretty good devops got split into a distinct title. It's not a great experience walking into a sysadmin interview only to find out they are looking for an exchange administrator.

<comment><USER20> > Are you trying a joke on Linux vs Unix?

No, I'm saying the the DevOps ideas have nothing to do with OS choice. You could use them in linux or Windows or in any other OS; or you could ignore them in linux or Windows or any other OS.

</comment></comment></comment></comment></comment><comment><USER22> Oh, another person telling the world what devops means.

If we take the 50 thousand or so other blog posts about the definition of devops and glue them together - it means whatever you want. Ops teams doing some code, devs building CI/CD infrastructure, whatever.

<comment><USER20> > another person telling the world what devops means....- it means whatever > you want.

I think that devops (like agile) will have a definite meaning, but uncovering that is mostly a process of examining the early history of it - who first used it and when? The definitions used, the problems that it aimed to solve, and the methods used to solve them.

However, like "agile" it can and often is abused to mean everything and nothing. This does not make it inherently meaningless, though.

</comment></comment><comment><USER23> Cloud engineer. Network engineer. Software engineer.... I've never heard of medstudents calling themselves doctors, why do cs students/grads get a pass?

Up next chefs will be food engineers, tailors will be clothing engineers, and because I changed the oil in my Toyota once, I'm now a Toyota engineer; specializing in fluids.

Words mean literally nothing anymore (ha). Titles in tech are hilarious at almost every level, especially from the outside looking in.

<comment><USER24> This argument gets rehashed in HN pretty often. When I just worked in ops or support my job title had the word "technician" in it. When I was designing systems my job title had the word "engineer" in it, even if I also had ops duties. As far as I can tell this is a regional thing, where certain jurisdictions have laws that regulate who can call themselves engineers, just like certain jurisdictions have laws about who can call themselves hairdressers. That doesn't stop people on HN from thinking that for some reason, we can all agree on a definition for "engineer", even though we have regular disagreements about the definition about almost every other word in the English language.

"DevOps" is at least ill-defined from the very start, so if we have arguments about what "DevOps" means, at least I can learn something.

</comment></comment><comment><USER25> I've met many smart people from large enterprises who said, "I'm the DevOps [guy|team|person]" with a straight face. Generally, I believe they know it's wrong, but their leadership didn't, and they were just eager to move the needle a little bit that they accepted.

</comment><comment><USER26> Maybe people shouldn't get stuck up that much about words. Unfortunately they are so it's smart to attach yourself to the currently fashionable title. If you do something with dev tools call yourself "devops". If you run a few database queries better call yourself "data scientist ". And if your current buzzword falls out of favor then don't change your work but find a new fashionable label.

It's an unfortunate state of the industry that we put value and prestige into ill defined labels.

</comment><comment><USER27> Yep. Similar notion applies with "Agile" \-- you can't just throw out all requirements analysis, up-front design, and architecture work, and say "We're Agile". But people do it all the time, because they're enthralled with the buzzword and not the actual _meaning_ behind the buzzword. Same applies for ( Agile | Devops | $WHATEVER). And the sad thing is, this in turn devalues the original idea and causes a backlash where people throw the baby out because somebody crapped in the bathwater.

<comment><USER28> It's how tech and capitalism interface. The $whatever is actively marketed, the profits are arbitrage between the true value of the thing and the perception of the value. Since that value perception is easy to manipulate with network effects, and true innovation much more difficult, we then become stagnant. Maybe this is why we don't see much productivity for the past several decades. Productivity gains are never realized because the tech stays constant while perceptions are maneuvered for profit. One reason China may win; less respect for IP.

</comment></comment><comment><USER29> Interesting, in my last company the team themselves thought DevOps was not a role, but more a responsibility that should be shared among all devs and they renamed themselves _" Production Engineering"_.

They said it was admittedly not the best, clearest of the names, but the important thing is that DevOps should be shared, not owned. As a dev, it made a lot of sense to me

<comment><USER30> > They renamed themselves "Production Engineering"

That jibes with my experience, where there has generally been one or more groups that build and maintain infrastructure to enable dev teams to build, deploy, monitor, etc. But what do you call it? It's not a DevOps role per se, nor really an Ops role, but it enables DevOps. We called it Platform, but said we were hiring DevOps engineers.

In short: it's a mess. :-)

<comment><USER20> That role /team is real, especially in larger orgs, and a better name for it is "platform" / "platform team" / "platform engineering" not "DevOps".

If you must call it "DevOps", it is "Devops enablement team", i.e. supplying a platform to enable dev teams to better Develop, build, deploy, monitor, Operate what they make, themselves - enabling others to do DevOps by supplying tools.

See:

[https://martinfowler.com/articles/talk-about- platforms.html](https://martinfowler.com/articles/talk-about-platforms.html)

[https://www.thoughtworks.com/radar/techniques/platform- engin...](https://www.thoughtworks.com/radar/techniques/platform-engineering- product-teams)

[https://hackernoon.com/how-to-build-a-platform-team-now- the-...](https://hackernoon.com/how-to-build-a-platform-team-now-the-secrets- to-successful-engineering-8a9b6a4d2c8)

</comment></comment></comment><comment><AUTHOR> Hard to believe (or maybe not?) there's still ambiguity around "DevOps" so many years after its introduction.

And with ModelOps, DevSecOps, AIOps, GregOps, and GitOps recently entering the lexicon brace yourself for lots of confusion and "xOps explained" articles ahead.

By the way, one of those xOps isn't real, but who can even tell?

<comment><USER19> I'm assuming it's GregOps, because GreggsOps is HugOps with bonus vegan* sausage rolls. :P

* vegan optional

<comment><USER31> It's actually been going by GregoryOps lately.

</comment></comment></comment><comment><USER32> Role names in most software companies that I've worked at and know of are almost completely arbitrary.

They're useful if you have an organization that pays a specific rate for a specific job title, and they're useful in a hierarchical sense (e.g. managers, CTOs, etc). That's about it.

I install and maintain servers and desktops, databases, run backups, build infrastructure, source control servers, do low level programming, high level programming, frontend, backend, ... etc, it's too long to even enumerate.

As far as I'm concerned that's just being a (non-junior) software developer. It's all ultimately the same thing with different names to me, barely anywhere really needs people who are at the forefront in a tiny niche (i.e. _real_ specialists).

You can call me whatever you want as long as you're paying the bills.

</comment><comment><USER33> DevOps, like most IT fads, is just trying to get more blood out of the stone and avoid letting anyone specialize in anything. That's obviously not the original intent, but it's what happens.

</comment><comment><USER34> IT fashion:

out: DevOps

in: SRE

<comment><USER35> Check this out: [https://www.youtube.com/playlist?list=PLIivdWyY5sqJrKl7D2u-g...](https://www.youtube.com/playlist?list=PLIivdWyY5sqJrKl7D2u-gmis8h9K66qoj)

</comment></comment><comment><USER36> The sad reality in most organizations today is that buzz words are applied to existing jobs to make it look like progress. So yes, apparently you _can_ rename your IT Ops team to DevOps and brag about "how you engaged your teams to move to a DevOps focus to better align them with company values while leveraging the low-hanging fruit within today's shifting economy" during an executive management meeting.

</comment><comment><USER37> Agreed, but, perhaps, as a management strategy, it may help some teams transition. Since after all, for folks with careers in manual provisioning, devops truly is a new frame of mind.. swapping words in titles around is just part of operations development? :)

</comment><comment><USER38> _"...not about hiring a 'DevOps guy'"_

Yet, this is one of the most common scenarios I've seen. "Oh, this guy/gal started devops at Xyz company.".

</comment><comment><USER39> DevOps means "the build and continuous integration system is so complicated, it needs dedicated people who have software dev credentials".

</comment><comment><USER40> Wait, nobody ever named a team "IT Ops".

</comment><comment><USER41> Or call technical customer support Devops. Which also contains the Ops team, which has recently been renamed Devops.

</comment><comment><USER42>
        > You can't just rename your IT Ops team and call it DevOps

Sure you can. Companies can and will do whatever they want. It may not be semantically correct, but it definitely wont stop anyone. Just go on indeed and look up "DevOps jobs" and you'll see many companies who have done just that.

</comment><comment><USER43> I'm so sick of all this hyped up bullshit!

Someone who administers systems is a system administrator and someone who develops is a programmer.

And in my 30+ years in the business I haven't seen a single BSD or Linux system administrator who couldn't also program in C or some other language.

</comment><comment><USER44> Of course not. You also need to lay off your entire testing team and rename the IT Ops team DevTestOps.

</comment><comment><USER45> Super interesting and relevant. Thanks!

</comment><comment><USER46> At public corporations (especially regulated) there are confounding factors that make DevOps a farce. For example audit, a point of view that IT is a cost center, and the non technical management decision making that go along with the previous challenge the spirit and proper execution to get DevOps right. But in reality DevOps is a symptom of a larger issue - functional reporting structures and goal misalignment.

Audit - the idea that your developer doesn't have access to production systems and data is a challenge to DevOps. The idea that one person codes and one deploys can be a challenge. Some organizations like management visibility and an audit trail to prove it - this can challenge automation and frequent deployment. This is not just a DevOps issue, audit expectations for business requirements and QA signoff can be just as bad. Admittedly some of the audit rules are relics of the past but the need to be addressed in order for DevOps practices (and really for agile teams to be agile.

In organizations where IT is a supporting function of the business there is a view point that it's a cost center only and doesn't produce value and should be cost controlled and managed to ultimate efficiency. I've reminded CIOs that the work the IT team does is not "a factory" as they sometimes insist on calling it - no one in technology that I've ever met (except management) really wants to think they work in a factory.

The efficiency mindset rank orders roles with QA and analysts at the bottom, devops slightly higher, developers relatively high, architects at the top of the skilled food chain and management of course at the top. To some degree these functions can be centralized so they can be optimized and made efficient. Centralizing typically means you work for management rather than a particular business mission. Your job is to make management look good and keep everything running smoothly (remember you work in a factory). Management generally looks good when quality is achieved at a lower price point. Along with that tends to be a higher level of off shoring at the lower end of the skill rank where larger numbers means more efficiency at lower cost. Here lies the problem - the premise of DevOps is that the role is integrated in the team. When DevOps is a function reporting to management then their goals aren't aligned to the development team. They might not even sit with the team and they might have their own orders. They might be in a 12-20 hour time zone offset.

To me the larger issue is management structures aligned by function instead of business. This leads to misalignment if goals and ultimately lack of integration in functions. It's a bigger problem than DevOps and it's a bigger problem than IT. I think the companies that get management reporting right will win in the end. I am curious to see how Google and Amazon respond to these issues at their scale. The pizza team doesn't work when everyone has different goals.

</comment><comment><USER47> *shouldn't</comment>


Why was SCTP selected for WebRTC's data channel? (2014) - <AUTHOR> https://bloggeek.me/sctp-data-channel/ <comment> Sean-Der I think SCTP was a very good choice.

Writing a SCTP implementation for Pion WebRTC[0] was really enjoyable. The SCTP RFC is well written and easily available [1]. Once you learn all the chunk types things start to fall into place. SCTP is also battle tested and we know what flaws it has.

I am pessimistic about alternatives

* New protocols/changes are spread across multiple drafts, and they are abandoned once they land in browsers. Most of the time these changes are already going to happen and these drafts are just a way to notify the general public it is happening. So it ends up being 'the implementation is the spec', and things are brittle. SCTP doesn't break like that.

* WebRTC is still very difficult to use. For large dev teams/corporations it is a solved problem, but I really wish there was more excitement/emphasis around lowering the barrier to entry. It is a really powerful technology, but it seems like we just keep getting half-baked things out the door and then moving on.

[0] [https://github.com/pion/webrtc](https://github.com/pion/webrtc)

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

<comment><USER3> RFC490 was simply a "rollup" of SCTP at that point with minor corrections not some protocol with immaculate birth where the initial RFC gets you up to date with the protocol. It also features a large set of errata and about a dozen feature extension RFCs that have come out since (as well as an RFC on security attacks found against SCTP that one definitely should to read before writing an implementation). I'm also not familiar with any recent protocol added to browsers that has been abandoned from a standards perspective in the way you describe. Websockets and what were known as SPDY & Quic have more standards activity than ever before.

Are you referring to the barrier to use WebRTC or the barrier to make your own implementation?

</comment></comment><comment><USER4> SCTP has been used in professional settings for telecoms for at least a decade.

The kernel implementation in Linux is stable and has been for many versions.

There are gotchas: \- Cloud support for SCTP is poor. Azure has no support for SCTP on its load balancers. \- Kubernetes support is similarly poor - <USER2> support is beta and behind a feature gate.

<comment> Sean-Der Have you done SCTP over the public internet?

I haven't tried it myself, but always heard the only way to make it work was encapsulated in UDP.

<comment><USER5> A lot of providers will filter out SCTP at the boundaries, especially for consumers. I know of providers that only whitelist TCP and UDP on their gateways.

</comment></comment></comment><comment><USER6> Note the final implementation is not running directly over IP, as section 1.2 of rfc 4960 says. Instead, WebRTC uses "SCTP over DTLS over ICE/UDP". This unfortunately means that WebRTC adoption means nothing for general STCP apps, and will never care about kernel-based implementations.

<comment> Sean-Der Do you know of anyone that is interested in bridging that gap? I only have done user-space/embedded WebRTC. After Pion WebRTC I got hired to write a pure C WebRTC implementation [0] that is at around ~700kb. It does media + DataChannels.

I want to eventually explore building a very minimal SCTP implementation and maybe get the binary size sub 400Kb. IoT/Embedded is just getting warmed up to WebRTC, I am really excited to see what happens next.

[0] [https://github.com/awslabs/amazon-kinesis-video-streams- webr...](https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c)</comment></comment>


Kubernetes Security Best Practices - <AUTHOR> https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/ <comment><USER2> It is unrealistic to fit Kubernetes Security Best Practices into a single blog post. Here are MANY other blog posts or other very similar content:

[https://kubernetes.io/blog/2016/08/security-best- practices-k...](https://kubernetes.io/blog/2016/08/security-best-practices- kubernetes-deployment/)

[https://www.aquasec.com/wiki/display/containers/Kubernetes+S...](https://www.aquasec.com/wiki/display/containers/Kubernetes+Security+Best+Practices)

[https://dev.to/petermbenjamin/kubernetes-security-best- pract...](https://dev.to/petermbenjamin/kubernetes-security-best-practices- hlk)

[https://techbeacon.com/hackers-guide-kubernetes- security](https://techbeacon.com/hackers-guide-kubernetes-security)

[https://www.sumologic.com/blog/devops/kubernetes-security- be...](https://www.sumologic.com/blog/devops/kubernetes-security-best- practices/)

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

[https://speakerdeck.com/ianlewis/kubernetes-security-best- pr...](https://speakerdeck.com/ianlewis/kubernetes-security-best-practices)

[https://dzone.com/articles/kubernetes-security-best- practice...](https://dzone.com/articles/kubernetes-security-best-practices)

and a quick search reveals a full length e-book about it:

[https://info.aquasec.com/kubernetes-security- sem](https://info.aquasec.com/kubernetes-security-sem) ([https://kubernetes- security.info/](https://kubernetes-security.info/))

[https://cdn2.hubspot.net/hubfs/1665891/Assets/Kubernetes%20S...](https://cdn2.hubspot.net/hubfs/1665891/Assets/Kubernetes%20Security%20-%20Operating%20Kubernetes%20Clusters%20and%20Applications%20Safely.pdf?t=1538587424944&_hsenc=p2ANqtz-_7jbqtRATdJAm7eFxtd5u4nVLYuIlrF67z5qbslZ10-I63-RZ4ogqu9iuuEMsx7fskPYWww2jDpVjOvrLs)

</comment><comment><USER3> _Earlier this year, Tesla suffered a complex cryptocurrency mining malware infection caused by a misconfiguration in the Kubernetes console. The attackers exploited the fact that the particular Kubernetes console wasn't password protected, allowing them to access one of the pods that included access credentials for Tesla's larger AWS environment_

Given the amount of driving data that Tesla has, and the apparent scope of the breach, I'm surprised the attackers only mined some crypto. Wonder if that's because the data is well segregated, or if mining crypto is just more profitable than extracting and leaking data?

<comment><USER4> Once I was hired to clean up after a site breach.

From logs I could watch the attackers spend an hour learning how to exploit some vulnerable php code, then learning how the customers admin area worked. Then they changed the html on some rarely seen pages to include google ads point to an account controlled by the attacker. And that was it - no trace of any other monitization or destruction.

The site in question was selling $1,000 a pop training courses via authorize.net. Given the access the attackers had, they could have run off with so many credit card numbers.

In a perfect free market for crime, this would never happen. A break in criminal would sell access to the organization that could extract the most "value" from the target. But as it is, many exploiters do not have the connections to do this, and so usually follow the same "monetization" pattern on target after target.

<comment><USER5> > In a perfect free market for crime, this would never happen. A break in > criminal would sell access to the organization that could extract the most > "value" from the target.

I don't know what you mean by "a perfect free market for crime", but penalties are presumably stiffer for cc theft vs selling ads; also more resources will be dedicated to finding the thief in the more severe case. So selling ads might be the right blend for more "conservative" hackers.

</comment></comment></comment><comment><USER6> Something I often don't see mentioned -- be wary of older (as-in lifetime, not version), long-running clusters. I have found multiple times where a product has some vulnerabilities because I can land myself into an "older" cluster that predated various security enhancements that were made to: provisioning, iaas lockdown, etc, that will old clusters will almost surely not benefit from due to the nature of the "fixes" being in the initial configuration.

(As an example, "SomeProduct" allowed users to run somewhat arbitrary, non- privileged, non-root containers. I assumed it was K8s and poked around. All clusters were on GCE and ostensibly running the same versions, but due to how they were initially deployed, had different levels of vulnerability. The older clusters predated GCE blocking the metadata server, and predated the existence of TLS bootstrapping for kubelet, so for some of their clusters, it was easy to grab the kubelets key+cert and impersonate the kubelet as an unprivileged user. It sort of requires having someone paying a fair amount of attention upstream and/or knowing details of k8s provisioning to catch some of these things.)

</comment><comment><USER7> What about PKI? I ran a decent size K8s cluster for a while and proper PKI was a pretty important thing IMHO. Everything running in a K8s environment supports PKI (roots, intermediates, client / server cn / rbac verification, etc) and there's no excuse to set things up properly when tools like cfssl exist and can be automated in deployment pipelines.

Edit: CRL[0] and OCSP(maybe?) appear to be coming soon.

0: [https://github.com/kubernetes/kubernetes/issues/18982](https://github.com/kubernetes/kubernetes/issues/18982)

<comment><USER8> CRL and OSCP have been asked for for a very long time! I don't see them coming anytime soon.

The golang TLS library author has a thing against them, so chose to not implement them[0].

Personally, I think he's wrong. He's describing a web browser style use case and not an internally managed CA for a single specific service, and he's then applied that reasoning to a languages TLS library. And it's left essentially all TLS in golang without revocation support.

For Kubernetes, you'll need to wire up nginx/haproxy whatever in front of every endpoint to do TLS+CRL checks before handing off the connection to the actual backend (kube-api, kubelet, etc) over 127.0.0.1 (still with SSL! Lookback is not safe when untrusted code is running on your server..).

[0]: [https://www.imperialviolet.org/2014/04/19/revchecking.html](https://www.imperialviolet.org/2014/04/19/revchecking.html)

</comment></comment><comment><USER9> The thing I love about Kubernetes is that it's batteries included and enterprise-first. Sure, it's not as simple as docker but when crunch time hits and you need security depth the configurability of Kubernetes is unmatched. Perhaps it just needs to be surfaced better.

</comment><comment><USER10> I got forwarded the CIS Securing Kubernetes benchmark document a few days back. That had around 100 things that should be set on a cluster for your Enterprise's next security audit.

[https://www.cisecurity.org/benchmark/kubernetes/](https://www.cisecurity.org/benchmark/kubernetes/)

<comment><USER11> There used to be a runnable cis benchmark libraries like neuvector/kuberntes- cis-benchmark[0] but there are less these days. Aqua Security also has one called kube-bench[1] which looks to be in better shape.

[0]: [https://github.com/neuvector/kubernetes-cis- benchmark](https://github.com/neuvector/kubernetes-cis-benchmark)

[1]: [https://github.com/aquasecurity/kube- bench](https://github.com/aquasecurity/kube-bench)

</comment></comment><comment><USER12> One of the better Docker security tutorials I've seen so far: [https://www.katacoda.com/courses/docker- security](https://www.katacoda.com/courses/docker-security)

</comment><comment><USER13> the first best practice would be not using Kubernetes, as long as it calls "home".</comment>


Meebo's Reach Spikes To Over 90 Million Users With Community IM Growth - <AUTHOR> http://www.techcrunch.com/2009/10/06/meebos-reach-spikes-to-over-90-million-users-with-community-im-growth/ <comment><USER2> They seem to be branching out quickly to new IM clients (facebook and gChat recently, I've noticed) and expanding their staff (current intro box says they're up to 90).

Has anyone worked with their API/do they have one? It'd be a useful thing to develop with a single source's API and be able to utilize all these different communications options in a single system.</comment>


In one Italian town, we showed mass testing could eradicate the coronavirus - <AUTHOR> https://www.theguardian.com/commentisfree/2020/mar/20/eradicated-coronavirus-mass-testing-covid-19-italy-vo <comment><USER2> I don't see how this could work unless you cordon off populations, test them and _keep_ them isolated from each other. Even then you would have to sterilize goods that passed between isolated groups. That may work for cows if you have enough barns and fences but definitely is impossible for humans.

I believe that we must be practical and treat based on symptoms. The oft- sought but elusive "test" is a mirage sought by medical researchers that would be nice but is not practical given today's technology and the limitations of human behavior. Besides the test is generally simply not available.

I'll be surprised if the italian towns' quarantines hold.

</comment><comment><AUTHOR> Mass testing seems to have worked. From the article:

"Nonetheless, asymptomatic or quasi-symptomatic subjects represent a good 70% of all virus-infected people and, still worse, an unknown, yet impossible to ignore portion of them can transmit the virus to others. Full testing would give us a clearer picture of how many people actually have the virus, and how many pass it on."</comment>


Google Is Training Machines to Predict When a Patient Will Die - <AUTHOR> https://www.bloomberg.com/news/articles/2018-06-18/google-is-training-machines-to-predict-when-a-patient-will-die <comment><USER2> A very close relative of mine passed away 2 weeks ago. She had cancer for 2 years and when she was first diagnosed the doctors would give her 8-10 "good years". Well...

When she died, I was shocked to learn that very few data points of her sichkness and treatment history would be preserved for later analysis. Doctors work almost entirely on their gut feeling and probably some clinical studies with n being very small. I hate that she died, but it's even worse to know that all her data died with her and won't help any other patient. I think this is one of the rare cases where collecting _more data_ would help protect people

<comment><USER3> I get the impression that much of medicine is one of those strange practices that looks kinda like science, but really isn't. Medical practice appears to work more like a highly evolved guild system than any other kind of recognizable scientific activity. It's probably far beyond the point where its necessary to bring in actual scientific practices, so I can't say it's on the cusp of a sweeping change.

One of the problems that really prevents the change is that analysis of patient data is so highly protected that it's virtually impossible to do proper studies. We assume that people with such access are performing them, but I know from second-hand experience that actual time spent on real treatment studies is very small and most of the time is spent dealing with policy and patient privacy issues.

Large insurance and government-based (VA, CMS, etc.) providers have the most data, but either what they're looking for isn't exactly aligned with what patients need, or the organizations are so fubar (e.g. the VA) that real studies are unlikely to happen.

There really needs to be some kind of research exception/feedback loop on massive scale data analytics that allows some group of objective researchers to mine patient data and put in place actionable recommendations that work their way into medicine rapidly -- perhaps with some penalizing stick insurance providers can leverage against practitioners to make sure they adopt newer better practices.

<comment><USER4> The simple fact that "evidence-based medicine" needs a special name to describe it, rather than all medicine being evidence-based, is still absolutely mindblowing to me.

<comment><USER5> Uh, you're confusing this with the distinction made between Western standard medicine and folk or alternative medicine practices.

<comment><USER4> No, this term was proposed as an "emerging new paradigm" in 1992 (!!) focusing on "the examination of evidence from clinical research" as our most reliable source of information.

"Western standard medicine" was still largely based on intuition and woo less than 30 years ago.

Source: [https://jamanetwork.com/journals/jama/article- abstract/40095...](https://jamanetwork.com/journals/jama/article- abstract/400956)

</comment></comment></comment></comment></comment><comment><USER6> Why did they just use a logistic model instead of survival/time-to-event model?

[https://www.ncbi.nlm.nih.gov/pubmed/21478775](https://www.ncbi.nlm.nih.gov/pubmed/21478775)

Uses cox regression model which is a survival regression model.

Also the base model aka previous model they're comparing it to is a logistic regression and the link leads to a pdf about how to increase hospital efficiency it seems like. This sounds stupid and heartless.

In statistic we got survival analysis, a whole branch that is focus on patient and their survival rate for the medical field. Google chose to compare to a paper and algorithm that focus on what seems like making hospital more money instead.

I've seen a lot of data science people goes into different field and just telling people they can make money for them. It's great but with healthcare I don't think people should be treated as dollar signs.

If anybody up and coming wants to use data science in bio, I would encourage them to look into statistic and biostatistic. We have tons of stuff already and then branch out to ML later. But at least know what's out there and there are establish organization, nonprofit out there too that all they do is biostat and build model. My friend works at a nonprofit child oncology.

I just want to point out there are people that's building model to help patient with terrible sickness out there to survive. We're not diddling our thumbs trying to make other people richer.

<comment><USER7> >I don't think people should be treated as dollar signs.

You're a bit late to the party, no? Basically mortality calculations and risk transfer is what the whole insurance business is based upon.

<comment><USER8> That reply is a bit factual... I want to talk about why it came to be this way.

Medicine has advanced to a point where some serious illnesses can be kept at bay for decades. People with some formerly mortal diseases can get medicines that cost $100k/year and/or professional help every day, and live well for thirty years.

This means that each of rich societies has to choose:

1\. Raise health insurance rates until the budget covers everything that's possible medically. However, in some rich countries, people's after-tax income is only a few doublings above the current health care plus pension costs...

2\. Decide that some treatments aren't worthwhile, ie. _everyone_ with Hyperthis or Abnormalthat Syndrome gets cheap palliative treatment and a peaceful, gentle death.

3\. Decide on a per-patient basis, often involving numbers such as "cost of treatment" and "years left of productive life".

Option 1 is the humane way, but slightly impossible. Options 2 and 3 involve treating people like dollar signs, one way or another. It's an unpleasant choice, not an avoidable one.

<comment><USER9> You've missed the way that it's done absent state intervention, which is perhaps a modification of #3:

        Decide on a per-patient basis, treating the illness when the individual or their family can afford the cost of treatment.

<comment><USER8> There are many minor variations. Another common one is the variation where you you pick an insurance plan before your illness, and the insurer later decides on the details on behalf of all of its insured individuals. And... but they're all minor variations.

</comment></comment></comment></comment></comment><comment><USER10> _As much as 80 percent of the time spent on today's predictive models goes to the "scut work" of making the data presentable, said Nigam Shah, an associate professor at Stanford University, who co-authored Google's research paper, published in the journal Nature. Google's approach avoids this. "You can throw in the kitchen sink and not have to worry about it," Shah said._

Alarm bells start ringing right about here.

A solid 90% of AI is data munging, so that work isn't going away even a little bit; historically, Google throwing the kitchen sink into healthcare problems with lots of noisy data leads to flu seasons being correlated with softball victories or other wildly spurious correlations.

<comment><USER9> > A solid 90% of AI is data munging

What's the other 10%?

I'm serious - I've got a better-than-average understanding of statistics, and everything I've seen referred to as "AI" seems to really be just a statical model with a thin layer of code over the top to make decisions based upon it on the fly. Is there more to the state of the art that isn't apparent from the outside?

In fact, the only thing that comes to mind that doesn't fit that description would be genetic algorithms, but I don't hear much about them these days.

</comment></comment><comment><USER11> I hate to pour cold water on this, but medical researchers have been predicting mortality for years.

For example, here's a paper from the 1980's also predicting when a patient will die, also using a couple of thousands of patients' data: [http://europepmc.org/abstract/med/3816253](http://europepmc.org/abstract/med/3816253)

And, Google's paper wasn't published in Nature, it was in a new open access journal owned by Nature. In academia, that is like the difference between a really fancy porsche, and a really cheap volkswagen (two very different things, both owned by the same company).

<comment><USER12> Regardless of medical / health insurance purposes, actuaries have been doing this for over a century esp. to price life insurance, among other things.

</comment></comment><comment><USER13> I would feel quite unconfortable if every action taken (or not taken) by medic staff has to be second-guessed simply because there are financial incentives derived from this research.

Customer A does not receive full medical support because "he's dying anyway"?

Is there a way to ensure that such cruel use of the research is prohibited?

<comment><USER14> >Customer A does not receive full medical support because "he's dying anyway"?

Unless the patient consents to stop or reduce care, this would be medical negligence, which is illegal (in the US). Medical providers are required by law to provide medical treatment with all the knowledge and skill they possess.

<comment><USER15> > Medical providers are required by law to provide medical treatment with all > the knowledge and skill they possess.

No, to avoid liability for malpractice, they need to meet the "professional standard of care", which is assessed by general practice in the medical community, _not_ "all the knowledge and skill" the individual provider possesses.

</comment></comment></comment><comment><USER16> This was a year ago so things may have changed, but a senior exec at one of the nations largest health systems told me they were looking to change their end of life care program and looked at dozens of AIs that predicted when patients would die. None of them came close to just asking doctors which patients they thought would die within 12-18 months

The point of the project was to make end of life easier for patients and families. Many patients get transferred between multiple facilities in their last few months, and few end up passing in a place and manner they'd like. This project aimed to ask patients and their families how they'd like to spend their last few months.

Initially the health system resisted this bc they wanted to keep patients in the hospital to make money off them, but then they realized these patients were in the hospital so long they weren't profitable. Then the plan was adopted quickly

<comment><USER17> > None of them came close to just asking doctors ...

at a conference, i once heard that the best single predictor of ICU patient mortality was reduction of doctor attentiveness. in other words, patients in ICUs whom doctors began to visit less, treat less, basically start to ignore -- those patients were the ones for whom death was imminent.

the challenge is that it's hard to untangle cause and effect. was it a self- fulfilling prophecy? etc.

</comment></comment><comment><USER18> Maybe this could be useful in countries with nationalized healthcare, but it seems a terrible idea to deploy in the for-profit monstrosity of American healthcare. Institutions will immediately begin to deferring to the "objective" judgements of such systems to either pull care to save costs, or, as was the case with that hospice provider in Texas, kill sick people for more money:

[https://www.cbs19.tv/mobile/article/news/north-texas- hospice...](https://www.cbs19.tv/mobile/article/news/north-texas-hospice- nurse-overdosed-clients-for-money/501-564776570)

</comment><comment><USER12> With deep learning, actuaries were inevitably, mostly obsolete, at some point. It's unpleasant to think, that in a way, tech can now readily disrupt nearly any arbitrary office-worker knowledge industry at will, destroying businesses and specialties and concentrate both capability and wealth in ever fewer hands. Coding isn't a "forever" specialty either... self-coding machines will create languages, protocols and systems humans will likely be unable to understand, limit, modify, monitor or audit.

</comment><comment><USER19> > Google's system even showed which records led it to conclusions.

What if the system points out that the particular doctors which appear in the records are the culprit?

<comment><USER20> Uncomfortable, but over all a good thing as long as the system uses this information properly; offering doctors additional supportive training, if appropriate. (And not forgetting that the doctors with the the worst recovery rates may be the ones predisposed to take the trickiest cases).

<comment><USER21> >(And not forgetting that the doctors with the the worst recovery rates may be the ones predisposed to take the trickiest cases).

IIRC there are a lot of surgeons not taking on cases already because of the risk involved to their career. This might exacerbate it if the data is used blindly.

</comment></comment></comment><comment><USER22> I'm sure it's an interesting technical challenge with huge amounts of complex, nuanced debate involved, and it could have a huge impact on health care.

That said, my wife is an oncology nurse, and I will bet everything that no machine will ever get better at predicting than an experienced, skilled nurse. Humans are built to read humans.

<comment><USER23> » my wife is an oncology nurse

Have you ever asked her if she wants to do the job of predicting when a patient will die? How many hours would she need to spend reading the patient's history to come up with a prediction she feels satisfied to use to decide what service the patient will get? I'm not a medical professional but my gut reaction is I don't want to do anything with predicting or sentencing if some machine can do it almost as well as I can.

I remember this story of a radiologist who told me he thinks we spend too much money for too little during the last about six months of a patient's life. If we had better information on when the last six months starts, maybe we could reduce the cost of healthcare? Apparently, we spend cost to 18% of GDP on healthcare in the US? Iirc, most of Europe is closer to 12?

</comment></comment><comment><USER24> I am sure Deutsch Bank will appreciate such "improvements".

[http://www.spiegel.de/international/business/short- selling-a...](http://www.spiegel.de/international/business/short-selling- american-lives-deutsche-bank-life-insurance-fund-in-hot-water-a-662447.html)

</comment><comment><USER25> I'm sure insurance companies will be glad to get their hands on this to use it as an excuse to deny coverage.

<comment><USER26> Insurance is all about pricing risk accurately, so yes, of course, these ideas will be used to price the risk more accurately.

The problem isn't that insurers are horrible people, it's that insurance is a bad fit for healthcare.

<comment><USER27> Why do you say that? Take insurance in its most basic form: a company does its best to determine how much money they're likely going to pay out over the lifetime of a policy and spreads that cost out for their customer who is then insulated from unexpected expenses or non-uniform cost schedules. It seems perfectly suited to medicine.

Insurance doesn't solve the problem of a population where the total cost of care is more then they can collectively afford or when an individual's treatment has known costs higher than what they can afford but nobody has a good answer for that.

Insuring everyone from birth can be a solution for the individual but not the population.

<comment><USER26> Insurance works when you incur a lot of one time costs, it works much worse when you start incurring a lot of expenses over a long period of time. Ideally you could buy insurance that would cover all of your long term costs once you contracted some disease, but this doesn't exist in the US. And doubly doesn't exist when you realise that there are a bunch of forces incentivizing people to get their insurance from an employer.

<comment><USER27> > you could buy insurance that would cover all of your long term costs once > you contracted some disease

Kind of defeats the point if you're using it to cover known future costs. Insurance can really only insulate you against risk, it's not free money.

<comment><USER26> But at the earlier point in time, when people are buying insurance, these are unknown future costs.

And this is the whole problem, insurers don't want to pay those costs because that would increase the premiums they need to charge, making them uncompetitive (and then you're into the realm of behavioural economics), but what people actually want is something that can insure against spending on chronic diseases, which accounts for 90% of the spending on healthcare in the US.

And IMO, to the extent that insurance doesn't cover chronic conditions, it is a bad model for healthcare.

</comment></comment></comment></comment></comment></comment><comment><USER28> How soon until Lifeline is a reality for a subset of patients?

[https://en.wikipedia.org/wiki/Life-Line](https://en.wikipedia.org/wiki/Life- Line)

</comment><comment><USER29> I work for a cancer research hospital. I'm training an LSTM today using TensorFlow to determine months left to live for specific patient conditions given previous outcomes.

</comment><comment><USER30> I'm programmer and I'm always saying (something like this) - the program / AI can be able to do things the best way how it can be done the best way by its programmer(s)

My point is - this is completely nonsense. IT world and Real world are two difference worlds.

It's look like Google needs wake up call.

<comment><USER31> Which is why positive AND negative feedback loops from your users/customers/<people whose lives your software will affect> are vital to building great software.

</comment></comment><comment><USER32> \- "Hey Google! How long do I have left to live?"

\- "Are you sure you want to know?"

\- "..."

</comment><comment><USER33> This will help with self-driving cars faced with a "trolley problem." You can choose the victim most likely to die anyway.

<comment><USER34> The trolley problem here already exists regardless. Just because making difficult decisions is uncomfortable doesn't mean the most moral outcome is to leave it to chance.</comment></comment>


Binary Numbers Haiku  - <AUTHOR> http://www.exploringbinary.com/binary-numbers-haiku/ <comment><USER2> One hundred percent / One, then zero: trivial! / The great Benford's Law.

</comment><comment><USER2> Binary solo / 10011 / The distant future</comment>


Good luck: Last words Europe's leaders had for Theresa May on Brexit deal - <AUTHOR> https://www.business-standard.com/article/international/good-luck-last-words-europe-s-leaders-had-for-theresa-may-on-brexit-deal-118112600303_1.html <comment><USER2> I want to know if anyone threw in the words of the last departing toy soldier in Toy Story 3: "you're gonna need it".</comment>


Show HN: Shippable - Continuous Integration service using Docker containers - <AUTHOR>

Hello guys,
I am the co-founder of Shippable (www.shippable.com) - a container-based Continuous Integration service. We recently switched from LXC to Docker containers, so please try it out and give us feedback.
We plan to launch on Jan 15th. Our UI is still in flux but any feedback is welcome!
Shippable is integrated with GitHub and supports Ruby, Node.js, Python, Java, Scala on Ubuntu 12.04.
Please try it out at www.shippable.com. Docs are at www.shippable.com/docs.
You can reach with me any feedback or questions at firstname.lastname@example.com
Thanks!! <comment><USER2> This looks amazing! Combine this with StackDock and it would be a totally killer combination.

When you look at something like what eBay is doing with Docker ([http://www.slideshare.net/dotCloud/docker-open-stack- austin-...](http://www.slideshare.net/dotCloud/docker-open-stack-austin-pdf)) this kind of service makes total sense. Kudos!

<comment><AUTHOR> Thanks cardmagic! We're engaged in discussions with them :)

</comment></comment><comment><USER3> Things that I need for my C and future GoLang projects:

      * Multi-platform (Linux, BSD, Illumos, Windows, Mac)
      * Building C and GoLang :-)

</comment><comment><USER4> Clickable link: [http://www.shippable.com/](http://www.shippable.com/)

</comment><comment><USER3> You send an onboarding email from hello@ and it is not accepting emails from replies.

<comment><AUTHOR> Ah yes. Thanks for the feedback... we'll fix that!

</comment></comment><comment><USER5> I've used Shippable. Superb team, fantastic service. Highly recommended.

<comment><AUTHOR> Thanks for your support maslam!

</comment></comment><comment><USER6> Looks really nice! Too bad there's no support for bitbucket...

</comment><comment><USER7> Very cool. Any plans for Ubuntu 13 LTS?

<comment><AUTHOR> Yes, we're working on adding more platforms. Thanks for your comment!</comment></comment>


Who was accepted from the interviews on 052417? - <AUTHOR> <comment><AUTHOR> My company wasn't accepted - I just wondered who was successful</comment>


Security flaw in Hotmail permits anybody to login with the password 'eh' (1999) - <AUTHOR> https://en.wikipedia.org/wiki/Outlook.com#Security_issues <comment><USER2> I guess the hackers were running a dictionary attack and saw that 'eh' worked for all of them</comment>


Encourage two of your Linkedin connections to join for a lunch - <AUTHOR> http://www.youguysshouldlunch.com/

<comment><USER2> I know two friends that should join me for lunch. How does youguysshouldlunch work? Normally I'd give them a call or email and say "lunch is on me" or "I saw a new restaurant on X street, want to have lunch?".</comment>


Twitter has enabled photo tagging by default. You might want to turn it off. - <AUTHOR> https://twitter.com/settings/security#Privacy <comment><USER2> If someone needs a screenshot howto to turn this feature off: [http://pic.twitter.com/V02HdSlriS](http://pic.twitter.com/V02HdSlriS)

</comment><comment><AUTHOR> i found this via [https://lobste.rs/s/e7rezf/twitter_has_enabled_photo_tagging...](https://lobste.rs/s/e7rezf/twitter_has_enabled_photo_tagging_by_default_you_might_want_to_turn_it_off) by [https://lobste.rs/u/eik3](https://lobste.rs/u/eik3)</comment>


Working at big software companies - <AUTHOR> http://blog.sacaluta.com/2012/08/working-at-big-software-companies.html <comment><USER2> After working for various start-ups and freelancing most my, I took a full- time contract at Inuit (TurboTax/Quicken) about a year a go. I was very surprised how much I enjoyed the work there. The start-ups I worked at were never huge successes so getting the chance to work on a Rails app that gets hundreds of thousands of requests per minute (it's embedded in TurboTax) was something new for me and provided a different set of challenges.

I've also found that large companies (or at least Intuit) are very open to progression and innovation. When I started our team was on Ruby 1.8.7, Rails 2.3.5, in a physical data center, used Perforce, and a bunch of other "enteprise" software suites. Now we are cranking on latest versions of Ruby and Rails, Github, AWS, and Campfire.

It has been a much more rewarding experience than I would have thought. Oh and you have no idea how good it feels to get real, publicly traded stock :)

<comment><AUTHOR> I absolutely agree that typically the impact you can have at a big company can be huge. But it may come with a cost - adjustment to that structure.

As I mentioned in the post, it is a great environment for many people, and I'm glad to hear about your case.

</comment></comment><comment><USER3> The " _You're Not Working With The Owner_ " aspect of a big company is usually the most underrated reason why some companies succeed in hiring and retaining top performers, and some don't.

The immediate manager is a major reason, from what I've seen, for why people leave or love their jobs. The manager may not even share the same ethics that need to flow down in the company from the founders/owners, and may even work towards ensuring her/his own appraisal success. This is why maintaining the big company's culture is such a tough task, and one bad hire at a senior level can slowly destroy major chunks of it.

<comment><USER4> I worked at a corporate giant where my skip level did not know who I was for close to 8 months. He never met with any of the employees besides the leads reporting to him, his manager and his peers. I think he had to find out about me when I left, but he still didn't even bother trying to talk me out of it.

<comment><USER5> How many people were under him?

<comment><USER4> I think somewhere between 30 and 40.

</comment></comment></comment></comment><comment><USER6> _> Sometimes some compromises will be made in order to keep the team "stable", so the business can keep going._

The thing to remember about big companies, is that they've already figured out some formula to approximately "print money." (Not really in all cases, what I mean more seriously and generally is just they already know how to make a profit.) So not rocking the boat will be seen by many there as the rational thing to do.

<comment><AUTHOR> You're absolutely right about that. It takes a lot of courage to do something that could affect the bottomline for the next quarter. Another thing is that, when the company's culture rewards those who don't make mistakes rather than those that are bold and try new stuff (therefore making some mistakes), then not rocking the boat is institutionalized. New things are not tried, as they are too risky, and anything old that becomes a liability must be quickly fixed or gotten rid of.

</comment></comment><comment><USER7> Another phenomena that exists in all companies, but that you really see in big ones, is secretiveness about how people are actually being rewarded. This has two purposes. The first is that it allows the company to reward certain employees (particularly top manager) while heading off jealousy among others. The second is that it allows them to lie to people about how well they are compensated versus others.

</comment><comment><USER8> I wouldn't want to work for an entity that implements "decision processes", I'd much rather work for a (small) company that takes decisions. It's that simple.

Also, even though I'm already in my early 30s the word "career" scares me. I'd rather build things

<comment><AUTHOR> I like your "I'd rather build things". I think you can also build things at big companies, but it's just different types of things and much different process. It's just that, depending on your org, you may end up building more slowly (sometimes way more slowly) or you will build something that was decided by others and that you didn't have much input on.

<comment><USER9> To be fair, some times you can build things much faster as the process for capital expenditure of sizes necessary is more straightforward. "Oh? You need to spend 20 million dollars on some hardware? Cool. Follow this accelerated RFP procedure."

</comment></comment></comment><comment><USER10> I've never worked at a "big company", but I've worked at small ones, and one of those grew to be medium-sized.

One thing that I notice that's missing from the article is support.

At every small company, I was in charge of more than 1 aspect of the product, even if that wasn't my area of expertise. I've even been in charge of _every_ aspect, as the sole employee that could handle them.

This is extremely exciting and fun, for a while. Eventually, it wears on you and you need someone else. As the company grew and we hired more and more, I eventually settled down into having 1 main thing I was responsible for, and even that could have been handled by someone else if needed. (For vacations, even.)

Because of that, I don't want to work at a small company again. Being able to go to a database-specialist and ask for help with performance was amazing. Even though I enjoyed all those hours of DB tuning and learning about it, I'd rather have been coding. (And of course, the DB guy would rather be doing DB- guy-stuff. They tried asking him to code, and that didn't go well. It wasn't what he was good at. To be fair, I was similarly inept at DB tuning at first, but when there was nobody else, you couldn't tell how bad I was. Heck, I couldn't tell, either.)

Anyhow, my point is that bigger companies have a network of employees to lean on for support, where smaller companies require more of people.

</comment><comment><USER11> I worked at a big software company and will never go back. The aspiring to mediocrity is the order of the day. I should never have gone to a fortune 500 and I never will again. The culture is corrosive.

</comment><comment><USER12> Interesting viewpoint, timely as I am interning at a big bank that has a tech division and trying to decide whether this is the kind of firm I want to work for.

Also, @rdcastro, you're looking for segue, not Segway.

<comment><AUTHOR> Thanks for the correction. Text updated.

</comment></comment><comment><USER13> I don't know why but consulting always seems to get left out of these types of discussions. As an consultant at a company of about 200 in size I get to influence decision making and innovation within the company - while learning about the ins and outs of medium-big companies.

</comment><comment><USER14> Wow!...perfectly described -- thats all i can say :)</comment>


Katherine Johnson Biography - <AUTHOR> https://www.nasa.gov/content/katherine-johnson-biography <comment><USER2> I just saw the movie Hidden Figures which is based on the incredible achievements of Katherine Johnson, Dorothy Vaughan and Mary Jackson. I was happily surprised to see this on HN. If you haven't seen it, please do.

It was an eye opener for me as an non-American to see how normalized racism was in the 1960's even at places like NASA where one might assume science trumps ignorance.

<comment><USER3> Fully agree. Considered this movie an eye opener as well - highly recommend to those who haven't seen it yet.

Since the movie, when people speak of "not lowering the bar" i have to think about how much people like her (and many others) had/have to run and jump uphill to even get to the bar.

</comment></comment><comment><USER4> I often exclaim how glad I am that my work doesn't directly lead to a life and death situation, but reading her biography gives a sense of the pride that must go along with those demanding challenges. I don't have those kinds of nerves, or I don't trust my ability not to error. I'm impressed by those who work in the fields of navigation and aviation.

</comment><comment><USER5> Having others trust their lives to you is the highest honor you can have. What a remarkable person.

</comment><comment><USER6> While reading I was imagining the movie "Hidden Figures" which I saw recently, and it turns out it was her. Was pleased to read she received the medal of freedom. Why did it take until 2015?

<comment><USER7> And would she have a chance of receiving such an honor today?

<comment><USER8> Why not?

<comment><USER9> Aside from the obvious answer that the current US president is one of the most openly racist in the past 40 years, there's a strong indication that white presidents fail to award black achievement, especially by women. Otherwise she would have been awarded the medal considerably earlier, given her retirement in 1986.

(The sample size is unfortunately limited; I recommend electing more black presidents to further test this hypothesis.)</comment></comment></comment></comment>


Former Facebook manager says company is 'failing' its black employees and users - <AUTHOR> https://venturebeat.com/2018/11/27/former-facebook-manager-says-company-is-failing-its-black-employees-and-users/ <comment><USER2> And what about its native indian employees?</comment>


Ask HN: Signing bonus situation sketchiness - <AUTHOR> Wanted to get some feedback from the hivemind:
Recently joined a company, compensation included a signing bonus 'provided I stay with the firm for 6 months'.
To me 'signing bonus' suggests a bonus you get at the time of signing, for signing.
After some weeks of not being very forthcoming about when I can expect my bonus, they are now telling me that I will get it at 6 months.
To me this feels quite sketchy and at best very misleading. That was not my expectation when signing.
What do you think? <comment><USER2> I've had both -- signing bonuses that are provided day 1, but can be clawed back if I don't stay the expected length of time. And I have had signing bonuses that are paid out on my one year anniversary. You should have asked for it to have been written/clarified in your contract though if it was not clear.

</comment><comment><USER3> The particulars should have been written into the employment contract that you should have signed but it's not unusual for such a bonus to be tied to remaining with the company for a certain period of time.

<comment><AUTHOR> No that was literally all it said; 'provided I stay with the firm for 6 months'. No discussion of provisions or details, nothing.

<comment><USER4> It's normal. I have a sign on with a public tech company you've heard of that has a one year stipulation.</comment></comment></comment>


Another name for the "wisdom of crowds" - <AUTHOR> http://abstractfactory.blogspot.com/2004/12/another-name-for-wisdom-of-crowds.html <comment><USER2> I don't have much patience for someone who critiques a book without reading it.

Unless he happens to know the algorithm that defines human intuition and intelligence, I don't think the "wisdom of crowds" is just another name for "the behavior of distributed algorithms." (That's after discounting marketing considerations.)

The blogger says: "Naively lauding the alleged "wisdom of crowds" obscures the critical issue, which is the design of the distributed algorithm --- i.e., the social organization of the crowd. What are its mechanisms for passing information?..."

Surowiecki believes there are some necessary conditions to have some wisdom from crowds: diversity, independence, and a particular kind of decentralization. He points out in the book that design of the crowd and their interaction is essential to wisdom of crowds. Yadda yadda.

The blogger says: "Now, as I said, I have not read Surowiecki's book. It is entirely possible that I'm being utterly unfair to him based on the yammerings of others."

Yes, you are being utterly unfair. No up arrow for you.

</comment><comment><USER3> Fun at-home version of the guess-the-weight-of-the-bull experiment. Last Easter, we put a few hundred small chocolate eggs in a large jar. We had 14 people at the house, and we all guessed how many eggs were in the jar. The closest guess was off by about 8%, and the worst were more than 50% off. As a little test of the wisdom of our crowd, we averaged the guesses. Their average was 3% off the right answer.

</comment><comment><USER4> "What are its mechanisms for passing information? For reaching consensus? Where are the possibilities for feedback loops?"

I didn't read the book as suggesting this was required. Surowecki champions a diverse set of people with diverse knowledge, consensus is reached when that knowledge combined tells us the crowd's opinion. Feedback loops are not considered. "The Wisdom of Crowds" applies more when people are acting in their own interests than collaborating towards a solution. Perhaps feedback loops are even what throws this system of crowd wisdom off (bubbles?).

</comment><comment><USER5> "emergence"

<http://en.wikipedia.org/wiki/Emergence>

The article is from 2004, but the idea goes back to Aristotle.</comment>


5,000 Pages of Verdi's Drafts, Long Hidden, Will Be Made Public - <AUTHOR> https://www.nytimes.com/2019/01/25/arts/music/verdi-papers-italy.html <comment><USER2> Here's hoping for an undiscovered bassoon concerto!

On a more serious note, I really hope "made public" means making the digitized copies available to anyone on the web, without restriction. There is an enormous amount of music that has lapsed into the public domain (most of it long out of print) that remains inaccessible because the parts can only be found in a handful of libraries. Even worse, many libraries restrict borrowers from making digital copies of public-domain works. Regardless of what Verdi intended for his drafts, I can't help thinking that most deceased composers would have been dismayed that their works remained obscure in an era where they could be instantaneously disseminated across the world for anyone to enjoy. (Time to donate to IMSLP again...)

</comment><comment><USER3> I've been playing Verdi's piano reductions lately as a way to get to know his operas better, so this comes as a wonderful surprise! He was not only a master of lyricism and orchestration but also quite involved in politics and well- loved during his time. Fascinating man.

[http://www.bbc.com/culture/story/20131002-verdi-when- music-m...](http://www.bbc.com/culture/story/20131002-verdi-when-music-meets- politics)

<comment><AUTHOR> I'm of two minds with regards to this story. On the one hand it is fantastic to gain concrete insights into the processes that went into the creation of his work. On the other hand, and more controversially, I can't help but think that the artist was disrespected when his heirs didn't follow through with his wishes that the drafts and notes be destroyed.

<comment><USER3> Same with Kafka. I honestly think we're better for having his writing than destroying his work like he asked.

Verdi—and Kafka—could have burnt his notes as he went so a part of me thinks, maybe he was just being coy.

</comment></comment></comment><comment><USER4> > [...] scribbling on their covers: "Burn these papers." Fortunately, his > heirs never carried out those orders.

I would be rolling over in my grave if this were the case. Doesn't this feel wrong?

</comment><comment><USER5> "The Verdi villa was never widely open, but scholars complained that under the family's stewardship, it was far too difficult to access documents ... The culture ministry took the trunk from the villa in January 2017, partly in response to the complaints."

Mama mia.</comment>


Interview with Oculus founder and CEO - <AUTHOR> http://www.theverge.com/2014/3/25/5547884/interview-oculus-founder-says-facebook-deal-will-make-virtual-reality

<comment><USER2> "WE'RE A ROCKET, AND WE JUST ATTACHED OURSELVES TO AN EVEN BIGGER ROCKET."

No, you've given your rocket to someone else. They control the flightpath now. You're just along for the ride.</comment>


Robotic dildo barred from CES, prompting sexism claims - <AUTHOR> https://www.theguardian.com/technology/2019/jan/08/ces-dildo-gender-sex-toy-ose-personal-massager <comment><USER2> Seems like a pretty fair point if they allow VR porn and sex robots.</comment>


Ask HN: Is there an archive, dataset or RSS feed of all HN posts? - <AUTHOR>

I know searchYC is great, but i'm looking for the actual dataset of posts. Either as an RSS feed or more likely as massive file. There were some datasets available up until about 7 months ago, but wondering if there are any up-to-date options? <comment><USER2> There have been several releases of the dataset. This is the most recent one I've been able to find: <http://news.ycombinator.com/item?id=296919>

An updated version would be great, though.

</comment><comment><USER3> I converted about 8700 links to delicious (along with tags for each link). <http://delicious.com/tag/hn_links>

</comment><comment><USER4> I suspect Google has a stored copy, because they store everything.

Agree with oscardelben though: It's going to be a lot of data.

</comment><comment><USER5> By looking at the URL item?id=569492 you should expect to get nearly 570,000 posts. Maybe RSS is not the best :)</comment>


Open Source Community Building -- Barriers to Entry - <AUTHOR> http://dneary.free.fr/articles/Community_barriers_to_entry_checklist.pdf <comment><AUTHOR> "There is a down-side to IRC which should be kept in mind. Over time, the people who will be most active in IRC will tend to be people whose only contribution to your project is being active in IRC. This is not necessarily a good thing."

<comment><USER2> Enjoying my blog? :-) I always like watching links propagate through the Web.

<comment><AUTHOR> Yeah, and you just posted something I posted to HN to your blog :-)

Your RSS feed is crap though -- linklogs shouldn't have permalinks to themselves in the <link> element -- put what you're linking to there.</comment></comment></comment>