Development quotes of the week [LWN.net]

All this has been replaced by a set of Docker containers running my docker-debian-base software. They’re all in git, I can rebuild one of the containers in a few seconds or a few minutes by typing "make", and there is no cruft from 2002. There are a lot of benefits to this.

And yet, there is a part of me that feels it’s all so… cold. Servers having "personalities" was always a distinctly dubious thing, but these days as we work through more and more layers of virtualization and indirection and become more distant from the hardware, we lose an appreciation for what we have and the many shoulders of giants upon which we stand.

— John Goerzen (retires a server that’s been running since 2003)

There was a time when commercial chat services supported XMPP because it was felt to be the right thing to do. But that was old-school hippie thinking, because if chatterers can just go ahead and talk to anyone anywhere, then your service probably won’t go viral and how are you going to monetize? You can simultaneously think markets are a useful civic tool and recognize obvious, egregious failures. So the links were severed and a whole lot of services just died.

— Tim Bray

I'm very disappointed in this. While I don't care for the way the SSPL was introduced, this license poses interesting questions about how copyleft can be extended (or not) and how the OSD's clauses about software packaging need to change in a SaaS world.

If nothing else, SSPL was a serious license proposal and deserved serious consideration it didn't get. THis was a dramatic failure of the license-review process, and I think shows that this group needs to be reconstituted.

— Josh Berkus

to post comments

Development quotes of the week

Posted Mar 15, 2019 9:20 UTC (Fri) by mjthayer (guest, #39183) [Link] (3 responses)

Regarding the SSPL - do the target users have any reasonable alternative to MongoDB? If not I could imagine it working for MongoDB unless someone thinks it worth their time to fork the pre-SSPL version. But that leads to the more interesting question is - is there anything that the MongoDB team can offer large users which would cost them more if they were to do it themselves in-house? Like prioritising certain features or fixes during development?

Development quotes of the week

Posted Mar 16, 2019 0:12 UTC (Sat) by flussence (guest, #85566) [Link] (2 responses)

PostgreSQL's native JSON support has pretty decent performance (a lot of ActivityPub server software relies on it, for example). In the face of that competition MongoDB didn't have a whole lot going for it even before the SSPL.

Development quotes of the week

Posted Mar 16, 2019 0:20 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

I noticed that Pulp (which is the open source content management component) of Red Hat Satellite simply moved on to using PostgreSQL instead of MongoDB + PostgreSQL and Red Hat has dropped MongoDB completely. No forks seem to have emerged. It may very well be that the license change would get more people to look at traditional databases which have grown support for NoSQL type features. That is probably a good thing.

Development quotes of the week

Posted Mar 23, 2019 21:41 UTC (Sat) by Wol (subscriber, #4433) [Link]

Or look at the original NoSQL database - Pick. Unfortunately I'm unaware of a viable Free Software implementation.

(aiui, the NoSQL domain was registered / is owned by one of the leading lights in the Pick community. It predates the rise of NoSQL in general, and was intended to trigger exactly that.)

But to implement a Pick database, really all you need is a decent key/value datastore, and a way of handling n-dimensional data (as provided by Pick's DataBASIC language). In maths, the general always trumps the specific, and Pick's n-dimensional data store trumps relational's 2-dimensional store.

Cheers,
Wol