This article ends up making a compelling case for DynamoDB. It has the properties he describes wanting. Many, many systems inside of Amazon are built with DDB as the primary datastore. I don't know of any OSS commensurate to DDB, but it would be quite interesting for one to appear.
> "Every transaction can only be in one shard" only works for simple business logics.
You'd be quite surprised at what you can get out of this model. Check out the later chapters of the DynamoDB Book [1] for some neat examples.
Kamailio is what is called a Session Border Controller. Its primary purpose is to provide protection and some lightweight filtering for the media servers/PBXs behind it. Once you want "advanced" features like voicemail, parking, hunt groups, three-way calling, etc, you will need to use a PBX like FreeSWITCH (recommended) or Asterisk (not) behind it anyway. If you're only running a single machine, an SBC isn't really worth the trouble.
> Once you want "advanced" features like voicemail, parking, hunt groups, three-way calling.
Right, but what I am saying is that I don't want any of those features. At least not yet.
I just want to give my customers a sip address (username@communick.com) where they can call other SIP addresses. In that case, is that a PBX still needed?
I always thought "intelligence" was defined as the capacity to learn. Websters' first definition of "intelligence":
> capacity for learning, reasoning, understanding, and similar forms of mental activity; aptitude in grasping truths, relationships, facts, meanings, etc.
seems to partially bear that out.
Its not clear what definition Microsoft is using, but I don't see any real learning going on here. These models are painstakingly hand-trained by lots of humans over a significant period of time. The model itself is not "learning" anything, the humans are.
...It proceeds to produce a poem, not a song, and without any references to Star Wars that would indicate that it "knows" who either of them are...
This post is very long on hype and very short on fact or supporting evidence. Many things are attributed to GPT models' capabilities that are not in evidence, so its hard to take the content here seriously.
You are right. I shared the post because of the idea Daniel had about the future. He mentioned that the ai models of the future will not have much in common with the models of today the post can only be hypothetical - yet with a lot of buzzwords.
You may have a problem in your math. A mean of 4.3us with a stdev of 10.9us should mean that your 99% should be over 26us, unless it's super smooth with a few huge outliers.
Also, are you sure you didn't mean ms and not us? Seems more likely for an HTTP service.
Thanks for your feedback. Always good to have an extra set of eyes!
To check if the numbers make sense, I dumped the raw data used to compute these stats and compared elli_stats with the same functions in R and they match up.
Anthony Eden has a project for this from a while back: http://activewarehouse.rubyforge.org/ Not sure how well its maintained at this point but it looks like a pretty good mapping of the concepts to me.
my bad..my english is not good..what i meant to ask was ORM needs Object Models of data schema..And its easy to make from relational database perspective..but when it comes to star schema perspective, what can be the trade offs?
IANAL, but: It would appear to me that the author doesn't understand the GPL very well. If my code is BSD licensed and yours is GPL, I can submit pieces of my code to your project but if I take pieces of your code into my project, my project is now subject to the virality properties of the GPL and itself becomes essentially licensed under GPL. This is where the author seems confused: if I subsume GPL code into a BSD-licensed project, my project becomes licensed under GPL. Given that I chose the BSD license for my project I'm assuming it would now be obvious to the OP why this might be onerous.
Zed starts with two tweets that make exactly that point. He understands perfectly. You misunderstand _his_ point:
He's releasing Lamson under GPL, so the Django folks can't use it. But if he was releasing Lamson under a proprietary license, they couldn't even look at it. The GPL leaves them better off. But while BSD projects generally don't complain about proprietary forks, some of them whine bitterly about the GPL (which, again, leaves them better off).
Choosing the BSD license for your code is, in effect, choosing to allow others to rerelease under more restrictive terms. If you made that choice, I'm not sure it makes a whole lot of sense to complain when people do that.
Proprietary forks are always able to submit pieces of their code back to the originating BSD project. That's fine -- proprietary developers never claimed to be anything other than what they are, and if they eventually submit something back, that's nice.
GPL developers claim to be open, but then take the originating code and place it under onerous "open" terms. This triggers the classic "hypocrite" response: they claim to be open, but they're actually attaching a viral license to my work. Any improvements they make can NEVER be sent back to us without all the contributors agreeing to license under the BSD license.
In real terms, the GPL fork is a dead-end one for a BSD licensed project. The commercial fork is, actually, not -- the company is quite able to push back changes at any time.
No contributions will ever result from the GPL fork, and given that the BSD license provides a superset of the freedoms of the GPL license, it's clear that the GPLers are only licensing under the GPL to enforce their own politics on the BSD licensed code.
The GPL is fundamentally a protection against companies distributing private modified forks. It wasn't created to give BSD code creators a bad day - basically what you're describing is collateral damage. I think most reasonable non-zealot OSS developers totally understand where you're coming from.
An interesting twist would be a BSD style license that states that if the code is incorporated into a GPL style licensed project, patches to your specific code subset must also be BSD licensed. Kind of like incorporating a LGPL library into a commercial product.
> An interesting twist would be a BSD style license that states that if the code is incorporated into a GPL style licensed project, patches to your specific code subset must also be BSD licensed.
I've used mixed licenses to achieve this in the past. The individual source files remain BSD licensed. The whole work, in aggregate, is GPL licensed.
It only works if the dependencies are one-way, though, and you keep the BSD code fairly isolated.
GPL is not about openness to everybody. GPL is not about maximizing contributions.
GPL is all about end-users' freedom, even over developers' freedom where those two collide (i.e. developer can't have freedom to take freedom away from users).
GPL is about preventing software becoming non-free and deliberately not helping those which want to have ability to control what users can and cannot do, like add DRM, unremovable crapware, etc.
GPL is deliberately open only to those who prioritize end-users' (not developers'!) freedom over everything else.
There seems to be some implication that because I disagree with the GPL's aims and find them incompatible with my own, I must not understand it.
I understand the GPL. However, compared to the alternatives, I don't believe the GPL/FSF are optimally beneficial to my interests, the interests of consumers, or the interests of corporations.
> Proprietary forks are always able to submit pieces of their code back to the originating BSD project
So are the authors of the GPL project.
> Any improvements they make can NEVER be sent back to us without all the contributors agreeing to license under the BSD license.
You have a very poor understanding of the GPL and copyright law. I'm afraid you've been infected by the "viral" meme.
BSD-licensed code that is incorporated into a larger GPL project is still under the BSD license, even though the larger assemblage may be viewed as being under the GPL. Any improvements made to your code may be licensed under the BSD by the people making the improvements if they so choose.
There may come a point where the code has changed so substantially that GPL'd and BSD'd portions are inseparable, but at that point, what good is their code to you, anyway?
Oh, I'm sorry, did you just want to take all their work and use it under whatever terms you like? Odd, then, that you don't want to give them the same freedom...
> There may come a point where the code has changed so substantially that GPL'd and BSD'd portions are inseparable, but at that point, what good is their code to you, anyway?
If the code they add is under the GPL, and the aggregate is the GPL, then the only new code retrievable from that project that is GPL code.
> Oh, I'm sorry, did you just want to take all their work and use it under whatever terms you like? Odd, then, that you don't want to give them the same freedom...
It seems like GPL advocates are so focused on the legal enforcement of ideals that there's a systemic failure to recognize the underlying nuanced social contracts.
Re-licensing forked BSD code under the GPL to make it "more open" is simply spiteful -- and is the linchpin of the BSD developers' objections.
The GPL fork will continue to integrate improvements to the BSD code base, and possibly siphon off open-source interest in the project to their fork, but the GPL licensed code will never move in the reverse.
> If the code they add is under the GPL, and the aggregate is the GPL, then the only new code retrievable from that project that is GPL code.
Which is as it should be. You gave them the right to use your code as part of a larger, differently-licensed work. You claim it is because you want people to have freedom. But now you want to beat up on them for exercising that freedom.
> It seems like GPL advocates are so focused on the legal enforcement of ideals that there's a systemic failure to recognize the underlying nuanced social contracts.
Claiming unwritten social contracts should guide behavior is asking to be disappointed. Not everyone will have the same view of what those contracts are. I certainly don't share your views on the subject. What, objectively, makes you right and me wrong?
> Re-licensing forked BSD code under the GPL to make it "more open" is simply spiteful
Please provide some examples of GPL projects claiming that they have made BSD code "more open".
> Claiming unwritten social contracts should guide behavior is asking to be disappointed. Not everyone will have the same view of what those contracts are. I certainly don't share your views on the subject. What, objectively, makes you right and me wrong?
This nuance is why the BSD license relies on social contracts. Attempting to codify the OSS social contract as license would result in something rather like the GPL, and is at the core of why we disagree.
No, it's not. The core of why we disagree is your bizarre double standard. There are no circumstances under which I would find a corporation's proprietary use of BSD code more socially acceptable than a GPL project's open-source use of BSD code.
This is a fundamental disagreement of principles, not a disagreement about proper enforcement mechanisms. You and I have utterly different views of what the "OSS social contract" is even about, much less says.
No, it's not. The core of why we disagree is your bizarre double standard.
It's not a double standard. The purpose of the BSD license to encourage widespread adoption which will hopefully lead to widespread contribution, under the assumption that the best way to encourage adoption and contribution is to not enforce it.
If a commercial vendor uses BSD licensed code for a proprietary product, they can and do still donate code back. If they fail to do so immediately, they might do so in the future -- this often occurs as vendors build larger systems on top of a BSD licensed code base.
The GPL, however, is purpose-built to break the social mechanisms by which BSD licensed code propagates by implementing an irreversibly viral one-way licensing OSS ecosystem. RMS has stated repeatedly that he won't be happy until all software is GPL and it's simply not possible to compete with GPL software due to the network effects of large, interconnected GPL-only software stack.
Finally, legal codification of behavior often has large unintended consequences. Choosing to use social pressure to discourage certain uses of your software while not legally forbidding it does not create a double standard.
You appear to have taken a very libertarian worldview and attempted to apply it to software. That's OK, but you have to realize that, as in the political realm, your views are not even close to universal, and some of them are definitely in the minority.
Social contracts are, by their very nature, a reflection of some sort of societal consensus. The societal consensus is not in (full) agreement with you on this matter.
You could advocate your views of what the social contract should be, that's OK, too, but claiming that your minority views are the social contract and that everybody else has to follow them or be somehow "wrong" is, at best, disingenuous.
I'm simply explaining the BSD/proprietary viewpoints. They're obviously contrary to the GPL+FSF viewpoint, but they're not logically inconsistent.
In his article, Zed actually said "we're both on the same damn side". However -- barring the use of open hardware reference information across OSS implementations -- that's not really the case.
The GPL and BSD licenses are competitive memes, and the ultimate success of the GPL (as per the FSF's goals) would be at the expense of the BSD and proprietary licenses.
No, you're explaining your viewpoint, and claiming it represents a "social contract".
While I periodically hear whining from some people, particularly the OpenBSD crowd, about other open-source projects using their code, I've seen no evidence of it constituting "the BSD viewpoint".
By the way, the only significant open source software I ever released was under the BSD license. I chose BSD because it made the most sense for what I was trying to accomplish, and specifically did not want to prevent anyone from using the code in any way they saw fit. It would never occur to me to whine about somebody doing just that.
Whether or not you recognize or care about these issues doesn't change the logic behind BSD developer's complaints regarding GPL re-licensing of BSD code, or somehow create a double standard.
If there is no open-source version of some piece of software, the BSD folks are better off than they would be if there was only a GPL version. In the absence of a GPL version, the newly-created liberally licensed version of the software is likely to get more contributors and users. In the presence of a GPL version, the BSD version has substantially lower chances of success given the same effort from the maintainers. If I am only willing to use liberally licensed components in my project, GPL software is actually worse than proprietary software.
>> This is where the author seems confused: if I subsume GPL code into a BSD-licensed project, my project becomes licensed under GPL. Given that I chose the BSD license for my project I'm assuming it would now be obvious to the OP why this might be onerous.
I think his intention was for BSD licensors to accept that as an inherent "danger" of their chosen licence. Like he pointed out, you wouldn't be able to use proprietary code from Google or Apple simply because it incorporates your BSD licensed code, so why should it be a problem when the aggressor - in a manner of speaking - is using a copyleft license?
The article says they are using Office Communicator, part of the Office suite, so I'd imagine they are going full-bore on that. Wonder if they are using SharePoint for the wiki, too.
This article ends up making a compelling case for DynamoDB. It has the properties he describes wanting. Many, many systems inside of Amazon are built with DDB as the primary datastore. I don't know of any OSS commensurate to DDB, but it would be quite interesting for one to appear.
> "Every transaction can only be in one shard" only works for simple business logics.
You'd be quite surprised at what you can get out of this model. Check out the later chapters of the DynamoDB Book [1] for some neat examples.
[1] https://dynamodbbook.com/
reply