Blizzard is secretly watermarking WOW screenshots - <AUTHOR> http://www.ownedcore.com/forums/world-of-warcraft/world-of-warcraft-general/375573-looking-inside-your-screenshots.html <comment><USER2> Some speculation in the thread about whether or not it's JPG artifacts, but if you make it to the 2nd page (post #21) someone included some information proving it's intentional: [http://www.ownedcore.com/forums/world-of- warcraft/world-of-w...](http://www.ownedcore.com/forums/world-of- warcraft/world-of-warcraft-general/375573-looking-inside-your- screenshots-2.html#post2489452)

Edit: Page 6 includes confirmation from a (supposed) Blizzard representative that this is for NDA leak tracking: [http://www.ownedcore.com/forums/world-of- warcraft/world-of-w...](http://www.ownedcore.com/forums/world-of- warcraft/world-of-warcraft-general/375573-looking-inside-your- screenshots-6.html#post2493282)

</comment><comment><USER3> One reason Blizzard would do this is to combat RMT + selling your account to a third party. All they would need to do is set up a crawler on eBay or any other website where somebody has posted a screenshot of their account for sale, then dole out a warning / suspension / ban.

<comment><USER4> One reason nefarious people would use this is to gain verified account name information. Get enough of those and there are bound to be some passwords that are easily brute forced.

Furthermore as the article states blizzard could use this to track private servers.

<comment><USER5> What I don't understand is why the screenshot would contain your literal realm id, and not a hash that only Blizzard could understand.

As long as Blizzard is the only party that can glean meaningful information from these watermarks I see no problem with it.

<comment><USER6> A hash isn't really the right construct for that purpose. If Blizzard just produced a salted hash of user_id & realm, it would be pretty expensive for them to reverse it, even given possession of a complete list of user ids and realms. If they didn't salt it, they could keep one big "rainbow table", but then again so could anyone else.

What you'd really want is encryption. If you chose symmetric encryption, the key would be in every client (easy to steal). If you chose asymmetric encryption, the message would suddenly get much, much bigger to the point where it's harder to reliably encode in a screenshot.

<comment><USER7> The data wouldn't get much bigger - a 2048-bit RSA key requires the output to be at least a 256-byte block, roughly 3 times as much data as the current watermark has, not some insane amount of data. The watermark is repeated many many times in the image anyway, so it seems like the trade-off could be made between less copies of the watermark and more data in it.

<comment><USER8> Current speculation is that most of the 88 bytes of data in the existing watermark is an error-correcting code that hasn't been reverse-engineered yet, so in practice it has less actual non-redundant data than that.

</comment></comment></comment></comment></comment></comment><comment><USER9> We'll add this one to copier watermarks, printer watermarks, and fax machine watermarks.

So your account id and realm is available as a watermark in the screen shots, what nefarious problem does that cause? (I can imagine it helps identify griefers and people who cheat and brag)

<comment><USER10> I'd be concerned for lots of random people that take screenshots and post them online, making public their account ids. Probably not a huge deal, but it's more information that they're giving out that they don't need to be.

The people under NDAs, hackers, and griefers are going to know about this now and just turn them off. Which means the only people negatively impacted by it are the innocents.

<comment><USER9> Well it will be interesting if they go the other way, and try to 'spoof' it which is to say get someone banned by posting a screen shot of some bad behavior that points back to them.

My understanding (and it may be incorrect) that the character name and realm is embedded not the battlenet account id. so something Blizzard could turn into an identity but 'regular' users could not.

</comment></comment></comment><comment><USER11> The only problem here is that Blizzard didnt encrypt the information in the screenshots. I can understand why they would embed this info, and 9/10 of those cases are ethically sound, but I wouldnt want some random skiddies get this information.

So why wouldnt they encrypt it? Not enough space?

<comment><USER12> Um, this is done client-side, no? How would they protect the encryption key?

<comment><USER13> Public/private key-pair. It wouldn't stop people from faking values, but at least only Blizzard can read them.

<comment><USER6> They don't really have enough bits here for asymmetric crypto.

How many bits are they able to reliably recover from the screenshot, especially if they want to survive simple downsampling? I would guess not more than 500, probably less than that given the patterns we're seeing.

You can't generate a ciphertext smaller than your key size. And 500 bits is really not enough to do typical asymmetric crypto safely.

<comment><USER14> "The pattern, which consists of approximately 88 bytes of data..."

Actually seems like more than enough room to be encrypted. They probably just didn't think of it.

</comment></comment></comment></comment></comment><comment><USER15> I'm growing increasingly tired of technology being used by the large to monitor the small. I'd like to see an RFS from YC for companies that use data mining, machine learning, etc. to the advantage of the individual.

<comment><USER16> I have a project for DRM for the masses. (will also use watermarking)

<comment><USER15> A tangentially related idea that might be interesting: adding a mechanism as easy as Bump for transferring public keys between users, then automatically encrypting all communication between them. It'd be great for business; meet people at a conference, then easily communicate with them without worrying about MITM industrial espionage.

<comment><USER17> Love this idea. Surprising that it hasn't been done yet, has it?

<comment> mike-cardwell Sounds like "STEED", which was announced about 11 months ago by the author of GnuPG: <http://www.gossamer-threads.com/lists/gnupg/users/56053>

Although I'm not aware of any implementations yet.

<comment><USER17> I've seen this pop up a few times on HN now, seems a good candidate for this type of setup.

Tomorrow on HN: "Hi, we're Stump! It's like Bump for messaging but with the encryption of STEED!"

</comment></comment></comment></comment></comment></comment><comment><USER18> _'in order to avoid any further watermarking, type: /console SET screenshotQuality "10" which will set the quality of your screenshots to the maximum and create screenshots that do not include the watermark.'_

If this was nefarious, I doubt they would give you such an easy way to disable it. Though I am curious what the default value of screenshotQuality is.

In any case, steganography remains awesome, as ever:

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

<comment><USER19> The default setting is 3.

<comment><USER20> Beat me to it...

Some links that confirm this

<http://www.wowhead.com/help=screenshots-tips-tricks> <http://us.battle.net/wow/en/forum/topic/3759356695>

</comment></comment></comment><comment><USER21> So it looks like Glyph Lefkowitz's "extremist" opinion on software ethics <http://glyf.livejournal.com/46589.html> was completely right. When a program does something the user doesn't want, the programmer is in the wrong. Programmer is to user as lawyer is to client. We need a recognized and binding way for programmers to submit to this code of ethics.

<comment><USER22> Your premise is flawed. Programmer is to user as refrigerator manufacturer is to user. If the fridge fails and your food goes bad, caveat emptor. If you have a problem with that, nobody is stopping you from writing your own code.

<comment><USER23> I assume you build your own refrigerator, just in case GE did include some wiretapping device in theirs?

A programmer has much more possibilities to include malicious code than a refrigerator engineer, simply because a program can have an almost arbitrary complexity while a fridge can not. Furthermore we see in programs today a spectra of shady behavior which ranges from user did not notice the obvious ( Facebook assumes private data is public) to outright fraud ( banking trojans). So the due diligence for users can not be too completely reverse engineer any program they use, but that programmers have a responsibility too create reasonably surprise free software.

<comment><USER22> I don't think we can agree on philosophy. But how can we punish those who misrepresent what their software does, when a large portion of the software out there was released anonymously? At least, if software developers were held responsible for malicious code in their products, software that could not be traced back to a developer would be easierto create than software created by a company, which would likely need more developers to review code, and insurance to cover possible lawsuits.

<comment><USER21> Commercial software is copyrighted and sold by companies. Open source software comes with copyrights and licenses. What anonymous software are you thinking of? Viruses or something?

<comment><USER22> TOR maybe.

</comment></comment></comment></comment></comment></comment><comment><USER24> Being a former player, I can think of some _good_ uses for this technology.

1) Automatically attaching image galleries to the Armory* profile of characters based on account id

2) Easy to give credit to players providing screenshots for Blizzard run contests

3) Opens the Armory API a bit more

Obviously, these can all be exploited due to the "openness" of the screenshot format.

*For the WoW illiterate: The Armory is a public database of player's characters, items, achievements, etc...

<comment><USER22> Yeah except they can be faked.

</comment></comment><comment><USER25> Clever, although I believe it's unethical.

It starts like this. How far from the day companies do this with the images you take with your mobile, with the videos you stream, etc.? The world will turn into a DRM fest.

<comment><USER26> something like this can be used to track down someone who does bootleg recordings. Say our bootlegger buys a camera from samsung, samsung uses a water mark like this which gives out a unique device id. The bootlegger who doesn't know about this tracking thing uploads his 1080p raw video. MPAA then collaborates with samsung to find out was the bootlegger(although that would involve tracking the sale from the reseller/distributer and contacting/capturing the bootlegger).I just gave MPAA a really nice idea.

<comment><USER27> Actually, imagine how much worse this could be: person on youtube posts (bootlegged | police harassment) video under one account, family video under another: bam they have you.

</comment></comment></comment><comment><USER28> Very interesting technology. Would be cool to see this put to good use. It's a lot easier to get someone to post a screenshot than it is to get them to email a dump.

<comment><USER29> Isn't this just steganography? I'm quite sure organizations of all flavors and kinds are putting it to good use as we speak :)

<comment><USER30> Spore saved its creatures in their portrait pictures: [http://nedbatchelder.com/blog/200806/spore_creature_creator_...](http://nedbatchelder.com/blog/200806/spore_creature_creator_and_steganography.html)

</comment></comment></comment><comment><USER31> I don't see the huge issue here. There's no real private information given by this, it's just character name and realm.

<comment><USER32> A minor point: the character name is not included, the account ID is. I don't think the account ID is that helpful for any prospective hacker, but this method might allow you to compare two screenshots and confirm that they were taken by the same person.

</comment></comment><comment><USER33> Why would Blizzard want to watermark their own screenshots?

<comment><USER34> A couple of hypotheses, off the top of my head.

1\. NDAs - if someone's in a closed beta, and starts posting screenshots, they can quickly identify the culprit.

2\. Hacks - if someone anonymously boasts about finding some exploit in the game, and shows screenshots, they can be tracked down.

3\. Abuse prevention - if someone posts screenshots of themselves abusing another player, or breaking the TOS in some other way - but with names blurred out - it would still be possible to find out who it was.

<comment><USER35> Also:

If a user emails support, and their email address is not directly traceable to their login(for example, if they use firstname.lastname@example.com for battle.net instead of firstname.lastname@example.com as the sending email), it allows support to add that to the ticket.

<comment><USER19> There is no direct email address for support. You must log in with your Battle.net account and file a support ticket.

</comment></comment></comment></comment><comment><USER36> Curious question here: If you take the screenshot you get from WOW and open it up with photoshop/gimp/paint and save it now as PNG or different format, would it be possible to degrade the quality of the dots rendering it useless to be tracked?

<comment><USER37> PNG is a lossless format and will not cause the image data to change whatsoever upon saving. JPEG, on the other hand, is a lossy format, but until more is known, it's impossible to say whether or not this secret data (if that's what it really is) happens to be muddled by the lossyness of JPEG's algorithm.

<comment><USER36> Thanks. You got me thinking in the right direction and I found a Wiki page that talked about image formats and if they are lossy or lossless.

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

I found it interesting and wanted to share.

</comment></comment></comment><comment><USER38> Secretly seems a little strong... is there any sort of effort to cover this up, or did they just not mention it in the patch?

I don't fault them for not mentioning it in release notes - if I make a change to my apps that the user won't notice, I don't mention it in the release notes.

To the extent that they introduced a security bug, they should admit it and fix it. But that's a technical lapse, not a moral lapse.

</comment><comment><USER39> I can see this being partially helpful when verifying that in-game screenshots have not been tampered with (for example. for support, when you claim you had an item and it disappeared etc), but I don't know if there are that many copies of it duped across the image.

<comment><USER19> There are a significant amount of logs for things like that. Screenshots are likely never accepted for that kind of request.

</comment></comment><comment><USER40> Is it just on my machine or does every single part of that web page start off a Amazon referral pop-up to Mists of Pandaria on click?

</comment><comment><USER41> He give instructions on how to find the watermark. Am I missing what you mean?

</comment><comment><USER42> Not sure whether to be upset about this or proud of the technical achievement

</comment><comment> mike-cardwell Textbook example of why proprietary software is bad for users.

</comment><comment><USER43> I find the title inflammatory and ignorant; I would downvote this if I could.

While I applaud the tenacity in prospecting and divulging the methods at which Blizzard has employed to create such "tracking" "watermarks," I highly doubt this is to discourage or indict anyone. Quite frequently, screenshots are used during support requests.

As the author states, "we [...] verified that there is no pattern included in high quality screenshots." I find this highly suggestive that Blizzard was rather interested in an easier way to debug their program, and the mode slipped out in production.

There's a work around, please remove your tinfoil hats.

<comment><USER34> I'm not sure if the title was changed, but it currently reads "Blizzard is secretly watermarking WOW screenshots", which seems accurate enough to me.

<comment><USER43> I was mainly referring to the implication by omission that Blizzard had nefarious intent with its watermarking. Though, my comment was itself inflammatory; karma's a jerk.

<comment><USER44> The title, as currently, written, "Blizzard is secretly watermarking WOW screenshots" is pretty generic (and entirely accurate - They are watermarking WOW screenshots, and it is being done secretly).

I'm curious as to what your title would have been:

"Blizzard watermarking WOW screenshots?" - This is less informative, but removes the word "secretly?"

</comment></comment></comment></comment><comment><USER45> All speculation, guess work, no external sources, no reproducible results.

Paranoid stoners is my guess.</comment>


Ask HN: How would you measure quality of a site like HN? - <AUTHOR> What metrics would you want to look at?  What would success look like?<p>Honesty might be one aspect - What % of posts and comments are undisclosedly by bots.
Who the site is tuned for. What % of the links that you clicked on, were worth your time. What % of the links that you didn't click on, due to the description or title, would have been worth your time. <comment><USER2> Primarily, the quality of discussion. This is difficult to quantify, especially if you want to do it algorithmically.</comment>


DNA Sequencing Caught in Deluge of Data - <AUTHOR> http://www.nytimes.com/2011/12/01/business/dna-sequencing-caught-in-deluge-of-data.html?pagewanted=all

<comment><USER2> _> In the case of human genomes, they might store even less — only the difference between a particular genome and some reference genome._

The results from comparative genomics would suggest, at least superficially, that a combination of compression and data de-duplication in the style of S3 and Dropbox would go a long way towards resolving the issue.</comment>


Introducing Keras 2 - <AUTHOR> https://blog.keras.io/introducing-keras-2.html <comment><USER2> Copying my rare product endorsement from the previous submission:

Keras is so good that it is effectively cheating in machine learning, where even Tensorflow tutorials can be replaced with a single line of code. (which is important for iteration; Keras layers are effectively Lego blocks). A simple read of the Keras examples ([https://github.com/fchollet/keras/tree/master/examples](https://github.com/fchollet/keras/tree/master/examples)) and documentation ([https://keras.io/getting-started/functional-api- guide/](https://keras.io/getting-started/functional-api-guide/)) will let you reverse-engineer most the revolutionary Deep Learning clickbait thought pieces.

It's good to see that backward compatability is a priority in 2.0, since it sounds like a lot had changed.

<comment><USER3> Yes

Trying to do something simple in TF is a pain, on the code there are some conflicting examples and code snippets that "train" a network just to print a loss number on the screen but actually do nothing besides that

Keras is easy to use and better if you're running CPU only

</comment></comment><comment><USER4> Will Keras2 support PyTorch as backend, in the future?

Answer: [0] No, there are no plans to support PyTorch. There is nothing to be gained in supporting every novelty framework that crops up every quarter. Our goal is to make deep learning accessible and useful to as many people as possible, and that goal is completely opposite to building up deep learning hipster cred.

[0]: [https://github.com/fchollet/keras/issues/5299](https://github.com/fchollet/keras/issues/5299)

<comment><USER5> To put this quote in context: this isn't specifically about PyTorch. Every couple of months since mid-2015, a new deep learning framework gets released. In the following week, someone inevitably asks "will X get added as a Keras backend?".

Supporting _several_ backends is a strong positive. But chasing every new framework as a backend is a quick way to kill Keras, via bloat, support issues and general technical debt. We should only support a backend that is considered mature, and we should stay away from the hype surrounding the release of every new framework. There will be another hyped up framework next quarter anyway. And the one after.

It is in fact possible that Keras will eventually support PyTorch. But if it ever happens, it would be at least 1-2 years in the future. When PyTorch becomes "uncool", just like Keras :)

<comment><USER6> Yay, making deep learning uncool again! ;) ([http://www.fast.ai/about/](http://www.fast.ai/about/))

But seriously - does it even make use to have a "define by run" dynamic framework as a backend? It seems to me that keras is particularly suited to wrapping frameworks that define and run a computation graph.

<comment><USER5> With the functional API of Keras, it would definitely make sense. In fact I do think that imperative model definition would be great to have at some point in the future. We'll see :)

<comment><USER6> I'm intrigued!... The kernel calling overhead and lack of any GPU while/scan/map/etc for Pytorch seems like a limitation, but I guess on 2nd thoughts you can still do all the keras fit/predict stuff and auto-connecting up the layers.

<comment><USER7> These ops are just not needed in PyTorch. while is just a Python while loop. Scan is a for loop, map is a list comprehension that applies modules. No need for anything fancy.

<comment><USER6> Sure - but on pytorch they suffer the kernel launch overhead each time through the loop, whereas on tensorflow and theano they do not. Which really impacts the kinds of algorithms that work well on each platform. Does that seem like a reasonable assessment to you?

<comment><USER8> Currently not many frameworks have actual fusion of kernels (to avoid launching many GPU kernels). If you look underneath a theano.scan or TF.scan, GPU kernels are still being launched individually (but are likely stream- overlapped where appropriate).

With TF's XLA compiler, they are slowly getting towards kernel fusion, which will then reduce launch overheads.

We have similar things in the works for pytorch: to quickly JIT at runtime the dynamic graph that is getting executed. More news on this will come when time- appropriate.

<comment><USER9> I WANT to use pytorch, but no bayesian learning or stochastic nodes like in edward. Any chance there are plans to for a compatibility layer with Edward or roll your own bayesian stuff?

Also, have you looked at Numba to do the jitting? Probably best not to have yet another separately maintained python JIT.

<comment><USER8> as core-devs, we dont plan to build-in something like Edward. However, folks in the community are brewing something:

[https://discuss.pytorch.org/t/bayesian-computation-in- pytorc...](https://discuss.pytorch.org/t/bayesian-computation-in-pytorch/755) [https://discuss.pytorch.org/t/distribution- implementations/4...](https://discuss.pytorch.org/t/distribution- implementations/400/6)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Highly recommend this course - [http://course.fast.ai/](http://course.fast.ai/) that utilizes Keras as the main programming tool

<comment><USER11> I'm definitely going to give this a shot, thanks for the link. Approaching ML at a higher level is exactly what I need to develop a better interest in it. I realize that underpinnings are important, but waiting 30 minutes for mnist on to process on my localhost is just unbearably boring.

<comment><USER6> If you try the course, be sure to make use of the forums for it too: [http://forums.fast.ai](http://forums.fast.ai) . As you'll see, they're _extremely_ active and helpful for all deep learning students (and all practitioners in general).

Disclaimer: I teach the course. Although it is free and ad-free... :)

<comment><USER11> Will do. I'm in a good position to start (no shortage of python/aws experience), so the only fighting will be with the deep learning bits, hah.

Side note: Great job on making AWS setup/teardown straightforward. 90c/h is not terrible, but not cheap to accidentally leave on!

<comment><USER6> Regarding AWS, one participant has created a system that lets you use spot instances for the course. It's published on the forum. Great way to save $$$ (400% or more...)

</comment></comment></comment></comment></comment><comment><USER12> Keras is fantastic. Not the tightest analogy and probably unoriginal but I think of it as the Python to Tensorflow's C. It's easy to drop into tensorflow flow when needed but you can probably get away with Keras for a long time. Also, Francois helped us when we DM'd him on Twitter which was incredible.

Thank you so much Francois! I'm incredibly excited about this release!

</comment><comment><USER13> I'm only starting with all that machine-learning, NN stuff and as many others I want to ask for some guidance/resources/learning material. What I feel especially lacking is something very broad and generic, some overview of existing techniques (but not as naïve as Ng's ML course, I assume). There exist a lot of estimators and classifiers, there exist a lot of techniques and tricks to train models, there exist a lot of details on how to design a NN architecture. So how, for instance, do I even decide, that Random Forest is not enough for this task and I want to build some specific kind of neural net? Or maybe I don't actually need any of these fancy famous techniques, but rather there exist some very well defined statistical method to do what I want?

What should I read to start grokking this kind of things? I feel quite ready to go full "DIY math PhD" mode and consume some heavy reading if necessary, but where do I even start?

<comment><USER14> _So how, for instance, do I even decide, that Random Forest is not enough for this task and I want to build some specific kind of neural net?_

The problem here is that it's really hard to give generic advice. As an analogy this is like asking "how do I know if Rails is enough for this task".

The answer is usually "yes", but the specifics matter a lot.

So in this specific case (and I realize you aren't looking for specific advice here, but I think the principles are useful):

Random Forests are very powerful, and work really well for hundreds, maybe thousands of features, on large but not huge amounts of data and are fairly easy to train.

There are a large number of types of neural networks. One of the big advantages of deep neural networks is that that can reduce the need for manual feature engineering. For examples conventional neural networks extract features from images that work better than any human engineered features, and LSTMs (and variations) work well at extracting features from text. The problem with deep neural networks is that they (generally) need a lot of data to train.

So, as usual the answer is "it depends".

In industry though, 90% of the time the question isn't "what classifier should I use". It's "how do I get the data"/"how do I extract features" and then "lets try all the classifiers and see what works best".

<comment><USER15> "Try 'em all" is not just an answer, but the only answer.

The __No Free Lunch Theorem __says that averaged across all possible problems, no single classifier is the best; in fact, they 're all equivalent.

However, you probably don't care about all possible problems, but a specific one. Over the last decade or so, we've discovered that deep learning works really well on certain classes of problems, particularly those that may have some kind of nested structure, as in object or speech recognition. If your problem resembles one of those, a deep neural network might be a good place to start.

<comment><USER14> Right - this is good advice.

To paraphrase the learnings of thousands of data scientists on years of Kaggle competitions:

A quick and dirty model for a baseline: Random Forest

Structured data: Use a boosted tree algorithm (specifically the XGBoost implementation of gradient boosting), ensembled with maybe Extra Trees, Random Forests and MLPs

Some kind of time component on large datasets: FTL regression, XGB

Binary data (images or sound): Deep neural nets

Text: Try LSTMs, but this will often be beaten by manual feature engineering and Word2Vec derived features put into XGB.

<comment><USER2> LightGBM ([https://github.com/Microsoft/LightGBM](https://github.com/Microsoft/LightGBM)) is shaping up to beat XGBoost; it has mostly API parity and it won in benchmarks _before_ a v2 with a new algorithm.

<comment><USER14> I tried LightGBM for a Kaggle. I couldn't get anywhere near XGB.

I was using the LambdaRank stuff. Given the boasting the LightGBM team had done I had assumed it would be close to XGB out-of-the-box for a ranking problem (since XGB only does pairwise ranking). It was far enough away that I had to ask if I was misinterpreting the output[1].

That was 6 months ago now, so maybe it has improved. I know they made big claims.

[1] [https://github.com/Microsoft/LightGBM/issues/37](https://github.com/Microsoft/LightGBM/issues/37)

<comment><USER2> Development was rapid when I was working on a blog post in January using the tool. Things have likely improved if you want to give it another shot.

<comment><USER14> Yeah, I might, thanks.

Did you manage to replicate their results vs XGB?

I don't think anyone has successfully used it for a high result in a Kaggle yet, which - for all its faults - is a good way to see what the maximum performance of a software package seems to be.

LibFFM is the other thing I should have mentioned previously as being worth trying.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> The mathematician in me has kept me from jumping into deep learning before I understand the mathematical and statistical underpinnings of the algorithms involved. Looking forward to reading through the latest book out by mit press and giving things a whirl with Keras which I've heard so much about.

<comment><USER17> what's the name of the book?

<comment><USER18> [http://www.deeplearningbook.org/](http://www.deeplearningbook.org/)

</comment></comment></comment><comment><USER19> I love Keras but I think this update broke more things than you realized. For example it's no longer possible to get the validation set score (val_acc) during training which renders early stopping impossible. This was a documented feature on your FAQ.

Is the old documentation still available? I'd like to wait before I upgrade.

Edit:typo

<comment><USER5> You can try opening an issue on Github. `val_acc` is definitely still accessible by callbacks, and the `EarlyStopping` callback, which relies on it, is fully unit-tested.

</comment></comment><comment><USER20> 1\. Still no support for multiple losses. Models like VAEs cannot be idiomatically implemented. The second loss has to be 'hacked' in. Notice how in the official example for VAE, the kl_loss is computed using variables which are NOT available via the loss function ([https://github.com/fchollet/keras/blob/master/examples/varia...](https://github.com/fchollet/keras/blob/master/examples/variational_autoencoder.py#L46))

2\. It's still an input->output paradigm, rather than a {input, output}->loss paradigm which gives more flexibility.

These two issues are the main reason why I stick to slightly lower level APIs, even though I _want_ to use Keras.

<comment><USER5> See the release notes: [https://github.com/fchollet/keras/wiki/Keras-2.0-release- not...](https://github.com/fchollet/keras/wiki/Keras-2.0-release-notes)

\- You can use a Keras model to compute some tensor(s), turn that into a loss, and manually add that loss to the model via `add_loss` (it just needs to only depend on the model's inputs).

\- Not all of your model outputs have to have a loss associated with them. So you can do both {input, output}->loss and input->output in your workflow, as you wish. Effectively, losses and outputs are decoupled.

The VAE example hasn't yet been updated to use the `add_loss` feature, but it should be.

<comment><USER21> I will look into updating the VAE example, as I've ported the example to the keras 2.0 API recently. There is currently no documentation on add_loss as far as I can see, so I will have to try a few things.

</comment></comment></comment><comment><USER22> Is it better to learn Keras instead of tflearn?

Copying a comment I made in another thread where one response recommended Keras:

I currently have a small pet project where I think some simple ML would be cool but I don't know where to start.

Basically my use case is that I have a bunch of 64x64 images (16 colors) which I manually label as "good", "neutral" or "bad". I want to input this dataset and train the network to categorize new 64x64 images of the same type.

The closest I've found is this: [https://gist.github.com/sono- bfio/89a91da65a12175fb1169240cd...](https://gist.github.com/sono- bfio/89a91da65a12175fb1169240cde3a87b)

But it's still too hard to understand exactly how I can create my own dataset and how to set it up efficiently (the example is using 32x32 but I also want to factor in that it's only 16 colors; will that give it some performance advantages?).

<comment><USER23> If you don't know how to set up a dataset, it's probably too early for you to worry about performance and efficiency.

If you haven't, already, I'd suggest to learn some general machine learning, including how to use logistic regression, random forests and SVMs.

Keras is certainly capable of what you want to do, at least from your description.

One way is to interpret the colors as grayscale images, that would be the fastest option. If however the 16 colors are actually from a palette, it may be better to convert the image to three channels, r/g/b. And if the 16 colors are 16 entirely different things, like 0 - Water, 1 - sand, 2 - earth and so on, you could even turn one 16 color image into 16 images with two colors (1 bit), and get a better model.

Again, getting into machine learning or deep learning is not as easy as reading the Keras documentation. You need to understand the basics first.

</comment></comment><comment><USER24> Keras is a great wrapper library built upon two fantastic frameworks -- theano and tensorflow. I'm glad to see it is moving forward, and kudos to everyone involved in all these libraries!

</comment><comment><USER25> Slightly irrelevant but curious question about the Analytics for 7day (34K), 14day and 30day active users. I'm running a similar site so, could it be that, a lot of users reading documentation are using ad/tracking blockers so that active users count appear higher than it actually is in GA. Documentation users tend to read quite high pages per session. If I'm right then they should see less page views per user than expected.

<comment><USER26> For most websites I am familiar with, 20-30% of users use adblockers or other privacy plugins. On content with a target audience of developers I have sometimes seen 60%. Most of these users are not recorded in google analytics, so the real number of unique users is higher than reportet by analytics.

Since no data from these users is sent at all (no user data and no pageview data) page views per user is not directly influenced because your are missing users _and_ pageviews in your reporting. It could be influenced because users with an adblocker behave differently then users without. To analyse this you would have to look at your server generated web logs.

The given data in the image is often not used to find out what the total amount of unique users on your webpage is. It is used for computing engagement: Monthly active users vs. daily active users. In this example we only have 7-day active users and no daily active users, but it basically is like: 34738/107942=0.32. At a value of 1 (the maximum) you have a high engagement. In simple terms: Each user would come back every week for this month. 0.32 is quite low. Around 0.25 would be the lower bound because we have 4 weeks in a month.

</comment></comment><comment><USER27> Awesome. Yet "codebases written in Keras 2 next month should still run many years from now" given that deep learning is no new, how can they that confident that this API will remain relevant years down the line?

<comment><USER28> What does one thing have to do with the other? Regardless of how "relevant" Keras 2 stays years from now, code written with it now should still be capable of running then, that's the thing they claim.

</comment></comment><comment><USER29> I wonder why they decided to get rid of MaxoutDense. Is there something better or is it so trivial to implement they decided to drop it?

<comment><USER6> It's trivial with 'max' merge param: [https://github.com/fchollet/keras/pull/3128](https://github.com/fchollet/keras/pull/3128)</comment></comment>


CPU Introspection: Intel Load Port Snooping - <AUTHOR> https://gamozolabs.github.io/metrology/2019/12/30/load-port-monitor.html <comment><USER2> I find it interesting that somebody dedicates his or her life to figuring out how these CPUs work when exactly that information is just laying about in some vault in Santa Clara.

<comment><USER3> If we're talking about dedicating their life, that's likely to be Agner Fog: [https://www.agner.org/optimize/](https://www.agner.org/optimize/)

He's put out the most detailed third-party documentation on Intel and AMD processors that I've ever seen.

</comment></comment><comment><USER4> I think I'll disable hyperthreading [0]. :-)

This interesting novel technique [1] can provide an unique window inside the CPU core black box, helping us to better understand how the CPU works internally when it comes to otherwise invisible loads and stores.

While I can't think of any scenario immediately, intuitively I feel this could be useful for those of us seeking to squeeze everything out of a system.

Not the particular case about low level TLB miss / page walk mechanics (we already know TLB misses are bad), but perhaps there are other situations where existing performance counters don't provide as detailed information.

[0]: Yes, I'm aware INVPLG (Invalidate TLB Entries) used in this blog post is a privileged ring 0 instruction. But there's clearly a leak regardless.

[1]: Using a core hyperthread to "spy" other hyperthread on same core.

<comment><USER5> Hehe, hyperthreading has some issues. This issue technically works single thread, but it's hard for sensitive data to survive a context switch. That being said, this issue is mitigated in all common OSes and latest microcode.

I'll be curious as to what there is to learn from this. It's more of a longshot goal for me to learn how things work, develop accurate uarch models, and then learn from those models better than I could guess and check hardware results.

Hard to say if it'll go well....

<comment><USER4> > That being said, this issue is mitigated in all common OSes and latest > microcode.

Emphasis on _this issue_ , eh?

> I'll be curious as to what there is to learn from this...

I'm also very interested to see what you and the community can discover using this trick!

<comment><USER5> I'll eat my hat for this, but effectively the mitigation to this is clearing all caches and internal buffers in the CPU on each context switch.

I'm sure we'll see more types of leaks, but unless they're actively fetching invalid data [1], there isn't much sensitive data to leak anymore.

I don't think there is much during speculation that can load _new_ data during that window.

[1]: So far almost every CPU bug has leaked something in an internal cache.

<comment><USER6> A _machine clear_ clears the pipeline. Does it clear these internal caches? There is, of course, no machine clear instruction. Could you construct a machine clearing sequence, insert it into the context switch code and test your hypothesis?

<comment><USER5> The `verrw` legacy instruction has been added to with microcode to flush internal caches (load buffers, store buffers, etc). Any serializing instruction should (hopefully) cause a pipeline flush. This is the mitigation solution Intel made available to OS developers and should be what is being used.

</comment></comment></comment></comment></comment></comment><comment><USER7> I read this. It's quite interesting, but I think it is short of a few clear basic definitions of terms.

Could anyone help explain, in a few sentences, what is a Load Port, and why is it interesting in this context?

It appears to be some type of indicator of the proportional time slice given to certain opaque internal processes which are not normally visible to users.

<comment><USER8> CPUs issue instructions through a few ports, each of which services a set of instruction types (eg, arithmetic, memory load/store, vector instructions, etc.). For example here are Skylake's ports: [https://en.wikichip.org/wiki/intel/microarchitectures/skylak...](https://en.wikichip.org/wiki/intel/microarchitectures/skylake_\(server\)#Scheduler_Ports_.26_Execution_Units)

So getting a trace from the load ports is basically a trace of all memory accesses in the system. Something particularly cool about this work is that you can even see loads that are hidden from software, like a hardware page table walk.

</comment></comment><comment><USER9> I don't understand why intel and amd can't give us access to the cpu cache the same way NVidia does with CUDA for local and shared memory on the gpu. I just don't buy the hand waiving that the cpu can magically do branch prediction better than a programmer with a static c compiler who actually know what they want in the future. maybe if they had offered cache control on the itanium or phi they wouldn't have had to cancel them despite the need for reprogramming user software which didn't stop CUDA.

<comment><USER10> I agree that we should be able to tell the processor which branch is more likely. Even something as simple as a flag to select between "I prefer you take any jump you encounter" and "I prefer you skip all jumps in this macroblock for speculation purposes" (and also "try to predict smartly" to stick to how it's working now, aka what this article is about). This would give a determined programmer everything he needs to make sure his program is executed optimally.

<comment><USER5> Back in Pentium 4 days you could use the DS and CS override prefixes on conditional branches to hint taken and not taken, respectively.

Kinda neat, but it's not a thing anymore.

Some more info here: [https://stackoverflow.com/questions/14332848/intel-x86-0x2e-...](https://stackoverflow.com/questions/14332848/intel-x86-0x2e-0x3e-prefix- branch-prediction-actually-used)</comment></comment></comment>


Top 35 Startups In Tech that TechCrunch missed out on  - <AUTHOR> http://www.startupplays.com/blog/top-35-startups-in-tech-that-techcrunch-missed-out-on-september-2012/ We love that Kunvay.com was chosen. <comment><USER2> Kudos to Kunvay for being mentioned.</comment>


does web.py have documentation and are you using webpy? - <AUTHOR>

<comment><USER2> I'm using web.py. I really didn't want something like Django or even Pylons where it feels like you're programming _to_ the framework and not to the language. In my experience (with other frameworks), this leads to a really quick 80%, and then you get really screwed over as you try to complete the remaining 20% and have to fight the framework all the way.

I am finding that as my project evolves, I ditch progressively more pieces of web.py. I ignored the form processing library and custom template library from the start, because plain old web.input() and Cheetah are fine for my uses. I ditched the DB library after a month or so - a single global DB connection prevented us from unit testing, and will prevent us from replicating or sharding the database. I'll probably ditch web.py's interface to Cheetah in the near future in favor of precompiled templates (necessary for i18n), at which point I'll just be using the request dispatching features. May end up ditching those too eventually as we've got our own dispatcher on top of web.py, but for now it provides a useful substrate.

That's the main benefit to web.py: it lets you get up-and-running very quickly, with little extra code to weigh you down, so you can _see_ your startup running and adjust from there. It's basically a prototyping tool.

IMHO, startups should not be using _any_ framework. The whole point of a framework is to abstract away common usage patterns so you can benefit from what other projects have done before. The whole point of a startup is to do something _new_ that hasn't been done before. Once a problem domain has been studied enough to build a useful framework, it's too commodified to make any money off of. After all, if it was easy for you to build, it'll be easy for a thousand other startups to build.

<comment><USER3> you lost me with that last paragraph, to put it nicely.

your innovation as a startup will not be reinventing wheels -- building and debugging frameworks that, fortunately for you, others have put [tens of? hundreds of?] thousands of man hours into, solving seriously unsexy problems like browser incompatibilities, security nits and writing init scripts. i can't see how it's faster to tackle all of these things _and_ your application code than just, um, building your application code leveraging one of the very solid foundations that already exist.

while your competitors are solving problems that matter to your users, you'll be running around feverishly putting out fires when someone types an é into your application, or starts getting funny with strings involving apostrophes, semicolons and "drop table", or script tags in comments.

<comment><USER4> Can you explain to me how unsexy problems like browser incompatibilities (yes a major pain) lie anywhere within the scope of webpy? Those seem to lie within the scope of the templating system and js library that you choose.

A larger, more complex framework _does_ present serious problems when you have to architecture everything in strange ways to meet scaling needs or otherwise.

Note how much the twitter guys were so scared by ROR's complexity that they resisted doing the most trivial modifications? I want to understand my framework "all the way down." This is much the same reason I use linux.

<comment><USER5> Parent has important questions that should be addressed, or is this is just a django vs the world flamewar?

</comment></comment></comment></comment><comment><USER3> looks like web.py has some interesting ideas and useful data munging functions. but unless there's something i'm really missing, most normal web apps (that aren't completely trivial) are way better off using turbogears or django, which provide mature and usable components (templating, object- relational mapper/query building/db access, web/WSGI server). i've built a couple reasonably large web apps using turbogears and love it (although i use cheetah instead of kid) and django seems to be winning the python framework race.

not to sound overly harsh, but web.py seems like a big case of NIH. each of its pieces seem like v0.1s of more established counterparts. mature web frameworks are occasionally big and ugly _because_ they work around that random safari bug from 2002 or the flash 8 player's uploader non-RFC-compliant MIME-multipart requests and all the unicode encoding and DB integration nits, etc. the plumbing looks gross because the surface area of the problem they solve is gross.

and with the big frameworks, thankfully hordes of others have banged their heads against and solved these issues; with a "lighter" framework, or one of the 4328429 me-too python web frameworks from 2001-2004 that didn't really make the cut, you're volunteering to blunder into and track down all these problems yourself over the next year or two -- probably not the best use of your time or problem solving skills.

<comment><USER2> There's value in using a v0.1. It hasn't had a chance to get large and complicated yet, so it's easier to learn and less likely to break.

Good third-party components should solve a problem with a large surface area and present an interface with a small surface area. I don't really see that with most frameworks: instead, they seem to solve a problem with a fairly small surface area and present an interface with a large surface area. Not really a great combination.

I'm all for libraries and standards, though. There's no way I could've built my app without Cheetah, PIL (despite installation headaches), Markdown, DBAPI, and WSGI. These solve the _real_ hairy problems, yet provide a small, often trivial interface to learn.

</comment></comment><comment><USER6> A timely post ... we're just about to release a biggish site running on web.py. Check out our blog, which I just released today: <http://blog.micropledge.com/>

We like web.py for its minimalism. It means we did have to write a database layer for it, but we still feel it was better than using Django as we've got more control. This app's big enough that we want it to run the way we want it to -- web.py lets us do that. And when it doesn't, it's small enough to hack.

As for docs, web.py's size means that the limited docs it does have are pretty much enough. When they haven't quite been, we've found the web.py group pretty helpful: <http://groups.google.com/group/webpy/>

</comment><comment><USER7> I'm currently working on a largish project using webpy (well, large for one person). In terms of getting started an barriers to entry, it's very easy to use and getting results is a breeze.

That being said, the documentation is a very large problem. When I run across issues and the documentation isn't there, it can be difficult to get a quick answer. There's a wiki of the documentation, but it has very few contributors.

I think the general problem is that the community is very split in terms of experience, with little intermediate discussion. The typical questions on the webpy board are either really basic ("how do i get started") or discussions about the project's direction. I don't think typical programmers are discouraged from participating, but there isn't enough "average" programming level discussion to make it feel like a community.

Just my 2 cents.

</comment><comment><USER8> I wasted 2 weeks on web.py. Why a waste? No documentation and you outgrow it VERY quickly. As soon as you realize you need a feature (e.g. caching), you'll have to implement it yourself.

The sooner you switch over to Django, the better and easier your life will be.

</comment><comment><USER9> <http://webpy.infogami.com/docs> \- documentation <http://groups.google.com/group/webpy?lnk=oa> \- Discussion Group

We've built <http://www.barcoderobot.com> using it ...

</comment><comment><USER10> No, I'm not using web.py. I started out using it and switched to Pylons, because web.py was too simplistic for my needs, and because a nasty security gaffe Aaron made eliminated my trust in his ability to write secure code.

<comment><USER4> That security gaffe was in Markdown - a piece of junk that I've been pointing out flaws in for the past year.

<comment><USER10> That's not the security gaffe I'm talking about.

<http://groups.google.com/group/webpy/browse_frm/thread/2fcbcb60a99a1c79/>

Aaron's mistake is at post #4, my response is post #5.

Yeah, that's from a while ago. That's about when I stopped using web.py, too.

<comment><USER4> Yes, I understand your concern. For sure, aaron was on drugs when he mentioned this quick, non-secure fix -- even though the asker most definitely had very loose security requirements given that he was using nothing more than CGI.

\ _But\_ from the beginning, everyone using webpy has seem to know flup sessions to be the recommended way of doing sessions:

<http://webpy.org/track/wiki/SessionsWithFlup>

Let's look at this another way though. If you _really_ need security, then which is better: a simple, quickly verifiable codebase like webpy, or a massive, magical code base like django and turbogears? Do _any_ frameworks make any guarentees of security?

I have seen several high profile sites within the last two years with major, obvious security problems. As hard as this is to believe, I no longer think that security is what will determine the success of most any web app -- at all. Unless you have special needs, _feelings_ of security should not be your primary metric in evaluating a framework.

<comment><USER10> Luckily I don't use a massive, magical code base like Django or TurboGears. I use Pylons, which is small enough that you can understand it all, large enough that you can actually do useful things with it, and written by some very smart people.

</comment></comment></comment></comment></comment><comment><USER11> I've been pretty happy with web.py for two web apps:

<http://www.colr.org>

<http://www.daltonlp.com/blog_my>

And a bunch of small one-off things.

I like it. It's not perfect - the templating system in particular is not as nice as what it aims to replace (cheetah & kid). Yet.

For all the complaining about NIH, web.py has done a pretty good job of playing nice with other layers in the web stack (fcgi/flup, cheetah/kid). The parts that are reinvented have been reinvented in quite different (and better) ways than other frameworks. i.e. Request dispatching and DB interaction.

</comment><comment><USER12> People seem to really dislike frameworks and I know they can be more trouble then they are worth at times but I really like TurboGears. It's python based, sits on top of CherryPy (webserver) and you can take as much or as little as you need. It has a great philosophy of pulling in all thats good from all over the python world and loosely coupling it together in to a framework. It's not perfect by an means but it's a lot better then inventing that wheel again!

</comment><comment><USER4> No and Yes. I am thinking of releasing tons of code for it though as soon as I wrap up the large project I'm working on.

I highly recommend webpy.

edit: downvote?

</comment><comment><AUTHOR> Thanks folks for your thoughts..

</comment><comment><USER13> no.

switched to django

</comment><comment><USER14> It will be interesting to see if web.py jumps on the facebook apps bandwagon before its competitors Rails, Drupal or Cheetah. Is Aron the next Zuck?</comment>


Boeing altered key switches in 737 MAX cockpit limiting ability to shut off MCAS - <AUTHOR> https://www.seattletimes.com/business/boeing-aerospace/boeing-altered-key-switches-in-737-max-cockpit-limiting-ability-to-shut-off-mcas/ <comment><USER2> What is the endgame now for 737 MAX planes? Every airline using them has had several weeks to totally reorganize to deal with these huge missing parts of their fleets.

Boeing keeps talking about fixing them and putting them back in the air, but I dunno. At this point, it should be agreed the fundamental design flaws are serious, and Boeing should have simply made a brand new plane, with much more modern controls and predictable maneuvering. Yes, pilots would have to be certified for these new plans, but that cost pails to the money lost from these grounded fleets.

I'd honestly like to see the 737 MAX taken out of service and Boeing simply ending this line. The old planes should be stripped for parts and as much recycled as possible. It's going to cost them a lot of money, and it should. Their mistakes lead to the deaths of two whole planeloads of passengers. Airbus, Bombardier and others will probably make a lot out of this disaster, and that's probably a good thing and will help competition in this small/narrow market.

<comment><AUTHOR> > What is the endgame now for 737 MAX planes?

The bugs will be addressed and they'll still fly. Airlines have no choice, there's a limited capacity in the world for airplane construction, several thousands of orders on the books for the 737 and 320 waiting to be filled. What can an airline do? They can cut back some orders but not all orders.

> I'd honestly like to see the 737 MAX taken out of service and Boeing simply > ending this line.

I have an alternate history fantasy where instead of going with the MAX and then trying to kill the C-series as they did, they instead bought into the C-series. Swapping the cockpit for a Boeing cockpit design. Built the -500 stretch of the C-series, and then used the C-series to replace the 737 line in the <165 pax market. And moved ahead on the 797/NMA for which they'd have a shorter version covering the 200-270 pax market as a pure passenger mover as it's proposed.

<comment> old-gregg > The bugs will be addressed and they'll still fly.

The engines are mounted incorrectly, so much so that Boeing believed pilots need the assistance of MCAS on take-off now.

The bug isn't with its algorithms, rather the need for MCAS to begin with. They can't "address" it. That's why I'll be very careful not to ever book a flight on a 737 Max, probably easier to simply stick to Airbus-only airlines: Jetblue, Alaska/Virgin, etc.

<comment><USER3> > The engines are mounted incorrectly, so much so that Boeing believed pilots > need the assistance of MCAS on take-off now.

This overstates the issue. The engine mounting changes the flight characteristics enough that the MAX 8 needs to be flown differently in certain corners of the flight envelope. The MCAS was added to avoid having to re-train pilots or trigger a new type certification.

The engine mounting certainly does not make the plane unsafe.

<comment><USER4> > The engine mounting certainly does not make the plane unsafe.

I don't think this is a very...'precise' statement. what is "safe" in the context of aviation? If you had no MCAS, then this plane has a very bad propensity _to stall_. I hope we can both agree that's an _unsafe_ airplane. You can't just say "don't do that [pull up too much] and then you're fine". The aircraft "wants" to pitch up too high and stall, which predicated the MCAS system itself. So to me, yeah the engine mounting (in and of itself) makes this plane quite unsafe.

Now, with a properly functioning MCAS it may be "safe", but when the MCAS is itself another point of failure, my opinion is that the aircraft is only safe on paper, while in practice it's just got too many hacks and kludges for it to be practically safe for the millions of safe flight hours that these things are expect to deliver.

<comment><USER5> No, it did not "have a bad propensity to stall". That's a very imprecise statement in the first place but if you take it to mean, it would try to stall during normal flight conditions, it's definitely false.

Airbus aircraft are "safe" despite the fact that dual conflicting pilot input is averaged without stick feedback (see the Airfrance flight from Brazil). If electronics being used to fly the aircraft upsets you, you're going to be in for a real shocker on any airbus.

<comment><USER6> So much ignorance and misinformation about this issue even on HN.

The parent comment and entire thread is 100% correct. There is nothing inherently unstable or unsafe about the MAX 8. It has a pitch-up characteristic that's mild compared to some other commercial jets like the 757.

The only reason MCAS was put on that plane was to allow the MAX 8 to share a type rating with the rest of the 737 family, to make it so that it handles like any other 737 despite the pitch-up characteristic.

Go ask any commercial pilot, go watch any of the commercial pilots on youtube who have commented on this, go look on stackexchange. The notion that the MAX 8 is inherently unstable, or unsound, or dangerous, is a laughable myth to anyone in the industry. I get that the news cycle is financially rewarded for fearmongering, but I really expected people who frequent HN to know better and do some cursory research into the topic rather than posting comments that perpetuate bullshit.

There are several major issues with what boeing has done, such as the alleged failure to reclassify MCAS as a critical system after flight testing. But instead of discussing these legitimate issues, public debate seems to have been directed towards a bullshit myth about the airframe being inherently unstable. This has been eye-opening and dispelled my notion that HN had above- average quality of discussion on technical topics.

<comment><USER7> Nobody who isn't an engineer wants is terribly interested in the argument that a model of plane that has killed 2 planes full of people recently is in anyone's opinion safe.

Personally I won't fly on one in my lifetime.

I'll leave the analysis of why to others to figure out why I fly on other airplanes.

Incidentally I have seen pilots argue that the max is inherently unsafe on this forum which is probably why people are reiterating it.

What is your area of expertise and what is your opinion?

<comment><USER8> Actual engineers do care about the "why" since that's what matters. Otherwise don't bother flying on any aircraft since all models have crashed at some point.

<comment><USER9> Your second sentence is too glib. By just about any statistic you want to look at, the MAX-8 has an abysmal safety record. Probably worse than any other aircraft in revenue flight.

It's perfectly rational to look at the results, regardless of "why", and decide that the risk is just too great.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> It has been fascinating to watch layer after layer peel back around all of this.

Bad design decisions forced from chasing the bottom dollar, optional, critical safety features with the warning indicator and now these switches.

> Boeing declined to detail the specific functionality of the two switches

That's also interesting- I assume they are in CYA mode and wouldn't discuss anything that could be sensitive to the current investigations in any point. I wonder how hard the Seattle Times had to work to get manuals for the MAX.

I hope the loss of life is vindicated in the end.

I hope there are lessons learned from this but I fear our culture of quarterly profits and lack of real punishment for companies and their directors will result in nothing drastic happening.

<comment><USER11> One of the lessons learned is that the FAA is no longer a credible institution.

<comment><USER12> Gotta love deregulation. How many institutions are left? Any? CFPB, EPA, HUD, Interior are all run by people that don't believe in their missions. It's all about undermining from inside. Who protects the public when private rights of collective action are forbidden by arbitration agreements and the government has been captured by private interests?

<comment><USER13> The Nuclear Regulatory Commission is doing just fine in their function.

<comment><USER2> True, but I also doubt we'll see new nuclear facilities in the US any time soon.

<comment><USER14> Some of these applications have been withdrawn, but there are in fact some in flight.

[https://www.nrc.gov/reactors/new-reactors/col/new-reactor- ma...](https://www.nrc.gov/reactors/new-reactors/col/new-reactor-map.html)

<comment><USER15> > In flight

Hopefully, their planes don't need MCAS ;)

<comment><USER16> I don't know - a lot of those nuclear plant applications seem to stall ;)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> So a lot is known at this point:

1\. The A320neo caught Boeing completely off-guard;

2\. The threat of the likes of American Airlines (already a mixed Airbus/Boeing customer and the largest airline in the world) placing a large A320neo order for regional aircraft operations scared the bejesus out of Boeing management;

3\. For airlines like Southwest that are pure 737, the prospect of adding a plane that didn't share a common type rating with their existing fleet would complicate their lives and make them vulnerable to a sales pitch from Airbus; and

4\. The development cycle for a completely new body was too long for many customers as it would arrive several years after the A320neo.

I don't think any of this is in dispute so the constraints for Boeing were to design a more fuel-efficient plane that shared a common type rating with the 737. To get there:

\- They added newer, more fuel efficient engines. These changed the flight characteristics so they had to be moved;

\- These engines moving made the plane more vulnerable to a stall situation. To counter this, they added MCAS, which would point the nose down when the AoA sensor told it the nose was too high;

\- Standard configuration had 2 AoA sensors but MCAS only ever read from one;

\- There was a safer configuration as an optional extra purchase;

\- Telling airlines and pilots about this and providing overrides risked the common type rating.

I don't believe any of this is in dispute. It is widely believed, but not yet proven, that the primary cause of both fatal crashes was a runaway MCAS that drove the planes into the ground. It's also believed that with proper training a pilot may have been able to counter this (as happened the day before the Lion Air crash with a pilot in the jump seat).

Now what I find interesting is the response people have to all this. Some claim this is a fundamental design flaw that puts a shadow over the plane. Others believe it will be corrected and everything will be fine.

I'm firmly in the first camp: the plane CLEARLY flies differently to a 737. An automatic system, with no triple redundancy, was required to correct the flight characteristics of the plane.

I'm no expert but it seems to me the plane is fundamentally flawed at this point.

<comment><USER18> > These engines moving made the plane more vulnerable to a stall situation.

I don't think this is correct. A lot is being made about the engine move with regard to aerodynamic behavior, but it doesn't seem at all outside of the bounds of what is considered standard. Pilots report that a similar 'light stick feel' at high AoA is already present in aircraft like the 757.

It's not that the aerodynamic change was worse or better, it's simply that it was a change at all. MCAS was there to satisfy the type rating. MCAS is not anti-stall.

The crucial mistake appears to be the extreme failure mode of the system; it is permitted to input high stabilizer trim angles without limit. Without any kind of restriction, the failure goes from annoying (pull up on flight stick + fiddle with stab control until you solve it) to the deadly crashes we've seen where pilots are in extremely tricky situations.

The fix could be as simple as making MCAS cutout in the case of an AoA disagree (no real hardware changes here) as well as limiting the input of extreme trim angles.

<comment><USER19> > MCAS was there to satisfy the type rating. MCAS is not anti-stall.

MCAS's _only_ observable intervention is to push the nose down to prevent stall, which means it is by definition anti-stall.

Boeing says MCAS is an acronym for "Maneuvering Characteristics Augmentation System", but a better name for MCAS is "Machine Controlled Anti Stall".

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

<comment><USER20> While the effect of pushing the nose down is an all-too observable effect, that its purpose is stall prevention is not directly observable.

According to this article[1], the intended purpose was to restore the back- force needed to put the airplane in a stall, as the effect of the new engines was to make the control feel lighter at high AofA. The article also discusses the certification requirements with regard to acceptable handling characteristics.

FWIW, Boeing CEO Dennis Muilenburg is quoted in [2] as saying that "When you take a look at the original design of the MCAS system. I think in some cases, in the media, it has been reported or described as an anti-stall system, which it is not. It's a system that's designed to provide handling qualities for the pilot that meet pilot preferences.

"We want the airplane to behave in the air similar to the previous generation of 737s. That's the preferred pilot feel for the airplane, and MCAS is designed to provide those kinds of handling qualities at a high angle of attack."

Of course, the elephant in the room not being mentioned here is whether Boeing's primary motive for replicating the handling characteristics of earlier versions of 737s was an overriding concern with avoiding pilot training.

[1] [https://leehamnews.com/2019/02/15/bjorns-corner-pitch- stabil...](https://leehamnews.com/2019/02/15/bjorns-corner-pitch-stability- part-10-wrap-up/)

[2] [https://www.businessinsider.com/boeings-ceo-on- why-737-max-p...](https://www.businessinsider.com/boeings-ceo-on-why-737-max- pilots-not-told-of-mcas-2019-4)

<comment><USER21> One of the requirements for an airplane to receive a certification is that the pilot needs to put more and more pressure on the stick to achieve higher and higher angle of attack. If at some point the airplane starts to pitch to higher AoA without extra pressure from the pilot, that's a big no. Reason: otherwise it would be all too easy to inadvertently enter a stall condition.

Boeing 737 MAX without MCAS violates that requirement (caused by the lift generated by large engine nacelles in front of the wings). MCAS is indeed designed to restore that required back-force. Back-force that is required to prevent stalls.

I suppose one could debate whether the stall prevention effect of MCAS is direct or indirect. But I don't think it's debatable that it is designed to comply with a certification requirement that's intended to help prevent stalls.

<comment><USER20> You have a point, though, from what I have read, I do not think the airplane would become unstable prior to the stall, merely less statically stable than its predecessors.

Boeing may be denying that MCAS has a stall prevention purpose only because to say so might put it in the critical systems category, requiring additional training. If so, this would apply as much to the fix as it does to the original version. To acknowledge that it has a stall prevention function might require an additional AofA sensor as well as additional training.

</comment></comment></comment></comment></comment></comment><comment><USER22> One thing that appears concerning in the series of articles being written about the 737 Max incidents is that they suggest a culture at Boeing of speed/cost over safety.

Now we can assume that the Max won't re-enter service until this issue is completely solved (I'm sure regulators will be extra-scrupulous here and customers will want cast iron re-assurance).

However, is anyone going over all the other safety decisions and changes made to other Boeing models over the period of the Max development?

It seems unlikely that this was an isolated incident of rushing things for commercial benefit...

<comment><USER2> I'm actually wondering if the 737 MAX will make it back into service. Every single one of these planes will need to be flow back to one of their maintenance centers (like the one south of Seattle) and undergo retrofits.

Hopefully it will result in Bowing being required to make this a new plane and a lot of pilot re-certification. If it does return to the market, I wonder if they'll be forced to rebrand it. It's obviously not a 737.

<comment><USER23> Bugs tend to appear in Poisson law of probability: 2 big bugs immediately, 2 others a few weeks later, but that means there are hundreds of them to discover over a period of 5 years (until the D-check).

So, in all probability, we don't even know the list of fatal flaws even yet!

<comment><USER24> It's a 737 with lower engines.

The flaw is using software to fix a hardware issue.

</comment></comment></comment></comment><comment><USER25> It strikes me how a seemingly insignificant decision at the time - to position fuselage slightly higher above the ground - gave Airbus a strategic advantage 50 years later. It forced the competitor into a services of unexplainable and reckless decisions that break basic principles of reliable engineering. Which in turn led to a very visible disastrous business consequences: Boeing had to silently reduce 737 MAX production despite having secured orders for over 5000 planes. A case to be studied in business schools.

<comment><USER26> basic principles? i think that's a bit far. the plane isn't inherently unstable is it? i thought it's just the black box of MCAS that is the problem and MCAS is there to avoid a lengthy type certification. it's completely explainable.

and it wasn't seemingly insignificant. it was for fuel efficiency. it was significant and they knew what they were doing.

<comment><USER25> They had to install MCAS _because_ the plane was unstable in high AoA mode, i.e. during takeoff.

And it was unstable because larger CFM engines could not fit under the wing anymore so they had to put it further forward and a bit up. This increased the pitch up moment when a full power is applied.

Also, can't really see how the height of the fuselage above the ground affects fuel efficiency.

<comment><USER27> > They had to install MCAS because the plane was unstable in high AoA mode, > i.e. during takeoff.

Forgive me if I'm missing something, but isn't MCAS disabled while the flaps are extended, which is the case during takeoff and landing?

<comment><USER25> You are right though pilots prefer to retract flaps soon after liftoff since extended flaps mean more drag and less efficiency. And the danger comes from the low altitude thus no margin for error.

In the doomed ET302 flight they retracted flaps 62 seconds after liftoff at only about 1200ft above the ground. MCAS kicked in 5 seconds later. Had autopilot been engaged it'd also had saved them from MCAS trim down commands.

</comment></comment></comment></comment></comment><comment><USER28> I just wanted to note that Dominic Gates and the Seattle Times have been the gold standard for reporting on the 737 MAX. Really great work by them on reporting a technical subject so non-experts can understand.

</comment><comment><USER29> Taking a forward view — I think FAA needs a way to defray the impact of operational costs by incentivizing the uptake of changes that produce safety improvements.

The ultimate economic reasoning for the 737 MAX was entirely to reduce operational cost: "give us a plane with better fuel efficiency that we don't have to pay to train pilots for!". This is actually a deeply broken incentive that, I think this case shows, should not exist. The plane delivered is objectively far worse than it _could be_ were it not for the need to reduce operational cost.

Ultimately — some large portion of that operational cost is induced as a result of the need to comply with safety regulations. That creates downward pressure on unecessary experimentation but also has created this very perverse incentive to design planes that are _deliberately_ not as safe as they could be given application of some approximation to "our best engineering knowledge".

Pretty early on in the design process for the 737 MAX — there shouldve been a meeting with regulators. The regulators should've been presented with this option and the design and economic reasoning for it — and they should've also been presented with another option wherein there was a relaxing of the need to defuse operational costs. The regulators should be empowered to then say "don't build this broken plane, build the safer plane and we will introduce tax credits sufficient to help offset the airlines retraining costs."

</comment><comment><USER30> So they removed a useful, granular functionality (switching off autopilot trim input while retaining electric-assisted manual trim) and made one switch simply a redundant backup, merging the previously separated functions without clear explanation.

A cynical man could be inclined to think that with this change, they casually removed a possibility of pilots/airlines realizing the existence of MCAS: "we have thrown off the right switch to unlink the autopilot from the trim motor and there is still _something_ making automated stabilizer inputs, what could it be?"

<comment><USER31> > So they removed a useful, granular functionality ... without clear > explanation

I'm as negative as the next person when it comes to the 737 Max, but this is just a bit to far. Read the rest of the article and you'll understand a logical reason why this was done and how it was communicated.

<comment><USER32> What was the reasoning?

<comment><USER31> The linked article says why, but to paraphrase, the training has always said to flip both switches. Previously the only time you'd need to flip the switches was due to an electric motor being stuck-on. It's only with the MAX that there was an actual useful reason to flip one vs the other, but the training was always to flip both and Boeing decided to simplify it.

My personal guess is that it was internally totally disparate teams inside Boeing and neither communicated about the change. Is that bad? Certainly. But how often does that happen in big companies? All the time. Sadly it might have had a part in causing fatalities in this case, but doesn't make it any less common.

Either way, it's not like the change definitively had any bearing. Turning off all electronic control was still the training given to pilots and then reverting to manually turning a wheel that controlled the horizontal stabilizer via cable. It's not an easy thing to do (turn the wheel manually), especially during a nose dive, but it's been done before in an emergency and pilots are trained on it.

Ultimately, the FAA had a prestigious record due in part to having excellent checks and balances. Whoever decided to move away from DERs to ARs ultimately should get the brunt of this blame, but sadly, that'll never happen.

<comment><USER33> Just to spare others from the search:

Before 2004, those Boeing technical employees who worked safety on behalf of the FAA were called "Designated Engineering Representatives," or DERs. Though paid by Boeing, they were appointed by the FAA and reported directly to their technical counterparts at the FAA.

What changed since 2004 is that safety engineers, now called Authorized Representatives, are appointed by and report to Boeing managers.

The opaque bureaucratic name for this new structure — Organization Designation Authorization (ODA) — masks the significant change: Instead of having individual Boeing employees authorized as FAA reps, Boeing now has an entire organization within the company so authorized. The individual FAA Authorized Reps — Boeing engineers — report up the chain to their Boeing managers, not the FAA.

source: [https://www.seattletimes.com/business/boeing- aerospace/engin...](https://www.seattletimes.com/business/boeing- aerospace/engineers-say-boeing-pushed-to-limit-safety-testing-in-race-to- certify-planes-including-737-max/) Interesting read.

<comment><USER31> Thanks! Spot on source and agree, it's a good read.

</comment></comment></comment></comment></comment></comment><comment><USER34> >A cynical man could be inclined to think that with this change, they casually removed a possibility of pilots/airlines realizing the existence of MCAS: "we have thrown off the right switch to unlink the autopilot from the trim motor and there is still something making automated stabilizer inputs, what could it be?"

It's worse actually. They've taken a procedure, and are raising it on a pedestal as if to say "See, this is how a 737 flies! It's all right there! You can stop looking now!"

It's as if they don't want anyone to realize that this plane simply does _not_ fly like a 737. Which is what has been getting shouted from the rooftops since the first disaster.

What I find wickedly ironic was it was exactly Boeing's insistence to "not inundate" flight pilot's with technical information, and give an accurate accounting of the vast differences in the minute details of the aircraft that created the problem.

Someone looked at the checklist item of "both stab trim switches to cutout", didn't look into what that actually meant, and changed the plane to fit the procedure. This change _cost_ extra effort. Instead of using the same switches and wiring they were using before, they actually degraded the granularity of control of the plane to hide the differences.

I can't imagine the thought process at the time. Be nice to see what the documentation turns up.

<comment><USER35> It's fair to recognize this is not entirely Boeing's fault either: it was the airline industries that don't want to re-train their pilots and wanted this type of plane (American Airlines was specifically keen on getting Boeing to manufacture this plane [1]), so they were kind of told "we want you to make exactly $this, otherwise we switch to Airbus".

[1] [https://www.vox.com/2019/4/5/18296646/boeing-737-max-mcas- so...](https://www.vox.com/2019/4/5/18296646/boeing-737-max-mcas-software- update)

<comment><USER34> Given. However, in Engineering, it is totally expected that when you start getting into areas that sketchy, you say "No. The best I can do is this. I'm sorry."

Instead, Boeing saw dollar signs, and threw caution and people's lives, and years of good will to the winds.

<comment><USER36> The people making the decisions weren't engineers. They were managers. And they just passed the buck to the engineers who actually had to go along with it to keep their jobs.

And I know people will try yo claim that it was the engineers fault and they should have just refused and gotten fired. But engineers have mortgages and have to work for a living. They can't afford to career suicide just because their boss is being unreasonable.

The people who made the decisions should be held accountable. That means the CEO should actually go to prison.

<comment><USER37> There's also a lot more understanding of the corporate and political culture against whistleblowers, so even engineers or managers with good morals would not risk the backlash of endless lawsuits or corporate shaming. We should add this to the list of contributing factors given that a few whistleblowers have only come forward after-the-fact.

</comment></comment></comment></comment></comment><comment><USER38> Off topic, but oh man does that website embody everything that is wrong with display advertising. Left the site open for 6 minutes: 8000 requests, 100MB transferred and a memory footprint of 700MB for that tab and climbing. Absolute garbage.

<comment><USER39> This article requires more computational resources than a Cray-2 supercomputer (1985).

It loads much better in Lynx with a tiny fraction of the resources.

</comment></comment><comment><USER40> Wait, what? Reading this is turns out that flipping both switches on the centre panel not only deactivates MCAS, but also deactivates the thumb switch on the control wheel that the pilots routinely use to change the elevator trim.

So, MCAS trims the plan to a dangerous attitude, then when pilots follow Boeing's SOP to disable, they lose the ability to re-trim the way they have done it a million times before? I can see valuable second being eaten up when pilots flick the thumb switch towards them and sit there wondering why the back pressure isn't easing up.

And the report also says that the manual trim adjustment wheel would be harder to move due to the load on the tail when the aircraft is in a nose (death) dive? This is already on top of the fact that the pilots have to hold around 60Kg back pressure on the control wheel while leaning forward to crank the manual trim wheel?

Recipe for absolute disaster.

<comment><USER41> Yes, exactly. The MAX "stab trim cutout" simply disabled the trim motor altogether. Everything you describe appears to have happened in the Ethiopian flight report. A 737 pilot also tried to run the same flight in simulator and had his arms wrapped around the control column trying to hold level while the copilot failed to move the trim wheel.

<comment><USER42> >737 pilot also tried to run the same flight in simulator

[https://news.ycombinator.com/item?id=19627660#19627755](https://news.ycombinator.com/item?id=19627660#19627755) That video was removed :(

</comment></comment></comment><comment><USER20> ' _The company said the two switches "were retained for commonality of the crew interface. "_'

...and without that commonality, the FAA might have required additional training?

<comment><USER34> Got it in one.

</comment></comment><comment><USER43> I don't understand why there's not something that just allows the pilots to completely turn off all autopilot systems without also turning off hydraulic supports? It seems like if they turn off autopilot it makes the steering become not powered or something?

</comment><comment><USER44> What changes should be made at the FAA (or international equivalents)? Clearly they weren't able to do their job of ensuring the aircraft were safe. They must share some of the responsibility, but how could we improve them?

</comment><comment><USER45> fack man, this is some crappy vendor releasing un-documented APIs.. Except this is a machine that is carrying hundreds of lives.

Regulations needs to ensure every little detail about these planes are articulated to the end-user.

</comment><comment><USER46> > As various warnings went off in the cockpit, they never reached the > conclusion to use the runaway stabilizer procedure.

We continue to put the microscope on Boeing but this is why there is a person in the cockpit: to oversee the planes automated systems. There were multiple failures, and while we pick apart Boeing, we have not done the same to the pilots.

<comment><USER47> Read up on the extensive reporting on both accidents. They never reached that conclusion because it was absolutely unexpected, as a result of Boeing's stealth changes to the aircraft.

There was an article recently where they put very experienced pilots in a simulator under the same conditions and they all failed.

<comment><USER48> But at least one aircrew in the real world actually succeeded.

<comment><USER49> True, but this seems to sound like, "if we just hire the right people none of these safety procedures would be necessary". If we only had ethical people we wouldn't need laws.

Its more important to focus on the processes rather than the individual people, especially because even great people can have off days.

<comment><USER48> My point was that we should figure out why one aircrew worked it out, and one did not. If we want to fix the process, we have to consider the humans. I get the impression from this whole debacle that one significant contributor to the accidents was that Boeing's idea of what the procedures should be and what pilots actually do is different enough to be catastrophic. Putting everything else aside for a moment, this has to be a lesson about how procedures are designed and documented. It does no good to decree how something should work if the operators won't, as a practical matter, ever follow those instructions.

Edit: This seems to be unpopular. I am curious how you guys would do it differently? Just document the controls and provide no procedural recommendations? Interesting.

<comment><USER50> It's like seeing someone make a half court shot in basketball at the buzzer and wondering why other players don't do the same. You could adjust the probability to it being a 3 pt shot, dunk, or free throw.

The failures in the Boeing 737 introduced a significant probability of unrecoverable failure. The fact that a few pilots managed to recover does not mean that the ones who didn't recover did something wrong.

On the other hand, the fact that 2 crews with over decades of safely flying planes were unable to recover from the same plane indicates it had a lot to do with the issues in the plane.

<comment><USER48> Sorry to confuse, I am not really interested in assigning blame. I am more interested to see what can be learned from this so flying continues to get safer. That will include looking at how the pilots responded to the training material in practice, and figuring out how that plays into designing future procedures, documentation, and training. I get that nobody here seems to have much appreciation for human factors, but I fly a lot. I do care :)

<comment><USER47> The entire discussion does revolve around human factors; how decisions were made, how the changes were designed to avoid the need for retraining, and in this specific article, designed to hide a change under the guise of preserving standard procedures for the people flying the plane. I'm not sure what other angle you're after.</comment></comment></comment></comment></comment></comment></comment></comment>


Is is possible to lead a company socratically? - <AUTHOR> http://alejorivera.com/post/91568537557/is-it-possible-to-lead-a-company-socratically

<comment><USER2> I'd love to hear his employees opinion on whether this is a good idea or just vastly irritating.</comment>


Elon Musk, Steve Jobs and the Rule of Awkward Silence - <AUTHOR> https://www.inc.com/justin-bariso/why-intelligent-minds-like-elon-musk-steve-jobs-embrace-rule-of-awkward-silence.html <comment><USER2> Strange not to use this example that was discussed quite a bit recently:

[https://www.cbc.ca/news/politics/trudeau-trump-george- floyd-...](https://www.cbc.ca/news/politics/trudeau-trump-george- floyd-1.5594918)

Also, seems like a misuse of the phrase "emotional intelligence". I mean, this article is talking precisely about _suppressing_ an emotional response and using your intellect instead and how important it is.

Or maybe emotional intelligence is just a misnomer in general and this is what it always means, not being emotional in order to gain an advantage through intelligence?

I don't know, but there's cognitive dissonance for me in that "emotional intelligence" always vaguely implied to me a different, privileged type of "intelligence" that's better that regular "intelligence" and this article is implying that emotions just make intelligence worse.

If I think about what I really believe, I think when people in other contexts talk about _lack_ of emotional intelligence, I guess that how I might rephrase the problem is that people who are identifying as _unemotional_ are frequently really not; they are motivated by their own emotions to the point where they confuse them for objectivity. Which leads back to the idea that pausing could help you detach from that.

</comment><comment><USER3> There is something about this article's style of writing that I just hate. I can't quite figure it out but it reads to me like a bunch of filler around buzzfeed spam or something.

Contrast that with the actual content which I found unique and super insightful.

I think it's too easy to put these 2 individuals on a pedestal but this is genuinely good advice from smart people I should pay attention to.

</comment><comment><USER4> This is so interesting and so difficult. Van Vogt wrote about the cortical- thalamic pause in Null-A (1948), you could almost read this as vindication of Korzybzki and Van Vogt.

</comment><comment><USER5> Keanu Reaves is another example.

<comment><USER6> I wonder if Obama has any of these on video?</comment></comment>


Firefox 10.0.2 fixes libpng integer overflow bug - <AUTHOR> http://www.browsomatic.com/2012/02/firefox-1002-fixes-libpng-integer.html <comment><USER2> This looks like an ad-wrapper around the information from [https://www.mozilla.org/security/announce/2012/mfsa2012-11.h...](https://www.mozilla.org/security/announce/2012/mfsa2012-11.html) .

<comment><AUTHOR> Great invention! Why don't you appreciate the other information provided?

<comment><USER2> Invention? I fail to understand.

In any case, in your posting (I see that you wrote that info tidbit):

1) most of the page was advertisement. I don't mean only the various side-bar and in-line ads, and massive numbers of links to other content from the same site, but the text itself including things like "Attackers can exploit your PC remotely" where "exploit" had a mouseover to an ad to "Watch TV live" and "your PC" was an iPhone mouseover ad.

2) the information was wrong: there is no known exploit. The actual published bug "allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors that trigger an integer truncation". This may or may not be an exploit.

<comment><AUTHOR> Apologies for my early reply

Actually the link mentioned in the post says this

"An integer overflow in the libpng library can lead to a heap-buffer overflow when decompressing certain PNG images. This leads to a crash, which may be potentially exploitable."

which may be potentially exploitable

that's what is mentioned in the post.

Also check this

[http://blog.mozilla.com/security/2012/02/17/mozilla- releases...](http://blog.mozilla.com/security/2012/02/17/mozilla-releases-to- address-cve-2011-3026/)

Regarding mouse over ads, apologies for not providing a good reading experience. Since the original link is in blue and the ad is in green, I thought it was easily distinguishable. I will look after it.

Thanks for the comment :)

<comment><USER2> "May be potentially exploitable" is not the same as "can". Your article several times says "can".

I hate reading spam-filled "news" sites, and would rather read the original news, or insightful commentary. As this is "Hacker News", the commentary you provided was not insightful to its expected audience.</comment></comment></comment></comment></comment>


Git underground features - <AUTHOR> https://medium.com/@mauriciogior/git-underground-features-1f7e981f2639 <comment><USER2> Good list but not _so_ underground.

`git commit --amend` is frequently used if you're using Gerrit for code review.

<comment><AUTHOR> I agree. The 'new' for me in this one was to append your staging area to your latest commit instead of just changing its message.</comment></comment>


A billion dollar gift for Twitter - <AUTHOR> https://medium.com/startup-grind/a-billion-dollar-gift-for-twitter-8b3d541b9e1e <comment><USER2> Really solid advice for everybody really. Especially the first point!</comment>


Ask HN: Why is Docker useful? - <AUTHOR> I have several Python web apps hosted on Heroku (Flask & Django). After hearing a lot about Docker, Kubernetes and containers in general, I began to wonder whether I need them or not. Can you please explain what is the perfect use case for Docker is (or other container tech for that matter)? What is the utility of using it? Does it worth the additional complexity? Thanks! <comment><USER2> Docker and Kubernetes are not the same thing and solve different issues.

Containerization (Docker, in this case) packages up dependencies into a working piece of code that can theoretically be deployed with the same operational results in dev, staging and production. It can be very useful if multiple services have dependencies that would otherwise conflict with each other if all installed on the same base operating system. Containers are faster to start up than virtual machines and can have less overhead. Their images are typically smaller than their VM counterparts. Most folks don't likely need the default overlay network it creates and can simply use --net=host to treat their container as yet another service.

Kubernetes is orchestration of containers / services and overlay networks. It certainly can be overly complex and should only be used if your application can be wrapped up in that layer of orchestration. One size does not fit all. In other words, taking a complex set of applications from your IT org and throwing them into K8's can be non trivial and can lead to complexity / fragility as a service. You have to research this topic completely and first understand your goals of how you are going to tie all your services together.

</comment><comment><USER3> The biggest immediate benefit I think docker has:

The ability to rapidly enable local testing for dev teams (and new hires).

Imagine you have a team implementing a mysql infrastructure but it won't be done for 2 months. The developers need to start coding using this mysql infrastructure ASAP.

Using Docker, you can just pull a mysql image and have your dev teams develop locally using this image as their app's backend.

You could also deploy that mysql image onto a dev server - now you have instantly enabled the dev teams to start working against an infrastructure that won't be ready for another 2 months.</comment>