This was to make it clearer across all Markets what products you buy to make a single market easier on everyone. This is just FUD that really shouldn't be part of this conversation.
It's not FUD, its not a myth, its real: Commission Regulation (EEC) No 1677/88 of 15 June 1988 laying down quality standards for cucumbers [1]
Yes i know this regulation is no longer in place, thats not the point. The point is that the EU is a overblown bureaucracy that should not be in charge of regulating every silly little aspect of life across the various member states.
And yes, they are STILL passing laws like this. Recently they passend regulation that limits the power consumption over regular vacuum cleaners.
It's _better_ for the EU to define these things. If the EU hasn't done it centrally, member states would be doing it individually. This way:
1) You get a single definition of cucumber class 2C for every country, rather than a bunch of definitions that make trade more complex
2) It's (num_countries_in_EU) times cheaper to do it once than to do it seperately for every single country.
It has become quite clear to me that anyone who brings up the shape of bananas or cucumbers in the EU is either just spreading FUD because they've decided they're against the EU for other reasons, or believes anything the papers tell them without applying critical thinking to the matter.
Other people already pointed out the mistakes in your argument as this is necessary to build a common market across dozens of countries and hundreds of millions of people. Please read up on what the EU is trying to do, you really don't seem to have a grasp on it.
Classifying produce only helps the consumer. You'd be a little annoyed if every week you went to the supermarket and they had a varying quality/size of produce but the price remained the same.
But what you're saying is that eventually you'll make money on every transaction which just goes along with the comment made before. The joke is really about goods where you can't lower the cost or increase the price enough to make the economics work.
> The fist copy of Microsoft Windows might cost 1 billion dollars to produce, while every next copy is essentially free
You'd have to split R&D costs by the units sold here. If you spend 1B and sell 1000 copies a price of 100$ per copy won't help you.
You are of course correct in your math, but the point is that it reverses the equation. Windows doesn't cheaper to make if you plan to sell fewer copies: the production cost is set (Roughly) so you have to target volume.
Then you have the secondary effects of lock in (with software/services) that makes every sale also reduce the cost of a future sale or economies of scale (physical goods) that again make volume more desirable.
This doesn't contradict the adage about having to sell at a per unit profit, but it complicates figuring out what number that is and can lead to some non-intuitive results, which does trash the value of the adage as a simple way of looking at things.
Not saying every company that is selling at a loss to get customers in hopes that they'll mysteriously figure out how to later profit is doing so correctly, but some are. Oversimplification adds little value to these problems.
"What is more probable is tha FB will try a legal trick claiming they are an American company and they follow the laws of California, not EU, even if they gladly accept European advertisers's money via Ireland"
That is specifically not possible under GDPR. It doesn't matter where your company sits, if you store data from europeans (or people living in europe) you have to follow the GDPR with potential for severe punishment. There really is no loophole afaik.
No. For all users within EU it must follow the GDPR. If you are a US citizen and access FB from EU, they must follow the GDPR, as far as I understand it.
And being FB, they really do not have a choice, since the EU do have leverage over them because they're doing business here.
I live in the EU. If I'm your "customer" (as in, you store my personally identifiable data), you have to comply with GDPR, regardless of where your company is.
>Obviously in the US there's more checks and balances, to make a company's statement more believable. Or that's what we believe anyway...
Without significant prove that this is not the case this handwaving way of comparing the US democratic state to China is just wrong. From Consumer protection to free and fair elections the US system is almost nothing alike the chinese system. Of course the US has massive issues (as do other Western democratic nations) but this handwavy "well they just don't tell you' stuff without actual good data behind is just destroys any credibility and is a huge problem for our democracies. Please stop doing it unless you provide exhaustive evidence.
Consumer protection? Let's ask the people in Flint how their water is. Free and fair elections? Yikes, you want to talk about this during this regime? How about voter suppression, gerrymandering, making sure minority districts have to queue for hours on voting day, electronic voting booths with accessible SD-card slots? Just because it's not covered on FOX News, it doesn't mean the problems are not there.
Or maybe oooh "We have massive issues, but China is worse.".
Also I don't think Obama ever did any curtailing of the NSA's program. Hello to the NSA machine reading this!
We're actually talking to everyone you mentioned. I'd love to see some "on-premise" Serverless infrastructure as well, the biggest issue with that is still the event system as a Serverless infrastructure really mostly makes sense if you can do things like "when you upload something to this bucket run this function". This is hard to replicate in an on-premise system.
I don't get what's so difficult to do on-prem. Your target market on-prem all use Kafka as their event bus and either Mesos or Kubernetes as their execution fabric - what's so tricky about fitting into that?
Its not about how tricky the implementation is, but what the value of setting this up is. With Lambda for example you just get this magic that invokes your functions when something happens. You don't have to deal with, manage or think about this at all. And its built into many different parts of the stack from S3 to APIG to Dynamo or SNS.
You can of course do something like that yourself in your own infrastructure, but then every piece of software needs to support it somehow, you need to manage that event bus infrastructure and you most likely have to push those events in yourself.
And that kind of thing is already there, so the appeal that Serverless event driven systems in the cloud have (because the providers give you all of this out of the box) is much harder to achieve when you have to do that yourself.
Absolutely not. We definitely want to support all of those providers, but as those integrations aren't in the Framework yet we decided to remove the logos until we actually support them.
Not just because users want those, but for us its important to become more provider independent as we don't otherwise have a defensible product. So multi-provider is definitely coming and we're in constant contact with many providers.
There certainly are other open source tools like ansible, Chef, Puppet, Hashicorp, MongoDB (and many more) that have started out as an Open Source project and are still OSS champions.
We have many plans for monetisation and are working closely with small to enterprise scale companies on building products and services around the Framework that help you once your infrastructure has reached a large scale. More info to come in the future.
To expand on my last point, how are you balancing the needs of an open-source community (steady, stable feature development, good communication/outreach/support, dedication to supporting existing products) with the needs imposed on Serverless by the VC funding model (acquiring new users quickly, launching new products you can monetize, getting hockey stick growth)?
The Serverless Framework is at the core of all our monetisation strategies, so we need the Framework to be spread to as many developers and into as many teams as possible and allow for way more complex infrastructure to be built. So by necessity we'll be pushing really hard on moving the framework forward.
I don't think the needs of an open source community stay in stark contrast to VC funding model, because without the Framework getting a lot of traction our other products aren't as interesting. So we'll be working on getting that traction. And we can't do this just by ourselves. We wouldn't be here without the Contributor community (literally because they implement so many features) so without good communication, outreach, support, ... we won't be able to grow fast enough.
I can only tell you that it is our true intention to push the framework forward very hard and build monetisation around it as much as we can to build this into a long term sustainable company. The more help and feedback we get to build the right commercial products and get great revenue (so we can give our Investors as well as our Team a return as well) the happier everyone is, including the community.
Sorry yup I conflated Open Source Tools and Open Source Companies into one. Vagrant, Terraform, Packer, Serv and all the other great stuff coming out of Hashicorp.
Thanks Miguel. We're going to release more about our plans for the next steps in the Framework soon. I'm currently writing those and will share with the community in the very near future (CTO of Serverless here)
> 1) What's the schedule on the documentation for best practices for SLS in production?
These are the goals for the next releases, giving you better tooling and best practices to go from a few services to many services.
>2) What's an example workflow ? (something involving multiple devs, testing, CI etc.)
Thats still relatively standard, with good testing, CI, CD , ... but we'll also add more blogposts and docs around that.
> And lastly, What's the timeline on adding support to Google Cloud Functions (in alpha) and Azure Functions?
Can't give an exact timeline, but we're working with both to be ready once GCF goes into production and working with Azure to get support into Serverless as well. Really also depends on talking to more users to understand how they want to use those providers.
https://blogs.ec.europa.eu/ECintheUK/straight-cucumbers/
This was to make it clearer across all Markets what products you buy to make a single market easier on everyone. This is just FUD that really shouldn't be part of this conversation.