241–250 of 408 posts
Earlier quoted context omitted.
“Loose” is the opposite of “tight,” “lose” is the opposite of “find.” Easy to remember because the opposites have the same number of letters.
It always amazes me how often I see this spelling error.
So...what is the future of enterprise open source? Is there a future for enterprise open source? If you start a company and open source your core/clients, your product becomes part of AWS, and AWS runs you into the ground. If you mix in proprietary licenses to protect yourself, AWS forks your core, adds in open-source licensed clients, then runs you into the ground (and you lose open-source contributors/supporters as…
Look at Confluent/Kafka. The PMC is stuffed with Confluent employees and they behave that way. They aren't acting like an Apache project, they are only acting in their own self interest. Any new ideas get the run around, and only their ideas see the light of day. I don't even know why they bother being open source, except maybe to get the free development and bug fixes.
Earlier quoted context omitted.
“Loose” is the opposite of “tight,” “lose” is the opposite of “find.” Easy to remember because the opposites have the same number of letters.
It always amazes me how often I see this spelling error.
I'm nervous about what this means for the future of nginx's built in load balancing. That's been an important and rock-solid part of my infrastructure.
I use F5's at work. The F5's do their job very very well, but are very very touchy. I've always considered nginx to be solid, stable, and low-maintenance. I think the opposite about F5 and am worried about this transition. 1) You can't export and re-import a config. Just doesn't work. 2) For the Virtual Appliance (not a recommended scenario by F5, to be fair) it's temperamental about its host and doesn't like to be m…
4: In over 10 years of using F5 never seen a reboot break a config. The part about needing reboot to make a config change apply might be https://support.f5.com/csp/article/K13253. In short F5 keeps the old config in RAM and applies it to existing connections. when the latter expire, the old config is gone. Can be very annoying indeed when you are not aware of it. You can delete connections manually though. No need for reboot.
3/5: Yes, all their releases have a list of all known issues. It's a bit odd indeed, but I think it's a good thing. Plan your upgrades carefully.
Earlier quoted context omitted.
My understanding is that Google has recently deviated from this strategy. The result of the strategy you mention is that the industry standardized on other companies' implementation of ideas that came from Google: Hadoop (MapReduce), HDFS (GFS), ZooKeeper (Chubby, and more. For examples of newer open source projects that see more active maintenance from Google, see Kubernetes and TensorFlow.
But K8s is not a development of Google software. It is developed specifically for the public, it throws out all of the interesting parts of Borg, and Google themselves don't use it, or barely do. As for that other stuff it seems to have worked out fine for Google: they describe obsolete technologies and the outside world develops hideous analogs of those and uses them for decades. Hadoop for example is just an unbeli…
So...what is the future of enterprise open source? Is there a future for enterprise open source? If you start a company and open source your core/clients, your product becomes part of AWS, and AWS runs you into the ground. If you mix in proprietary licenses to protect yourself, AWS forks your core, adds in open-source licensed clients, then runs you into the ground (and you lose open-source contributors/supporters as…
My understanding is that Google has recently deviated from this strategy. The result of the strategy you mention is that the industry standardized on other companies' implementation of ideas that came from Google: Hadoop (MapReduce), HDFS (GFS), ZooKeeper (Chubby, and more. For examples of newer open source projects that see more active maintenance from Google, see Kubernetes and TensorFlow.
Earlier quoted context omitted.
I can summarize my feeling with Caddy as it's probably a good choice for solo developers with a handful of sites on a single VPS that's not terribly important. If you have something really important, I would look elsewhere. Caddy used to put non-removable advertisements in the response headers. (That one got such a bad backlash that they backed away...) Caddy refuses to cooperate with OS packaging teams. It reeks of…
I am sorry to hear about the damage done to your business. I appreciate that you took the time to list out those grievances. I'd like to respond on a few points, for the sake of clarity (if you're interested, but also for other readers here). That header thing was indeed a bit of a fiasco; a misguided attempt to honour the few that stepped up to support Caddy monetarily. Once the depth of the issue was made clear to…
Obviously hard to complain too much about a free product - I'm sharing my personal experience for others.
So the thing I like about AWS is that they can give you a cert before pointing the DNS A record at your site. Really fool-proof and excellent. Much better than the let's encrypt flow by design.
In fact on some of my sites I now run Caddy on AWS behind a load balancer with the AWS load balancer providing HTTPS. Works much better and I can sleep at night with less fear.
So...what is the future of enterprise open source? Is there a future for enterprise open source? If you start a company and open source your core/clients, your product becomes part of AWS, and AWS runs you into the ground. If you mix in proprietary licenses to protect yourself, AWS forks your core, adds in open-source licensed clients, then runs you into the ground (and you lose open-source contributors/supporters as…
> If you start a company and open source your core/clients, your product becomes part of AWS It seems not obvious to everyone, but you don't have to use a license, that allows AWS to run you into the ground. Take a look at API Copyleft License: https://github.com/kemitchell/api-copyleft-license
> you must contribute all software that invokes this software's functionality..
So that rules out all proprietary operating systems, databases, 3rd party services, but why stop there? give us your CPU microcode.
Earlier quoted context omitted.
Note that none of the successful large companies are actually open sourcing their 'secret sauce'. There is no open source version of Google's search engine, Facebook's social network etc. It's only supporting tools and infrastructure they release (i.e. commoditization of their complements or dependencies.) A product company open sourcing their core product is committing suicide on the product front. Sure, there will…
I don't think Facebook has any "secret sauce". The integration and scale is certainly impressive, but there's no part of the functionality which is at all mysterious to me. Unlike, say, Google Search, everything on Facebook appears pretty straightforward. They did open-source HHVM, React, GraphQL, and Cassandra, which are the closest things I can see to a secret sauce.
Earlier quoted context omitted.
My understanding is that Google has recently deviated from this strategy. The result of the strategy you mention is that the industry standardized on other companies' implementation of ideas that came from Google: Hadoop (MapReduce), HDFS (GFS), ZooKeeper (Chubby, and more. For examples of newer open source projects that see more active maintenance from Google, see Kubernetes and TensorFlow.
But K8s is not a development of Google software. It is developed specifically for the public, it throws out all of the interesting parts of Borg, and Google themselves don't use it, or barely do. As for that other stuff it seems to have worked out fine for Google: they describe obsolete technologies and the outside world develops hideous analogs of those and uses them for decades. Hadoop for example is just an unbeli…
This is not true. It throws out the Google-specific parts of Borg (like integration with Google's service discovery, load balancing, and monitoring systems) and improves a number of things compared to Borg. For a good reference on the evolution of Borg into Kubernetes, I recommend the recent Kubernetes Podcast interview with Brian Grant: https://kubernetespodcast.com/episode/043-borg-omega-kuberne...
> Google themselves don't use it
This is not true, and the reasons why it hasn't replaced Borg are related to the integrations I mentioned above (which will take time to integrate or replace) and the zillions of lines of borg config that have built up over the years, rather than concerns that people outside of Google would have (production-worthiness, reliability, etc.)
(Disclaimer: I worked on Borg at Google, and now work on Kubernetes at Google.)