geezerjay

> And I will definitely concede that the space of problems in which they excel and are tractable is smaller than the space of problems for something like a neural network, in my experience.

The only thing that EAs and neural networks have in common is the buzzword abuse. Neural networks are actually useful as they are at their core an efficient way to approximate multivariate functions, while EAs are computationally expensive heuristics abused by being passed off as optimization algorithms even in domains where deterministic algorithms (and even brute force approaches) actually perform better.

> Ok, I admit that a lot of papers compare only against other metaheuristics, but only in cases where it is already accepted that those other metaheuristics far out-perform weaker methods.

Those methods are invariably other evolutionary methods, and benchmarks are cherry-picked to show only encouraging results under the convenient guise of the "no free lunch" theorem. That' pretty much the norm, such as the repetitive recipe for inventing a metaheuristic algorithm of a) coming up with a clever nature-inspired metaphor with a catchy name, b) put together an algorithm that is arguably inspired on the metaphor, c) come up with a benchmark that arguably portrays the algorithm as being any improvement, even if only on a fortuitous corner case.

> Definitely false. The vast majority of OR-type papers in good journals include comparison to weak baselines like those, and wouldn't be published (in those venues) if they didn't win.

That statement is not correct. Although it's customary to accompany papers with benchmarks, these benchmarks focus practically exclusively on popular evolutionary algorithms. Worse, the "no free lunch" theorem grants authors the freedom to cherry-pick which benchmark problems are used.

> Well one area where genetic algorithms are better than basic gradient descent is, naturally, nondifferentiable functions. But that is facile.

That's a poor assertion because even if detivative-free algorithms weren't already a thing, there are a myriad of smoothing techniques that enable nondifferentiable objective functions to be approximated by differentiable functions.

> I think the realistic strength is that there are some easy to use libraries that don't require the user to really know anything about optimisation or work too hard and can deal with very difficult optimization scenarios (and sometimes even deal with them well).

That's also not a reasonable assertion because there are also plenty software libraries for continuous and discrete optimization that are easy to use.

GAs in general are explored in academia because they are a fad that's easily publishable. Other than that this class of methods is in general very computationally expensive and very inefficient, and don't provide any advantage over plain old adaptive sampling, or even dumb regular lattice sampling.

AWS Lightsail charges $3.50/month for a vm with 512MB RAM.

Hetzer charges €3.00/month for avm with 2GB RAM.

> Is 6K a lot for what they are providing?

From other comments, 1k alone is for the display stand. So, yes.

> Is there any response that would satisfy you?

Do you believe that a PR response made in damage control mode that actually changes nothing is something that's satisfactory?

I mean, apparently this screwup was so damaging that it killed a company. What part of the PR statement addresses that precendent?

* Photos of a person is personal data, particularly those that are scraped from social networks. This is pretty much the whole point of GDPR.

* Screwing up someone's life, as it is extensively desribed in the article, fits well into the definition of "vital interest".

I find it quite baffling how someone posting on HN is oblivious to the link between GDPR and the need to punish those who abuse data collected from social networks against the wishes and best interests of the users to screw up their lives.

> Not sure how this relates to GDPR

GDPR states that the lawful basis for processing of data depends, among other things, on:

* the individual's explicit consent to the processing of his or her personal data.

* protecting the vital interests of a data subject or another individual

This violates both criteria, thus is indirect violation of the GDPR.

Minikube adopted VirtualBox as its default and recommended VM driver, and personally I never managed to get non-VirtualBox VM drivers to work with minikube, including Docker.

> I've heard of a startup spending many days of contractor time to optimise their database so they didn't have to go from the 4GB Heroku database to the 8GB one.

From Heroku's site, Heroku's 4GB database plan goes for 50$/(instance.month) while Heroku's 8GB plan goes for 200$/(instance.month).

Therefore, it isn't a question of if it makes finantial sense (it does) but how long the startup plans to operate to recover their investment.

> I've heard of a company refusing to purchase an external drive for an employee so they could process a handful of ~50GB datasets on their MacBook Air – instead forcing them to use "the cloud" or constantly download and backup datasets.

I find it rather strange how someone believes that it's a decent idea to conduct a company's data analysis work on what an employee manages to fit on an external HD, as it creates a whole lot of hard problems both legal and technical. I mean, how do you ensure the data's provenance is tracked and other data analysts can access the data? Who in their right mind would put himself on a situation where a minor lapse or misfortune (losing/getting the HD stolen) could put the company at risk?

> Roughly I'd suggest that "fits on my laptop" is <1TB, "fits in memory" is < 1TB, "fits on one computer" is < 10TB, "fits on a small cluster" is <100TB, and "might be worth Hadoop" is >100TB. I could be too low on these though.

That's a rather naive and missinformed take on Hadoop. Hadoop might be conflated with big data but it's actually a distributed system designed to reliably process data shards without having to incur a penalty to move data around. It makes absolutely no sense to base your assertion on data volumes alone. What matters if it the performance increase justifies setting up a hadoop cluster with the resourses available to a company.

> Insert "almost" into parent's sentence and it becomes correct.

No, it still remains astonishingly wrong. Even container orchestration platforms are being adapted to provide the same service that Hadoop has been providing for years, and no one in their right mind would claim that running processing jobs on the cloud is a problem that almost no one has.

> Hadoop solved a hard problem that nobody had.

This baseless assertion is patently wrong on so many levels. Building computing clusters on COTS hardware is a very mundane problem. Running processing jobs on data shards is a very mundane problem. Scaling COTS clusters transparently is a very mundane problem.

Confusing funding with subsidies is a very disingenuous mistake. Whoever thought of this nonsense was desperate to sell the idea that somehow rideshare services were less efficient than incumbent taxi services, which flies on the face of reality.

In fact, whoever came up with this nonsense is so distant from reality that he even failed to acknowledge that the main criticism that incumbent taxi services direct at rideshare services is that rideshare companies have a lower operational cost due to lack of expenses such as purchasing medallions.

You have no idea who I am so refrain from making up accusations and personal attacks founded on your personal baseless assertions. If you have nothing of value to add to the discussion, simply don't add noise or drama to the discussion.

If a marketing team wants to edit anything then let them put up their own blog or website instead of abusing other people's service.

It's this sort of abuse that brought spam into the world and pretty much destroyed fundamental services such as email and also usenet.

> This seems to assume that the tests will be higher quality than the problematic code in the first place.

If the problem lies with probematic code then tests are not the problem. At most they're just yet another way that problematic code affects the problem.

Let's put it this way: would the problems go away if the tests were ripped out?

> Unit tests will actually make bad code even worse because it will be even more difficult to change the underlying logic (because the tests lock all the poor implementation details into place).

This statement is patently false, unless for some reason a project includes unit tests themselves as the production code, which would be highly unusual.

At most, unit tests must be refactored along with the code, but that's the standard operating procedure.

> I’m obviously not in line with the tenor of this thread, but I really don’t think it’s a big deal.

If this sort of abuse isn't nipped in the bud, it will only get worse and become standard operating procedure for each and every single ad company, big and small.

You're presenting a personal pov that's grossly hyperbolic even in its subjectivity and does not reflect reality. With the exception of a hand-full of highly sensible topics that are prone to brigading, such as political issues, most articles barely receive any edit and are far from being monitored. Articles that are particularly vulnerable are articles on geography-related topics from nations that don't have a strong wikipedia presence.

Wikipedia is routinely manipulated to promote corporations and individuals. It's no surprise that some of the people engaged in this sort of practice are paid to work exclusively. In fact, I peronally know a case where congress promoters had among their marketing strategy creating and maintaining wikipedia pages that helped them promote their event.

Google's blanket dismissal of any criticism of Go's GOPATH design screwup pushed people away from adopting Go.

The expression "ivory tower" has an entirely different meaning. Just because the couple of dominant players chose to ignore a standard, particularly in a time and age where they were outright hostile to interoperability initiatives, it doesn't mean the standard was not reasonable.

I would also add that having third-parties propose specifications to standardization bodies is a widely established practice. In fact, standards are supposes to reflect industry practices and are a way to establish common ground.

Sounds like the complains are targetted at faulty implementations, not the document standard.

> And luckily, tables have become redundant as layout technique, since CSS would do that, already then.

It took well over a decade to get CSS to play nicely with layouts. It's disingenuous to present CSS as the obvious solution to a problem while criticising table usage to implement grid layouts, as this line of argument entirely ignores the recent history of the web.

> "Standard" = consensus definition of desired behaviour. "Living" = open to change. > I don't see what is so oxymoronic about this?

A standard is set in stone as a fixed target for implementers.

No fixed target? No standard.

And no, an unversioned document that changes arbitrarily is not a standard.

To put it differently, a standard is a goal. If the goalpost is arbitrarily kept on the move then there is no goal.

> Almost every major significant OSS project has a corporate sponsor (usually in the form of paid employees doing the bulk of contributions). Don't see the problem with that.

Your arguments are deeply cargo cult-ish: they lack any rational train of thought and boil down to an empty belief on how a greater power will eventuall deliver good things to those who have faith in it.

> What does it even mean for it to be "supported for years to come"? It's not a web service.

I'm pretty sure those writing and building software today would like it to build and run 6 months from now.

> Machine learning is an area where you need to be able to produce results.

Having to produce results is one thing. Mindlessly throwing tensorflow/pytorch at problems is an entirely different problem.

It's like those front-end devs who mindlessly insist that they need to use heavy javascript frameworks with convoluted build processes such as React/Angular to churn out a static web page with a couple of paragraphs and images.