HN user
True, but it's been a goal to open source Quay from before Red Hat acquired CoreOS. The Quay team has always wanted to go community OSS, and it's been Red Hat's policy since acquisition to help them. There were just a whole bunch of prerequisites to iron out first.
And now users are in a much better place, because they have multiple choices of container registry, which will hopefully drive innovation.
No, the CoC violation was for making a video, in his very popular podcast channel, supporting the "right" of Somnez to attack women in tech. Since Woods was coming to Kubecon specifically to podcast it, this made several women going to Kubecon feel very unsafe.
Charles Woods was denied a pass to Kubecon on the basis of his podcasted support for attacks on women and black people in tech by Mr. Somnez. It had absolutely zero to do with MAGA hats.
Charles Woods was denied a pass for Kubecon on the basis of his podcasted support, at length, for Somnez's attacks on women in tech. It had absolutely nothing to do with MAGA hats.
Wow, congrats PG devs! This has been a dream for Postgres for like 8 year now.
They're certainly Christian values, but they're not "conservative", at least not by the American definition. I'll point you to these tenets:
* Relieve the poor. * Clothe the naked. * Visit the sick.
... those seem like "liberal values" to me, at least on the American spectrum.
It's not a joke. Dr. Hipp is a genuinely religious person, and he means this seriously.
Why should the success or failure of VC-funded startups be a concern for open source?
If Redis Labs folds, that's sad for them and I'm sure I'll end up writing some references for people.
But it's only a concern for open source if Redis stops being maintained as a result. Which I seriously doubt would happen; Salvatore built Redis before Redis Labs existed, and I'm sure would land a job at one of those "established enterprises" if they fold.
Maybe we should be more focused on how the VC-funded startup model is actually reinforcing the power of established players, instead of messing around with licenses?
If you read the shutdown blog post for RethinkDB, licensing was not among their problems. Instead, they were market positioning, reputation, and developing products suitable for their market in a timely fashion. In other words, business execution.
Believe it or don't, no license, no matter how clever, will allow you to be financially successful if you blow the business execution.
Let's turn this on its head: what was the business plan that RedisLabs re-invented itself under? Was it a good business plan? Is is vulnerability to Amazon/MS that made it fail, or was the plan flawed from the start?
Josh Berkus, member of the OSI license review committee here.
License Zero was rejected because it's not open source. It is, in fact, a business model for a specific startup (and, I'd argue, not for the writers of the code either).
Kyle had some other interesting ideas for licensing that could have been approved as open source, but was uninterested in pursuing them if they didn't support License Zero the business.
For historical relevance:
Microsoft already tried this with its "Shared Source" nonsense, an attempt to reap the marketing benefits of Open Source while actually opening anything. If Microsoft couldn't pull it off with their $billions in marketing funds, why on Earth do you think Redis Labs can?
(yes, the Shared Source program still exists, but it's no longer Microsoft's answer to Open Source, but just a way of handling required government disclosure of their older proprietary products. It's pretty clear to anyone who follows MS now that they consider Shared Source to have been a complete flop)
Kevin,
If the goal is to monetize the Redis Labs modules, why not just put them under straightforwards proprietary licenses? This is a well-trodden and well-understood path.
This Commons Clause combines the twin mistakes of being both offensive and ineffective. It will get Redis pulled out of many OSS repositories, decreasing your distribution and mindshare. At the same time, I can see Amazon and Microsoft lawyers laughing at it now; it will do zero to prevent them from building their own cloud offerings.
I really have to wonder about the quality of advice that FOSSA is providing to its clients if it went ahead with this. You say 'OSS-savvy companies aren't dumb' but it seems like the consultants of FOSSA are, or they are counting on everyone else in the industry being gullible.
(and before you play the "consider the poor OSS developer" on me, I worked on Postgres for 18 years, and we never pulled this kind of nonsense)
"always" is a really long time.
This is where we'd love to have your community input on Fedora/CentOS versions. Fedora Atomic Host has had very recent kernels available, and I don't see why that wouldn't continue with the Fedora version of the new OS.
It is to move our technology stack forwards. Container Linux and Tectonic have technology which the RH container stack has lacked (e.g. Ignition, Operator-based host upgrades). At the same time, there's tech in Atomic/Openshift which hasn't been available in the CoreOS stack, like rpm-ostree and S2I. We're really trying to do a "best of both" with the new projects.
Of course, you may disagree with what's "best". You know where to reach me (Josh Berkus) if you want to send backchannel feedback.
For anyone reading this thread who is at Red Hat Summit, we will have a Container Linux/Atomic BOF at 1pm today (May 10), in the BOF area on the 2nd floor.
Also, I'd really like to know how you're deploying Kubernetes on Atomic, because we will likely stop building some of the multiple ways to install K8s on Atomic, and would prefer to keep the ones people are actually using.
So, it depends on which Atomic.
Fedora Atomic Host will be updated through at least the end of Fedora 28 cycle (december?). I'd like to keep it updated through Fedora 29, but we'll see what actually happens; best intentions aside, build engineers are always in short supply (your contributions can help). Red Hat Atomic Host will be supported into 2020. Centos Atomic Host tracks RHAH, so it will likely be available through the same period.
After that ... there will be some kind of migration plan to the new OS, details TBD. The real asset we have there is `rpm-ostree rebase` which makes it really easy to swap out the Atomic Host base in-place.
Hmmm. PostgreSQL treats output rowsets as their own thing, so this works differently in a subquery than in a top-level query. Not that that's desireable, it's just a consequence of an implementation that gives a lot more flexibility in other areas (table functions, for example, where Postgres goes well beyond the standard). So looking at the standard I agree that having your example work is superior to not having it work. I'd appreciate a footnote for that particular item for Postgres, though, since the most common forms of GROUP BY dependencies do work.
That's a fairly obtuse example. Is there a standard you're drawing from, for this? Because this example works fine:
postgres=# create table func_test ( id int primary key, data text );
CREATE TABLE
postgres=# insert into func_test values ( 1, 'josh' ), ( 2, 'markus' );
INSERT 0 2
postgres=# select id, data from func_test group by id;
id | data
----+--------
2 | markus
1 | joshYes, that's correct. If you are going to use sync rep because you can't lose transactions, you really want to use the latest version of PostgreSQL, which supports quorum sync (i.e. "one of these three replicas must ack"), even in complex configurations ("one replica from each availability zone must ack"). Note, though, that the existing HA automation solutions (Patroni, Stolon) don't currently have support for complex topographies, so you'd need to do some hacking.
It is a tradeoff though. With synch rep, you are at a minimum adding the cost of two network trips to the latency of each write (distributed consistent databases like Cassandra pay this cost as well, which is why they tend to have relatively high write latency). It turns out that a lot of users are willing to lose a few transactions in a combination failure case instead of having each write take three times as long.
Postgres also has some "in between" modes because write transactions can be individually marked as synch or asynch, so less critical writes can be faster. I believe that Cassandra has something similar.
Yes, and (1) no longer applies because service locators which locate the master are now easy to do.
Also, the article does show us the kind of knowledge that admins will always need to have, such as the tradeoffs between asynchronous and synchronous replication.
I wouldn't say that you need deep knowledge at this point. However, you do need at least journeyman level knowledge. Lots of folks (including me, on Patroni) are working to make more things automatic and lower the knowledge barrier, but we're not there yet.
A big part of the obstacle is that preserving state in a distributed environment is just hard, no matter what your technology, and the failure cases are generally catastrophic (lose all data, everywhere). This is true both for the new distributed databases, and for the retrofits of the older databases. So building DBMSes which can be flawlessly deployed by junior admins on random Kubernetes clusters requires a lot of plumbing and hundreds of test cases, which are hard to construct if you don't have a $big budget for cloud time in order to test things like multi-zone netsplits and other Chaos Monkey operations.
Making distributed databases simple and reliable is a lot like writing software for airplanes, but clearly that's possible, it's just hard and will take a while.
Exactly.
Coffeemug: there's one other thing you missed in the postmortem. The early marketing (1st year) for RethinkDB was all about optimizing for SSD storage. Since this was largely nonsense, database consultants like me (who were in a position to push technically correct solutions) read about it, and dismissed RethinkDB from our thoughts forever. I keep up pretty well with the OSS DB field, and didn't realize what you were really trying to build until five years later. With the number of NoSQL and NewSQL DBs entering the market in 2007-2010, I simply didn't have time to re-evaluate any of them.
So that's an other "take-home" from the post-mortem: be careful about your "first impression" on the market, because it can be really hard to change.
Given Thiel's long history of crazy an immoral utterances and behavior, why pick out his support of Trump as the "line in the sand"? It's practically normal compared to his other activities, and protected by law to boot. Compared to:
* Suing a news publication (Gawker) out of business for criticizing him * Funding research into vampirism (stealing young people's blood so he can live longer) * Paying to design an actual John Gault Island * Funding an initiative to split California into 6 states * Saying that women shouldn't be allowed to vote
There are tons of reasons why YC should disassociate form Thiel, but his donation to the Trump campaign has got to be the least of them.
The other part of the tradeoff is that inserts and many other write operations are less expensive in heap tables. A Big Table in InnoDB, measured in "when do I start having to spend a lot of time troubleshooting this table's performance" is about 1% the size of a Big Table in Postgres. TokuDB was introduced for MySQL for a reason.
Heap vs. Index organization is a classic tradeoff of database design.
Now, if you're saying "it would be really nice if Postgres had the option of index-organized tables" I'd agree with you. I'd love to have that, as an option.
That's pretty much the case, yes.
You'll be interested in ongoing work in this area, then. Oleg & Teodor are working on a new index type (RUM indexes, no less) which will speed up ranking operations conserably.