I'm pretty sure that it was another class at the same time where I picked up 'bang' for 'exclamation point'. Looking back, I'm surprised that both had eluded me for so long.

This assumes you'll know if passwords were exposed in a breach. Some breaches go undetected.

If you use unique passwords for everything and a leak goes undetected, the damage is contained to just that one site/service.

cherry picking quotes to nitpick is only effective if you address the full quote rather than cherry picking a point of a cherry picked quote

An economy is an inanimate object; it can't #{active_verb} something. This may sound nitpicky, but: language carries meaning; language influences perception; and, in this case, language ascribes blame.

Insofar as Ameirica is concerned, the contractors working for gig apps, like Uber or Postmates, have chosen not to exercise their rights to worker protections. Even as contractors, giggers have a legal right to unionize, collectively bargain, and form a cartel to demand better compensation. These people have chosen not to.

That's not to say organizing is "easy" -- especially when you're living paycheck-to-paycheck -- it's not. But, to the degree that contractors are upset enough to act, organizing is feasible and achievable.[1] Self-organization is the free-market solution to a person feeling exploited or trampled upon by his boss. No government intervention is required.

Given that the right to exercise collective bargaining is a choice, and afaik the majority of giggers do not collectively bargain, the rational conclusion is that these gig contractors aren't upset enough about the terms of their gig to take action.

[1] https://drivers-united.org/

It's sad to see this sort of propaganda on HN.

Gig workers choose to take up a gig job in alternative to starvation, in most cases. There are big socioeconomic problems undermining the misguided notion that it might be a rational choice, in the overwhelming majority of cases.

This is why the State, in a modern society, is supposed to step in and forbid employers from taking advantage of workers.

These are lessons that were first learnt in the XIX and early XX century.

Would like to see a source on the claim that Uber drivers' only alternative is starvation. Uber has been founded in 2009, I am old enough not to remember mass starvation anywhere in the US before that. I am also vaguely aware of something called welfare state in the US that collects massive taxes exactly to prevent people from starvation (among other things), and I don't remember - before 2009 - any claims that this system has failed so much that people are suffering starvation in the US on the massive scale, or were until Uber came along to rescue us.

Moreover, to work for Uber, you must have a car (and a driver's license). Not just any junker clunker car barely moving around - a relatively nice car that a passenger would be fine with sitting it. Usually people literally starving do not have those, I think. In most cases.

My personal experience with Uber drivers (and other gig workers, like TaskRabbit or Fiverr) also does not match the description that they were starving before they had this job. Of course, this is only a personal anecdote, so I would very much like to see your source to that claim. Though I suspect you do not have one.

Gig workers, at least in the UK, are overwhelmingly from minority and disadvantaged backgrounds; they don't do it out of choice, but because they have little or no alternative.

> to work for Uber, you must have a car

This is the same as for regular taxi work (there are various arrangements, but in most cases drivers end up paying for their vehicle one way or another). In fact, Uber lowered requirements since you don't need a specific type of cars (like UK cabs) or paint jobs/registrations (in most countries). And that's why it got popular: it lowered standards even further, in a sector already predominantly staffed by the worse-off.

> My personal experience with Uber drivers [...] also does not match the description

Of course; they want your five stars, they'll all try to look and sound happy and successful - not unlike many entrepreneurs.

If they have no alternative, that means removing these jobs would leave them with literally no income at all. How can anyone think it's a good thing?

> This is the same as for regular taxi work

No, it's not, at least not in the US where taxi medallion (completely government-imposed cost) could cost over a million before Uber, and even now can cost hundreds of thousands. Uber medallion costs $0 - they give you the windshield decal for free, as I heard.

> In fact, Uber lowered requirements since you don't need a specific type of cars (like UK cabs) or paint jobs/registrations (in most countries)

And that's bad because it allows those with no other alternatives to earn income access these jobs without impossibly high upfront investment, which also allows to better serve customers, which is obviously bad because.... ? I can't finish this phrase.

> Of course; they want your five stars, they'll all try to look and sound happy and successful

And that's bad because... ? Anyway, you can't be starving and dirt-poor and "look" an owner of an upscale Mercedes - you'd need the Mercedes at least. You can't just "look" like having one - you have to actually get one.

> people really are actually poor in real life. It happens. A lot.

Who you are arguing with? I never claimed there are no poor people in real life. What I said that Uber drivers aren't doing it because their alternative is starving. Most people who are really poor do not participate in the gig economy at all.

Fine: the gig business model is undermining.

Here's the bottom line: Google didn't have to call it's resizable array java.util.ArrayList<E> -- it could have made android.data.ResizableArray<E>. But they didn't. Google copied the method signatures, and more importantly their organization into packages, to avoid the "drudgery" of defining their own original API. While a function that finds the minimum of two numbers -- int min(int a, int b) -- can arguably only be written one way and may not be enforcable, the issue isn't any one method's signature. The issue is that the Java API is an original, curated taxonomy of classes, methods, and interfaces, organized by authors. And taxonomies are protected under copyright. In the case of the Java API, the whole API taxonomy is greater than the sum of its method signature parts. Oracle owns that taxonomy.

Don't let any animus towards Google blind you to the real harm this will ruling will cause if it stands: say goodbye to any S3-compatible APIs, and good luck to WINE and Proton and say hello to lock-in and higher switching costs.

However the knowledge that Java isn't open-source compatible in mobile environments was known before Google started building their own.

That's one explanation of their motive, but it's not the only one and it's not the one they claim. The one they claim is that they wanted their platform to be compatible with existing software written for the Java platform. And along with it, with existing software developers writing on the Java platform. From that perspective it's not a choice: you can't use a different standard library API and have Java software run on your platform, just like you can't have a different instruction set and have a compiled executable work on your CPU, just like you can't sell an appliance with a different plug and have it work in a standard household outlet.

All SQL derives from IBM. Can they sue everyone on the planet? What about the guys who made B or C, can they sue everyone? Where does the insanity stop?

This is not an apt analogy, because this isn't what happened. Google wrote all of the implementations from scratch: the only thing they copied was the character names (and potentially one tiny function used for sorting). This is more akin to taking the Wikipedia summary of the plot of a book and writing a new book based on that summary.

Personally I'm with the perspective that API which has informally become an industry standard should weaken copyright protection.

OTOH, ARM was rather adamant about not wanting to see ARM instruction set implementations in software for a long time.

Either they saw the value in these emulators existing so that changed their minds - or somebody didn't let themselves be bullied into compliance: just because a company threatens you with lawyers doesn't mean they actually have a case.

> Since this article was first published, Sun (now part of Oracle) has relicensed most of its Java platform reference implementation under the GNU General Public License, and there is now a free development environment for Java. Thus, the Java language as such is no longer a trap.

From: http://www.gnu.org/philosophy/java-trap.html

So it looks like at least older versions of Java were under the GPL. Apparently you can't use the name "Java" without passing a conformation testing suite, but you should be okay as long as you didn't call it Java, (say calling it Android).

Or is this outdated/incorrect information?

Now I am likewise confused: how can it be copyrighted if it's been open sourced?

The opposite of a copyrighted work is not an open sourced work: it's a work in the public domain.

That kind of depends on whether you can apply a different license to an API and its implementation. There's not really any precedent for that kind of question, because it presupposes the validity of a kind of copyright that the industry has grown up assuming is not valid.

I think Android has since switched to OpenJDK, so it seems to me what Oracle and Google are arguing about is whether Google owes Oracle some damages for their previous use of Harmony. And of course, the lawsuit could have larger repercussions as well, if API's are deemed to be copyrightable.

https://openjdk.java.net/legal/gplv2+ce.html

The implementations are something else entirely, specifically because there are a thousand ways to implement the same function that are all functionally equivalent but nonetheless have different code. It's not a matter of how long it is, it's a matter of whether there is another way to do it.

A taxonomy is copyrightable?

What other examples of copyrighted taxonomies are there?

Question for you since you sound knowledgeable: If Oracle wins- can Linux in some way enforce this on Microsoft given Microsoft's work on WSL? Or is that applicable only where there is a taxonomy as you pointed out? My understanding from fosspatents is that it doesn't specifically have to be a taxonomy and even a flat API can be copyrighted (which I agree with since there is work that goes in it...)

Answering it from cwyer's comment on this page- doesn't apply to fair use so WSL is fine.

I would urge people who are looking to get the other side of this argument (pro-Oracle) to also read fosspatents.com. That is a sensationalist blog but the facts presented are very true.

Telephone directories also take quite a bit of work to compile, yet (per Feist) can't be copyrighted.

I can immediately think of many ways to do dates, and so can many java programmers (think the Date api, the Calendar Api, JodaTime, JSR310).

And having "new Date(1,1,1)" mean "the first day of the second month of the year onethousandninehundredandone" surely requires a bit of creative thinking.

1) Operationally, HBase is a nightmare whereas FDB is extremely easy to operate. 2) HBase doesn't natively, or efficiently with extensions, support transactions across rows. 3) GC makes HBase performance unpredictable whereas FDB is written in C++. 4) HBase depends on Zookeeper and it is operationally painful to support and we were replacing it with FDB also.

I don't think I will ever again use anything from the Hadoop ecosystem if I can get away with it.

1) Why use Scala to write (a relatively simple) internal CMS?

2) Why use a clustered database for 2 million records?

3) Why write your own proxy? (in Akka, none the less)

4) Why would you migrate articles from Mongo to Postgres using a script that runs overnight in screen?

The Guardian is, prima facie, a Wordpress blog. A simpler architecture would be:

1) Any CRUD web framework to build the CMS for reporters to draft their articles (Django, Rails, etc). Any basic RDBMS with read replication will do. Or, ditch the webapp entirely and just make a simple Markdown editor that commits to a git repo, a la Prose or Netlify.

2) When a reporter "publishes" an article, generate HTML for it and push to the CDN network. (I can't easily tell by looking at their HTTP headers, but I assume they're doing this already)

Okay, I'm being a little tongue-in-cheek. It's probably not that simple. But, one has to wonder, when you're serving up 100 million static HTML pages a day, if it really has to be this complicated.

A bloated web framework makes your code simpler because there are many things that you don't need to reimplement by yourself.

The problem is when developers use a framework without understanding it well and:

1) Reimplement in the code features that are already present in the framework. 2) Fight against the framework because their business needs conflict with the conventions choosen by the framework. 3) Fight against the framework because they don't agree in the way the framework solved a particular problem and want to solve it their way.

In both cases, the origin of the issues is not the framework itself.

> The most trivial way to implement a website for high traffic is simple static content generator

Agree. But in any case, those kinds of sites are not hard to catch neither.

Django itself was literally developed to suit the use cases of a newspaper.

I spent 4 years at a large financial news company, where we benefited from many ex graunaids who decided to migrate over the river.

They helped us create the new front end to the website, to much acclaim. However, it was hard for a number of reasons(this is from the financial news company, not the gruan.):

1) The journalists hated change, especially as they couldn't see any benefit. They just want to keep their same interface exactly as it is, bugs and all. They also had an active union.

2) There is 20 years of "micro services" moving data from the CMS, through various things to allow stuff like translations, syndications (very important source of money) data extraction, meta data processing, physical page layout, and many many more. Most of which is done by a legacy ETL framework pushing to and from a solaris FTP server that is old enough to join the army.

3) there is more than one way to enter data into the CMS.

4) The type of article, and the data in said article changed depending on where it came from, and what services nobbled it.

5) looking after the journalist's interface, curating the data, sorting the articles and adding meta data, looking after paying subscribers, and finally the front end, were all different departments that refused to talk to each other.

This meant that unlike a rational place, there was no source of truth for the CMS. It wasn't like you could call up article 342923 and display it. There was no guarantee that it would have all of the metadata (like were we allows to publish it) required. Add to that the inter department rivalry, which meant that for some reason the membership department were allowed to spend 4 years re-writing the same bit of functionality over and over again. (user management and payment gateways is a solved issue, but alas it took the best part of 25 million quid to find that out.)

To answer your questions:

1) because it scales maaaaan, looks good on my CV, I don't want to spend time doing boring work, I want to learn a new tool

2) see 1

3) see 1

4) Because I suspect that they've never seen a working ETL system

To answer your bonus questions:

1) Journalists have unions, changing the editor requires a _boat_ load of training, and is almost never worth it. Buy over build every time. But yes, its just text. However its the metadata that makes it. Whos in the article, whats the subject. Is it a lifestyle piece, does it have photos, who owns the copyright for the photos, is the article syndicatable, can we syndicate this article, who edited it. Etc, etc, etc. The text entry is the easy bit, its the parts that make it a real news paper that are hard.

2) Nope, almost certainly never done like that. The article will be given a UUID, and dumped into the CMS DB. The front page generator system will then dynamically pull out the articles based on parameters given first by the editors, (front page image, leading headline etc) then the related articles might be curated by hand, or by keyword/metadata or user's preference.

Then the advertising and tracking bits have to be injected, which account for 50-70% of the effort.

CDNs now allow a lot of logic to be pushed to the edge. (see https://labs.ft.com/2014/10/caching-user-agent-specific-resp...) which means that its not overly taxing to host a very large website.

https://www.youtube.com/watch?v=OVqBokd3l2E