bbrazil

I usually use Google (or for things like oz, switch the units on my kitchen scales).

I think it's devolved beyond that into a marketing term, I've seen realtime mean anything from milliseconds to hours. I'd mostly interpret it as "faster than what you already have/are used to".

"In June 2013, VA’s former chief information officer held a chat forum on the platform, “giving the false impression that VA approved the use of Yammer.com,” IG officials said. In fact, VA officials have not approved use of Yammer for any department work, despite the large number of employees on the site."

Sounds more like it wasn't made clear what was or wasn't an okay internal communication tool, which points to a lack of training and IT management.

There's practically reproducible and completely reproducible.

Let's say you had a bug, and are trying to see when it was introduced.

Something like the compilation time printed in a log at startup you don't really care about, the versions of each part of your build chain and all dependencies are where your focus will be. This is easier to achieve.

I've been considering using bcache on one of my systems, last time I checked it seemed a bit unready in terms of all the steps needed to set it up and keep it working. What has your experience been?

> DV SSL also allows someone to register '*.othercompany.com' wildcard and then create 'yourbank.com.othercompany.com' and have this domain name display a green lock in older browsers.

Wildcard certs only work one level down, when I looked into this Firefox was the last browser to remove support for doing multiple levels.

Mesos is looking at allowing things other than Zookeeper to be the dependency, I'm not aware of them removing the dependency altogether.

https://issues.apache.org/jira/browse/MESOS-1806

As well it's interesting to see the different responses of teams when problems are raised.

Some are very thankful for the analysis, others don't seem to appreciate how important correctness is in this type of distributed systems. I find it's a good indicator of the maturity of the teams working on them, and how much I'm willing to trust each system.

> Several engineers suggest that Aurora is more robust, though more difficult to set up, than Chronos. I haven’t evaluated Aurora yet, but it’s likely worth looking in to.

I've tried out Aurora (and helped improve the setup docs a small bit) and found it quite nice. If you're going to try it out use vagrant, and to deploy it in production I suggest working off the Vagrant setup: https://github.com/apache/aurora/blob/master/examples/vagran...

> Instrument your jobs to identify whether they ran or not

Prometheus.io let's you alert on when the job last succeeded, which is generally what you want. http://prometheus.io/docs/instrumenting/pushing/ has a full example for Java.

It's also important to let your admins fail, and let the people and systems improve based on what you learn from the failure.

Being completely risk averse creates an environment where it's very difficult to improve, for fear that your good change will happen to cause a problem and you'll get blamed for it.

OS X doesn't have a procfs. I'd presume there's a syscall and/or debug feature that offers similar functionality.

To expand on that a little, the main property you're looking for is that if I give you the N random numbers that have already been generated you can't predict what the next one will be with certainty beyond random chance.

https://en.wikipedia.org/wiki/Cryptographically_secure_pseud... has more detail.

Using Twitter to figure out which vulnerabilities you probably need to care about is a neat idea. Not as thorough as going through all the CVEs by hand, but better than nothing.

The article says it's quadratic, which would put it in P as it's polynomial time.

It's only quadratic, for asymmetric crypto you'd want something with a much higher complexity and preferably non-polynomial.

Java by default can cache DNS forever, which may be why many people are seeing problems. Set networkaddress.cache.ttl to adjust this.

http://javaeesupportpatterns.blogspot.ie/2011/03/java-dns-ca... has more detail.

I have recent experience in this, as I spent 4-5 hours trying to name my new company.

I was first looking for some reference on prometheus.io and a transliteration for the Irish for "fire" looked free - but turned out to be to a derogatory term for Indians so that wasn't an option (always check Urban Dictionary). Next I looked for something with the initials AE (which means "liver" in Irish), and even after trawling through a thesaurus and /usr/share/dict/words nothing worked that was available in DNS.

Finally I had a list of ~100 words that were candidates. Single words were out as they weren't easily Googleable, and all were taken. I played with word pairs a bit, and the 3rd or 4th I really liked was free in DNS and not popular on the web. I now have robustperception.io, with the .com and plurals to be safe.

People I've talked to have liked the name "Robust Perception", and it ties into what we do, so it seems to have been worth all the hassle. Name pollution is a real problem.

Flabbergast is solving a different but related problem, it's about expressing the state of your system. Lots of times you want to say the dev environment is like the prod environment, except for these 3 things. And by the way, anything in the European region needs different settings too that interact with dev/prod.

I'm a fan of Ansible, but it isn't really suitable for expressing multi-dimensional and multiple-levels of exceptions, from experience it works for about 2.

How that state is actually rolled out is the job of something else (which could be Ansible or the update portion of your cluster scheduler).

I'm not following you. I'm thinking of things like https://github.com/prometheus/prometheus/issues/482 where core elements of a language don't behave in a predictable manner (in this case == has two distinct modes). That's a simple example, more structural issues can be compound by workarounds and lead to a lot of complexity growing over time.

A phenomenon I've noticed is some believing that containers solves configuration management. It's true that containers through being immutable means you don't have to worry about what cruft has built up from previous changes (which is a big win). That still leaves you with the core problem of how you manage your configs.

The core of configuration management is a) how you express the state of the world and b) how you move from state to state safely, with potentially hundreds of changes in flight at once. For the former I'm excited about projects like https://github.com/apmasell/flabbergast, and the latter is mostly a matter of breaking rollouts into individually rollbackable changes combined with good policy.

The main challenge I've observed with DSLs is maintaining and growing them over time. It's not unusual for a DSL to grow organically based on individual use cases that seem like a good idea, and the end result is a language that's not quite consistent or orthogonal.

"A foolish consistency is the hobgoblin of little minds" is the rallying cry of those who only have to deal with a small number of libraries/languages/tools/systems, and don't realise the true externalities of having to memorise hundreds to thousands of special cases. Small consistent languages are good languages.

If you're interested in this, https://www.youtube.com/watch?v=OTHggyZAot0 which was given at EuroPython 2012 on "Music Theory - Genetic Algorithms and Python" is also good.

Looks like it's a group GitHub is a member of: http://todogroup.org/members/

While GC is always going to take some resources, the new Go 1.5 GC will bring the latency down such that a lot more use cases will be able to consider it. Going from seconds to milliseconds is huge.

That could cause confusion with CPython (the main python implementation) and possibly also Cython (C extensions for Python).

I ran into the overflow behaviour with our source repository provider, as they'd get hammered on the top of every minute by all the continuous integration servers and silently drop connections. The specific version of SSH we were running didn't send the client banner until it received the server banner, so the connection just hung for 2 hours on the client.

After much debugging and reading of kernel source this was all figured out, and the provider adjusted things on their end so this wouldn't happen.

Moral of the story: You probably should set tcp_abort_on_overflow to 1.

http://blog.dustinkirkland.com/2013/10/fingerprints-are-user... bears repeating. If you can't change it then it doesn't make for a good passwords as there's no revocation.

This sort of thing is useful as a signal when deciding if a user is who they say they are, but it's not sufficient on it's own.

The same is true for the converse, as in both cases you get to be your own query planner and add client<->server latency on every join.

Among all the definitions I found, that was the only common theme.

I've been discussing this with others in the "DevOps" space and in recruiting terms a "DevOps engineer" seems to mostly mean an "Ops engineer". True Devops (in the sense of developers who also care about and perform all of their own operations) is a culture, not a job role and one that seems quite rare in the wild.

My read of it (as someone in the Debian/Ubuntu world) is that the CentOS split meant new sysadmins and users tended more towards Ubuntu.

RHEL/CentOS is still around, but you don't hear about it too often.