skysight-inc/HackerNews huggingface dataset:
I see two reasons for this:

- If you don't use google container engine (hosted kubernetes, also known as GKE), kubernetes have a reputation of being hard to set up. I am running on GKE, so I can't comment too much.

- It's hard to see how all of the orchestration/docker/etc. things play together when entering the area. I expect many people hear "docker" and want to just try "docker", not being aware that there exist alternatives for some parts, some parts are more reliable that others, etc. E.g. the article we are discussing seem to be doing this.
<ironic> right... and you also can simulate initial conditions to infinitely arbitrary precision as well.
I'd love to hear about the tools which almost completely mitigate parallelism errors.

The author's list of things that are wrong with "software engineers"' code is 50% "things that are just language features" and 50% "bad ways to use language features that nobody thinks is best practice in software engineering".

Part of the irony is that lot of the more hairy software engineering techniques that he decries are used by the people writing platforms and libraries that scientist programmers use, to make it possible for their "value of everything, cost of nothing" code to actually run well.

There is a big difference in attitude between scientist programmers and software engineers.

Often, a scientist already has the solution to the problem, and is just transcribing it into a program. The program doesn't need to be easy to understand in isolation, because a scientist doesn't read programs to understand somebody else's science, she reads the published peer-reviewed paper. After all, if you wanted to understand Newtonian dynamics, you wouldn't start by reading Bullet's source, even if it's very well written. (I don't know if it is.)

Conversely, for a software engineer the program is a tool for finding the solution. Even though they're in a scientific field, if it's accurate to call them software engineers they'll be from a background where the program itself is the product, rather than the knowledge underlying the program.
The question is will they come to invade our planet?
The security exec at Pivotal, where I work, has been talking about "repaving" servers as a security tactic (along with rotating keys and repairing vulnerabilities).[0]

The theory runs that attackers need time to accrue and compound their incomplete positions into a successful compromise.

But if you keep patching continuously, attackers have fewer vulnerabilities to work with. If you keep rotating keys frequently, the keys they do capture become useless in short order. And if you rebuild the servers frequently, any system they've taken control of simply vanishes and they have to start from scratch.

I'm not completely sold on the difference between repair and repave, myself. And I expect that sophisticated attackers will begin to rely more on identifying local holes and quickly encoding those in automated tools so that they can re-establish their positions after a repaving happens.

But it raises the cost for casual attackers, which is still worthy.

[0] https://medium.com/built-to-adapt/the-three-r-s-of-enterpris...
This is a mess of an essay and does little to persuade me that allowing domain experts to have free reign to make software messes is in any way a good idea.

One of the criticisms applied to software engineers -- the one about bad abstractions like "DriverController" and "ControllerManager" etc. -- is a huge pet peeve of mine because it's basically a manifestation of Conway's Law [0]. It indicates that the communication channels of the organization are problematically ill-suited for the type of system that is needed. The organization won't be able to design it right because it is constrained by its own internal communication hierarchy, and so everyone is thinking in terms of "Handlers" and "Managers" and pieces of code literally end up becoming reflections of the specific humans and committees to which certain deliverables are due for judgement. This is not a problem regarding best practices at all -- it's a sociological problem with the way companies manage developers.

Domain specific programmers aren't immune to this either. You'll get things like "ModelFactory" and "FactoryManager" and "EquationObject" or "OptimizerHandler" or whatever. It's precisely the same problem, except that the manager sitting above the domain-specific programmers is some diehard quadratic programming PhD from the 70s who made a name by solving some crazy finite element physics problem using solely FORTRAN or pure C, and so that defines the communication hierarchy that the domain scientists are embedded in, and hence defines the possible design space their minds can gravitate towards.

There is definitely a risk on the software development side of over-engineering -- I think this is what the essay is getting at with the cheeky comments about too much abstraction or too much tricky run-time dispatching or dynamic behavior. But this is part of the learning path for crafting good code. You go through a period when everything you do balloons in scope because you are a sweaty hot mess of stereotyped design ideas, and then slowly you learn how only one or two things are needed at a time, how it's just as much about what to leave out as what to put in. The domain programmers who are given free reign to be terrible and are never made to wear the programming equivalent of orthopedic shoes to fix their bad patterns will never go through that phase and never get any better.

[0] < https://en.wikipedia.org/wiki/Conway%27s_law >
since we are not on GKE already, I want to be able to use k8s to forward to my host machine journald and thats broken. I think Google is doing a lot of handholding to get it working with stackdriver.

This is the blocker for me. I cant switch to GKE already because I use AWS postgresql. But I want to use k8s :(
I'm am not a physicist, but interested in QM. Photons behavior cannot be completely explained by treating them solely as particles. The simples counter example (one you can perform yourself with a laser pointer), is the double-slit experiment. If photons behaved classically (like billiard balls) they'd never interfere with themselves.

If you'd like a good intro to QM, youtube is full of great material. Here are some of my favorites:

NOVA - The Fabric of the Cosmos: https://www.youtube.com/watch?v=NbIcg0XsbFQ

The Secrets of Quantum Physics: https://www.youtube.com/watch?v=VgDlzGZAPcY

Particle Fever: https://vimeo.com/125987472
I find that unneeded functionality also complicates refactoring efforts.
A photon is a wave packet.
Not if you dynamically bind with qt libs. But yes you have to, if you statically bind with qt libs.
I can't judge that by myself, but my external impression that if there is such thing as Western propaganda, it must be incredibly subtle and seamless, omnipotent and omnipresent to be real. Russian propaganda is not a thing you are not aware of as a Russian, it's just that it gets you emotional and grows a self-protection from external believes.

Many Russian medias start to claim "look at the others, they are not better" when confronted with a clear evidence of their lie. Even more, it grows a kind of double-speak: I have an impression that the majority of Russians understood who the Crimean "polite green men" were, but they were still supporting the official narrative in public.

I strongly advise against believing in "all these media are sides of the same coin", it's a well-known instrument of propaganda.
Too much caffeine caused me to suffer acid reflux, so I've had to give it up :( But after a few days of bad headaches, life is as it was before. Hopefully less acid reflux now. But yeah totally addictive. Love it. (Ok: loved it.)
I think he is rather referring to cascades of function calls/types and "custom solutions". Of course abstractions are a great tool when used properly. Thinking of a best practice from Object oriented design: low coupling but high cohesion.

When you use abstractions, you get low coupling. But like everything in life, also this has a price: you may need an extra line of code to instantiate the abstraction and sometimes have to write an extra getter because it's not perfect yet. That's a fine price to pay unless go you use way too many abstractions and they are nested deeply. It may have some aesthetics but it can be hell to debug and overly complicated to extend code.

So that's why one must also focus on high cohesion. I really like the modern JavaScript way, the imports/requires are for low coupling and the build automation is for cohesion. Anyways, these things are best practices as well but not sure if the author took those into account... ;)
Docker is the new mongodb.
Let's just use freebsd jails + postgresql.
Is this a scientifically supported assessment? I say this because I have heard it often, but in thinking about it, I cannot see this necessarily being true. WPF uses XAML, which is similar to HTML or other markup languages in structure. Sure, this is much different than the paradigm where you specify coordinates for all window elements (Win32, WinForms, et al.), but is it proven than a person having no background knowledge or experience in software would find markup-based layout more difficult than coordinate-based layout? Even if so, is the difference big enough to warrant telling all newcomers to use a coordinate-based layout, despite its inherent lack of responsiveness? Yes, XAML has many additional features, particularly in terms of effects, but these need not be used.
> or think it's more appropriate for their users and target public.

I wonder who would that be. Mind you, programmers who shop for an editor are usually very knowledgeable about what they want. They know how to extend Eclipse or Emacs or Atom or VS Code or whatever they have ever laid their hands on.
I'm not sure if you watched the entire video, but I seem to have gotten the impression that all through 2014.. he fixed hundreds of libraries that did not work with Python 3.
Editors are paid a pittance, at most.
If humans write the algorithms then all the subconscious bias of their authors will still influence them.

Algorithms are not holy. Nor is data.
Why would you turn off compression?
A given amount of requests is more burdensome on the CPU when decompression is to be performed.
Smells like corruption to me. Why allow un-tariffed imports, or not have a trade agreement? Somebody probably has their hand jammed quite tightly in the cookie jar.
> You're better off testing at major functional boundaries, and if you do that, the length of functions matters less than the interface major modules provide to each other.

Otherwise known as integration testing, which is far more useful than unit testing because bugs, especially regression bugs, more often occur in the system, than in specific functions.

You can have as many unit tests as you want, but until you have integration test, you have zero coverage for the really complex part of your code.

Unit tests are great for algorithms though.
You can have a swarm with only a handful of commands now, with TLS (for docker api). Eventually stable docker host to docker host container networking will have encryption out of the box too. The number of steps for a production docker setup keeps getting shorter and shorter, kubernetes seems to be now focused on this aspect, they might catch up. This is all of course ignoring the IaaS solutions and obviously for the reasons stated in the article, swarm doesn't see those benefits with 1.12 because major features do not work yet which are supposedly stable.
I've also used ECS for a production system, and have found it to be an excellent runtime for docker containers.
This article should really be about Docker Swarm not being ready for production. It's much newer technology than Docker and is predictably brittle.

The only points made against Docker proper are rather laughable. You shouldn't be remotely administering Docker clusters from the CLI (use a proper cluster tool like Kubernetes), and copying entire credentials files from machine to machine is extremely unlikely/esoteric.

Docker, with Kubernetes or ECS, is totally suitable for production at this point. Lots and lots of companies are successfully running production workloads using it.
You shouldn't need to wrap pulls with flock anymore, the pull code got completely rewritten and should be fine now.

Also hosts shouldn't need to be rebuilt THAT often. Of course, your infrastructure should automatically nuke and replace failing hosts (and there's various ways to establish what's "failing"), and like any good infrastructure team you should be keeping your hosts up to date with security patches, etc, which is best done by replacing them with new versions (as then you can properly test and apply a CI lifecycle), but docker itself is stable enough these days that you don't need to be that aggressive with nuking.

Agree (especially with the comments about orchestrating with kube/mesos) with all the other points, though.
What's the problem?

Google's initial success can be attributed to the effectiveness of the PageRank algorithm, not the quality of the code that implemented it. It doesn't matter if the first implementation (or even the current implementation) was a horrible mess of gotos in a single ten-thousand-line-long function, from the point-of-view of its users.
I never drank coffee or tea until my early 30s even a sip would make my heart race.

Then one day a new job I would sit with coffee drinking coworkers and eventually I tried tea. I had tea each morning about an 8 ounce cup drinking about half or a bit more.

Then another new job setting up a casino before the hvac sysem was in (cold Canadian spring no heat brr) and I stared drinking french vanilla coffee.

Starbucks opened a few years later and I was drinking venti cappuccinos with extra shots even at 10pm.

It got to the point where I needed it to sleep the caffeine calmed me down instead of revving me up. I guess the typical addict story wanted it then needed it; not to belittle true addicts.

I cut down due to GERD later discovered I had hypothyroidism so maybe it was all related. Tea seems to hit me far more than coffee both for heartburn and being jittery.

Even through all that I do think I am hypersensitive my liver can't process caffeine as well as some people. I now drink one small cup of instant coffee per day and that's enough for me. I do suffer withdrawal if I don't drink it for a few days maybe a week.
To be fair, that is kind of a jerk move. They can't resell them as new, and I guess they have to either now sell them as used, or return them to the manufacturer somehow? If you want to try something on and they won't let you, but want to support them, go to Best Buy / Bic Camera or whatever you have locally.
You can prove it retrospectively but you can't predict it in the moment was what I was trying to say.
One of the things I like about K8S is that is serves as the building block for creating a PAAS. I built a small tool on top of K8S for a production run. Deis is doing something similar (and far more ambitious), though they are also creating packages of abstractions called Helm. K8S is flexible and extensible because it doesn't try to be a Heroku, more of a framework for building your own Heroku.

Is there value-added in someone providing the higher level pieces? I bet there is. The flip side is, why did Kubernetes gain so much traction so fast, in a way that Cloud Foundery hasn't?

And if Deis and Helm overtakes Cloud Foundry? (They dropped what they had in order to build everything back from K8S) Maybe there is something CF folks are not seeing about this.
Besides Russia, I see the same on Venezuelan and Brazilian media, at different levels of intensity.

What these countries have in common?
The development hopefully goes further to replace moving objects: humans, cars etc. for rebuilding 3D scenes from video for VR.
I don't like the classification of dwarf planet. The classification should be based on its size, shape, and make up. Instead they classified it based on the number of objects in its orbit, which is so arbitrary and weird. If hypothetically we cleared up the objects and dumped them in Earths orbit, Pluto would suddenly become a planet and Earth would lose its classification.

Just bite the bullet and accept there are a lot of small planets in our solar system, or classify them based on size.
since most people use k8s in the context of GKE.. there seems to be some magic that Google has put in.

But if you read the bug, this doesnt work quite well in the wild. In fact, an entire spec is being written on it and right now the debate is whether to forward to journald and have it proxy further or reimplement a new logging format.
>If you ever feel the urge say something like "but the internet gave us mass surveillance", just stop and think wether you would really complain about hospital waiting times to someone who had to have surgery before the invention of anesthetics

...I'm sorry, I don't understand how that parable is supposed to make sense.
https://en.wikipedia.org/wiki/The_Hercules_Text
Spring Boot Angular 2 starter 2.1.0 released
Hence the "in our models".
@moah - thank you so much for this. This is really awesome. I will take you up on that offer.
Kubernetes definitely runs best on GKE, but projects like kops (https://github.com/kubernetes/kops) are making setups on AWS etc. a lot easier.

You still have to deal with the other drawbacks of those platforms (slow networks, disks etc.) but that's not really a k8s issue.
Is it really a bad example? The typical scare story about trade agreements seems to be that they're going to result in some big scary multinational shutting off the water supply or something.

Is that really the common case or even all that plausible? Or is it just going to be normal businesses like Apple colliding with some country's protectionist policies that are counter to the trade agreement?

Besides, if these supposed kangaroo courts are really so unfair the aggrieved countries could just leave the TTIP.

That seems to be another detail that's glossed over, that somehow these pan-national arbitration bodies are going to be corrupt, but not quite so corrupt that the trade agreement isn't an overall improvement for the countries involved, because otherwise they'd be pulling out of it, right?
Docker founder here.

It makes me sad that you believe that. We're not perfect but we try very hard to keep our users happy.

Are there specific issues that you could point out, so that I can get a sense of what you saw that you didn't like?

Keep in mind that anyone can participate in github issues, not just Docker employees, and although we have a pretty strict code of conduct, being dismissive about another participant's use case is not grounds for moderation.

EDIT: sorry if this came across as dismissive, that wasn't the intention. We regularly get called out for comments made by non-employees, it's a common problem on the github repo.
In side-by-side taste tests, and even when seltzer is free, I almost always choose water, and usually leave containers of seltzer unfinished, and sometimes wait until they go flat before finishing them off if I'm feeling extraordinarily patient.
A Letter in the Name of Science
That was eye-opening, and not just with regard to the titular subject. I'd never thought of energy stored in fields as a consequence of energy conservation.
Thats a lot of ifs that could go away if docker would put some more emphasis on quality.
Minimum wage and rent (high in the very places we most want such stores to exist) seem to set a lower bound on performance below which such things simply can't exist today.

Perhaps if one operated as a non-profit or a co-op so people who loved this stuff could realistically volunteer and keep it going?
Support Vector Networks (1995) [pdf]
Can anyone using Swarm seriously in production post any account of their experiences here? Thanks.
Just as a hint in case you're not aware of this: If you log errors in the format[1] expected by Stackdriver Error Reporting, your errors will automatically be picked up and grouped in that service as well.

1: https://cloud.google.com/error-reporting/docs/formatting-err...
I have run docker in production at past employers, and am getting ready to do so again at my current employer. However I don't run it as a native install on bare metal. I prefer to let a cloud provider such as Google deal with the infrastructure issues, and use a more mature orchestration platform (kubernetes). The author's complaints are valid, and the Docker team needs to do a better job on these issues. Personally I am going to be taking a close look at rkt and other technologies as they come along. Docker blew this technology open by making it more approachable but there is no reason to think they are going to own it. It's more like databases than operating systems.
google :)
If I write a program X and tell you it was proven correct, do you know that X is useful?

To know that a correct program is useful, you have to know what it does. And if you know what it does, you have constructed an implementation.

Which is to say that a nonconstructive verifier is really just deferring the 'constructive' part of its operation to the compiler and programmer. (And this is the 'hard part' I was referring to.)
>>...without turning every little international company v.s. company or company v.s. government issue into a full-on diplomatic dispute between the respective governments involved.

The thing is that "full-on diplomatic dispute" is the only fair way to settle that, because governments are chosen by people, so they are legal representatives of them. ISDS on the other hand is some shady institution without any democratic control, and probably sponsored by the very corporations they are supposed to judge.

If you put things in perspective you can see what this TTIP deal is all about: big international corporations like Apple or Google don't like the fact that governments can create laws that they are obliged to respect.

What corporations hate even more is every country having it's own set of laws to follow. So, the whole idea of TTIP is to strip governments (with possible exception of US government) of power over corporations.
> So, can you elaborate on why rebuilding the containers is good advice?

While I sincerely hope I'm wrong, I assume it's because you reset the clock on the probability something goes very wrong.
in principle

You're missing the point, which is

no room for mysticism or "consciousness" nonsense

not anything to do with the limits of computation.
its actually harder to read, in my opinion, since the % character is often used for formatting,eg '%s' % somevar.

personally, i dislike such spammy prs. it adds nothing to my code, and its not like accepting the pr is going to attract you as a developer on my code.