skysight-inc/HackerNews huggingface dataset:
I have the same experience. I am trying to set a new node where I accidentally installed 1.10 and CLI does not work. Looking for some thing on the internet how do X with Docker, only articles available for previous versions. I mean seriously, command line development is not supposed to be this hard, get a set of switches and stick to it unless something major forces you to change. If you shuffle around CLI switches between minor releases nobody is going to be happy.
Sorta off topic Other Music closed/is closing? Wow, I thought its location (close to NYU in a fairly "hip" area of Manhattan) would keep it in business. I remember visiting it often in my freshman year of college when I was really into music—it was rarely empty. NYC rents may be though, but I thought they were doing fine.
All deals on AngelList will soon be private
There is only the mathematics. "Shut up and calculate", as one physicist put it.

Here's Feynman talking about it.[1] "We interpret the intensity of the wave as the probability of finding a photon".

[1] https://www.youtube.com/watch?v=_7OEzyEfzgg
>Sure, but I don't think this is a show stopper. You can and should only carefully upgrade between versions of Docker (and other mission-critical software).

Whether I upgrade carefully or not, the Docker CLI should work with all versions of Docker.
When I first heard about Chat Roulette, I thought the idea was amazing. Imagine hearing about Chat Roulette in 1970, or better yet 1800! How cool. Get connected with random people anywhere in the world! The possibilities! I could talk about war with someone in pakistan, healthcare with someone in Britain, Chavez with someone in Venezuela, learn about cuisine they eat in Uruguay! Maybe I could make a new friend who'd I'd end up visiting some day.

But of course when I say Chat Roulette now, all of you probably just chuckle inside - because it's a good example of how anonymous things on the internet turn out (for those who don't know, Chat Roulette is pretty NSFW, with many nude men on it... breaking down borders, but not in the way I'd have hoped).

I hope services like this become successful as a way to break down borders and form connections across the world - but I'm not holding my breath.

Edit: Maybe I'm part of the problem because I guess I could say the same thing about having a digital personal assistant (Siri) - and I just end up just asking her things like "How many calories are in a cubic light year of butter"? (5.83 x 10^54 kcals for those on MyFitnessPal)
I'm not trying to justify anything. Saying "I don't know" is not justifying, it's admitting lack of information.

> your opinion isn't valuable.

Unlike yours, which is even though I obviously take the effort of not forming opinion before I have the information, while you seem to have formed opinion not only about the situation, but even about my motivations in discussing it, without any information to go on. If you think that makes your opinion more valuable, I think you are sadly mistaken.
One of my favorite authors. The Dispossessed is also a fantastic read which goes far beyond the simple classification of SiFi.
> some opposition from the public

TTIP is highly unpopular in Germany. In recent polls, 70% had unfavorable views about the treaty.

I personally don't know anyone who isn't concerned about it. The concerns I've heard to far were about consumer protection and the investor-state-dispute thing.
6 weeks?! Insane... welcome to the other side!
"On Aug. 27, 1976, a team led by Don Nielson, then assistant director of telecommunications at Menlo Park engineering firm SRI International, drove a specially equipped van 6½ miles south and parked at Zott’s. They ran a cable from the van’s radio to a computer set up at a picnic table out back and used the radio to connect to another computer at the SRI office and on to Boston. The Internet was born."

The internet (ARPANET, at the time) was born when the first packet was sent several years earlier, on 29 October 1969.[1]

This article seems to describe the first time that mobile equipment was used to connect to the ARPANET, which is interesting, but not the birth of the internet.

Also, a network connection on a dedicated radio link was a fun experiment to do, but it didn't make possible the widespread mobile deployment of the internet we have today. That required the building of a cellular phone network capable of sending data at high speeds, which happened many years later.

[1] https://en.wikipedia.org/wiki/ARPANET#ARPANET_deployed
Even better, thanks for that link!
> I predict the Docker fad will end in 2-3 years, fingers crossed.

I work for what is, ostensibly, a competitor and I don't agree.

Containers are here to stay. Docker will pretty much have a brand lock on that for a long time.
One of my secrets is to load reading material onto a tablet and then read it while doing cardio at the gym. This is very good for things for which book learning is effective.

If you want to use, say, maven or spring, you will completely destroy yourself by looking up answers on stackoverflow or google and not understanding how the system works. If your team does it for a few years they will be up sh1t creek and have to pay somebody like me $200 an hour.

Read the manual from end to end a few times and then do it again and you will find systems like this are not so bad when you understand them.
This is pretty dangerous path to failure. If you look at the most successful companies it is obvious that they respect the user base using their service. Software is no exception to that, you have to make it user friendly, regardless if your user base is mostly software and systems engineers.
So far I'm feeling pretty good about the decision to skip the first generation containerization infrastructure.

At the outset it had the look of something that wasn't an advance over standard issue virtualization, in that it just shuffled the complexity around a bit. It doesn't do enough to abstract away the ops complexity of setting up environments.

I'm still of the mind, a few years later, that the time to move on from whatever virtualization approach you're currently using for infrastructure and development (cloud instances, virtualbox, etc), is when the second generation of serverless/aws-lambda-like platforms arrive. The first generation is a nice adjunct to virtual servers for wrapping small tools, but it is too limited and clunky in its surrounding ops-essential infrastructure to build real, entire applications easily.

So the real leap I see ahead is the move from cloud servers to a server-free abstraction in which your codebase, from your perspective, is deployed to run as a matter of functions and compute time and you see nothing of what is under that layer, and need to do no meaningful ops management at all.
I think there's some ebb and flow in what practice is ideal.

There are benefits to a detailed up front design. Conversely there are benefits to jumping straight into code, to get feedback and let the design emerge through real experience.

Unit tests are a nice way to define interfaces. Conversely sometimes it's better to discover an the ideal interface organically rather than setting it in stone up front.

Some of it is just differences in what medium you perform design. People want the medium to be like playdoh so it can be changed. Before they cast it in marble. Some languages are more like marble, some like play doh. But don't ever delude yourself, thinking you have found the best way to design.

Source control is not really software development. It's a very good thing, but in the same way that eating a healthy lunch will assist creating things.
How do you propose to mediate trade disputes between companies and states without something like the ISDS?

Imagine this on say the US national level. Apple wants to sell its computers in Alaska, but Alaska has a domestic computing company that gets goverment subsidizes, creating unfair competition. In this case the federal government would step in.

There's an analogous issue with international trade agreements. National governments will enter into those agreements, but their courts are always going to be biased towards their local constituents, so in my example Apple couldn't hope for a fair result by suing in Alaskan courts.

So there needs to be some pan-national body to settle these sort of disputes 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 ISDS in the TTIP seems like such a facility. Why is it unreasonable? I'm not some TTIP proponent or corporate shill, I'm just genuinely curious about this, it just seems to me that a lot of comments on the Internet, including on HN, have knee-jerk negative reactions to every provision in the TTIP without thinking about the real issues those provisions might be solving.
I think you meant "Kardashev". https://en.wikipedia.org/wiki/Kardashev_scale Unless this was a Kim Kardashian joke.
Airtime is also using ECS to run docker containers in production. We ran into a few issues early on due to early adopter status, but the AWS team was very quick to add many features we needed.

I have no complaints about ECS now, and in fact I'd say that ECS solves a lot of the problems that the author complains here. I'd say that Swarm is not production ready, but docker itself as an engine for running a container is fine. You just need to build your own orchestration layer, or use something like ECS.

More details on Airtime's docker setup here: https://techblog.airtime.com/microservice-continuous-integra...
Err and now for your real question.

Honestly, I don't think you get anything. Lower blood pressure is probably the biggest benefit. But it may be offset by other benefits (coffee may reduce risk of some cancers, diabetes, Alzheimer's and dementia, etc).

IMO the reality is people see addiction as a scary Boogeyman, irrespective of whether the addiction is combined with actual damaging health effects.
Global central backers, stuck at zero, unite in plea for help from governments
Depending on usage pattern also consider reserved instances where you pay deeply discounted upfront price for your instances OR/AND spot instances where you bid for computing power for instances that are suitable for transient loads and doesn't matter if they get terminated suddenly. The good this is that RIs and SIs are integrated with other services like EMR Amazon map reduce or ECS ec2 container service.
This has nothing to do with scientific programming and everything to do with "best practices" being mind blowingly awful. Coupling execution and data is good for data structure initialization, cleanup, and interface. Everywhere else they should just be kept separate. Data structures should be as absolutely simple as possible, not as full and generic as possible.

Where people get into trouble many times is thinking that every transformation or modification of data should be inside one data structure or another, when really none of them should be except for a minimal interface.
FWIW now format shifting has been disallowed again in the UK the percentage of the population committing copyright infringement likely very high -- Mix CD for the car? Infringing. Rip a CD you bought to iTunes? Infringing. Put a DVD you own on your computer? Infringing.

Very briefly UK copyright entered the 20th Century (sic); the balance away from the public interest now is so wrong it's ridiculous.
> ISDS is just another vector with which the rich can buy justice for themselves.

I don't think it's that simple either. It was probably started with the best of intentions and is staffed by well-meaning, competent administrators. The problem is that it's not enough.

In the same way normal US police departments can become vulnerable to subversion through tactics like swatting, the ISDS is vulnerable to concerted attempts to subvert the system for personal gain. And there is every reason for them to want to do so.
I've used K8S before, and those things are smooth once installation happen. We have a project which is looking at using Docker Swarm on a two node set up. The idea is that this will give us a baseline, and since it is looking more and more we'll move to GKE, this sets us up for a later move into GKE. I thought Docker Swarm would be mature enough to handle two nodes, for a short time (maybe half a year) until we make the leap to GKE. But based on the reports coming in from the wild, that's looking less and less likely.

We hired a contractor to do this part. My team is so resource constrained that I don't have time for this, so we farmed it out. But now I'm thinking, the risk of project failure is much higher than I thought, made worse that the contractor is also showing signs of having poor communication skills. (I would rather be updated on things going wrong than to have someone try to be the hero or cowboy and figure it all out).
We use it in production.

It generally works if:

* you don't use it to store data

* don't use 'ambassador', 'buddy', or 'data' container patterns.

* use tooling available to quickly and easily nuke and rebuild docker hosts on a daily or more frequent basis.

* use tooling available to 'orchestrate' what gets run where - if you're manually running containers you're doing it wrong.

* wrap docker pulls with 'flock' so they don't deadlock

* don't use swarm - use mesos, kube, or fleet(simpler, smaller clusters)
Quite the opposite - if the police detains a black person that did absolutely nothing wrong, while they would not detain a white person in the same situation - aren't they the actual racists that actually acted on their racism? Why is that so hard to blame a person who has absolutely no power in the situation except telling the police their opinion - and so hard to blame somebody that has all the power?
I think you are missing the point. It is not about upgrading the production cluster, more like erasing muscle memory and re-learning docker cli again. How often do you re-learn grep, awk, ls, ps, or other command line tools? How mad would you be if these were developed the same manner as Docker CLI? I would be definitely not happy.
On a tangential note, I was happy to see that they're using Solidworks files within git. There are precious few examples of this "in the wild", and after guiding my previous (small, <20-person) company to using git for hardware version control, I always get a bit happy seeing other projects doing the same.

Git gets a bad rap with binary blobs like Solidworks files because merge conflicts are extremely opaque, but that's really not much worse than anything else you've used as a mechanical engineer (at least not in my experience). And, unlike other options -- like the litany of built-in solutions that are "integrated" (if you can call it that) with the CAD program itself -- you get the benefit of branching and sandboxing. Really the only downside (from my perspective) is that you have to be very careful about communicating who is working on what, and being absolutely meticulous about sizing subassemblies in a way that minimizes work conflicts. Beyond that, the biggest hiccup is that Solidworks assembly files are rather... poor abstractions... and that changes to individual files within them will result in changes to the assembly file, even if the assembly itself never changed [1].

Tools like openscad get a lot of love from software engineers, but programmatic definition of geometry like that is just orders of magnitude less productive than, for example, the Solidworks UI. I think the primary reason they get as much appreciation (aside from using a familiar interface to software devs, namely code) is their compatibility with source control and collaborative work, which is in just a profoundly abysmal state with mainstream CAx tools. The CAx world is in dire need of a software-independent, merge-friendly formats.

Note that STL, IGES, STEP, etc don't count; they're package independent, but only transfer the "compiled" final geometry of the part, and not the history ("source code") you used to create it, so they're essentially immutable snapshots. That makes them great for sending a release to manufacturing, but utterly unusable if there's any design left to do.

[1] This is a result of the assembly file also storing a "compiled" version of the final assembly geometry, in addition to the various rules -- Solidworks calls them "mates" -- that define the relationships between the parts. So if you change the geometry in any of the parts, the assembly file changes, even though none of the mates did. Very frustrating.
We use it via GKE in prod. Zero complaints so far.
Newbie question: if there are no particles, then why are there quantized packets of energy such as photons?
This sounds like I wrote it.
Well it depends looks like your company was ok with spending the ongoing opex of engineering salaries for essentially building or attempting to build an infrastructure that is kind of functionally similar to AWS. As a businessman this does not make much sense when computing is today really an utility.
> On another note, calculating the payback of
> residential solar panels is tricky because many
> online calculators don't consider (stuff...)

Sometimes they do, we installed Solar in 2003, we replaced a failed inverter in 2016. At the time we installed the system we got a new roof with asphalt shingles (50 year roof) which both helped the roof load (they were lighter than the previous wood shake) and was a time period longer than the payback period for our panels.
Yes.

You have to understand that startups "by default" are failing. They are searching for and developing repeatable and scalable business model.

If they found that "repeatable and scalable business model" they are not startup and they are called established business.

If they do not find "repeatable and scalable business model" they fail.

I was in 3 startups so I would say 100% fail but that is my luck.
I still need to read that one. The Left Hand of Darkness has been my favorite so far.
I've also had such an experience. Same with Realm.io. The developers get very dismissive with just about anybody who comes in saying they have a use case which doesn't fit the scope of what already exists. Meanwhile features/fixes sit on the backlog for years.

I'm not saying this will necessarily stop me from using a project, but it definitely does not create any loyalty.

Compare this to say Rails, where I've had really positive experiences with the maintainers.
Suggestion to all companies: please have a /pricing/ page.
For the most part new projects have been doing a good job of either working with Python 3 out of the gate or making it a main priority (Issue #1 on Tensorflow was Python 3). In general, you'll be fine with Python 3 now. Some older, academic-type packages are still only Python 2.7 (Though might be easy to port).
Heard this elsewhere. Why do people use Docker swarm with Kubernetes around? Does it require less setup or something?
I assumed that the quotes were intended to point to a verbatim quote. I still think that's the most likely case.
The UK is back of the queue but at least we're still in the queue !
"If there's a dearth of options, then there's room for a better API."

A new UI framework is not something you can wish for Christmas. One can implement one (like Blender has done) but other than that, one is limited to the options which are available.

I don't think anyone claims there is no space for new UI libraries. It's not obvious one can simply implement a new one. This is not something someone does for fun over a weekend (at industrial scale) or just to try an epiphany of design over a few months. They are huge, laborious beasts. If one has resources to implement a huge UI framework, then generally, they probably have the resources to implement the UI natively on every platform they wish to deploy on.

"A better API" is kinda moot feature for a UI library since they are technically so demanding, all other factors are more critical.
New URL: https://framagit.org/tuxicoman/googleplaydownloader/
The same shit is happening here. Massive distortion of reality and epic-level propaganda on US media. We need to always be skeptical of the pushed narrative.
I'm a fan of Docker in general but I'm amazed by some of the poor choices they've made with Docker for Mac.

- Stable? That's honestly laughable. It is nowhere near stable. As an example, I was trying to upload images to a third-party image registry but the upload speed was ridiculously slow. It took me forever to figure out but it turned out I needed to completely reinstall docker for mac.

- They had a command-line tool called pinata for managing daemon settings in docker for mac. They chose to get rid of it. Not only did we lose a way to declaratively define and set configuration but the preferences window has no where near all of the daemon settings that are available.

- The CPU usage is still crazy. I regularly get 100% CPU usage on 3/4 of my CPU cores while starting up just a few containers. Even after the containers have started it will idle at 100% 1/4 cores.

- It needs to be reinstalled regularly if you are using it on a daily basis. Otherwise it will get slower and slower over time. See my first complaint.

- The GUI (kitematic) will randomly disconnect from the daemon forcing me to restart the GUI repeatedly.

- They really need some sort of garbage collector with adjustable settings. With the default settings the app will just keep building and building images and eventually fill up, crash, slow down, etc. How is that acceptable? What other apps do that?

Like I said, I like docker in general. I think they are tackling some very hard problems and definitely experiencing some growing pains from such crazy growth. However, at some point they need to take a step back and focus on the core of what they offer and make it as simple, and rock solid as possible. As another example, they still haven't added a way to compress, and/or flatten docker images. No wonder docker for mac slows down after regular use when it's building 1GB+ images for simple things.
> Each version of the CLI is incompatible with the last version of the CLI.

I'm pretty sure that as long as the CLI version is >= the server version, you can set the DOCKER_VERSION env var to the server version and everything works.

I haven't used this extensively, so maybe there are edge cases or some minimal supported version of backwards compatibility?
it seems that none of the container frameworks are generally ready.

Take for example k8s - I just started exploring it as something we could move to. https://github.com/kubernetes/kubernetes/issues/24677 - logging of application logs is an unsolved problem.

And most of the proposals talk about creating yet another logger...rather than patching journald or whatever exists out there.

For those of you who are running k8s in production - how are you doing logging ? does everyone roll their own ?
woah, wait.....

It "geneerally works if" you " rebuild docker hosts on a daily or more frequent basis."

Perhaps I'm misunderstanding, but needing to rebuild my prod env several times a day seems pretty "not ready for prime time" to me.

That's like when we'd say that Rails ran great in production in 2005, as long as you had a cron task to bounce fastCGI processes every hour or so.

So, can you elaborate on why rebuilding the containers is good advice?
Critics say one of the main concerns with TTIP is that it could allow multinational corporations to effectively “sue” governments for taking actions that might damage their businesses.
I think it's worth noting that caffeine is a vasoconstrictor, at least with respect to blood vessels in the brain. (Aside: This may be why it provides partial headache relief for some.)

So while it's true that our brains get a stimulating boost from caffeine, it's also a fact that caffeine significantly reduces cerebral blood flow. A moderate dose (250 mg) may reduce cerebral blood flow by 27%(!)

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2748160/

I'm no brain scientist but I would expect this to reduce some cognitive function to some degree.
Where can I read more about the container patterns you mentioned?