This flag is Android-only. It seems that disabling WebRTC on the desktop versions of Chrome isn't easy.
2,587 karma · joined May 16, 2011
Encrypted data is supposed to look random, and as a consequence, it tends to compress very poorly.
2/ Gnome started requiring systemd (via the dependency of GDM on logind). So, if they want to keep supporting Gnome, they have a choice between switching to systemd or developping some shims. And it's probably safe to assume other major pieces of software (KDE?) will adopt similar requirements.
There's "one lonely dude complaining on the internet", which you can safely ignore. And there's "half the audience has horror stories to tell", which should probably be a red flag.
They want to be called tech startups, because tech is cool, and they have an app, because apps are cool, but their core business has nothing to do with tech.
Mesos is a generic cluster manager. Its job is to keep track of available resources (RAM/CPU/Disk space) on a group of machines, and to share these resources between "Frameworks", which are more or less specialized distributed applications.
Available framework include existing applications that have been ported to Mesos (Jenkins, Hadoop, Elasticsearch, ...), along with some that have been developed specifically for Mesos (Chronos for running cron-like tasks, Marathon for running long-running tasks).
For example, you can tell Marathon "I want to run 10 instances of ./my_code, with 512MB of RAM and 2 cores each", and the framework and Mesos will collaborate to figure out where to run them. As a bonus, Mesos has some Docker integration, so you can natively do things like "Start 20 instances of container my_organization/my_app".
The datacenter OS thing is a bit of a shaky metaphor, but the idea is that, like the OS does for a single computer, the role of Mesos is to view your cluster resources as a single pool, and to try to fairly allocate these resources between multiple (distributed) applications.
They can be made to work, but you regularly stumble on some more or less obscure bugs. The short of it, is that you have no guarantee that the compilation step won't introduce bugs in your program, so you need a solid test suite for the compiled binary. It's feasible, but clunky, and you really get the feeling that the compilers aren't first-class citizens.
And even though it can handle both init and process supervision, runit has a clear separation between the two tasks. The "runit" program handles init tasks. The "runsvdir" program handle process supervision. And each one is completely functional without the other.
Why go with PHP and have to roll your own framework, when you can go with something else, and leverage all the great work that has been done by the Django/Rails/whatever folks? This post tells me all that they have accomplished, which is cool, but doesn't tell the most important thing: why did they choose PHP?
I have to take missions in PHP (Symfony2 and Zend Framework) from time to time, and it really makes me appreciate how much more advanced Rails is. And I don't mean advanced as giving me lots of options for doing obscure things. I mean advanced as doing for me all the repetitive stuff that I would have to do anyway, so that I have much less code to write, much less room to introduce bugs, and I can focus on what really matters. The PHP ecosystem is trying to replicate that, but so far, it's still quite far behind.
On the other hand, if you have some heavy static files to serve, the scalability of S3 is hard to beat. It can serve the files more reliably than anything you can come up with.
You can build your docker image, push it to your registry, and all the production machines will only have to pull the new layers.
But if you already have an in-house engineering team who is reasonably competent at maintaining services, the tradeoff is probably different.
The new pkg uses the up-to-date repository by default. It has fixed all this mess, and turned binary packages from something very clunky that nobody really used to something fairly solid that can be used in production. The only reason I use ports nowadays is when I need to set custom build options on a package.
It makes the experience in this regard not much different from any apt-get based linux distribution. The old way of having to compile everything makes your system very configurable, but it gets brittle on systems where you have to make big upgrades.
I've never used those, and I don't know how relevant these are for companies, though.
* DNS: you need to add a specific record to your DNS zone * File: you need to add a specific file to the root of a HTTP server listening on the domain name * Email: they send an email to admin@ on the domain
All three are pretty much ways to check that you are the person in control of the associated DNS.
This isn't really a MITM attack.
This is an internal attack, which requires different mitigation measures, and is seen less often in the wild (compromising 500 servers from a specific provider is more difficult than 500 random servers on the internet, and you're pretty much guaranteed that the provider will deactivate most of them after the first attack), so I guess their protection systems aren't as developped against it.
OVH isn't responsible for what people do with the servers. They provide the initial installation, networking, hardware monitoring and some management tools, but that's it. If they detect that a server is sending too much traffic, they can guess that it has been hacked, so what they usually do is disable it and notify the owner to fix it. But they don't do more, that's not their business. If you want a host that does more for you, it's managed hosting you want, not a dedicated server provider.
The vulnerable ftp we're talking about here is a completely distinct piece of software, which is generally used only when you want to interactively browse a ftp server. But it doesn't seem to be related much to fetch(1). It has obviously common origins with the OpenBSD one, but I can't comment on how vulnerable the OpenBSD version is.
You're not screwed. If you need SMACK, IMA, or SELinux, you still have systemd. That's choice.
Testing and documentation make a difference in the long term. Unless your business model is "build a shiny tower and sell it before it crumbles", at some point, you'll have to fix the mess you made in the early days of the application.
In my browser (FF nightly), I see the HSTS header, with the value: "max-age=15552000; preload"
If I do a request with curl, no header... (which is probably what this app sees).
I don't have a clue why they are doing that, though. Not that curl would do something with the HSTS header anyway, but still...
Neither the accept header alone nor the user-agent alone are sufficient. It seems they are testing for both.
curl -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" -A "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0" -I http://i.imgur.com/zvATqgs.mp4Poettering wants to show how his community is nice and welcoming, and he does it by... making gratuitous attacks at Gentoo? Sounds legit.