hosay123

Can't book a flight (ITA), order a taxi (this), book a hotel or chat with a friend (Gmail), or pay for dinner (Wallet) without generating an activity log with a single company.

Even if (and perhaps even probably) Google weren't doing this intentionally, they've already demonstrated through failing to encrypt their inter-DC connections how they're becoming a massive single point of failure (remember Snowden showed us the NSA were tapping Google's internal network already). Whether the end result is an intelligence service tap, or some legislative measure affecting the company done in the open, I'll simply never be comfortable with one company concentrating so much personal data affecting so many people.

    They use the same tracking system Google uses to create unique keys, except
    they built their own. That means the microtime of installation is sent to
    the mothership every single time someone pulls down the anti-phishing and
    anti-malware lists (from 10.76.1.11) in the browser. This microtime is
    easily enough information to decloak people, which is presumably the same
    reason Google built it into the browser.

It's frankly boring that 20 years later we still feel attracted to discuss any of this stuff. It's not like the machines or the code running on them have fundamentally changed in the interim..

From this I guess that weak DRM is very often entirely intentional.

As for the kind of engineer that does it, you do. Or more accurately, every engineer who has ever been asked to place their ideals ahead of their paycheck -- and realized jumping ship simply wasn't worth it

That's overstating things slightly, since it appears no Docker employee has ever contributed a single line of code to the LXC implementation itself (that would be hard work, rather than bikeshedding userspace tools, after all). The kernel tree contains only one reference to a Docker bug, fixed by a Red Hat employee, while the LXC tree contains a single reference to a Docker bug, fixed by a Canonical employee who looks to be one of the LXC maintainers.

The reality is replacing Docker isn't all that hard, as we're now seeing with Rocket. The kernel interfaces aren't tied to it (hell, its clear from Git logs the LXC devs are barely even aware of it).

edit: It's simpler to look at Docker and Rocket for what they both are: commercial plays built on the work of others. That work hasn't magically disappeared somewhere, it still exists and is in use (albeit by a slightly less PR/buzz-aware side of the community).

A vendor-independent implementation of containers already exists, as it did long before Docker did. If people are serious about seeing the "container ecosystem" flourish, they should be contributing cash, employment offers, or employee time to the real people and projects doing the work (as opposed to publishing upset blog posts and writing fashionable Go code)

Google App Engine has had numerous outages like this, the only one I can find any public documentation for being a 6 hour outage in 2012: http://googleappengine.blogspot.co.uk/2012/10/about-todays-a... (and let's not forget the old-style Datastore corruption incident, where every App Engine user got to manually merge split-brain database tables after a messed up failover)

https://radian.org/notebook/porsche

Yay, another decade before we get YouTube on OS X

Docker is for deployment, it works in terms of graphs of filesystem images. The tools do slightly overlap in use case, but they operate in entirely different domains.

It wouldn't be unreasonable to mix both in the same project, but there is no hard rule for when this would be appropriate.

The next might be "__getattribute__ mechanism has surprising behaviour in common use-case" (which itself would imply having a use case where any of this mattered). This one might actually result in some productive discussion regarding a fix.

Your second reply is basically a doc bug, one of "__getattribute__ optimization is not specified in the language reference" or "__getattribute__ optimization causes non-comformance with the language specification", either way, you would get the attention of the few people who can actually help you, rather than attention from the many more who can't

Ronacher should also know better than to post microbenchmarks like the one provided here, especially without corresponding (C) profiler output. At the C level, slots allow the implementation constant-time access to the most common code paths for an object, and especially when you have C code calling other C code via the type system (IMHO the primary use for Python, and still its strongest use case), "interpreter overhead" is reduced to a few extra memory indirection operations.

In the alternative world, sure, perhaps some microbenchmark may behave faster, but now systemically, and for e.g. "reduce(operator.add, range(1000))" requires more hash table lookups than I can count.

Python is all about providing a lightweight way to compose bits of fast code (the kernel, network stack, NumPy, MySQL, whatever). Unfortunately somewhere along the way solutions like Django got popular, which are almost the antithesis to this old viewpoint. Ronacher seems to be advocating that we should punish the CPython implementation's traditional strong areas in favour of.. actually, he didn't even describe any vision that was impacted by his complaints. He just seems to want the CPython implementation to suffer.

Perhaps his complaint about new-style __getattribute__ would be better suited as a bug report, it seems the only substantial observation made about the language itself in this post.

Firefox memory usage has always been, and I suppose will likely to continue to be far ahead of Chrome, since the desktop implementation is now largely identical to that used in Firefox OS.

This kind of policy needs to be discussed openly in a suitable forum, e.g. the IETF, not handed down to us by a single company who think they have a right to dictate how the Internet works - and have provably done a horrible job of it in the past (websocket over SPDY, anyone? Yeah, I'm not even sure which version combination of SPDY and websocket I'm talking about either - pick one of the hundred)

There are strong arguments for not enabling privacy by default - not least since it prevents any kind of decentralization or caching of content. At a time when OpenSSL just suffered one of its worst bugs in history, forcing small sites to assume the risk of running code like this, which they inevitably will get wrong, materially worsens security for all, it doesn't improve it.

Sounds much simpler than trying to ensure a continuous supply of glasses for 500 energetic kids

> Spyware is software that aids in gathering information about a person or organization without their knowledge and that may send such information to another entity without the consumer's consent, or that asserts control over a computer without the consumer's knowledge.

Save me the boring arguments about how regular people who can barely work a toaster can still somehow magically elect to avoid Analytics using browser plugins and editing their hosts file

It would only require something like 0.25 9/11's to turn Lex into the worlds largest and most terrifying defence contractor. Of course this sounds ridiculous, but it's probably just a few short pieces of emergency legislation from reality