Nim: Deploying static binaries - <AUTHOR> https://scripter.co/nim-deploying-static-binaries/ <comment><USER2> The reason why static linking has been all but banned is security and bug fixes: with static linking, the bugs and performance issues are fused into the resulting binary; fixes to libc will require a complete re-build. If you're delivering static binaries for embedded firmware images, this will quickly turn into a security maintenance nightmare, especially for end users of the final product.

Linking dynamically with libc will never be an issue on illumos- or any real UNIX-based operating system because libc includes all previous interface versions and can therefore guarantee that it is backward compatible.

Long story short: develop and build your software on an illumos-based operating system like OmniOS or SmartOS and dynamically link only with libc and you won't have to worry about static linking for convenience delivery: link on the oldest version of SmartOS and sleep well at night knowing your application will work on the latest nightly build. As an added bonus, your binary will be smaller and the runtime linker will only mmap(2) the required code pages out of libc into memory.

[http://garrett.damore.org/2015/09/on-go-portability-and- syst...](http://garrett.damore.org/2015/09/on-go-portability-and-system- interfaces.html)

<comment><AUTHOR> Hello, thanks for the detailed reply.

I am not from a software development background (I am kind of (Verilog), but am not much familiar with the best practices of software development). So you comment was quite insightful for me.

>The reason why static linking has been all but banned is security and bug fixes: with static linking, the bugs and performance issues are fused into the resulting binary; fixes to libc will require a complete re-build.

Wouldn't the same apply to the whole binary itself even if it is dynamically linked? What if the app itself has a security bug? Wouldn't the overhead to fix+recompile the statically linked binary be the same as that for dynamically linked?

[Or may be the problem is that the users with the binaries build with buggy musl-gcc need to be aware that there's a security risk, and that they need to download the fixed version I later re-deployed?]

> If you're delivering static binaries for embedded firmware images, this will > quickly turn into a security maintenance nightmare, especially for end users > of the final product.

Hmm, my goal is to deploy simple CLI apps. Here's an example of one[0] in progress. If someone wants to try this CLI app for Todoist, my goal is that they should be just able to download it and run.

> Linking dynamically with libc will never be an issue on illumos- or any real > UNIX-based operating system because libc includes all previous interface > versions and can therefore guarantee that it is backward compatible.

Do you know if I to use illumos/OmniOS/SmartOS (this is the first time I am hearing about these) on Travis CI? And how?

> Long story short: develop and build your software on an illumos-based > operating system like OmniOS or SmartOS and dynamically link only with libc > and you won't have to worry about static linking for convenience delivery: > link on the oldest version of SmartOS and sleep well at night knowing your > application will work on the latest nightly build.

Thanks! If I can do this on Travis CI (or any other auto-deployment solution via GitHub or even Gitlab), I am willing to give that a try. I am open to suggestions and pointers on how to do that.

> As an added bonus, your binary will be smaller and

+1

> the runtime linker will only mmap(2) the required code pages out of libc > into memory.

That part, I did not understand :)

[0]: [https://github.com/kaushalmodi/ntodo](https://github.com/kaushalmodi/ntodo)

<comment><USER2> You're welcome.

"Wouldn't the same apply to the whole binary itself even if it is dynamically linked?"

No, because if the bug is in the library, under the presumption that the library is backward compatible, all that needs to happen is for a new version of the library to be installed on the system and replace the old one. Next time the application is run, the runtime linker (ld.so.1) will link the new, fixed code of the library and one's application into memory pages on the fly. Therefore, no recompilation of the binary itself will be required. That's the reason why shared object libraries and dynamic linking was invented.

The situation is quite different if the bug (or a feature) needs to be made in the binary: then one must re-compile and re-link the binary, but the shared object library can stay the same, and the code calling it from the binary doesn't have to change.

"Wouldn't the overhead to fix+recompile the statically linked binary be the same as that for dynamically linked?"

The time itself would be the same for the binary, but if the problem is in the library, things would change dramatically: one would have to fix every binary which was ever statically linked to that library, not just yours, versus just fixing the library, in which scenario the binaries would not have to change, the idea being that all binaries on the system linked to that library do not have to be modified.

"If someone wants to try this CLI app for Todoist, my goal is that they should be just able to download it and run."

Yeah, but the problem is your substrate, the OS you are building on: since GNU/Linux is just the kernel, and the userland (libc) is delivered by someone completely unrelated, there are many, many different operating systems based on that GNU/Linux kernel. They all have various versions of binaries, libraries, and even libc from different projects (some have GNU libc, some musl, ...) The correct thing to do would be to build a dynamically linked version of your binary for every GNU/Linux-based OS you want to support, but it's certainly understandable why that's impractical (infamous Linux OS fragmentation).

On the BSD's, illumos-based, and traditional UNIX operating systems, libc and the userland always come as one coherent whole, so the above concern of having a libc delivered from someone unrelated does not exist.

"Do you know if I to use illumos/OmniOS/SmartOS (this is the first time I am hearing about these) on Travis CI? And how?"

Travis CI is just a piece of software which kicks off a nightly build (fancy name: "continuous integration software"). Travis can run on pretty much any operating system, but I seriously doubt "Github" is that advanced as to run SmartOS. They probably pander to what they know and what's popular, and that's the GNU/Linux hegemony.

You could probably run Travis on SmartOS, but you'd have to do this on your own server(s): Travis people themselves punted:

"Closing this issue for now, as we have no immediate plans to add this feature.

Should we add it to the roadmap eventually, we'll make sure to update this ticket."

[https://github.com/travis-ci/travis- ci/issues/1368](https://github.com/travis-ci/travis-ci/issues/1368)

"That part, I did not understand :)"

[http://illumos.org/man/1/ld.so.1](http://illumos.org/man/1/ld.so.1)

[http://illumos.org/man/2/mmap](http://illumos.org/man/2/mmap)</comment></comment></comment>


Go 1.1 RC2 is out - <AUTHOR> https://groups.google.com/forum/#!msg/golang-nuts/PoQGGq-V2l8/8e6y9zBylE0J <comment><USER2> I have been learning go for the past 4 weeks now and love it. Does anyone have any advice on a good GUI library that works well with Go? I have had a look at some of the Qt bindings but they are not that great sadly.

Also is there a decent MSSQL library for Go yet?

<comment><USER3> _Also is there a decent MSSQL library for Go yet?_

You will find some here:

<http://godoc.org/?q=mysql>

<http://go-lang.cat-v.org/pure-go-libs>

EDIT: I just realized that you asked for MSSQL libs and not MySQL. Sorry, those links wont help you.

<comment><USER2> No worries. I have had a pretty good look but have not found anything for MSSQL sadly. There are some bindings for Qt and some custom widget kits but nothing that great sadly. I would love proper Qt bindings but that will take a while.

<comment><USER4> I use this one for MSSQL through ODBC: <https://github.com/LukeMauldin/lodbc>

</comment></comment></comment></comment><comment><USER5> I love how they update every few weeks :) I'm looking forward to each new version like a kid in a candy store.

<comment><USER6> I doubt they will change much after 1.1, given the designers' philosophy in language design.

<comment><USER7> That's my favorite feature. They still may make significant changes that don't effect syntax.

<comment><USER6> That is what made me disregard Go, after my initial interest on the language, but then again I am a CS guy that feels at home with FP and similar stuff.

Nowadays I rather play with D and Rust, but I wish success to the Go team anyway, as choice is always good.

</comment></comment></comment></comment><comment><USER8> What are some common gotchas I should be wary of if I want to try out Go? I haven't touched the language since I first heard about it, due to an issue that has been left unfixed for almost three years.

<https://code.google.com/p/go/issues/detail?id=909>

Here is a C# example of what I'm looking for:

LINQ brings brevity and clarity to complicated collection operations. However, if you rely on it in performance-critical applications, then you will find that it causes enough garbage collection overhead to slow your app to a crawl.

<comment><USER9> From what I know on the topic issue #909 only ever had a realistic chance of affecting 32-bit users. And from the looks of it, they've made the GC in Go 1.1 more precise, so hopefully the incidence of those problems on 32 bit goes down even more.

I use Go exclusively on 64 bit and have never had that problem. This includes Go programs that use 64GB+ of memory that can run for days. I also use other long running Go programs (a web site and an X window manager) and haven't run into problems.

> What are some common gotchas I should be wary of if I want to try out Go?

The most common complaint people have is that Go doesn't have "generics" like that found in most other statically typed languages (e.g., parametric polymorphism or ad-hoc polymorphism). You can still get a lot of code reuse through Go's flavor of polymorphism (structural sub-typing), but it requires a little brain rewiring---and that puts some folks off.

</comment></comment><comment><USER10> Is there a list of changes since Go 1.1 RC1? Just curious what held up the release.

<comment><USER11> <http://tip.golang.org/doc/go1.1>

<comment><USER12> That's not what he asked for. I'm too curious about the changes since RC1.

</comment></comment></comment><comment><USER13> There is no new features here, it's just issues being fixed and closed, mostly weird and harcore ones.

<comment><USER14> Which is typical for RC releases, feature freeze and bugfixing.</comment></comment>


React HTML5 Drag and Drop Mixin Examples - <AUTHOR> http://gaearon.github.io/react-dnd/#/dustbin-interesting

<comment><USER2> Good work! If you are able to add touch screen support as well it would be even cooler! ;-)

<comment><AUTHOR> Yeah.. My intention is to make backends separable, so you could use HTML5 -or- touchmove-based one.</comment></comment>


Nick Bostrom: one of the first to theorize the simulation theory - <AUTHOR> http://www.simulation-argument.com/simulation.html <comment><USER2> It really pisses me off when people are entirely ignorant of history. Come on, guys; the simulation theory was cliche by the early 1960s. In 1999, there were two hit movies about it, one of which was a direct adaptation of a book from the 1950s that had already had three other popular film adaptations. During the 1960s, PKD alone wrote five or six separate books about it, and in 1977, he gave a pretty well-known lecture that set forth a number of arguments accepted later by Bostrom. By that point, it had already been the plot of two different Doctor Who serials.

Stop saying somebody is the first to do something, unless you've actually done the research.</comment>


Will Shortz: A Lifelong Crossword Puzzle Master - <AUTHOR> https://www.nytimes.com/2017/08/01/insider/will-shortz-a-profile-of-a-lifelong-puzzle-master.html <comment><USER2> Showing my age here, but I was a huge fan of Will Shortz long before the NYT crossword due his involvement with Games magazine in the 80s. I expect there are other Games fans here. In the age before the internet it was a huge part of my entertainment cycle each month.

Love the guy, he's a national treasure.

<comment><USER3> Games Magazine was amazing in its early years. Puzzles often were interlinked, and ranged in complexity so that an 8 year old could be completely absorbed and so could a life long puzzle solving grandparent.

I loved discovering the hidden puzzle contests

</comment></comment><comment><USER4> I'd swap the word 'Puzzle' for 'Crossword' in the title. I thought the article would be about someone like Martin Gardner or other puzzle designer.

<comment><AUTHOR> Duly noted. To accommodate non-native English speakers, I kept 'puzzle.'

</comment></comment><comment><USER5> He's also a very good table tennis player: [https://news.ycombinator.com/item?id=14946868](https://news.ycombinator.com/item?id=14946868)</comment>


Ask HN: Snapchat, the harbringer of the bubble? - <AUTHOR>

From their App description: "Snap a photo or a video, add a caption, and send it to a friend (or maybe a few). They'll view it, laugh, and then the snap disappears from the screen - unless your friend takes a screenshot!"<p>So default functionality can essentially invalidate their entire angle in the texting game. The only way this has an 800M valuation is if it is acquired, which is pure speculation. This isn't even vaporware its bluffware. <comment><USER2> I agree that there is a huge market for this functionality. But it seems less like a business and more just a feature of the phone or something that should exist by default.

</comment><comment><USER3> How many users does it have?

</comment><comment><USER4> It will actually tell you if your friend takes a screenshot.

I'm not sure why you think it's bluffware, they've obviously identified a major market for transient internet communications.

Yes, the tech's not perfect yet, but they've hit a nerve and have a lot of users.</comment>


MaidSafe: The Ants are coming - <AUTHOR> http://blog.maidsafe.net/2015/07/01/the-ants-are-coming/

<comment><USER2> The word "ants" only appears in the title of this article....</comment>


Robinhood Will Retool Checking Product Following Scrutiny - <AUTHOR> https://www.bloomberg.com/news/articles/2018-12-15/robinhood-will-retool-checking-product-following-scrutiny <comment><USER2> Kind of funny, in light of the people saying _of course_ it was fine, and it was the SIPC head who didn't know what he was talking about, and must be out of the loop on the details.

</comment><comment><USER3> Who at Robinhood gave the greenlight for a new financial product that's clearly in a regulatory grey area and _didn 't_ think to discuss it with regulators OR insurers first? Mind boggling.</comment>


Please Stop Quoting Your Product's Price - <AUTHOR> http://joabla.com/2011/07/21/please-stop-quoting-your-products-price/

<comment><USER2> I'm not sure what kind of parallel universe this guy is living in. If somebody wouldn't quote me a price for something but would only say 'you'll make it back in 2 months!' (without making any guarantees or sharing any of the risk), I'd laugh him out of the room.

You know who uses this same tactic? Multi-level marketing and condo-sharing organizations. 'Don't worry about going 5 times your yearly salary into debt! You'll make it back, _guaranteed_! [^]'

[^] Some restrictions may apply. Past performance does not guarantee future results. Void where prohibited.

<comment><USER3> Agree 100%. You tell me what your service is and how much it costs. Leave the projections about _my_ business to me.

</comment></comment><comment><USER4> One of the things I hate about B2B marketing is vendors that won't quote a price in public.

It's how I qualify vendors. No price on the web site, no call to a salesperson. Period, you lost the sale.

<comment><USER5> When I don't see a price where there should be a price, I call it "price too obscene for the internet" - though usually it's in the context of end user goods advertised with "Call now for special pricing!".

</comment></comment><comment><USER6> Unless you are working on a profit-share type deal where you are going to do the work at a cut-rate price and share in the profits later, most clients in my experience want to know what something is going to cost as early as possible (even it it's just a guesstimate).

You can work as much as you like on a proposal and it can, on paper, be the greatest thing ever and promise to increase profits by whatever-percentage but if it's something that is going to be out of reach of the immediate budget of the client, then you're wasting your own (and their) time.

I have been involved in multi-million £ proposals and when it got to the end it turns out the client was expecting something for 50k. Would have been much easier to lay the cards on the table earlier in the process.

<comment><USER7> @bitdiffusion Thanks for the real world reply. The only decision maker able to just work on an ROI number is the CEO and even then I'm not sure. Budgets rule. And I have worked for both Fortune 3 and 3-person startups. ROI is important but more important is the cost of entry.

</comment></comment><comment><USER8> _As a customer, it is of very limited use for me to know that your product's price is 100K._

That's true in business school cases but few other places. Budgets matter whether they are 10K or 10KKK.

</comment><comment><USER9> Please stop trying to obfuscate your product's pricing. I won't buy from you unless you give me clear pricing. If I can't work out for myself how much money it will save/make me, that's the fault of your supporting marketing materials.

</comment><comment><USER10> This applies almost exclusively to B2B markets with high price points. Even then, the quoted price makes a big difference.

If I'm spending money, I care more about my cash outlay than about the optimistic estimates of someone who a) believes in their product, and b) doesn't know my business. But moreover, lots of products have no measurable ROI: it's a little amusing to imagine a grocery store using this kind of pricing.

I guess the best way to illustrate this is to note that I can get the author a 200% ROI by editing and perhaps rewriting this blog post. All he has to do is send me a blank check and I'll get started.

</comment><comment><USER11> Agreed with all the posts here so far - I would only add that if you're selling to a larger organization, you'll likely go through some sort of vendor qualification by a centralized group - and it is unlikely that you'd ever get by without quoting a price.

The author also seems to forget that most companies have budgets for software - so you might be quoting a great ROI, but if the price is outside of my budget, it's a no-go.

An ROI analysis, at the end of the day, is a good add-on to a proposal in my opinion, but can't replace a pricing schedule.

</comment><comment><AUTHOR> I agree with previous comments. In fact, you can't calculate an ROI without the product's pricing schedule. A pricing schedule is always part of a proposal. My point is not _just_ to quote a price – as the startup mentioned did. Always place it in the context of an ROI-calculation. Start pitching the ROI. Explain the outcome with your assumptions about additional revenue and your product's price.

</comment><comment><USER12> If you quote someone for a project, and never specify that you're going to want approximate $X, wouldn't that mean you're quoting 'free'?</comment>


Comedy Theory - <AUTHOR> https://medium.com/@rayalez/comedy-theory-fd142076657e <comment><AUTHOR> I am trying to understand how comedy works, and this is my first attempt to express the ideas I have about it.

I'm not a neuroscientist, and I'm sure everything is much more complicated, and my theory can be totally incomplete and mistaken, but I think it has some useful epiphanies that explain a lot of things.

I am still working on it and trying to figure it out, and now I'm looking for some feedback/ideas, I really want to talk to some smart people about the subject.

Please let me know what you think. Any criticism/questions that you have, anything that is unclear or can be better explained, any thoughts/ideas would be very valuable to me!</comment>


Battleship AI Algorithm - <AUTHOR> http://www.datagenetics.com/blog/december32011/index.html

<comment><USER2> Cool algorithm! One problem is that its probability density calculation assumes a random ship placement. If the opponent were aware of how the algorithm works (let's say they deduced it from its behavior, which seems plausible) then they could devise a counter-strategy of placing ships on the squares which have the fewest other possible ship placements (e.g. in the beginning of the game, this is along the edges of the board).

</comment><comment><USER3> Is your battleship code publicly available?</comment>


Forget in a Flash: A Further Investigation of the Photo-Taking-Impairment Effect - <AUTHOR> https://www.sciencedirect.com/science/article/pii/S2211368117301687 <comment><USER2> I am shocked by this as I find myself mostly able to remember the moments when I took a photo... like, I went to a wedding last week, and I have a really strong memory of most of the photos I took _even though I have not yet looked at any of them_. I would have assumed the process of paying careful attention to a scene with the goal of capturing "the perfect moment" makes that moment itself special and unique, not just from your analysis and critique but also simply from how it forces that moment to be separate from the continuous stream of time over which your interest would previously had have to have been spread.

<comment><USER3> > _the process of paying careful attention to a scene_

I think you've hit on the main thing here that (in a sense) differentiates you from the "normal photographer". Honestly, a lot of people just "point and shoot", in the article's "save an ephemeral memory" sense. You're taking the time to make a careful composition (and artistic composition is not something most people study). Your "capturing 'the perfect moment'" and "analysis and critique" are just not something a lot of friends and family do on vacations.

Not that there's anything wrong with any of that! But I think that's probably the difference here.

<comment><USER4> Agreed. Personally, I take photos daily - but a big portion of them is to capture something I don't have time to write down or a capacity to remember. Those could be adds in newspapers, clothing in some store etc.

</comment></comment></comment><comment><USER5> On the other hand, photos reviewed 2-3 times (especially after few months/years) become much more durable memories than those simply observed directly. I tend to only remember things I have photographed in the last 20 years, that is why I take photos of things I want to make sure I will remember. A photo can revive a whole lot of extra memories associated to the moment.

<comment><USER6> I think the best approach is to only take a few photos of an event. Just enough to be memory triggers.

Increasingly, we see people spending more time worried about photos than just enjoying the thing they are photographing.

For events that do need more "documenting", then you should have a designated photographer (professional or not) that way the rest of the attendees can just enjoy it.

<comment><USER7> Do whatever you enjoy. If you like taking photos and want to spend your time doing it good for you.

[https://xkcd.com/1314/](https://xkcd.com/1314/)

</comment></comment></comment><comment><USER8> Hm, this reminded me of the "A placebo can work even when you know it's a placebo" case: [https://www.health.harvard.edu/blog/placebo-can-work-even- kn...](https://www.health.harvard.edu/blog/placebo-can-work-even-know- placebo-201607079926)

We take a pill that we know will do nothing, and our body reacts anyway

We take a picture that we know will do nothing, and our body reacts anyway

What I see here is that our ""logic"" gives no feedback to the ""subconscious"" mechanisms that get formed, such as : "I take a pill, I get better", "I take a picture, I will see this again"

</comment><comment><USER9> What's most interesting to me is that the conclusion seems to be that their hypothesis wasn't quite right, and that offloading isn't quite what's happening here:

        These results suggest that offloading may not be
        the sole, or even primary, mechanism for the photo-
        taking-impairment effect.

I'm taking the time to comment on this because other comments seem to ignore this interesting turn of event.

<comment><USER10> At a more meta-level, they basically failed to replicate their own paper (they disproved the main hypothesis).

Which shows exactly what the big problem is: you just throw some ideas out, do some statistical analysis, and presto, you are "a scientist discovered a new thing"

<comment><USER11> This is a big success. We need more scientists willing to publish dead ends and ideas that turn out to be wrong. At the very least it hints at future areas of research. A lot of great science involves testing common sense and finding it's wrong.

They could have hacked their way to a positive result, good on them for not.

<comment><USER12> As a molecular biologist whose been in the field for nearly a quarter of a century (ouch, I'm old), I can't tell you how important your comment is. Too many times I've been to conferences where a small group of researchers is informally discussing a common roadblock in a procedure or technique and one in the group says, "We found out months ago that you can't use compound Y because it inhibits X downstream". For the love of all that is good, why didn't you publish that?! You could have saved countless combined hours and materials for other labs and increased the rate of progress. We all know the answer: Reviewers and editors want to publish flashy new discoveries, not fizzled experiments. Online discussions and open access has helped the issue, but the underlying pressure on scientists to publish only positive findings and leave out the critical trial-and-error data must end as it is is essentially fudging research and does a disservice to other researchers and science as a whole, intended or not. Whew, that was cathartic. I'll fade back into the shadows now.

<comment><USER13> I'd like to take the effort to thank you for staying true to the pursuit of real science and trying to demand that others meet the standards. A well- tested negative result is not a failed experiment, it is one less option to pursue.

As I've been known to tell junior engineers that ask how to become expert in some field, "the easiest way is to fail in every possible way without repeating yourself. Whatever is left is correct. Note that I didn't say that's the fastest way." Gaining new knowledge is always a combination of discovering both dead ends and possible successful paths.

</comment></comment></comment></comment></comment><comment><USER14> This might be similar to the "write it down so you can stop thinking about it" effect. I often have an idea, e.g. for a blog post, that I just can't seem to get rid of. My mind just keeps turning it over and over. Then I write a draft, and _poof_ I stop thinking about it. The fact that I usually don't finish turning the draft into a real post is a separate problem. ;)

There really is something about "offloading" those thoughts into some external place, and I really don't see why the authors even think it's relevant if it's subsequently deleted. The damage has already been done, the thing already partly forgotten, the instant the picture is taken. Did it ever seem likely that we'd have to check back multiple times to see whether a memory was stored elsewhere before forgetting it? Certainly when I've forgotten stuff that's never how it has been. Once is enough.

<comment><USER15> That's one of the key things I learned when I read the Getting Things Done book. If I'm stressing out about the number of different tasks I need to get done, capturing them (whether writing them down, putting them in Trello, etc.) helps me to not dwell on them, allowing me to more easily focus on a single task.

</comment></comment><comment><USER16> I wonder if you'd get different results with analog photography.

I'm really into film photography and I find I remember the motives I'm shooting quite well. Maybe that's because with film you're more deliberate in what you shoot and due to the sense of anticipation to seeing the final result.

<comment><USER17> The study tested people who would lose access to the photos immediately or delete them intentionally, and they still succumbed to the effect... so I'd expect it would be similar for analog.

I think the the more important distinction you mentioned is that photographers who are a bit beyond amateur are more likely to analyze what they're shooting, and therefore remember it.

<comment><USER18> They have still seen them after taking, which is what might actually be a trigger for the discussed offloading effect.

</comment></comment></comment><comment><USER18> How about seeing the photo itself? I'd be interested in testing situations where you take a photo but don't see it even once, not even the preview after taking it (for instance, using an analog camera). As I understand it, both situations tested here forced you to see the taken photo, which may actually be the trigger for the effect, not the photo taking action itself.

</comment><comment><USER19> This study is confounded and made unnecessarily complicated by using Snapchat. The experimental design should have been to instruct participants that during two (of the three) sessions they will be required to take a photo of each painting using the native camera app; and photos from one of the sessions will be available for reference during the test.

</comment><comment><USER20> I think there's a lot of information we take in about our surroundings (sounds, smell, peripheral vision, motion, etc) that all gets shoved in to a 'memory'. When we are focused on taking pictures, we block that stuff out - either physically (peripheral vision) or mentally (sound, smells).

</comment><comment><USER21> Obviously if I'm operating recording equipment I'm less receptive to my surroundings. That's all they found. I don't see how this should be called "offloading". I'd call it "overloading".

</comment><comment><USER22> Does Google Glass continuously wipe your memory?

</comment><comment><USER23> I had this problem with digital photography and was scared SHITLESS. Glad this is a known effect.</comment>


Operation reWired: 281 suspected email scammers arrested around the world - <AUTHOR> https://www.grahamcluley.com/operation-rewired-281-suspected-email-scammers-arrested-around-the-world/ <comment><AUTHOR> Fun fact: The Nigerian prince was really from Nigeria.

</comment><comment><USER2> nice, but the nigerian prince free money hydra email can never be stopped</comment>


Ten things we know to be true - <AUTHOR> https://www.google.com/intl/en/about/company/philosophy/ <comment><USER2> 11\. Don't be evil but if you can't define evil then pretend you never raised the question, now that your company is worth billions of dollars.</comment>


Basecamp's cofounder explains why it ditched Google Cloud for Amazon this summer - <AUTHOR> https://www.businessinsider.com/basecamp-google-cloud-amazon-aws-2019-8 <comment><USER2> Sound Interesting, but its behind a paywall

<comment><USER3> I managed to read it by hitting stop after the text appeared and switching to reader mode (Firefox Android.)

Basically, Google Storage failed at least three times and they didn't have absolutely any way to get to their files. They are setting up manual access from multiple zones in AWS. They say it takes a lot of work but at least they can access the files from another zone of one fails. With Google it's all or nothing.

<comment><USER2> I found a copy in another website.

[https://trulytimes.com/basecamps-cofounder-explains-why- it-d...](https://trulytimes.com/basecamps-cofounder-explains-why-it-ditched- google-cloud-for-amazon-this-summer-amzn-goog-googl.html)</comment></comment></comment>


Show HN: Bypass HTML with native Markdown rendering on Android and iOS - <AUTHOR> http://uncodin.github.com/bypass/

<comment><USER2> On iOS, there's also AttributedMarkdown[1] for parsing markdown into NSAttributedStrings.

[1]: <https://github.com/dreamwieber/AttributedMarkdown.git>

</comment><comment><USER3> Interesting project. However, I wonder if the developer has considered accessibility for blind users. Both Android and iOS have built-in accessibility, but whenever an application takes text rendering into its own hands, accessibility for that text becomes the responsibility of the application. I don't know what actual performance requirements led to the development of Bypass, but to me, the extra work required to regain accessibility would probably not be worth the performance boost in this case.

<comment><USER4> Accessibility is maintained, Bypass doesn't do any of the text rendering, it simply figures out the styles and text and then passes that on to the text containers on each platform.

<comment><USER3> Bypass may be accessible to blind users on Android; I'm not currently set up to verify this easily. But it's not on iOS.

The reason is that on iOS, Bypass implements its own UIKit views. It does use the CoreText framework to render the text into a CoreGraphics context, but that doesn't help accessibility. The views would need to implement the UIAccessibility protocol.

<comment><USER5> Thanks for your feedback. I have entered an issue so that this problem can be addressed.

</comment></comment></comment></comment><comment><USER6> Very interesting, I've got a project this might be very useful in. Bookmarked.

<comment><USER7> Checkout the benchmarks to see how much faster it is than other solutions :D

[https://github.com/Uncodin/bypass/tree/master/platform/andro...](https://github.com/Uncodin/bypass/tree/master/platform/android)

<https://github.com/Uncodin/bypass/tree/master/platform/ios></comment></comment>


Stripe – Outage postmortem - <AUTHOR> https://support.stripe.com/questions/outage-postmortem-2015-10-08-utc <comment><USER2> Hi, I work in infrastructure at Stripe and I'm happy to provide more insight. Several threads here have commented on our tooling and processes around index changes. I can give a bit more detail about how that works.

We have a library that allows us to describe expected schemas and expected indexes in application code. When application developers add or remove expected indexes in application code, an automated task turns these into alerts to database operators to run pre-defined tools that handle index operations.

In this situation, an application developer didn't add a new index description or remove an index description, but rather modified an existing index description. Our automated tooling erroneously handled this particular change and interpreted it not as a single intention but instead encoded it as two separate operations (an addition and a removal).

Developers describe indices directly in the relevant application/model code to ensure we always have the right indices available -- and in part to help avoid situations like this. In addition, the tooling for adding and removing indexes in production is restricted to a smaller set of people, both for security and to provide an additional layer of review (also to help prevent situations like this). Unfortunately, because of the bug above, the intent was not accurately communicated. The operator saw two operations, not obviously linked to each other, among several other alerts, and, well, the result followed.

There are some pretty obvious areas for tooling and process improvements here. We've been investigating them over the last few days. For non-urgent remediations, we have a custom of waiting at least a week after an incident before conducting a full postmortem and determining remediations. This gives us time to cool down after an incident and think clearly about our remediations for the long-term. We'll be having these in-depth discussions, and making decisions about the future of our tooling and processes, over the next week.

<comment><USER3> hi jorge

I'd actually applied to work at stripe about two years ago, you guys turned me down ;)

I was responsible for ops at a billion-device-scale mobile analytics company for about 1.5 years. Your tooling is far superior to anything we produced. I like the idea of a single source of truth describing the data model (code, tables, query patterns, etc.) a lot, and doubly-so that it's revision- controlled and available right alongside the code.

I think it's far from decided though, how much to involve human operators in processes like this. Judging from this answer, you seem to be on the extreme end of "automate everything". How then, I'm curious, do you train/communicate to developers what can be done safely vs. something that would cause i/o bottlenecks, slowdown, or other potentially production-impacting effects? Can you even predict these things accurately in advance? (Some of our worst outages were caused by emergent phenomena that only manifested at production scale, such as hitting packet throughput and network bandwidth limits on memcached -- totally unforseeable in a code-only test environment).

It sounds like you let developers request changes (a la "The Phoenix Project") but ops is responsible for final approval of the change? That actually sounds like a great system. Would love some elaboration on this.

In any case, great writeup and from one guy who's been there when the pager goes off to another, sounds like the recovery went pretty smoothly.

<comment><USER4> Shouldn't developers understand how a database change is going to impact an environment based on the code they've written?

<comment><USER5> Yes they very much should! But in my, admittedly anecdotal, experience only the best / most senior ever do. Almost every junior or mid developer I've worked with (and a small handful of senior folks) not only have no idea how changes like this would impact the larger environment but many won't even care to look into it.

<comment><USER6> In part though that's because the tooling to do it easily absolutely _sucks_ , the impedance mismatch (overused but in context here) between the two parts of the system causes a lot of the underlying issues, better tooling is a large part of the solution I think but I've not seen anything that would help and the surface area of a modern RDBMS is so large without even getting into vendor specific stuff I'm not sure what that would even look like.

<comment><USER5> That's certain a great point! If there was a way to automatically test much of this I bet even the newest of engineers could stop this. Doing that is tough, hmm...

<comment><USER6> I think the only way you could do it on top of a RDBMS is to use a strict subset of features that are common (something that many ORM's already do) which reduce the problem scope down to something manageable, the issue then would be that there would always be the temptation to use something outside that subset and forgo the easier testing, fast forward and you have the same issue.

It would be interesting to build a RDBMS that enforced that subset by simply not allowing those features to be used/abused with support for many of the modern features (JSONB etc) but that is _way_ beyond my area of expertise.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> What's so striking about this is that entire retail chains can be shut down by a problem in some cloud server. Starbucks had a server outage in April which caused stores to close.[1]

There's a trend towards "hosted POS", where point of sale systems have to talk to the "cloud" to do anything, even handle cash. Until recently, most POS systems were running off a server in the manager's office, which communicated to servers and credit card systems elsewhere. A network outage didn't affect cash transactions. Often, the systems could even process a credit card transaction without external help, giving up real-time validation but still logging the transaction for later processing.

There's a single point of failure being designed into retail here.

[1] [http://www.usatoday.com/story/tech/2015/04/24/starbucks- poin...](http://www.usatoday.com/story/tech/2015/04/24/starbucks-point-of- sale-cash-registers-down/26338505/)

<comment><USER8> When Blue Bottle Coffee switches to Square there was a noticeable decline in the throughput at the cash register. It just takes the retail employee longer to do anything on an iPad. Pretty much everything can be done faster on a real cash register. There have also been the requisite outages, of course. Recently I was at Blue Bottle and the Square terminal wasn't opening the cash drawer. They were making change out of the tip jar :-/

<comment><USER7> There's something that a lot of retailers don't get - never put an obstacle in front of the customer giving you their money. Don't let lines form at checkouts. Don't clog up the counter with impulse-purchase stuff. Don't put displays in the path of customers headed for checkout. Don't make customers jump through hoops with loyalty cards and data entry. Don't do anything that slows the checkout process.

There are expensive retail consultants who clean up stores and improve sales by doing this.

Gap gets this right. Gap stores have big, clear counters, so you can bring up lots of merchandise and have a place to put it. This increases sales per customer. Gap is amazingly successful despite a rather blah product line.

<comment><USER9> On the other hand, having a line out the door seems to sometimes be good marketing.

<comment><USER7> No. That went out decades ago. The Syufy chain of theaters (later Century) used to try to create lines by not opening up enough ticket windows. Then came video rental. Then came half-empty theaters.

Retailers no longer have the power to make customers wait. Consumers have too many other buying options.

<comment><USER10> Wrong. Clearly you've never lived in NYC, where people apparently use lines as a proxy for how good something is. Lots of other big cities too.

Also, box office revenue hasn't collapsed or anything, so I'm not sure what you mean with your example. In fact, come to think of it, I see people lining up for things multiple times every year at the theaters I frequent.

<comment><USER11> When I see those long lines in front of [insert trendy food item] stores I think, "I'll have to try that one day when there's no lineup" but when that day actually comes, I've already forgotten about the place. Some of us do gauge popularity by lineups, but we also can't personally be bothered to stand in line.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> This is one of the best incident reports I think I've ever read, detailed, honest and without recrimination.

I'm reminded of something I read in a book a while back about aviation disasters "It's not the first problem that kills you, it's the second".

In this post the described system for change management is at least as good as any I've seen in production and yet a series of small problems got out of hand quickly.

<comment><USER12> Totally agree. Came here to say pretty much the same thing. On a related note, highly recommend the Checklist manifesto (book) for devops.

<comment><USER13> [http://amzn.com/B0030V0PEW](http://amzn.com/B0030V0PEW)

</comment></comment></comment><comment><USER14> I appreciate the post-mortem and, of course, we've all been there. I have to say, though, that the cause is a little surprising. That DDL needs to be executed sequentially is pretty basic and known by, I'm sure, everyone in the engineering and operations organizations at Stipe. It surprises me that an engineering group that is obviously so clever and competent would come up with a process that lost track of the required execution order of two pieces of DDL. If process (like architecture) reflects organization, what does this mean about the organization that came up with this process? It's not a sloppy exactly. Is it overly-specialized? It reminds me of that despair.com poster "Meetings: none of us is as dumb as all of us" in that a process was invented that makes the group function below the competence level of any given member of the group.

<comment><USER15> I was thinking the same thing.

If nothing else, I don't understand the role of "database operator" if they'll just blindly delete a critical index without thinking about it. Shouldn't that person have known better than anybody how critical the index was?

<comment><USER16> There is an open secret you may not be aware of: every startup is a shitshow on the inside.

<comment><USER17> Also top 20 financial institutions, USG orgs and places that store your healthcare and tax information ;-) I'd argue that a good number of startups these days (especially ones borne out of larger organizations with lots of combined experience) are way more capable of handling these issues with finesse and speed.

</comment></comment></comment></comment><comment><USER18> Nicely done. Good job avoiding retrospectively blaming people and instead focusing on future system improvements.

(For those wondering why this is important, Sidney Dekker's "Field Guide to Understanding Human Error" is a mindblowing book.)

<comment><USER19> Agreed. It looks like this was caused not because the application developer or DBA caused an error, but because the system didn't allow for ticket dependencies.

<comment><USER18> Definitely. But it would have been very easy to yell at the developer ("you should have known not to do it that way") or the DBA ("why are you doing tickets out of order? you know we have to do deletes last!").

Especially after a dramatic event, those are very easy reactions to have, and they can sound very sensible.

</comment></comment></comment><comment><USER20> For schema/index changes I prefer migrations. These should be committed along side the code, tested, and promoted through environments. This largely prevents dependency issues because the migrations are ordered.

Devops is like 80% dependency management. It's painful initially but you have to crack down on manual changes to production - all production changes should be defined in code, committed to git, tested, and flow through non-prod environments first. (just had an outage yesterday that was essentially because I failed to do this)

<comment><USER21> Do people even test for perf issues in non-prod environments?

<comment><USER4> I've found it to be extremely difficult to replicate production workloads in staging/development.

</comment></comment></comment><comment><USER22> >> the database operator didn't have a way to check whether the index had recently been used for a query.

Appreciate the disclosure. Stripe engineers have been so helpful to me and my business. Keep up the good work.

</comment><comment><USER23> What is the point of having a human "database operator" who carries out simple tasks like deleting an index when it shows up in a work request log? Is this how most companies structure their dev teams?

If you have a human there to perform tasks, then it would seem natural to allow them "human advantages" such as the ability to communicate with the person who created the request, or the ability to have some of their own checks and balances before performing the index deletion (ex. let's take a look and see if this seems safe based on the current schema and codebase).

I am also surprised how easy it was for a single dev to make a request that subsequently results in the modification of a production database.

<comment><USER8> Indeed, what is the point? If they have some separation of concerns between dev and ops then it also makes sense to give ops some separate rights and responsibilities, such as vetting a change like this by analyzing the resulting query plans from a sample of production database queries. I'm sure something like that will be in their internal postmortem action items under "prevention".

</comment></comment><comment><USER24> > At 00:08 UTC, our on-call engineer had been paged and had responded. At > 00:10 UTC, we linked the API degradation to the removal of the index.

I'm sure stripe has very good metrics of all their systems, nonetheless that's some rockstar level debugging skills.

<comment><USER25> We had a utility I wrote at one of the places I worked where you ran it against the database and it showed you all of the query plans running. It was easy with 15 seconds to see some non-indexed query and what was executing it. We used to run it after new version deployments to see if we had query problems. Tooling is very important.

<comment><USER26> As a stopgap solution, enabling the slow query log can also be very helpful.

<comment><USER25> Yep. A lot of databases have some form of system tables that can tell you a lot about a running system with just some queries. I know Sybase and MS SQL server have the tables to find all the current queries and what they are doing. Ingress had a neat graph (seeing FSM should illicit a panic in most DBAs) and a log monitor. Read up on what is part of the database and write some tools.

</comment></comment></comment></comment><comment><USER27> Good post mortem, just some thoughts, would love to hear what others think.

Shouldn't the app developers be in charge of deploying their code and making sure its working? It seems odd that they pass off a migration like this to a DBA to then go deploy randomly, or that they weren't around when it was happening to monitor it.

Also, it seems like there should have been a script that can be run that encapsulates the required dependencies, namely, don't drop an index before building the new one maybe? This should at least minimize the amount of context needed in a ticket.

Relying on fully correct context in tickets seems like it could be super error prone.

</comment><comment><USER26> It's a vicious circle: an index is missing, so requests take longer, so more DB queries run at the same time, the load on the DB server shoots through the roof.

And then it needs to rebuild an index on top of the already above-average load.

</comment><comment><USER28> Why would someone delete a existing index without recreating it first? This is common sense for a DBA but not for our full stack engineers who have to know everything about everything g.

</comment><comment><USER29> People seem to be focusing on the fact that the two operations should have been linked, but I think they actually should have been further separated. The old index presumably could have been left around for days, at the cost of some performance, and only deleted once they were sure that the new index was successfully being used by all production code.

While splitting these two changes may be silly in the case of a simple index change, I think that it's a good general policy to only deploy the minimal set of changes to a production database at once. On the production system I manage (admittedly, much simpler, and many orders of magnitude smaller), I always deploy changes in two stages, with the second stage generally deployed about a week later, once I'm sure that only new code will be running against the database.

This comment is not meant to second guess the Stripe developers (who produced a great postmortem), but to suggest another possible remediation.

<comment><USER30> I had a similar thought but if it's that critical an index it's entirely possible they couldn't afford the write overhead to keep both copies around.

</comment></comment><comment><USER31> Very interesting.

In a continuous delivery environment like this, you generally want to test and validate any change you make. Do any DBs support the idea of turning off an index (but keep updating it). That way you could disable it, keep going for a while, and then delete it once you're sure it's unused?

<comment><USER32> In MySQL/MariaDB (and presumably other major databases) you can instruct any given query to ignore an index, but it has to be done at the query level. Perhaps the db interaction layer of the application code could be written such that all select queries are built with a variable containing a list of indexes to disable. You could then set that globally (or using dependency injection) and any query using the index would stop using it, without needing to go around and search for uses manually.

</comment></comment><comment><USER33> Great postmortem report. I am very surprised to see that the DB ops simply deleted the index without even considering the consequences. More importantly, why isn't the 2 changes part of a single migration file? For e.g. in Django, south migrations can have both remove, create indexes in one file and executed together. Also, like some of the guys mentioned, why is the update performed to your entire global cluster. Shouldn't it be incremental like for e.g. one availability zone at a time?

</comment><comment><USER34> Would be cool to start the report with a tldr, containing just the essence of the incident, sth like

"dev needed to update index and at time .. submitted two tickets for new ibdex creation and old index removal. at time .. Op processed the removal ticket first which caused outage in service .. It was alerted at time .. and on-call op identified it at time .. He proceeded to ...

Just for people who want to know what's happened but dont care for details.

</comment><comment><USER35> Is it an option for you to maintain a set of tests which simulate behavior on the tables?

I've have great success doing this with datawarehouses (i.e. star schema, large tables with few writes). You run the tests after each index change on acceptance. It caught a errors.

For OLTP it's harder, you need to record some production workload and reply it. At your scale it's easier said than done, though.

<comment> brown9-2 If the change that was introduced required creating a new index, it's unlikely that a test would have though to remove the now-outdated index or testing performance if the create-new/remove-old operations were reversed.

</comment></comment><comment><USER36> Woot, a postmortem from Stripe! I've been asking for these for over a year and hopefully we'll see more from them in the future.

</comment><comment><USER37> "Quick code fixes" almost always make the problem worse and just cause stress and anxiety. It's always better to simply tackle the root cause and fix that.

Unless you're disabling a feature, don't push "quick code fixes". You'll pay for it later.

<comment><USER38> Except this seems to be counter factual? And the quick fixes were just temporary until the index was finished building. Seems like a perfectly fine thing to do to restore service during an outage, as long as they're rolled back or reviewed later.

<comment><USER37> > Seems like a perfectly fine thing to do to restore service during an outage, > as long as they're rolled back or reviewed later.

Rolling back later seems to forgotten in most cases (unless it's disabling a feature). Then you end up with this weird behavior and code path that few remember. "Oh yeah we did that when...." You usually only rediscover it after that quick hack is a problem. This is decades of experience here.

</comment></comment></comment><comment><USER25> So, and engineer can just submit a production change that an database operator will execute? What is the ceremony around this and does Stripe employ DBAs for production. What is the review process for a production change?

<comment><USER39> The change was to add a new index and then remove the old one. It's something that would have passed review.

The cause was a defect in the tooling. The requests weren't tied together in the way they were displayed and so the DBA removed the old index first.

<comment><USER25> That's not a tooling defect, that's a process and personal knowledge of the system defect. No DBA should remove an index without knowing what is replacing it or that code got deployed to make it obsolete. Checking if that index is currently being used would be a minimum. If a DBA cannot stop a deploy you have process problems.

<comment><USER30> The post mortem specifically noted that it looked unused, presumably because the code in master now claimed to depend on the new index.

<comment><USER25> I do not mean by looking at the source code. I mean by looking at the production database that you are about to remove an index from. This is a financial institution, and I am really struggling with this post mortem to understand how they do not have more ceremony around production changes. Checks and balances are important.

</comment></comment></comment></comment></comment><comment><USER40> ohh. Could this mean that a payment may have failed ? I did have a failure of a payment around this time but it said "Card declined". So I hope it really was the card and not related to this incident.

<comment><USER36> Failures caused by this should have returned an api_error, a card_error (like card declined) would have been returned upstream from Stripe.

</comment></comment><comment><USER41> "Outrage postmortem"

</comment><comment><USER42> Sigh, yet another example of hot shot teams using MongoDB just because it's new and sexy. Existing, established tools such as Oracle and Postgres would have offered lots of ways of avoiding such a problem.

<comment><USER43> We detached this subthread from [https://news.ycombinator.com/item?id=10366459](https://news.ycombinator.com/item?id=10366459) and marked it off-topic.

</comment></comment><comment><USER44> They clearly just need to add Devops. That'll fix everything.

<comment><USER44> Wow, message received HN. Don't make fun of Devops! It doesn't seem that long ago that it was hailed as the silver bullet that eliminates the "throw it over the wall" mentality that causes issues exactly like this one.

This issue was caused by a failure in communication between team members. That communication is just as important as good engineering.

<comment><USER45> Your comment was obviously meant as commentary on the DevOps trend, but in fact devops is not so well-defined a trend to make a good target for sniping comments like this. I mean, people talk about "devops" today to mostly just say "we must increase investment in our infrastructure." No one's saying "devops will fix everything." So I don't think people downvoted you for cutting on devops per se, as much as for not presenting any clear POV.

It's not like Node, where evangelists DO go around saying it's the best thing ever and blindly ignore the problems with it. Now... there's a good target for snippy remarks! :-P</comment></comment></comment>


Interactive Online Platform That Visualizes Algorithms from Code - <AUTHOR> https://github.com/algorithm-visualizer/algorithm-visualizer <comment><USER2> Love the idea! I'm finding a bug in Firefox, though. At least on the backtracking examples, when running them, the board section starts expanding vertically until the console and the positions sections completely disappear.

<comment><USER3> Same issue on Firefox 67 on Mac.

Another issue is the left-side list of algorithms isn't scrollable so when you open up a big list like "Brute force" it just cuts off.

</comment></comment><comment><USER4> > for us being coders, nothing can be more comprehensible than visualizing the > actual working code.

This tool is _really_ great, but I don't think it's the panacea that the statement implies. For some people, the visualization may not be as helpful as it seems.

<comment><USER5> The concrete details can crowd out the more abstract details you need to worry about, eg watching a concrete list of number being sorted doesn't directly help someone grock the abstract structure of a sorting algorithm.

<comment><USER6> so, what might be ways to visualize the other structural components of an algorithm such that it brings a better understanding of the approach and modeling of an implementation? I would expect it to be very very hard, but something that would be of great benefit if it can be implemented.</comment></comment></comment>


The Man in the Middle - <AUTHOR> http://www.bbc.co.uk/bradford/content/articles/2006/11/02/m62_farm_feature.shtml <comment><USER2> I think this needs (2008) in the title.</comment>


Rapper Divine Drops A Music Video Tribute To New Friend Ben Horowitz - <AUTHOR> http://techcrunch.com/2014/06/24/rapper-divine-on-his-music-video-tribute-to-new-friend-ben/

<comment><USER2> Oh dear, namespace clashes. [http://www.youtube.com/watch?v=pd2Gzkkwe9Q&feature=kp](http://www.youtube.com/watch?v=pd2Gzkkwe9Q&feature=kp)

<comment><USER3> baha, I fell for the same thing

</comment></comment><comment><USER4> This is hype lol</comment>


Data Science Projects with Business Impact: Churn Prediction with R - <AUTHOR> https://www.dataoptimal.com/churn-prediction-with-r/ <comment><AUTHOR> I wish there are more articles like this. Seeing how performance characteristics (specificity/sensitivity) effect business outcomes is really insightful! It would be cool if you can improve the performance metric of this model, how much money/impact that would make on a business.</comment>


Show HN: Spotify Playlist Rater – How hipster are your playlists? - <AUTHOR> http://www.hipster-rate.me/

<comment><AUTHOR> I'm a big fan of Spotify's year in review statistics, so I thought I'd take a stab at creating an application which will rate your Spotify playlists on a hipster scale. Would love any feedback: [https://github.com/tripproberts/spotify-playlist- rater](https://github.com/tripproberts/spotify-playlist-rater)</comment>


Chromostereopsis (2002) - <AUTHOR> http://www.ritsumei.ac.jp/~akitaoka/scolor-e.html <comment><USER2> Best theory I've heard of this is that it's due to chromatic aberration in the lens of your eye. Blue is deflected slightly to the left/right relative to red/yellow due to the wavelength-dependent refractive index of your lens. This deflection causes a spurious parallax shift on your retina which your brain interprets as depth.

<comment><USER3> That doesn't explain the white/black background difference shown at the end.

<comment><USER2> Seems in agreement to me-- The white will contain red, green, and blue, which will make a red-green fringe against blue, and green-blue fringe against red.

The sensitivity of the eye is also nonlinear, so bright-against-bright is going to have far less contrast than bright-against-dark.

</comment></comment></comment><comment><USER4> Huh, I wonder if this is related to why all blue LEDs and Neon lights look vaguely blurry to me, while all the other colors look fine. I honestly have trouble reading anything at night if it's written on a building in blue; I catch myself checking if I have my glasses on.

<comment><USER5> This is due to dispersion, or ACA (axial chromatic aberration): your eye actually focuses at different depths for different colors. This will be most noticeable for large apertures (so at night, when your pupils are dilated), and for extremely long wavelengths... like highly spectrally pure indigos, like neon lights, or certain LEDs.

<comment><USER4> Cool! Does this mean that if I shine a light into my eye, like looking at a bright cellphone screen, I should be able to focus a little better on blue lights for a minute?

<comment><USER5> Sadly not; the lens in the eye is somewhat adaptive, but the 'blooming' effect of bright, short-wavelength lights at night mean your eye is incapable of focusing all of the rays onto a single small spot.

Unless, that is, the bright light (color irrelevant) causes your pupil to contract. Then things will appear sharper and darker (until your pupil expands moments later).

It's sort of amazing that biological eyes work at all, to be honest.

</comment></comment></comment></comment><comment><USER6> I appear to be part of half the people. What does it mean for me?

Additional read [https://en.m.wikipedia.org/wiki/Chromostereopsis](https://en.m.wikipedia.org/wiki/Chromostereopsis)

</comment><comment><USER7> I couldn't really see any of them until I started moving my head back and forth a little bit, then they popped. The effect was really noticeable with the red-black-dark blue images.

</comment><comment><USER8> I experience this occasionally with LCD monitors. The effects are most profound when I'm using a terminal and there's colored text on a black background.

<comment><USER9> I don't think the display technology makes much of a difference (except that maybe modern displays have better contrast than older ones). Can happen with CRTs too. I first noticed this as a child with Teletext on British CRT TVs back in the 80s, which often had bright primary coloured text on a black background, much like a terminal.

</comment></comment><comment><USER10> Does not work for me using f.lux at night and mono-vision contact lenses for bifocal vision. In fact, in a few cases the blue looks in the foreground.

<comment><USER3> Try turning off f.lux? The colors matter for this.

</comment></comment><comment><USER11> The only effect I see is "Vertebral column". Everything else is just plain pictures without any "depth".

</comment><comment><USER12> I've seen red links on black backgrounds pop out in 3D for years. Finally a name for this.

<comment><USER13> Me too! Though I've really noticed it the past two or three years (maybe because I've been using more 4/5k monitors?) I've been meaning to poll friends for a while now to see if it was "just me" in a way it's a relief to realize it isn't!

</comment></comment><comment><USER14> Sometimes happens to me with an OLED phone but not with any other kind of display.</comment>


Crocker's rules - <AUTHOR> https://wiki.lesswrong.com/wiki/Crocker%27s_rules <comment><USER2> Would be great to see some meaningful example where these principles clearly improved the conversation, be it in terms of time, conclusion, compromise or what have you. I've got this feeling that it's one of these things that cause a threaded discussion to be misinterpreted by outsiders in terms of predictability.

<comment><USER3> It is important to understand the milieu in which Crocker's Rules originated. The old Extropians mailing list was, by design, a place where even highly controversial and socially taboo subjects could be discussed and argued from positions that average people might find abhorrent _if_ the position was carefully constructed, interesting, and grounded in rational or scientific observation. Many people found it emotionally challenging to engage on that list due to the volume of uncomfortable ideas they were exposed to. Even on that list, many topics were difficult to discuss because it triggered too many people regardless of the merits of the topic.

Declaring "Crocker's Rules" was an explicit statement that you refused to be triggered and that every possible subject matter was on the table for reasoned discourse without devolving into an emotional response. The flip side of this is being open to accepting better ideas that you are not predisposed to accepting.

As an aside, Lee Daniel Crocker gets credit personally for successfully challenging some long-seated political beliefs I held, by virtue of compelling argumentation.

<comment><USER4> > that you refused to be triggered

Was it a refusal to be triggered, or a decision to steel yourself for possibly being triggered and commitment summoning the wherewithal to handle that gracefully?

<comment><USER5> It's basically a rephrasing of Jon Postel's dictum. "Be liberal in what you accept, and conservative in what you send."

<comment><USER6> It invites others to _stop_ being conservative in what they send to you.

<comment><USER5> Yep, that's an unfortunate side effect in both cases. It can encourage sloppy coding and sloppy rhetoric.

<comment><USER7> That's not a side effect but rather the point, isn't it? To allow others to communicate to you more directly by committing to not responding emotionally.

Edit: to be perfectly clear, by "not responding emotionally" I mean not sending a nasty email while angry. I don't mean suppressing any emotional response.

<comment><USER5> Well, one criticism of Postel's principle is that it's contributed to the security hazards of the modern-day Internet. We have a lot of ill-behaved software, written by programmers who felt free to take the easy way out because everyone else bent over backwards to accommodate them. The critics argue that a more formal, RFC-respectful approach -- the equivalent of what we'd call "political correctness" in a conversational context -- would bring about a safer Internet (or safer world) for everyone.

I don't subscribe to that point of view because I disagree with the idea that safety and security should be prioritized above virtually everything else including freedom. But I think it's worth acknowledging in a devil's-advocate sense. The question, "What's the minimum level of standards enforcement / political correctness that's required to enable technological development / human progress?" is an interesting one. Clearly the answer isn't "Zero" in either case.

<comment><USER7> Political correctness is about being conservative in what you say. Crocker's rules is about being liberal in what you accept. You could do both, then you'd be following a conversational equivalent of Postel's principle.

The analogy breaks down pretty quickly though.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I think the idea that emotions are not information... alien? I guess. Whatever. These sorts of rules do select for certain kinds of people to have certain kinds of conversations, but I don't buy that the actual selection effect is what is intended or claimed.

When intelligent people have great conversations, they are not the kind where people's emotions are disregarded. That does not make them less efficient, in fact, considering that humans have a great deal of circuitry for empathy, I think it would be perfectly reasonable to claim the opposite: That an environment where a high level of emotional communication is processed in a constructive way is the most efficient way to convey information.

I don't think this post holds up to scrutiny:

> The underlying assumption is that rudeness is sometimes necessary for > effective conveyance of information, if only to signal a lack of patience or > tolerance

In other words, some emotions are perfectly acceptable! It's ok to be rude, because, I guess, somehow rudeness is an emotion conducive to rational communication? Ok. Granted. Why is signaling that one is upset not also a constructive emotion? It's not entirely spelled out but it's easy to infer that what is really at issue here is the expectation of empathy and good faith. The implication being that empathy is an obstacle to rational discussion.

That's what disregarding "emotional feelings" means.

To put it lightly, I emphatically disagree.

Edit: To make it clear, here is an alternative rule I think would be more productive. Crocker's rules gets you some types of conversations with some types of people you otherwise wouldn't get. Instead, I think one should offer to be receptive to empathetic discussion about a difficult topic. I think this gets you other kinds of conversations with other kinds of people and I think they are more useful.

<comment><USER9> > The underlying assumption is that rudeness is sometimes necessary for > effective conveyance of information

I see this sort of thought come up a lot, but what situation requires rudeness to be more concise? For example, you could take Torvald's emails, cut out the rudeness, and they'd be much shorter and to the point.

The idea that rude == direct doesn't really hold up in my experience.

<comment><USER10> It is not the same. The level of insult conveys the information of how wrong the patch/bad the situation is, in Linus's view.

That's important information.

From Torvalds:

The fact is, people need to know what my position on things are. And I can't just say "please don't do that", because people won't listen. I say "On the internet, nobody can hear you being subtle," and I mean it.

And I definitely am not willing to string people along, either. I've had that happen too—not telling people clearly enough that I don't like their approach, they go on to re-architect something, and get really upset when I am then not willing to take their work.

<comment><USER9> \- This looks good

\- this looks bad

\- this looks extremely bad

\- this is dangerous, I imagine you can exploit this

\- You can easily exploit this code with attached example

A free scale if you need to convey degree of good/badness for attached code. CC0 license.

This is a bit snarky, but I do think that a bit of effort can be made to describe code as being bad without declaring that the author's mother should have aborted them.

<comment><USER11> Well, taking the "shut the fuck up" incident, the scale was used at the maximum level (an example of the commit breaking a program was provided, with a patch fixing it) and the maintainer insisted it wasn't really a bug because the app was holding it wrong. Therefore, your scale needs an extra level.

</comment></comment></comment></comment></comment><comment><USER12> Sounds interesting, but where can we read Crocker's actual rules?

<comment><USER3> As I recall, "Crocker's rules" originated in an email Lee Daniel Crocker posted on the old Extropians mailing list in the 1990s. He simply declared in an email, during some contentious or heated discussion (as was the norm for that list), that he wanted people to communicate with him without any regard for whether they might offend him, valuing bluntness, honesty, and authenticity over social nicety, pleasantness, and diplomatic protocol.

The rules were never a formalized thing. A person that declares Crocker's rules is basically saying that they (1) want people to not filter their communication with them in any way for the sake of pleasantness and (2) take full responsibility for and ownership of their reaction to that unfiltered communication.

(The article references a source on the SL4 mailing list, but that is not the origin. SL4 post-dates Crocker's Rules, and the people that moderated and ran SL4 were all on the old Extropians mailing list.)

<comment><USER12> Huh, no wonder it's obscure. If someone wants to see this become popular, there needs to be a clear statement that you can link to. (It should make a clear distinction between the rule and the commentary/justification for the rule.)

<comment><USER3> I don't think it is trying to become popular, it is just a cultural artifact of the Internet as it existed in the 1990s. Enough influential people in tech today were on that mailing list at the time that the reference and idea is still known to some people even though the mailing list is long gone. The only reason I know about it is that I was there (virtually) when it happened.

<comment><USER13> Its descendant lives on: [http://lists.extropy.org/pipermail/extropy- chat/](http://lists.extropy.org/pipermail/extropy-chat/)

</comment></comment></comment></comment></comment><comment><USER14> Here is Crocker's Wikipedia user page: [https://en.wikipedia.org/wiki/User:Lee_Daniel_Crocker](https://en.wikipedia.org/wiki/User:Lee_Daniel_Crocker)

Also the discussion page on LessWrong is pretty interesting: [https://wiki.lesswrong.com/wiki/Talk:Crocker's_rules](https://wiki.lesswrong.com/wiki/Talk:Crocker's_rules)

</comment><comment><USER15> Safe spaces disable free speech so you do not upset others.

Crocker's rules state you cannot be upset to enable free speech.

<comment><USER16> You didn't actually read it. Only the listener can declare they're operating on Crocker's rules. You can't just unilaterally declare that nobody can be offended by anything you say.

<comment><USER17> I think you're misinterpreting the comment.

<comment><USER18> If you think gp is misinterpreting, perhaps attempt to rephrase it so they might better understand?

<comment><USER19> "Invoking Crocker's rules means choosing to state that you cannot be upset because you want to enable free speech."

</comment></comment></comment></comment></comment><comment><USER20> Is there evidence that this is effective?

<comment><USER21> Considering the rule is only self-imposed, it's pretty self-selective.

"Crocker emphasized, repeatedly, in Wikipedia discourse and elsewhere, that one could only adopt Crocker's rules to apply to oneself, and could not impose them on a debate or forum with participants who had not opted-in explicitly to these rules, nor use them to exclude any participant."

In essence, it's a rule about how you allow people communicate to you, rather than how you communicate with others.</comment></comment>


Why was CRLF/LF/CF to make developers life miserable - <AUTHOR> Why were so many End of line formats created for different operating system. Couldn't it have been simpler to adapt to a predetermined standard to at least end the line in same fashion. <comment><USER2> Well, first off -- do you understand what those terms mean? Why they're called that, I mean? Probably you do, but just in case, I've detailed them below.

        Carriage return: return the carriage head to the margin regardless of what its current horizontal position is.

        Line feed: advance the position of the paper by one line.

These are teletype metacharacters that control the behavior of the "display" for historical computers. As a result of being one of the early computer standards, text file encodings and terminals have inherited these qualities.

What should a computer terminal/terminal emulator do when it encounters these archaic control characters? Well, the carriage return could move the cursor to the beginning of this current line, ready to over-write any text on this line. And the line feed could move the position of the cursor down one vertical line, leaving the cursor at this same position. In order to move to the beginning of the next line, as is customary, you would need to perform both of these steps.

Now imagine you're a computer OS vendor in the early days of computers and you say to yourself: these metacharacters are a silly legacy of the teletype -- who would want to advance the linefeed without a carriage return? Let's just make it implicit when you do a linefeed that we will mark the position of the cursor at the beginning of the next line. And you can do that if you offer an out-of-band channel ("termios", e.g.) to move the cursor around the terminal independent of the print stream. But imagine you're another computer OS vendor and you don't have that feature and if you get it later you have a bunch of customers who wrote their software contingent on the explicit carriage- return/linefeed behavior. Now, you might feel bound by compatibility to preserve that behavior. Both OS vendors use what they call ASCII-encoded text files, but the metacharacters now mean something slightly different.

EDIT: it sounds like I wasn't _too_ far off. But the canonical reference seems to be the wikipedia entry cited in another post.

</comment><comment><USER3> [https://en.wikipedia.org/wiki/Newline#History](https://en.wikipedia.org/wiki/Newline#History)

<comment><USER4> Summary: CR+LF was in common use because it directly descended from commands used to directly manipulate a printing head. Multics started using LF only because by that time the hardware was abstracted from the software, and Unix later followed this convention.

See also, [https://en.wikipedia.org/wiki/Carriage_return](https://en.wikipedia.org/wiki/Carriage_return), which describes more about how early CR was used.

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

</comment><comment><USER6> Obligatory XKCD:

[https://xkcd.com/927/](https://xkcd.com/927/)</comment>


Sony PS2 exports restricted because graphics powerful enough to control missiles - <AUTHOR> https://www.theregister.co.uk/2000/04/17/playstation_2_exports/ <comment><AUTHOR> Article is from 2000. Couldn't fit the year into the title, sorry.</comment>


Adventures in Document Thumbnailing - <AUTHOR> https://github.com/bcoe/Adventures-in-Document-Thumbnailing

<comment><AUTHOR> A post going over the document thumbnailing approach we use at Attachments.me. Included is an example Python library which creates thumbnails for several common document formats.</comment>


Stack Exchange embroiled in 'he said, she said, they said' row - <AUTHOR> https://www.theregister.co.uk/2019/10/01/stack_exchange_controversy/ <comment><AUTHOR> This might be old news. See [https://news.ycombinator.com/item?id=21113344](https://news.ycombinator.com/item?id=21113344)</comment>