Computer Science students: Learn to write - <AUTHOR> http://www.xaprb.com/blog/2011/08/04/computer-science-students-learn-to-write/ <comment><USER2> > _I've seen a lot of what passes for excellence in high schools, and it's not > good enough._

I've encountered many brilliant students in college, with straight A's through highschool and stellar SATs, who cannot string three or four sentences together into a coherent paragraph. I am now trying to realize a vision of a Khan-inspired service for writers who are not getting the help they need from school. This is probably not the time for a shameless plug, because my site, as a site, still sucks, but if any student here wants free, quality reviews of their writing projects, you can get them at <http://www.essayjudge.com>

I say "free," and mean it, but if you want to abuse the service, then I may ask you for a return favor in the form of development advice.

At present, you can submit writing quickly at the site using anon/anon as uid/pwd, but for HNers who don't want their writing and the attendant review published, you can google-email me (bbquigley). No promises if I'm inundated, except to try my best.

<comment><USER3> You sent me my password in the confirmation email in plain text. Please fix this security hole ASAP by hashing the passwords.

Edit: The content looks great. Sorry, didn't mean to sound snarky, but that is a scary first impression of the site. I have some more comments that I tried to email to the contact email address, but my email was retured. Is there an email I can use to contact you or someone at the site?

<comment><USER2> Thanks for the feedback. On my immediate to do list. No excuse, but I didn't build the site, and the process of trying to fix its bugs since I took it over while completely changing its focus has been especially onerous for me. Please use my personal email in my comment above.

</comment></comment></comment><comment><USER4> I don't normally comment prior to reading the post, but given a topic such as this i feel obligated:

This should read "Humans! Learn to write"

CS students are not alone in this need.

The one course, more than any other, that taught me to write efficiently and convey ideas clearly was my 400 level Philosophy of Mind course. We were to write 1 page (double spaced) essays, weekly, on the papers we read. The class argued our professor up to 2 pages.

When i received my first essay back, the full first page was crossed out. I learned not to include any dithering or bullshit in my essays after that, one page was almost exactly right. That was the point at which I really understood the joke "I would have written you a shorter letter, but I didn't have the time."

Edit: homophony: two -> to; in the most ironic spot possible.

<comment><USER5> I went to a liberal arts school where everyone was required to take a 5 credit freshman English course. I still remember "No BS" across the top of many papers during that course.

<comment><USER6> Freshman English classes were required where I went to school, too. Some people _still_ couldn't write a coherent paragraph, even after passing all their English classes.

</comment></comment></comment><comment><USER7> When I tell people I'm a programmer they always go "oh, you must be good at math." The truth is that I'm pretty bad at math, but in terms of logical syntax and parsing I am pretty good. Programming (especially high level modern stuff) has much more to do with syntactical and epistemological skills than math. I learned to program from writing.

<comment><USER8> Given that all of computer science is based off of math at some level, i'd say math is more important than you think.

Anyone can glue some APIs together[1] and make some kind of application, but it takes some math skill to design and implement strong algorithms. Computer science is not about syntax and semantics, it's about about algorithms and data structures-- and if you're not good at algorithms and data structures, it doesn't matter how good you are at memorizing Python syntax.

This is anecdotal, but every good programmer i know of has a strong math background, or at least knows how _vitally_ [2] important math is to being a good programmer. Incidentally, most bad programmers i've met put much more weight on memorizing APIs and language semantics (e.g. Why do i need to know the big-O running time of bubblesort? python has sort() built in!) than learning math.

[1] And they do. You can find them on odesk and elance charging $10/hr and blowing past deadlines, producing unworkable code.

[2] Seriously. I cannot stress this enough.

<comment><USER9> _Given that all of computer science is based off of math at some level, i'd say math is more important than you think._

There's your problem right there. He isn't talking about computer science, he's talking about actually programming.

Sad thing is, on HN, many more people will probably support your side.

<comment><USER10> Agreed, the only Math I do in my daily programming is:

1) Drawing code. One recent example was an (animated) undefined progress bar designed all in code I did last friday: <http://akhun.com/seo/skitch/photo-20110805-195455.png>

2) Sorting, ranking and scoring algorithms. Eg. figuring out which ad to show based on the average eCPMs, or which option to show based on a Quicksilver fuzzy search algorithm.

Everything else is as grandparent condescendingly calls it, stitching APIs together. Design patterns, data managements, doing all the little polish that makes up a real app.

</comment></comment></comment></comment><comment><USER11> I agree that many programmers need to work on improving their writing skills. However, I disagree with the notion that the humanities department is suited to providing an education in the kind of writing skills CS students need. The humanities are full of fuzzy concepts that defy precise definition and the writing styles associated with those fields tolerate a level of ambiguity that is inappropriate for CS, engineering, or the physical sciences. If you really want to learn to be a great writer capable of expressing CS concepts unambiguously and concisely then a course in technical writing taught by science/engineering faculty is what you need. An even better way to improve your writing skills is to get involved in research and publish a paper in the scientific literature. The "biggest pedantic miserable fascist sonofabitch" editors you can find in the university are not in the humanities department. They're the faculty in science and engineering whose livelihood depends upon writing amazingly clear and concise documents that withstand the intense scrutiny of NSF and NIH grant review committees, journal editors, and peer reviewers who genuinely care about whether or not the experiments are described unambiguously and in sufficient detail to enable others to replicate the experimenter's results.

<comment><USER12> > The humanities are full of fuzzy concepts that defy precise definition

Perhaps its beside your point, but this is exactly what's most important about learning how to write. There's a whole lot more that you learn by exploring 'fuzzy concepts' and non-precise systems. Approaching natural language like a science or system is delusional at best. Reading and writing "amazingly clear and concise documents" is just one way of using language as a tool.

</comment></comment><comment><USER13> Yes! Written communication is so important, especially so with collaborative technical works.

Some tips: learn to state or restate a problem as a problem rather than an unimplemented solution. Consider: "I need a faster horse which eats less food" vs "I need a mode of transport which is faster and has less upkeep". This is especially important when dealing with feedback and bug reports from users. Learn how to extract the essential complexity of the problems they are facing and don't become biased by the possible solutions they offer up.

Also, be as direct, concise, and clear in written communications (email threads, commit messages, bug tracking comments, etc.) as possible. Make a habit of listing and relisting assumptions and presumed findings. Make a habit of summing up and distilling results, especially when new people are added to a discussion or issue. This saves so much time and avoids so many missteps due to ambiguity.

Additionally, teach yourself how to discuss technical topics without becoming excessively emotionally involved. Address the technical issues, don't fall into thinking that a criticism of your idea is an attack on you, learn to play devil's advocate. Learn to progress toward the best possible technical solution regardless of who had which idea.

<comment><USER14> I would upvote this twice if I could.

</comment></comment><comment><USER15> Some of the most rewarding courses I took during my time in college were writing courses, in both fiction and poetry. Definitely, it helped refine my grammar and composition skills.

But the creative writing courses really provided a lot of other valuable experience too. Having to put together a creative work involves parts of my brain I never really used while coding -- it was sort of a challenge to put aside the methodical, linear path I live in while programming and have to imagine a world, then put someone in it, and have them do things that people might want to know about.

The other nice thing about workshop-based writing courses is that you generally read and comment on works written by your fellow students. You learn new craft skills from reading their work for sure, but you also learn how to give constructive criticism where it needs to be given.

This sort of diplomacy is something you need to practice in order to be good at it. It will help you later when you're in a code review meeting at work and you are the guy who can step up and say something more useful than "you're doing it all wrong, that code sucks, and so do you."

<comment><USER16> While we are talking about diplomacy: You can also start join a game of play by mail Diplomacy.

</comment></comment><comment><USER17> I have a one-word piece of advice for anyone who wants to learn how to write:

Blog.

Don't worry about which software to use, how to customize your template, or how to promote your thoughts. Just find a service that lets you start writing right away, and then start writing about what interests you or inspires you.

If you feel intimidated by formatting or structure, a trick that works well is pretend you are writing an email to a friend, explaining to that friend something that he or she may not understand very well. Real friends or strangers may start to read your posts. How do they respond to your presentation of facts, observations, and arguments? Use the feedback to tweak your approach.

Your organization and "voice" may seem awkward at first, but regular practice -- every day, if you can manage -- will help you develop your skills. After 100 hours you'll notice a big improvement. After 1000 hours, you will be well on your way to being a master.

</comment><comment><USER18> People can't just learn to write. They write incoherently because they _think_ incoherently.

When I tutor children I ignore the topic they are having trouble with. I go back to basics and teach them basic critical reasoning skills. Their performance in everything skyrockets.

The fact that our society is failing at teaching children how to reason about _basic decisions_ is cause for serious alarm. I'm looking forward to Eliezer Yudkowsky's forthcoming book on how to think correctly (currently use How to Solve It as a guide for teaching others).

</comment><comment><USER19> I can not emphasize how important this is. I skimmed my way through most of my classes in college, dropped out, then became a self-taught developer. While I do well as a developer, this is the one skill that I miss the most.

</comment><comment><USER20> Techies need to learn more than just programming. This isn't sarcasm.

<comment><USER6> Or, more generally: humans need to learn more than just one field.

</comment></comment><comment><USER21> Site is having database issues.

Cached Version: [http://webcache.googleusercontent.com/search?q=cache:W4_uDOQ...](http://webcache.googleusercontent.com/search?q=cache:W4_uDOQARdQJ:www.xaprb.com/blog/2011/08/04/computer- science-students-learn-to- write/+http://www.xaprb.com/blog/2011/08/04/computer-science-students-learn- to-write/&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a&source=www.google.com)

</comment><comment><USER22> Not just CS majors — I'm an art school grad and after 20 years I'm amazed at just how much writing my career has required of me. And it's not just writing skills, but communication skills in general which includes public speaking and presentation. And sadly I'll even add one more skill which you can't even acquire in school — just having patience to do hand holding is more important than I would ever have imagined.

</comment><comment><USER23> A friend of mine went for a job interview in accounting. He almost didn't get the job because they didn't think he wrote so well.

They basically said. The accounting part is the easy one but if you can't write we can't use you.

It always struck me as a great insight. Almost no matter what level of expertise one will acquire the ability to communicate is just so much more important than we like to think.

</comment><comment><USER24> If BS is a problem, the subject probably isn't interesting. If page minimum lengths become requirements, expect lots of filler when students have said everything that needs to be said in less than the required page length. (If it's a maximum, expect highly dense paragraphs that, while containing lots of information, lose their ease of communication and the endeavor of better communication has been lost.) When weekly or daily writing becomes the norm, expect quality to go down since there are many more important things and the papers will be rushed. Nevertheless, Strunk & White + Practice = Success. Getting people to pump out their first million words, which will inevitably be crap, should be a goal of the educational system.

Clarity should rule above everything else, correct grammar included. This encompasses the "What's the point?" question, since if there is no point, the paper may be grammatically perfect but shouldn't be clear.

<comment> mkr-hn Strunk is dead. He can't hurt you anymore. Move on with life and language. It's best to leave the almost century old reference on the shelf and study contemporary writing and references.

<comment><USER16> Strunk & White was never good to begin with. Classic texts can stay good as they age.

<comment> mkr-hn I've got a writing reference from college that I refer to all the time. If the paper holds out for 80 years I'm sure I'll pass it on to someone.

</comment></comment></comment></comment><comment><USER12> After a few quarters of CS and internships in the industry, I realized how great opportunity it was to change majors in order to focus entirely on writing within a superb Humanities department. The lack of a CS degree hasn't stunted any bit of my work as an engineer, and having demonstrated writing skills can only make you more employable.

</comment><comment><USER25> I would add more than just writing - as he touched on, all communication skills. And yeah, definitely not for only computer science majors. Any person needs to work on their verbal communication skills as well!

</comment><comment><USER26> Video: Ray Bradbury (2001) 'teaches' the art of writing

[http://www.learnoutloud.com/Free-Audio- Video/Literature/Cont...](http://www.learnoutloud.com/Free-Audio- Video/Literature/Contemporary-Literature/An-Evening-with-Ray-Bradbury/19494)

</comment><comment><USER27> Isn't Technical Writing a required course for most CS/E curriculum anyways? I know UF requires it. Although knowing it and applying it takes practice and time.

<comment><USER28> It was for me. I liked it so much I made tech writing my minor.

Oddly enough, my advisor thought that a CS + TW combo made no sense.

I ignored him, much to my benefit.

</comment></comment><comment><USER29> I believe writing an essay is the same as writing a program: you are trying to express an idea, and organize your thoughts in a way others can comprehend.

</comment><comment><USER30> Since I will not be enrolling back in University any time soon, can anybody recommend a decent online resource I could use?

</comment><comment><USER31> Poor CS students. People are always giving them advice, Learn more SQL, learn functional programming, learn whats going on at the low level hardware, contribute to open source, start a blog, get on github. I seem to remember Computer Science is ranked as one of the hardest degrees, It certainly was no picnic for me. Leave the poor kids alone.

</comment><comment><USER32> He goes through all that and still doesn't actually present a case for his argument?

Guess he really is still learning to write.

</comment><comment><USER33> I am having a negative emotional response to this post and I don't know why. Is it because the author is a writer, and saying I should learn to write?

"You know what your problem is? You aren't like me."

<comment><USER33> _Error establishing a database connection_

English Lit Majors: Learn to scale.

Or, "you know what your problem is, Mr Writer? you aren't like me".

Shit, maybe, instead of everyone learning everybody else's skills, we could work _together_.</comment></comment>


Network Tomography - <AUTHOR> https://netbeez.net/2014/07/08/network-tomography/ <comment><AUTHOR> Hi everyone, I am the author of the post. Network tomography is a very intriguing idea and very promising. However, it hasn't taken off outside the academic/research realm.

I am wondering what networking folks think about it.</comment>


PaintCode 2.3 adds over 15 new features - <AUTHOR> http://www.paintcodeapp.com/news/paintcode-23

<comment><USER2> Very nice. I'm a little confused at the "over 15 new features" phrasing. It lists precisely 15 features. If it added exactly 15 features, why say "over 15"? If it added more features, why does it list precisely 15? I would have expected the list to end with something like "And more!" if there are features it didn't want to list.

</comment><comment><USER3> > 14\. Canvas Arrangement

This type of feature needs to be added everywhere possible.</comment>


Game Dev Story for Android: run your own video game company - <AUTHOR> http://www.appbrain.com/app/game-dev-story/net.kairosoft.android.gamedev3en

<comment><AUTHOR> I'm not affiliated with the developers, but I thought HN would enjoy this. The official website is here, if anyone is wondering: <http://kairopark.jp/android/en/></comment>


Corporation vs. Startup in One Photo - <AUTHOR> http://startupruminations.com/2011/08/corporation-vs-startup-in-one-photo/

<comment><USER2> I don't get it. His previous employer littered his desktop with stupid icons?

<comment><USER3> I think it's a PC v Mac issue.</comment></comment>


CloudFlare: Happy 3rd Birthday - <AUTHOR> http://blog.cloudflare.com/cloudflare-happy-3rd-birthday

<comment><USER2> More years to come for sure!</comment>


How Rupert Murdoch's Empire of Influence Remade the World - <AUTHOR> https://www.nytimes.com/interactive/2019/04/03/magazine/rupert-murdoch-fox-news-trump.html <comment><USER2> "A Bit of Fry and Laurie", "It's a Soaraway Life: The Rupert Murdoch Sketch" from season 4, episode 1 (the only version I found uses PIP and pitch changing to avoid automatic copyright infringement algorithms - [https://youtu.be/gziBQG9ea4g?t=1172](https://youtu.be/gziBQG9ea4g?t=1172) .

It's a spoof of "It's A Wonderful Life" with Murdoch in place of George Bailey. In the world-without-Murdoch, there is much niceness in the UK, people are happy and like each other, the UK has some of the best TV in the world, no one has sat TV, the hospital system is doing well, people like the monarchy, etc.

At the end, the Murdoch character realizes how much money he could make in this world. His guardian angel then throws him into the river, ending the sketch.</comment>


Show HN: Sealistings – The Zillow/Trulia/Realtor of Boats? - <AUTHOR> https://www.sealistings.com <comment><AUTHOR> Hey All!

Long time lurker here. I doubt there is a ton of interest on hn for this sort of thing, but my buddy and I have grown up in the boating community due to our location from the water.

The roots of the boating industry are very very interesting. It turns out that boating is basically just an American passion. There are some crazy statistics saying that most boats are made and used in the USA.

Long story short, we decided the avenues to search for used boats on the internet were very bleak, so we created a marketplace of our own!

We would like to eventually work on it full-time, but have absolutely no idea how we could monetize this without annoying ads.

Any criticisms are welcome.

Stack: Rails + VueJS on Heroku

We recently also launched basic React Native Webviews of our app using Expo. It seems to work pretty well, except that the limitations with Expo and React Native become really apparent really quickly haha.

Even if we never monetize and this never takes off, it was a pretty cool personal project to work on.

<comment><AUTHOR> PS Did you know 1 in 10 households in the US own a boat? I really didn't think it was THAT popular.</comment></comment>


My Glucose Manager – follow your daily health - <AUTHOR> https://github.com/foxmask/dj-diabetes <comment><AUTHOR> Feel free to submit improvements if you need. I made it for a friend at the beginning.</comment>


WebGL Fluid Simulation - <AUTHOR> https://paveldogreat.github.io/WebGL-Fluid-Simulation/?play <comment><USER2> I understand why real 3D fluid sim is much harder to do at reasonable speeds than 2D but I wonder if there's a pseudo-3D version that would look good (I'm especially thinking of VR here)

A few transparent layers to add depth? Or something akin to parallax occlusion mapping?

EDIT - this Shadertoy is remarkably awesome despite only running on a 128x128x128 grid: [https://www.shadertoy.com/view/wlG3RW](https://www.shadertoy.com/view/wlG3RW)

<comment><USER3> There's this paper which describes a simplified fluid dynamics appropriate for games: Real-Time Fluid Dynamics for Games by Jos Stam. You can find the paper and implementations by searching. It's based around numerical stability and speed, rather than accuracy. I think it would be interesting to put this into a simcity-like game to get good air pollution maps.

I'm not sure if this WebGL page is based around this algorithm.

<comment><USER4> What does that have to do with 3D versus 2D?

<comment><USER3> 3D is hard to do in real time as you have many more grid points. The method I linked to is much faster than properly solving the fluid equations, so is suitable for a 3D interactive simulation.

</comment></comment></comment></comment><comment><USER5> On my iPhone 6S, I turned the quality up to high and played with the simulation for around five minutes. It kept working smoothly, but holy crap, I'm not sure if my phone has _ever_ been this hot!

Great work though, it's gorgeous!

</comment><comment><USER6> If anyone is interested, I made an implementation of this (based on the GPU Gems article) in Lua using the LÖVE framework that adds a bunch of effects like reflections, normal mapping and more.

[https://sixtyfour.itch.io/fluid](https://sixtyfour.itch.io/fluid)

<comment><USER7> macOS?

<comment><USER6> No.

<comment> jagged-chisel It was fairly straightforward to get the .love running on macOS. I grabbed Nuklear[1] and LÖVE-Nuklear[2], built [2] on macOS (had to point at Nuklear's header), dropped the .so in your /bin, a one-line edit to main.lua, repackaged, et voila!

Check my profile and drop me a line if you'd like.

1 - [https://github.com/vurtun/nuklear](https://github.com/vurtun/nuklear)

2 - [https://github.com/keharriso/love- nuklear](https://github.com/keharriso/love-nuklear)

</comment></comment></comment></comment><comment><USER8> This reminded me of a great game called Plasma Pong.

It was successful but unfortunately it was killed via a Cease and Desist letter from the Pong people.

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

There's a web clone of it here: [http://anirudhjoshi.github.io/fluid_table_tennis/](http://anirudhjoshi.github.io/fluid_table_tennis/)

<comment><USER9> One of the all-time great tripping activities, along with Rainbox ([http://www.axlrosen.net/rainbox/rainbox- large.html](http://www.axlrosen.net/rainbox/rainbox-large.html)) and Audiosurf

</comment></comment><comment><USER10> Feels so smooth on my iPhone. I'm aware these phones have pretty killer SOCs but I couldn't have imagined running this on something that fits in my pocket 15 years ago.

<comment><USER11> To be fair, first gen iPad also had apps like this. Not 15 years but...

<comment><USER5> It had apps like this, but I don't think there was anything as complex.

</comment></comment></comment><comment><USER12> The author made this also into an iOS app: [https://apps.apple.com/us/app/fluid- simulation/id1443124993](https://apps.apple.com/us/app/fluid- simulation/id1443124993)

<comment><USER12> And android: [https://play.google.com/store/apps/details?id=games.paveldog...](https://play.google.com/store/apps/details?id=games.paveldogreat.fluidsimfree)

Also, last years discussion of this:

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

</comment></comment><comment><USER13> Beautiful! Would be awesome to have as a desktop background.

</comment><comment><USER14> Very impressive! Many years ago, I had made a fluid simulation (a different kind):

[https://jsexperiments.herokuapp.com/sph/](https://jsexperiments.herokuapp.com/sph/)

Code: [https://github.com/asadm/SPHjs](https://github.com/asadm/SPHjs)

</comment><comment><USER15> Would love to see this as an audio visualizer.

<comment> Const-me If you want to make one, and you know C++ and Direct3D 11, you can fork this and implement one more effect: [https://github.com/Const- me/vis_avs_dx](https://github.com/Const-me/vis_avs_dx)

It's a plugin for old winamp so the music part is handled quite well there. The code already uses non-trivial amount of compute shaders, e.g. gaussian blur effect: [https://github.com/Const- me/vis_avs_dx/tree/master/avs_dx/Dx...](https://github.com/Const- me/vis_avs_dx/tree/master/avs_dx/DxVisuals/Effects/Trans/Blur)

</comment></comment><comment><USER16> The controller in the upper right hand does not support higher resolutions directly, but you can edit higher resolutions into the select box and it'll absolutely accept them. I was able to push it up to 2048 no problem, though it is more interesting at 512 and 1024.

</comment><comment><USER17> Might use the "SIMPLE" navier stokes algorithm: [https://en.m.wikipedia.org/wiki/SIMPLE_algorithm](https://en.m.wikipedia.org/wiki/SIMPLE_algorithm)

</comment><comment><USER7> Has anyone tried making any games or interactive music videos with this?

<comment><USER18> This is IMO a more relevant question than it seems. You'd think so, but it's absurdly rare to see real-world uses of demo techniques like this (not only talking about fluid-sims, here). I long wondered why this is (easy answer: because it's hard).

These things are often designed to run _very_ efficiently and getting maximum effect out of limited hardware and memory. It's perfect for, say, a small indie game looking for a cool background effect or something. I'm sure there's examples, but I couldn't even come up with one.

<comment> s-macke The game PixelJunk Shooter [1] is a game that that takes advantage of fluid dynamics. They use a technique called "Smoothed particle hydrodynamics". Particle based techniques might be better suited for real time fluid dynamics.

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

</comment></comment></comment><comment><USER19> The app is well worth downloading, and given how much time I've wasted just futzing around in it, I was more than happy to pay a few bucks to unlock the additional features. Really superb.

</comment><comment><USER20> Discussed last year: [https://news.ycombinator.com/item?id=19963640](https://news.ycombinator.com/item?id=19963640)

</comment><comment><USER21> I opened this website expecting very little, as I know Apple has refused to deploy WebGL 2 (Apple is essentially always the stubborn bottleneck) and particularly as I am still running iOS 12.

It was glorious. It was smooth and responsive and maybe-weirdly _fun_ to play with given how simple of a toy this little demo of a website itself represents. I had this momentary feeing of joy.

And then it popped up a dialog asking me to install an app. I think I want to go cry now about how fucked up the world is and how it is no longer possible to have good things on the web :(.

</comment><comment><USER22> Doesn't show anything in Firefox Developer Edition? (Works fine in Chrome/Brave).

<comment><USER23> Works fine for me. I'm on 79.0

<comment><USER24> Me too, on Nightly/Android.

Tiny bit choppier than Chrome but fully working.

</comment></comment></comment><comment><USER11> My little one approves this app

</comment><comment><USER25> Screen on fire! Had a good fun

</comment><comment><USER26> This is really beautifull!!

</comment><comment><USER27> Would be interested in painting with this. Too much fun.

</comment><comment><USER28> Could this be modified to make a lava lamp simulator?

</comment><comment><USER29> Great multi-touch demo.

Be sure to turn up the quality and res.

</comment><comment><USER30> Made me smile. The colors are great! :)</comment>


Xkcd "Self-Description" solved with python+pygame - <AUTHOR> http://www.philhassey.com/blog/2010/01/13/xkcd-self-description-solved-with-pythonpygame/

<comment><USER2> That xkcd reminded me of this histogram fun: [http://www.ironicsans.com/2007/09/idea_the_histogram_as_the_...](http://www.ironicsans.com/2007/09/idea_the_histogram_as_the_imag.html)

</comment><comment><USER3> I considered expending effort to verify this and the units hobby one. However, I fully trust that Randall does his homework on each and every xkcd. Good netizens like yourself never fail to keep him honest for me. Thanks!

</comment><comment><USER4> Can someone upload the result for those of us who don't have Python & friends installed?

<comment><USER5> Especially considering the Pygame site is down.

<comment><USER6> I was sure there was a pygame-package for Ubuntu. But I can't find it. So it's probably just my bad memory that makes it up.

Pygame is a really nice library for 2d gaming, if a bit low-level. I like their approach to sprites and sprite-groups.

<comment><USER7> "sudo aptitude install python-pygame" works for me in karmic.

<comment><USER6> OK, so I just got the name wrong. I just tried `pygame' on its own.</comment></comment></comment></comment></comment>


Basic Self Defence? - <AUTHOR> Does anyone here know any good resources for practical self defence? Not formal fighting styles like karate or taekwondo, more like things that can be used to protect yourself (and maybe retaliate) if you're being attacked in the streets. <comment><USER2> Judo or Akido, one of my Japanese friends had his father teach it. You use an enemies strength against them. If they throw a punch you grab their wrist in a clockwize movement and throw them.

I would also Google Ashida Kim

[http://www.dojopress.com](http://www.dojopress.com)

He used to give out free ninja books. I have not checked in a while.

</comment><comment><USER3> Krav Maga [https://en.m.wikipedia.org/wiki/Krav_Maga](https://en.m.wikipedia.org/wiki/Krav_Maga)</comment>


Emails show the meatpacking industry drafted executive order to keep plants open - <AUTHOR> https://www.propublica.org/article/emails-show-the-meatpacking-industry-drafted-an-executive-order-to-keep-plants-open <comment><USER2> A lot (most?) legislation is written by industry (or other) lobby groups. This has been the case for a while. I guess an executive order is a little different. But it's the same principle really...</comment>


Cryptography for ULP Devices - <AUTHOR> http://semiengineering.com/cryptography-for-ulp-devices/

<comment><USER2> Title is wrong, you mean "ULP":

        U ltra
        L ow
        P ower

You have "UPL in the title.

Apart from that, this seems to be a useful article, listing lots of issues in a single place. While it is light on detail, and seems to contain nothing new, it is an interesting summary, and possibly a good starting point for people to research further the many, many issues.

<comment><AUTHOR> Fixed the typo--need more coffee :) Anyway, thanks for letting me know.</comment></comment>


[translated] Last Norwegian party chance to stop the surveilance act caved - <AUTHOR> http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=no&tl=en&u=http%3A%2F%2Fwww.aftenposten.no%2Fnyheter%2Firiks%2Farticle4055711.ece

<comment><AUTHOR> This means that we too will be entering the digital dark ages. Bad news for anyone concerned with privacy, but probably good news for anyone creating privacy preserving software, encryption software and similar.

With much of Europe in the same situation, this is probably a good time for people to think about startups in the field of privacy.</comment>


Looking for Website Feedback - <AUTHOR> I am wondering if anyone could check out my website https://teamup.zone and give me some feedback.  Its a website for creating online groups and events such as pickup soccer.  Thank you for your time. <comment><USER2> The homepage appears cutoff [http://prntscr.com/k2z3pl](http://prntscr.com/k2z3pl)

Honestly, the "more" page would make a better homepage. [https://teamup.zone/team/browse](https://teamup.zone/team/browse)

I don't know the site, so show me as much great content as you can.

<comment><AUTHOR> Thank you

</comment></comment><comment><USER3> When submitting use the title "Show HN: <name and what the website is about>" and it will go to the [https://news.ycombinator.com/show](https://news.ycombinator.com/show) category where others users check to give feedback.

<comment><AUTHOR> Thank you</comment></comment>


DevOps is a culture, not a role - <AUTHOR> https://dev.jlelse.eu/devops-is-a-culture-not-a-role-be1bed149b0 <comment><USER2> First, let me say I totally agree with the premise here--that all parts of a software engineering organization need to be on board with DevOps, buying in to the vision, learning the full stack, taking responsibility.

However, this article does serve as a good example of one of the big problems with most DevOps/SRE evangelism: It's usually coming from the Dev- perspective, rather than the -Ops perspective (or better, a balanced perspective). In particular, this focuses mostly on getting code to users, and speeding up that process. While that's certainly important, it leaves out any discussion of:

        * security
        * infrastructure design
        * instrumentation and monitoring
        * planning for failure
        * security
        * performance evaluation and tuning
        * disaster recovery planning
        * security
        * off-hours on-call responsibilities
        * security

Successful DevOps cultures _must_ address these things just as much as they address code feedback loops, time-to-production, rollback strategies, code pipeline automation, etc.

<comment><USER3> A company I worked for started a devops team. 3 years later and there's still not a single ops person on it. There were so many security holes in their group we had to ban them from releasing to our servers, so now they have their own cloud setup that is bleeding money.

The frustrating thing is: I'd have _loved_ to work closer with them. But every time we tried, the response was "You have no place here, your slowing the process down". We just wanted to automate the security testing, they decided that throwing the security tests out altogether was a better idea. I do admit that it _was_ indeed faster....

<comment><USER4> Just because someone has an Ops title doesn't mean they know anything about security. I've worked places where the Ops team caused every security incident.

Its a business leadership issue. When teams accept requests from the business and prioritize those requests over security then we have problems. Ops teams can be just as guilty of this as any other team.

</comment></comment></comment><comment><USER5> "DevOps Engineer" is simply just title inflation.

In 2017, there's literally _no_ difference between the outcomes expected from a "Systems Engineer" and a "DevOps Engineer" \- both are expected to produce HA, Automated, Well Documented Infrastructure, to allow developers to run their code. Anyone not doing that is just a _bad_ "Systems Engineer"

Developers don't call themselves "Agile Developers" because they started using agile methodologies or "CI Developers" with the boom of CI, but for some reason Ops guys want to call themselves "DevOps Engineers" because they read The Phoenix Project.

People talk about automation as if automation = DevOps, but I believe automation is a side-effect of the shared empathy which DevOps fosters. Because you have that empathy with your devs, you realize that their main goal is to be able to get their code in front of users _as fast as possible_. Automation is the answer to that.

<comment><USER6> It is not the engineers that call themselves 'Devops'.

It's the recruiters and managers.

Every engineer that I know that holds the 'Devops' title hates it, but has no choice in it.

<comment><USER7> I've observed this, but it depends on experience level.

Folks with <5 years experience, tend to enjoy the DevOps portion of their title. Whereas, neckbeards with a deep background tend to dislike it.

<comment><USER8> That is because DevOps is basically what 'a good sysadmin' always did, only now it has a title, and those in the sysadmin role now 'don't have relevant experience' because 'devops' is not on their resume, and 'systems administrator' has been re-associated with 'server tech' as a result..

</comment></comment></comment></comment><comment><USER9> Having worked on over 100 DevOps initiatives, I'm inclined to disagree.

8 years into DevOps, automation, cloud computing etc, it's time to accept that DevOps is a specialism and a function that companies - especially big ones - need to put into place in order to adopt the principles.

See here for further thoughts - [https://devops.com/im-happy-devops-engineer- job-title/](https://devops.com/im-happy-devops-engineer-job-title/)

<comment><USER10> If you have the job title "DevOps X", then you've missed the point of DevOps.

The _entire thing_ was brought in to remove the silos between SysOps and Dev. If you have people in the "DevOps" role, then you've just created a new silo, which means you just have traditional SysOps with a new and fashionable, but less meaningful name.

<comment> FLUX-YOU Unfortunately, "Cultural Engineer" as a title has some pretty scary implications. So the DevOps Engineer is becoming a cultural engineer of the company with a better name.

Which of course is title inflation and title overloading. Now if they'd just overload the salaries, we'd be set.

<comment><USER11> I've seen this a few times in the thread and I don't get it. Nobody is saying there is a "Cultural Engineer" role, they are saying that there are operations roles and development roles, and that DevOps is not a role, but a culture where the people in both roles understand, help, and cooperate with each other.

<comment> FLUX-YOU A devops engineer should know how to apply devops to your organization before the other roles have become proficient. It's someone to ask vs. reading the Internet for things that might not apply to you.

</comment></comment></comment></comment></comment><comment><USER12> I am a DevOps Engineer by trade and title.

Here is my take on this:

It is a role - not something that can be done by OPS or DEV or SEC or what have you.

Allow me to explain my 2 cents worth:

\- With the amounts of tooling (CI/CD pipeline, infrastructure monitoring, infra. provisioning, config. management, etc.), you do not want your DEVs or your full-time admins focusing on this bit at-all. It is good if they have some know-how (or even if they do the initial groundwork) but if your DEVs or sys admins are focusing on what 'entails' as DevOps -- then Houston, we got a problem. Because this means that DEV or sys admin or what have you is not focusing 100% on their role.

\- Why is 'DevOps' getting so much flak?? How about titles/roles such as 'scrum master' or 'Agile Practitioner' or 'Product Owner'?

\- I am not a noob by any means (~10 yr IT experience) and I am past the stage of getting excited by a job title. However, the 'DevOps' title given to a 'DevOps' guy is a correct move. AND, believe-it-or-not, it is a IT specialization -- just like 'cloud' is. Just because everything is a code doesn't mean you don't need a dedicated person who will not only preach DevOps -- but will also 'implement' DevOps -- and that fella should be called 'DevOps' \-- just like 'Agile Coach' ;-)

<comment><USER13> Would argue that you have a tools/service team. The fact that you failed to mention changing what devs and sysadmins consider when "focusing 100%" on their role indicates that what you are talking about isn't the concept of DevOps in the article.

Saying you have a DevOps team is like saying you have Lean team, a Theory of Constraints team, or a Just-in-time manufacturing team. DevOps doesn't say that devs shouldn't write code any more then Theory of Constraints says a guy that paints car hoods should be building brake pads. It is about the fact that they should work together to ensure the organization as a whole meets the goals. Not as isolated units that only prioritize their own goals.

I've seen the same flak about Agile and scrum roles for the same reason. People think they can buy the DevOps/Agile/whatever. Only difference with DevOps is rest is that it is getting more noise.

</comment></comment><comment><USER14> Yes yes, we get it, it's a mindset not a role. Now could we hire a DevOps guy to setup that CI/CD pipeline, ChatOps stuff, Kubernetes and dev/staging/prod flow so the coders can ship. ;)

The original thought was beautiful but the way I see it: DevOps is a branch where you specialise. After school people might learn front/back/db stuff and then specialise to "DevOps stuff" \-- or then you have more sysops kind of people who start to venture in the land of automating their work. Both are needed imho.

<comment><USER15> I hate specialization, and I want the person who develop something to think about how that stuff will be deployed and kept online. In particular, some tradeoffs have to be made between the development side and the production side, and I want the same person to see both side and decide with a technical criterion (or just choose one option, and later reverse course and change it), not on a "it's not my problem" criterion.

<comment><USER16> There is too much. It's specialization out of necessity. I know enough "DevOps" to be dangerous, but in addition to having a deep knowledge of our product's codebase, the multiple features of our product, configurations, etc. there are not enough hours in the day to master (not simply be familiar with) Jenkins pipeline, Docker, AWS, Ansible, Zookeeper, etc, etc.

99% of the people who could claim to have knowledge of all the above in their organization either have a very shallow (read: not useful) knowledge, OR their product itself is simply the gluing together of various DevOps technologies listed, so there is little more to know outside that.

<comment><USER8> it is definitely possible to have fairly deep level of knowledge at all layers it just takes effort.

That said, the larger the project, the more the need for specialization and the less possible it is for someone to keep up with all changes and be a domain expert.

<comment><USER17> I disagree. Maybe, there's a couple of guys/gals around that can go up and down the software and hardware stack and know where issues may lie when there's a problem, but I doubt there are many.

As a someone that's been in the tech industry a very long time, I came to the realization a long time ago that I couldn't be the expert at everything. Can I dabble in Oracle, Windows, Linux? Sure, would I want to bet my job on how much I know some of these products in the time of crisis, hell No!!!

<comment><USER15> My last job as an employee, I had to install AWS, develop some server software, develop some web facing software, develop some embedded software (with a bit of easy real time), get the freaking 2G to work, get the sensors to work properly, model the mechanical parts to install the embedded device on site, order all that crap (electronics and mechanics) from the providers, create the boxes, try to think about lightnings and how not to fry the customer's equipment. And get the sandcastle to stay put.

That's what happens when you work at startups, there is no plethora of employees, and a lot of work.

</comment></comment></comment></comment></comment></comment><comment><USER18> I do not know. We always had "DevOPS" aka sysadmin that knew C,perl and bunch of others. Then it became too much for a single person to know everything and we invented "more ops" and "more programmer". Now we have better tools albeit more complex and we have decided that we again can have this "DevOPS" person whatever that means.

But again we are facing this dilemma when there are literally thousands of different tools and ecosystems and you just simply cannot be an EXPERT or even ADVANCED in most of them. We should clearly define what we expect from the role and the candidate. We can't waste other people's time by hiring for DevOPS when we clearly want a PowerShell programmer,windows administrator and database admin in a single package

<comment><USER10> DevOps is a cultural idea. It's supposed to be the collaboration between sysops and dev, in order to break down the traditional silos. Having a "devops" team or role creates a new silo, hence the reason it's BS to have it.

<comment><USER19> Sadly this. Speculating on why -

Doing development work, whether it is application development or infrastructure automation, is really hard if you are being interupted frequently.

Traditionally, you avoid interupting programmers by putting some kind of buisness analysis layer ontop of them. That might be a product owner or just telling everyone to communicate requirements through tickets.

But you can't build stuff without talking to eachother. So programmers working on similar stuff tend to chat eachother, sit near eachother. They chat in an informal way.

The trouble is that, for DevOps, often the developers are customers / users. If you chat to them the way you chat to the other DevOps, you'll never get any work done.

Infrastucture automation can happen 2 ways - either the developers take over the IT, or the IT take over that part of the development. IT support organisations have a very anti-customer culture to be honest. Combine that with the need to protect engineers from interuption and you get a very hard silo.

</comment></comment></comment><comment><USER20> Everywhere you see the word "devops" replace it with the word "empathy".

That was the true meaning of DevOps - fostering empathy and communication between different groups, and to stop the siloed "throw code over the wall to Ops" mentality that existed.

By having a "DevOp's Engineer" you have admitted you have failed at DevOps, because you have created a new silo.

A good team will have a combination of Operations Engineers, Software Engineers, Automation Engineers and Test Engineers all of whom work together, and collaborate on tooling, processes and deployments, who also share in the rewards for a projects success, and share in the responsibility for when something goes wrong.

DevOps is not a team created to "provide DevOps services to R&D" \- which is the basic job description for far to many DevOps jobs postings.

It is also not just handy R&D pagers, and expecting them to manage a system.

Of course all of this is talking about the initial spirit of DevOps, not the current "Buy my Book", consultant driven mess that is now associated with the word.

<comment><USER21> That's like Agile; the practices that emerged after the principles are sometimes (often?) WTF.

<comment><USER22> It confuses me when I read the Agile Manifesto and then look at Scrum, Lean, Kanban, XP, etc.

On the one hand you have a manifesto advocating self-organising teams citing individuals over processes, while all those methodologies claim to be 'agile', but dictate your processes and how you should organise.

To me, they seem incompatible. It's like several of the original signatories have developed doublethink.

The one that really makes my mind boggle is that you can be a certified Scrum Master. To become the guy who tells everyone how to work? Is that not the very antithesis of the agile manifesto?

<comment><USER20> Yeah, this gets me too.

Just because someone went to a training course, and now runs a standup, and use Jira or Trello does not make what you do agile.

</comment></comment></comment></comment><comment><USER23> As a DevOps consultant, I think it can actually be both. Culture is central to DevOps but someone has to lead. Sometimes this can be the CTO but often it helps to have a dedicated advocate, especially within larger orgs/teams.

Essentially it boils down to semantics. Often DevOps engineers are one part evangelist and one part automation engineer. The software industry has just chosen to call those people "DevOps".

</comment><comment><USER24> I've seen two prevalent definitions of devops:

1\. It's a culture where dev and ops work together (as per TFA);

2\. It is the application of software engineering practises (such as version control and test automation) to ops.

I prefer the second definition because it's the only one that's got anything to do with new developments in infrastructure-as-code and isn't just a new name for what competent teams were always doing anyway.

<comment><USER25> Alternative third definition: Make the devs also be the ops guys

<comment><USER26> you mean the ops guys. and yeah it's just an easy way to take nerds and make them do more stuff so you can save that extra 85-100k salary. More profit for the shareholders, what's not to love.

<comment><USER25> I did indeed. Good catch.

</comment></comment></comment></comment><comment><USER27> A big part of the problem is that DevOps are not really about new technologies but just a new word the same bottom up management theory that also gave rise to buzzwords like LEAN.

In essence it's a shift from thinking in terms of grand strategic plans drawn up by the high management to be mindlessly implemented by the "replaceable" employees, to thinking in terms of reacting to problems as seen from the bottom of the org chart.

The problems with buy in is that DevOps kills a lot of the prestige difference between different teams/silo's as it's basically about realizing that the no developer or systems architect have enough knowledge about the "real world" problem they are trying to solve to design/write anything in isolation.

Or to put it differently DevOps means that the implementation and development teams owe operations a steak dinner if/when the system tumbles over and operations gets the dreaded 3am pager call, due to an untested edge case, not that the two roles merge into one.

</comment><comment><USER28> Here's my point of view as someone who's title currently is "Senior DevOps Engineer", and used to be a software engineer for many years:

DevOps has multiple meanings - in some (usually smaller) companies it can be thought of as a philosophy in that all developers are responsible for managing production infrastructure and their deployments. As a company scales, and the codebase grows, people have to start specializing. It's just not feasible for everyone to have perfectly overlapping skillsets and be completely replaceable by each other. It happens with frontend/backend, and it happens with "DevOps". I focus on our production infrastructure, making sure deployments are smooth, our database has backups, etc. That doesn't mean that other developers are completely detached from our production environment - if there's an issue in production multiple parties are involved in working through it and fixing.

I personally interchange the title DevOps Engineer with Site Reliability Engineer, Infrastructure Engineer, Ops/SysOps Engineer, etc. Different companies have different titles, but I'd wager that the majority of those positions tend to perform work of a similar nature. Depending on the size of the company, some may specialize even more (i.e. a large company may have SRE to focus on production/monitoring, and someone else to focus on deployments). It definitely varies company to company, but by and large I think it can all be grouped under "software operations", which itself is a subset of software engineering.

</comment><comment><USER29> While I agree that DevOps needs to be a mindset/culture to be of any benefit beside ticking buzzwords checkboxes - but I really don't see any harm in giving someone a title containing the word DevOps.

Someone who can do the proselytism, take initiatives to drive the adaption and at the same time be the go to guy for the technical knowledge needed for any new processes/tools.

We all agree that the old waterfall inspired way of working when the developers work on their own, throws a bunch of new code down a hatch for the ops guys to deploy and they both blame the other team when something don't work is less than desirable.

Maybe there are some startups that have the devops mindset already from the beginning and a few old companies that can get there on there own, but I think many need some help to get there. Perhaps they could hire someone to get them started?

</comment><comment><USER30> My official title is DevOps, but my coworkers know that I'm just the most cloud-oriented developer on the team. In that regard I also regularly push code into our products, with an insistence that I am not simply the guy that does AWS/Jenkins/Ansible work.

So, in one respect I entirely agree that DevOps is just another developer, at least the way I practice it. That being said, it's naive to think that DevOps isn't a specialization, or that everyone writing your code is going to be equally knowledgable on a product landscape as complex as AWS.

Ultimately where you fall on the spectrum of developer and ops is company specific, even project specific, and to try and make some generalizable dogma on the issue is a waste of time.

</comment><comment><USER31> Related, I've found that the term devops is too poisoned to be used effectively when hiring. It brings out charlatans in far greater numbers than anything else at the moment. Garden variety technician level folks who self inflate their titles and roles to try to jump from 60k to 100k overnight. It's been frustrating as they're able to get things syntactically correct for the most part that they get through early phone screening but absolutely fall apart once they reach someone with technical expertise, wasting everyone's times.

<comment><USER32> Devops is less about knowing the syntax of something like Terraform and more about understanding, communicating, and implementing 'devops' best practices across an organization. The early phone screen should be an easy place to weed out people.

I do agree that devops is the hot new title so people are jumping on it to try and make more money.

<comment><USER31> I mean syntax of the conversation. They're basically gaming the initial phone screenings and making us waste engineer time discovering that they don't really know anything. It's not exactly easy to get good filtering for this with first level screening but it's what we've had to do

</comment></comment></comment><comment><USER33> I've been browsing around job boards lately and see a lot of "DevOps Engineer" positions, but the descriptions of each vary widely. Some of them appear to be "real" DevOps roles, that is they sit somewhere between the traditional dev and ops roles and the basic mission is to get code out to users fast. But then many of them are simply rebranded systems engineers, while others are dev roles where managing infrastructure is part of the job, while other job description have read like very basic sysadmin job descriptions.

</comment><comment><USER34> Devops just means your IT people are software engineers. That's it.

Web systems are so complex (and automated) to manage these days that you need to be able to write code to manage the infastructure.

Google has been doing this for ages without calling it Devops. As far as I'm aware all of their main support people are software devs

<comment><USER35> > Google has been doing this for ages without calling it Devops

Are you of the opinion that DevOps, like Agile, is a buzzword and money making opportunity? I had a brief stint in a DevOps-ish role and that was my conclusion.

<comment><USER34> 100% from the two companies I've seen implementing it.

All it means in practice is "fuck, our IT guys don't understand this docker thing. We need a software guy to write up stuff to automate all this"

I looked at a couple Devops position and saw the same. Basically "we need a software engineer with networking skills".

IT jobs are quickly vanishing. All the stuff that doesn't require software development has been automated away besides things anyone can do like wire some machines to a switch.

Everything is either really easy or quite hard and it's hard to hire a guy that knows software at an IT salary. Now we have Devops, so that execs can justify hiring software engineers to maintain the network.

</comment></comment></comment><comment><USER36> I agree its a culture, but there is a role to be played, and in all the cases where I have moved teams down the DevOps path it has always started with specialists who can help the team out as they transition.

Then there is the operations part, no sane person would say since we do "DevOps" and "Continuous Delivery" now, so lets give ever member of the team full admin on AWS. Even in a _very_ mature organization you have snowflakes. If your DevOps team is doing its job, more and more of the workflow is being shifted all the time to the product teams and less and less is being owned by them. Then once they have delivery fully migrated, they move on to be your SRE's which is something I think most teams who have devops people will never get to.

</comment><comment><USER37> In my experience, "devops" is just employer-speak for "We're too cheap to hire proper sysops or DBAs, so we'll expect you to do everything yourself."

<comment><USER38> I think there is more to it than too cheap. I think it is not enough money and not enough need. If the budget is $150k and it is SV, you aren't going to hire a team.

Another problem is I think Google and like companies have been vacuuming up the best of the best sysops and DBAs. This has had the effect of making them hard to find, and even if you can, you can't afford them. Then you see the conquences of companies trying to figure out an alternative plan. The results are Devops and NoOps.

</comment></comment><comment><USER39> Here's a thought: skilled devops engineers are indistinguishable from skilled software engineers, and vice versa.

Who can be specialized anymore? Isn't devops just the compression of skill sets that we've been witnessing for the last two decades?

As a developer, you now must be able to deploy, to write and maintain unit tests, and possess the knowledge to debug code deep on the system and network layer, and write code that follows up-to-date security practices.

Specialization is dying.

<comment><USER40> Data scientists would disagree. Specialization is alive and well.

<comment><USER41> I think think most skilled developers could easily do data science work, they are just more expensive to hire than data scientists.

<comment><USER40> Data science involves a lot of statistics and graduate level mathematics. I don't think skilled developers can fill the gap.

</comment></comment></comment></comment><comment><USER42> Dev = "how do i start a new instance? just chmod -R 777!"

Ops = "yyour code is broken!"

Devops = "I am super tired."

</comment><comment><USER7> I used to repeat this statement, but a few years of the current pattern, I disagree.

(I'm going to generalize for UNIX systems, apologies in advance)

Your traditional systems engineers are well versed in the ways of UNIX, but that does not automatically qualify them to wear the DevOps hat.

And vice versa. Systems and DevOps are two different sides of the house.

There is an entire tooling set that someone with the DevOps attribute needs to be aware of (CI/CD, tools that enable code review, etc), how they tie into the tools that the developers use, and how to troubleshoot when these things break down.

You, Systems Engineer, will be called when someone can't run "npm install" and an ERRNO message scrolls down the screen. While it could be something as innocent as a missing header file from an external dependency, it's still on you to rapidly troubleshoot and resolve.

You also need someone with UNIX and networking infrastructure chops. Someone who is familiar with a how to generate and read a packet capture, or maybe even use strace.

You, DevOps, will be asked why does it take forever-and-a-half to run 'ls' in a directory containing 10,000 files. Scratch that, you will asked to make it faster.

It's unreasonable to ask either of these folks to stretch and cover the other role, it results in a lot of resentment in how they're expected to do "two jobs" as well as complaints from developers that the DevOps/Systems Engineer's priorities and timelines don't line up with their own.

Worse, you'll see abominations (a relative viewpoint) because everyone knows their tools the best. To a person with a hammer, everything looks like a nail.

I've seen automated DNS failover triggered via Jenkins, and I've seen automated code deployment triggered via cron on a 5 minute schedule.

DevOps is more than automation, it's about enabling developers to rapidly iterate in a sensible way that doesn't cause too much wake around a growing startup, an already functioning business, or a fast moving behemoth.

It's about enabling operations to rapidly provision new applications, monitor existing applications, properly perform capacity planning, and create repeatable infrastructure ...repeatedly.

And it's about both developers and operations coming together to onboard new employees into the environment in a short timeframe, so they can become productive.

This is all not to say that DevOps and traditional Systems Engineers + Network Engineers should live on different teams. Ideally, they're all on the same team, with different roles, and plenty of communication and cross-training.

<comment><USER43> It looks like you're just talking about a good, old-fashioned, well-built operations team.

In DevOps there is no "I can't run npm" unless the new guy is building his first personal env. In DevOps ERRNO scrolling down the screen means your kit is broken and you need to rebuild it to a known, working state, yourself (and crap like that certainly wouldn't be making it into production). In DevOps the entire organization is on board. Everyone has a role even if it's just feedback or a ring-ring fielding phone jockey and they'll know why and they'll know it's an important contribution because every lost piece of information affects delivery and quality.

If you're automating, integrating, designing, orchestrating, trouble-shooting or just about any other ing-ing you can think of than you're an engineer and you can front that with whatever you like be it systems, integration, quality- assurance, software, application, automation, monitoring, cloud, reliability, hardware, database, support, etc. etc. and even devops, if you like.

The difference is whether the organization you're doing all of your "engineering" for has accepted and/or is applying the DevOps "method".

I've perused some "DevOps Engineer" postings and a good amount of them look like garbage idolization of this or that toolset combined with looking for someone they can beat on until their infrastructure works like they think they'd like it to.

DevOps ain't infrastructure and it certainly isn't ace dev guy running the prod kit and no, it's not about "enabling" developers either. It's an operation comprising the entire cycle of delivery with expectations and requirements from all members.

Given the case of some new startup and they're on the hunt and poised to ramp then what they're really looking for is a savvy engineer (or 12) that can ing- ing all. day. long.

Sadly, because of business overlays and buzz-wordery and agile styles and .. certain software stacks, a more than fair share of time gets sucked right out of the actual developing and operating parts, especially if there's any palatable resistance to acceptance but, alas, it really is just another thing fronting ing.

</comment></comment><comment><USER44> I was thinkging about that Mike Dilworth quote: _" DevOps is a culture, not a role! The whole company needs to be doing DevOps for it to work."_

It's one of those kinds of statements that at first glance, looks really insightful and invites the head nodding up & down in agreement.

However, thinking about it some more, that type of quote can be applied to _anything_.

"Compliance is a culture not a role. Everyone from the CEO to the janitor should be aware of legal compliance. Having a compliance department is wrong."

"Security is a culture not a role. Every employee should create quality passwords and follow proper encryption procedures, ..."

"Marketing is a culture not a role...", "Design is a culture not a role...", "" etc, etc. Every employee should know/do everything. If you have a separate marketing team and design team, your company has failed.

Yes, I can see where one ideal of devops is to "break down silos" and therefore, having a set of programmers who specialize in that is "recreating the silo" which is a contradiction. On the other hand, I can see the opposite view: if a company wholeheartedly embraces "devops", they will acknowledge that by having _a team that focuses on devops_. If you're a Google paying a programmer like Jeff Dean $500k+ a year, you really don't want him working on Chef/Puppet scripts instead of Tensorflow research. At a more advanced level of skills above Ansible/Docker automation is the SRE (Site Reliabity Engineers) which has a lot of overlap[1] with Devops focused engineers.

A specialization in devops seems inevitable especially for larger companies that exceed 10 people. In short, I'm not sure why "devops" in particular has to rigidly adhere to Heinlein's _" specialization is for insects"_.[2]

As for other comments saying it's _" title inflation"_, I'm confused as to the source of that sentiment. The "devops engineer" doesn't seem like a glamorous tile similar to _" I'm CEO, bitch"_[3]. There are no "50 Shades of Grey" movies where the female lead gets weak at the knees at the mere mention of "devops programmer". The _" sanitation engineer"_ euphemism of _" garbageman"_ I understand as inflation but "devops engineer" seems like a sideways or neutral label. I'm mystified by the outrage over this programming label.

[1] [https://en.wikipedia.org/wiki/Site_reliability_engineering#D...](https://en.wikipedia.org/wiki/Site_reliability_engineering#DevOps_vs_SRE)

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

[3] [https://www.google.com/search?q="i%27m+ceo%2C+bitch"](https://www.google.com/search?q="i%27m+ceo%2C+bitch")

<comment><USER13> I think the DevOps is a culture statement is just as misleading to folks as the DevOps is automation/tooling.

If you look at the early conversations, it was a discussion that outlined a management paradigm that borrowed heavily from Theory of Constraints in the manufacturing world. The discussion lead to a consensus among those involved that defined core values of culture, automation, measuring, and sharing (CAMS).

To many people, DevOps means that paradigm. The examples you list (security, marketing, etc) are not paradigms composed of several values. They are business functions as infrastructure automation might be. We don't call the accounting team the "cash-flow" team cause it is a paradigm. Not a function.

While I don't think it is worth falling on your sword over, the fact that folks care about the wording is good. It means they are thinking about more then just the function, but also the underlying paradigms.

</comment></comment><comment><USER40> Problem with "culture" is everyone has their own variation of it.

<comment><USER45> thats the point. its the same story as when people were trying to do agile processes as a one size fit all.

</comment></comment><comment><USER46> Yes, yes, a thousand times yes.

</comment><comment><USER47> Linux basement monkey/Sysadmin supporting a dev Team and soon clients, here!

I dont care about nomenclature. I chose my weapons, and i can do fine with them; jenkins, artifactory, puppet, docker, vagrant and ammonite. All strung together using scala and bash scripts. Github MDs for docs and svn because it was there and the lads and ladies here like it.

Anyone can choose a stack. They just have to get good at it.

VALAR MORGHULIS!</comment>


Everything I Needed To Know About Waits and Queues I Learned From the TSA - <AUTHOR> http://thomaslarock.com/2010/12/everything-i-needed-to-know-about-waits-and-queues-i-learned-from-the-tsa/

<comment><USER2> Decent article, but isn't billing yourself as "SQL Rockstar" just a tad pretentious?

<comment><AUTHOR> i suppose, except my last name is "LaRock" and i have had the nickname "Rockstar" for going on 30 years...it just seemed to fit nicely.</comment></comment>


The Fading American Dream: Trends in Absolute Income Mobility Since 1940 [pdf] - <AUTHOR> http://www.equality-of-opportunity.org/papers/abs_mobility_paper.pdf <comment><AUTHOR> This study is of the article that is the basis of this web site and broader initiative: [http://www.equality-of-opportunity.org/](http://www.equality-of- opportunity.org/)

The post is based on a WSJ article that was posted to HN: [https://news.ycombinator.com/item?id=13133141](https://news.ycombinator.com/item?id=13133141)</comment>


Pavlok – The Habit Changing Device That Shocks You - <AUTHOR> https://www.indiegogo.com/projects/pavlok-the-habit-changing-device-that-shocks-you

<comment><USER2> Is it wrong of me to hope for a security flaw that lets me shock anyone I see wearing these?

Not that I'm against the device's concept, or the idea of habit building. It would just be funny.

<comment><AUTHOR> Not sure if that'll happen, but you can at least slap the founder if you pay $1,250</comment></comment>


JavaScript and Desktop Apps – Introduction to Electron - <AUTHOR> http://www.slideshare.net/brainhubpl/javascript-and-desktop-apps-introduction-to-electron <comment><USER2> I've started playing with Electron after I heard it on the Dot Net Rocks podcast. It is interesting and I like it for cross platform apps (already have an application in mind) but I've come across some issues. Mainly using React with Electron. I copy examples verbatim and it just won't render properly. It is incredibly frustrating and makes me want to just do .NET Core instead. Another downside is that it seems to create very large executables when using electron-render, which may not be a big deal but they are much larger than apps I've seen in the Windows store.</comment>


Review my tool svgpath.com - <AUTHOR>

Hi all,
I had sometime during the weekend, while exploring svg (in particular, svg path), i build a really simple thing to help me understand some of the more complicated examples at various places on the web. How everything fits together. After typing/copying in a path string, you can mouse over the structure analysis section to see how the string is built. Hope someone else finds it useful!
Here is the link: svgpath.com <comment><USER2> What is the draw! button suppose to do? I loaded it up on firefox and nothing seems to be happening.The page is just static.

<comment><USER3> Works in Opera, but the drawing updates when I change the value of the field, so by the time I click draw there's nothing to update - perhaps that's what's confusing you.</comment></comment>


Spotlight search in Yosemite exposes private user details to spammers - <AUTHOR> http://arstechnica.com/security/2015/01/spotlight-search-in-yosemite-exposes-private-user-details-to-spammers/

<comment><USER2> Yet another reason not to "upgrade" to Yosemite.</comment>


Show HN: Bolt: A research language with finer-grained concurrency than Rust - <AUTHOR> https://github.com/mukul-rathi/bolt <comment><USER2> So the features that the dissertation claims Rust doesn't have are:

\- Single-threaded mutable aliasing

Actually, Rust supports this in the form of the `Cell` type. It's admittedly not very ergonomic, though. Also, Bolt runs on the JVM and thus has a garbage collector. This pattern is more powerful in a garbage-collected environment, because merely reading a pointer is enough to guarantee it won't be collected. Suppose you (1) read a mutable field of type string, (2) call some other code that might write a different string to that field, then (3) access the string you originally read. With garbage collection, this is safe; without it, your string might have been freed by the time you access it. You can also make this safe with reference counting – most interpreted languages do this, Swift does it with class fields, and there are libraries to do it in Rust – but fiddling with reference counts every time you access an object is fairly slow.

> Concurrently mutate disjoint parts of object

Out of the box, Rust lets you take mutable references to disjoint parts of an object and send them to different places, including different threads. Bolt also apparently lets you pass these around as linear capabilities; translated to Rust terms, it's like if you could take a Box<(Foo, Bar)> and split it into a Box<Foo> and Box<Bar>. Rust doesn't support this out of the box, but you can get something equivalent with the owning_ref crate (again, a bit less ergonomic, but still safe).

> Concurrently mutate object, locking overlapping state

You can easily do this in Rust with Arc<Mutex<Foo>>. Bolt apparently inserts mutexes automagically where needed, but other than that I don't see any ergonomic difference. Most Rust programmers would probably not appreciate mutexes being inserted automatically; locking is expensive and creates the possibility of deadlocks, so for both a performance and correctness standpoint you want to understand where mutexes are being used.

<comment><AUTHOR> > Also, Bolt runs on the JVM and thus has a garbage collector

No, Bolt targets LLVM IR

As for your other points, whilst there _are_ escape hatches in Rust that do let you do it, it's not in the core ownership type system. That's what is being compared - the type systems.

The escape hatches mean you lose some of the guarantees the type system gives you - Bolt's approach still gives you the guarantees. That's the difference.

<comment><USER3> I'm not sure what you mean by bypassing the type system. The types mentioned are part of the type system. Some of them move checks from compile time to run time. `unsafe` could be seen as an escape hatch, but as far as I understand that wasn't part of the discussion?

</comment></comment></comment><comment><USER4> Discussion on r/ProgrammingLanguages: [https://www.reddit.com/r/ProgrammingLanguages/comments/gg0cm...](https://www.reddit.com/r/ProgrammingLanguages/comments/gg0cmd/bolt_a_new_language_with_datarace_freedom/)</comment>


Part kid, part machine, all cop - <AUTHOR> http://www.sweet-juniper.com/2010/10/part-kid-part-machine-all-cop.html

<comment><USER2> Ok, this guy wins major Awesome Dad points. That costume is amazing.</comment>


Creating Simple Transactional Emails for Referly - <AUTHOR> http://blog.refer.ly/creating-simple-transactional-emails-for-refe

<comment><USER2> Looks good - I like the simple message and clean look.

Don't forget to use multi-part and include a text portion. HTML only emails are a spam flag. We have some more tips about content and how it affects deliverability here: [http://documentation.mailgun.net/faqs.html#does-the- content-...](http://documentation.mailgun.net/faqs.html#does-the-content-of- my-email-matter-for-deliverability)

</comment><comment><USER3> Looks good to me; you've managed to avoid the common caveat of ugly or over- imaged HTML e-mail. This is a message I'd certainly welcome into my inbox!

One thing you might consider is changing the wording of the message, assuming that a balance update always means rewards being earned (rather than deducted). It might have more positive connotations to state something like "You've earned rewards!" rather than the cordial "your balance has been updated."

I know I always get a nice feeling when I get the Paypal email "You've got Money!"

<comment><AUTHOR> Ah very good point! I should have mentioned the subject line (very important to email design) is:

Your Referly Account Has New Rewards

do you think it would be worth repeating in the body too, or overkill?

<comment><USER3> That definitely makes it a lot clearer from the get-go.

It probably couldn't hurt to re-include the message (who doesn't like a reminder that they just made money?), but with the subject line in mind, the body seems to serve more as reinforcement for the original message.

Again, great job with this, it's always tricky to toe the line of much- anticipated email and spam-like messages.</comment></comment></comment>


The Libra Blockchain White Paper [pdf] - <AUTHOR> https://developers.libra.org/docs/assets/papers/the-libra-blockchain.pdf <comment><USER2> There's really one big question that any sort of cryptocurrency design has to answer, and that's the state precedence system. If a new client comes up and sees two different states both advertised as genuine, which one does it choose?

This has to be an unambiguous decision to prevent any disagreement about consensus or state evolution.

Bitcoin, for example, is just the accumulated proof of work -- an unbiased estimator of the amount of SHA256 hashes that were computed to produce the chain. Ethereum has a similar design currently, but wants to switch to proof of stake; the algorithm here is more complicated, but basically the longest chain that has no attestations against it on a competing chain.

I can't quite tell what Libra is offering here -- I think they create a group of validators (section 9.2), and the state is the one that the most validators have cumulatively agreed upon is the current state. How validators are unambiguously identified is unclear at this point; presumably the public keys will be shipped with the client so that they are effectively public knowledge, and eventually will be proof-of-stake based, so that key pairs that hold large amounts of LibraCoin will use their key to sign the state. There seems to be very little specificity here, though.</comment>


DMVs Are Selling Your Data to Private Investigators - <AUTHOR> https://www.vice.com/en_us/article/43kxzq/dmvs-selling-data-private-investigators-making-millions-of-dollars <comment><USER2> Government data should either be entirely open to anyone freely, or not available except with a warrant. This middle ground is very scummy.</comment>


The P=?NP Poll (2002) [pdf] - <AUTHOR> http://www.cs.umd.edu/~gasarch/papers/poll.pdf <comment><USER2> A really cool result which seems relatively unknown is that if we augment our Turing machines with an oracle X chosen uniformly at random from all oracles then P^X =/= NP^X with probability 1.

An oracle is a black box that can solve a particular decision problem in O(1).

The notation means e.g. P^SAT = class of all problems that can be solved in P time with a machine that has an oracle for SAT.

It gets really ingesting because there are particular oracle machines for which P^X == NP^X.

See [https://en.m.wikipedia.org/wiki/Oracle_machine](https://en.m.wikipedia.org/wiki/Oracle_machine) for references to papers.

Also see [https://en.m.wikipedia.org/wiki/Almost_surely](https://en.m.wikipedia.org/wiki/Almost_surely) if you don't know what with probability 1 is.

Off topic (but related to almost surely), one of my favourite theorems is Pólya's recurrence theorem which says that a simple random walk on Z^d (lattice) is recurrent for d=1,2 and transient otherwise, so if you get lost on a 1 or 2 dimensional grid, just execute a simple random walk and you'll get back to the origin almost surely! IIRC the probability of recurrence is about 34% in 3d.

<comment><USER3> Anyone got suggestions for what a web dev should read or what classes he should take to understand what this guy is saying?

<comment><USER4> What you're looking at is the theory of computational complexity.

Here's a short-ish overview: [http://www.math.uchicago.edu/~may/VIGRE/VIGRE2011/REUPapers/...](http://www.math.uchicago.edu/~may/VIGRE/VIGRE2011/REUPapers/Hogan.pdf)

For a more extensive overview, try this textbook by Michael Sipser (Amazon Affiliate Link if feeling generous: [http://amzn.to/2fy9tKZ](http://amzn.to/2fy9tKZ), Google Books link otherwise: [https://books.google.com/books?id=1aMKAAAAQBAJ&dq=introducti...](https://books.google.com/books?id=1aMKAAAAQBAJ&dq=introduction+to+theory+of+computation)).

<comment><USER5> I bought Sipser for this very purpose. I found it very difficult without being able to discuss it with anyone to clarify my understanding of the ideas. I would love to work through it, but would need a CS tutor to help me... any takers? ;)

Edit: to be honest it's the maths notation that is a big barrier for me. Until one can read it relatively fluently it's very hard to translate the ideas into a meaningful mental model .

<comment><USER6> It's been mentioned elsewhere but I recommend: [https://www.youtube.com/playlist?list=PL601FC994BDD963E4](https://www.youtube.com/playlist?list=PL601FC994BDD963E4)

Seems like a few lectures are missing but if you google around you might be able to find them somewhere.

</comment></comment></comment></comment></comment><comment><USER7> #8 is a fun one (some of these answers are half-joking):

"Proof by contradiction. Assume P = NP. Let y be a proof that P = NP. The proof y can be verified in polynomial time by a competent computer scientist, the existence of which we assert. However, since P = NP, the proof y can be generated in polynomial time by such computer scientists. Since this generation has not yet occurred (despite attempts by such computer scientists to produce a proof), we have a contradiction."

<comment> surrey-fringe Is that true -- that the proof (if we produce one) will be verifiable in polynomial time?

<comment><USER8> It is not really meaningful to talk about a single instance being verifiable in polynomial time.

<comment> surrey-fringe Well I was open to evidence that applies generally, but sure.

</comment></comment></comment></comment><comment><USER9> I like Scott Aaronsons approach: Using NP hardness asumption as a physical constraint and seeing what follows.

[https://arxiv.org/abs/quant-ph/0502072](https://arxiv.org/abs/quant- ph/0502072)

<comment><USER10> I second this; check it out even if you're not the type to usually read scientific papers. This is a fun one that's not hard to understand.

</comment></comment><comment><USER11> Knuth's perspective on this topic is quite interesting, bordering on the infuriatingly frustrating: he seems to be of the opinion that p=np, but any proof we find for that will be non-constructive and the actual algorithm will evade us.

[http://www.informit.com/articles/article.aspx?p=2213858](http://www.informit.com/articles/article.aspx?p=2213858)

<comment><USER12> It's worth noting that _if_ P=NP, then there's already a known (though highly impractical) algorithm which can solve any given NP problem in polynomial time: [https://en.wikipedia.org/wiki/P_versus_NP_problem#Polynomial...](https://en.wikipedia.org/wiki/P_versus_NP_problem#Polynomial- time_algorithms)

<comment><USER13> This argument is useless since polynomial time is just as intractable as exponential time if the exponent is large. For example, lets say that we found a way to solve all np problems in n^1000 time, would that change anything? No, there aren't even 2^1000 atoms in the universe so we will only be able to solve it for the case n=1.

<comment><USER14> Your argument supports the view that P is a useless concept, not that that argument is pointless.

<comment><USER15> Often a "proof" that P does not equal NP is that it would be terribly inconvenient if solvable in n to the second or whatever, and therefore in a sort of cosmic censorship saves us by claiming it clearly can't be the case because it would be so annoying.

A good argument can be provided by an analysis of statistical thermodynamics gas laws. It highly disturbs some people to think that atoms being in motion implies that all the oxygen atoms in the room air might coincidentally cluster into a small corner of the room leaving the victim to suffocate. There is no reason to think that impossible under most thermodynamics theories. However, it is nearly infinitely unlikely and you'd merely have to wait a ten to the hundred times the lifespan of the universe for it to coincidentally happen. I suppose it scales quite strongly with room volume and linearly with air pressure, you have one atom in the ISS airlock and being in one half the air lock at any given moment is a very predictable 50:50 odds...

Likewise if the smallest polynomial solution to a NP problem takes a google's worth of universes to calculate, then even if it is poly you need not worry too much about mere human inconvenience.

I'm not saying its a wise way to go thru life, but there exists a large set of people who get hung up on whats convenient or beautiful must be right, even if whats right turns out to be very ugly or inconvenient, so for them "P=NP but your bank account is still secure" is a very big deal.

</comment></comment></comment></comment></comment><comment><USER16> Is there any probabilistic argument around the proof?

For instance, a decade before Wiles' proof of Fermat's Last Theorem, Feynman[1] showed it was extremely unlikely to be false. While you're not getting a million from Clay for that, it something non insignificant that we can use to guide our intuition.

[1][http://www.lbatalha.com/blog/feynman-on-fermats-last- theorem](http://www.lbatalha.com/blog/feynman-on-fermats-last-theorem)

<comment><USER17> As mentioned elsewhere in the thread, if provided with a random oracle A, P^A != NP^A with probability 1. It's not clear though what this actually buys you, intuition wise, since it's already sort of intuitively clear that nondeterministic oracle queries are much more powerful (then again, I guess you could say the same about nondeterministic computing...)

[http://epubs.siam.org/doi/abs/10.1137/0210008](http://epubs.siam.org/doi/abs/10.1137/0210008)

Edit: For those who are interested, the oracle separation gives you one of the few properties we can prove about the nature of any proof of P ?= NP, that it must be 'non-relativizing'. We know a few other properties of any possible proof, described here: [http://www.scottaaronson.com/papers/alg.pdf](http://www.scottaaronson.com/papers/alg.pdf)

</comment></comment><comment><USER18> Richard Karp: (Berkeley, unsure, P!=NP) My intuitive belief is that P is unequal to NP, but the only supporting arguments I can offer are the failure of all efforts to place specific NP-complete problems in P by constructing polynomial-time algorithms.

I believe that the traditional proof techniques will not suffice. Something entirely novel will be required.

My hunch is that the problem will be solved by a young researcher who is not encumbered by too much conventional wisdom about how to attack the problem.

<comment><USER19> >> My intuitive belief is that P is unequal to NP, but the only supporting arguments I can offer are the failure of all efforts to place specific NP- complete problems in P by constructing polynomial-time algorithms.

Actually, there has been tremendous incremental progress in inventing better and better algorithms for NP Complete problems. As a result, these problems are more deeply understood now. I think that the gap to poly time is closing fast.

Contrast that with the almost complete absence of progress in proving P != NP.

Also, from a practical viewpoint, many NP Complete problems of industrial size are now solved routinely.

<comment><USER20> Sure, in some cases (the easy ones) we can solve NP-complete problems. However, tons of useful instances of NP-complete problems are not particularly close to being solved. We can even characterize fairly well when the instances become hard (for instance, for graph problems the treewidth seems relevant). I see absolutely no evidence that we're anywhere close to constructing a polynomial-time algorithm for any NP-complete problem. If anything, we are slowly finally making some progress on proving P != NP because we are finally getting some nontrivial superlinear bounds on these problems (thus far, the biggest obstacle to proving P != NP has been the difficulty of proving _anything_ about lower bounds on runtime that isn't directly tied to space consumption).

Seriously, if you're interested in this approach ("well, in practice we can solve the problem if [insert thing here] is bounded"), check out the field of parameterized complexity. It's very popular in the database area. It also reveals some very sharp limits to tractability for these problems in practice, not just in theory.

<comment><USER19> >> (thus far, the biggest obstacle to proving P != NP has been the difficulty of proving anything about lower bounds on runtime that isn't directly tied to space consumption)

I probably don't understand the proofs of these bounds - it seems to me though, that any lower bound without some relationship to the time or space to _input_ the problem into some kind of computer, implies a belief that an instance might be solvable _in-place_ , in some physical system.

I have some doubts about that ....

<comment><USER20> To be clearer, a trivial lower bound is something like "the input is of size n and for any n-1 length yes-instance you can find n-length extensions that are no-instances, so you have to check all n elements." It doesn't tell us anything interesting about the worst-case problem complexity. What's been surprising is how hard it is to make meaningful lower-bound statements stronger than that (well, not surprising to people who work on this stuff for a living, I guess). But that doesn't make it more likely that P = NP, really, except in the sense that we (obviously) haven't characterized the entire space of problems in P yet.

To more specifically address your "in-place" concerns, you can often formulate the problem in terms of circuit complexity--circuits are inherently parallel, so minimum circuit depth is a good proxy for a required number of steps, and it's also generally agreed that if you can design a circuit to do something it's physically realizable (even though that's arguably not always true, especially in cases with very wide fanout). So a (somewhat) promising direction has been to try to find circuit complexity lower bounds for problems, especially nontrivial ones.

</comment></comment></comment></comment></comment><comment><USER21> For those that do not have time to read the whole thing, #29 is worth quoting:

"Stuart Kurtz (University of Chicago, 2050, P!=NP) [on wether and when proof will be found]:

Knowing Ketan Mulmuley, I live in fear that the solution will be via algebraic geometry, and it will come soon enough that I'll be expected to understand it. An alternative nightmare is that the undergraduate who solves it will publish his solution in French."

But it is by far not the only funny opinion in this paper.

</comment><comment><USER22> Reference needed: Once upon a time Turing Machines were my thing. But that was decades ago. Now I think I have a result that's interesting, following up on graduate school work I did way back when... but... reading such things as the P=NP prize problem definition I see that at least some terminology in the field has changed, or at least, concepts have been added. (Such as "language", if I remember rightly.) Can someone point me to sources that will allow me to translate Turing oldspeak into Turing newspeak, and vice versa?

<comment><USER23> If investigating a specific result, I would recommend Wikipedia, ComplexityZoo and yes, even CSTheory.StackExchange. There are more comprehensive documents, however (re)learning a field may be an overinvestment to test a single idea.

<comment><USER22> Certainly it's not in Wikipedia, and if Google knows about it; I've probably visited it. A question in CSTheory.StackExchange might work, though.

<comment><USER23> Wikipedia won't have an entry on every specific problem, but it can come in handy if there's a general idea of what to search for. A quick investigation on "language" reveals "Formal Language" and "Model Theory" are relevant topics.

</comment></comment></comment></comment><comment><USER24> This bit makes me wonder

> My longest-surviving proof that NP does not equal co-NP (about 5 years ago) > survived for about 3 days and fooled some very smart people into believing > it.

Is this a path towards selecting by insidiousness of mistakes? Can we mistakenly prove something by evolving a method by which no-one can figure out what is wrong with it.

Is there a limit to how hard it is to identify a mistake in a false proof? If incompleteness keeps you up at night, how about the possibility of a proof that you can have a mistaken proof in which the mistake was provably unidentifiable.

<comment><USER20> Generally speaking, if there's a step that isn't clearly logically justified in your proof, the proof is considered wrong. So in most "normal" proof systems, this wouldn't really be a valid technique (that is, the moment someone tried to formalize it they'd run into this roadblock, and if it wasn't trivial to surmount the original proof would be thrown out). That said, there are some sequent calculi where you can do a _lot_ of work in each step, so it might be really hard to figure out whether the step was valid; but I believe cut elimination theorems in those calculi basically assert that you can turn any valid "large step" into a (possibly very long, but finite) sequence of "small steps".

From a sociological perspective, since most mathematicians don't use formal methods for most of their proofs, there can of course be proofs that may be right, but that nobody can understand well enough to verify. The ongoing famous example here is that of Shinichi Mochizuki: [http://www.nature.com/news/the-biggest-mystery-in- mathematic...](http://www.nature.com/news/the-biggest-mystery-in-mathematics- shinichi-mochizuki-and-the-impenetrable-proof-1.18509?WT.mc_id=TWT_NatureNew).

Anyway, neither of these seem too relevant to P vs. NP.

</comment></comment><comment><USER25> Not a lot of mention of AI for CS, even in 2002. What about (2080+, P/=NP, proof techniques completely opaque to humans). And by that I don't mean mechanical exclusion of special cases like for map-coloring. As mentioned already, there's like a handful of people that understand the FLT proof, that situation is unlikely to improve.

</comment><comment><USER26> [2002]

<comment><AUTHOR> Updated. To my mind still relevant.

</comment></comment><comment> Paul-ish I wonder what this survey would look like if done today.

</comment><comment><USER27> Maybe the solution to P=NP problem is P=NP.</comment>


How measles causes body to forget immunity to past infections - <AUTHOR> https://science.sciencemag.org/content/366/6465/560 <comment><AUTHOR> After the disease, the children lost, on average, about 20% of their antibody repertoire. Some fared much worse, losing more than 70% of their immunity to viral pathogens. The findings are particularly sobering now that measles cases are increasing sharply, by more than 30% due to undervaccination and misguided vaccine safety concerns.</comment>


A podcast created by and about a startup that produces podcasts - <AUTHOR> http://gimletmedia.com/show/startup/

<comment><USER2> very meta</comment>


Show HN: Optimage – Advanced Image Optimization Tool - <AUTHOR> http://getoptimage.com <comment><USER2> Curious about the advances Optimage incorporates relative to other image compression options.</comment>