What's the confusion? The allegation is that choosing to build this represents, at best, incredibly poor judgment. The GitHub issue and GP post are good faith appeals to kindest possible interpretations of this work. To use your own example, explosives can be useful, but if you discovered that your neighbor was building pipe bombs in his garage, you'd probably want them to stop. "I'm not gonna use them. I just think they're neat." is not a convincing argument for them to continue. To extend the analogy a bit further, this seems comparable to discovering a box full of pipe bombs with a big "free" sign in front of their house.
This isn't a fair analogy. There's a cost to adding new tools to a software environment, and an ongoing cost to maintaining that tool. Closer, IMO, is you're speccing out a new house with a builder and ask for a swimming pool, a hot tub, jacuzzi tubs, and body sprayers in the showers. Getting all of those installed and running to spec is going to be much more expensive than getting one or two of them. If your builder says "You really need the pool. I'll see if I can get that dug in my free time, don't worry about it." you are probably going to worry about what you're actually getting. If you do have the budget to do everything properly, you also need to have the ongoing budget for cleaning and maintenance. Pools and tubs have very different maintenance profiles. The same is true for software.
Which is to say, using the "right" tool is nice, but not always in the budget. R or Julia may be a better language for data science than Python, but if you're the only one using them, you're just making things harder for the rest of your team. A Python shop has probably invested in coding standards, linters, test infrastructure, common libraries, and has expectations for how code runs "in production". Expect that you'll need to clear at least some of that bar for a new tool you introduce. Expanding towards tools that better fit problems is good, but unless you're doing 100% green field development it needs to be intentional and measured.
How does being able to point at a database prevent land being stolen in the absence of a trusted third party? It's not like the land itself can authenticate the farmer. For the database to have any weight, there'd need to be an authority that can enforce what it says (and won't take bribes to ignore it, or collude in extorting "voluntary" transfers). If you do have such an agency, well, there's your trusted third party.
Interesting concept! A couple quick things I noticed trying to use the site.
First, you can't view product details without paying for a subscription. I wanted to look at the t-shirt to see basic details like sizes available, product measurements, material, and country of origin. I made an account but that still requires paying $70 before I can actually see product details. That's a tough pill to swallow for something I might not want to buy.
Next, there's not a return policy specified anywhere (maybe if you have a membership?). For online clothing stores, I tend to expect that returns are included, but the price-point here would make me more cautious. Does the membership pay for my returns?
Finally, the products themselves seem pretty generic (I realize that's the point). But there's a difference between "we created/are using a generic pattern" and "we are reselling blanks intended for printing. Specifically, why should I buy the latter from you? And if they’re original designs that are made well and from quality materials, what actually goes into that?
That really depends on what you're working on and to what degree it's coupled to the system it's a part of. A form on a web application, or an API endpoint? Sure, rewriting it is probably trivial. A new process scheduler for Linux? The caching system in an HTTP server? Maybe writing the code will be easy (though probably not), but building any confidence that it doesn't break something that's unexpectedly load bearing will be anything but cheap. And if what you're rewriting that started out as "just code and see what happens" it's going to be more expensive still.
Which isn't to say that rewriting can't be cheap, but some intentional design (or at least diligent maintenance and refactoring) must have gone into the system to support that style of development. At which point you're back to targeting "quality," even if it's no longer a focus of on the smaller scale.
A few questions/observations from reading over the docs and source code. There's not necessarily any significance to the order, or weight to the observations.
With the recent NPM stuff fresh in my mind, it seems like you've got a lot of data serialization libraries as dependencies (YAML, msgpack, rapidjson, marshmallow). Are all of those really needed? Why depend on rapidjson at all when Python has builtin json support? It'd be nice if the default config used only builtin libraries here and allowed users to use something fancier or faster if they wanted to.
It's not spelled out particularly well how subjects actually acquire roles and permissions, or how given a subject I'd go about giving them new permissions.
More integration how-tos in general would help a lot with getting started. e.g. Here's how to make this work in a single sign-on environment. Or here's how to use ldap for authentication. Or (how I would want to use this) here's how to use SSO for authentication, group memberships from LDAP, and permissions those groups have from a database.
Is there any way to deny privileges based on permission/role? e.g. If I have a forum that doesn't allow new users to post until they've been vetted, I'd like to be able to say posting requires the 'user' role, but forbids the 'new user' role. Is there some other way to quarantine users?
You say "Because most account stores usually contain Subject information such as usernames and passwords, a Realm can act as a pluggable authentication module in a PAM configuration". Do you just mean that a realm is similar to a PAM module? Because it sounds like you're saying you can actually stick a Yosai Realm in a PAM config. I can see the similarities between a hypothetical LDAPRealm and pam_ldap.so in terms of authentication, but do realms have analogies in other behaviors of PAM modules?
You describe Yosai as being batteries included, but don't seem to be including many useful batteries (LDAP, OAuth, SAML). I know this is an early release, but do you see these being added to base library?
Yosai_AlchemyStore gives me yet another user model (that claims the user table no less!). Can't I provide it with my own?
This is promising though! Most similar libraries tend to be tied to one specific framework or another, so it would be very nice to have something standalone.
I believe the difference is that Open vSwtich is intended to be used as a software switch similar to how a VM is intended to be a virtual server (and its intended use there would presumably be networking between VMs). While OpenSwitch is intended to be an OS run on an actual physical switch. There seem to be overlaps though since it looks like Open vSwitch will also run as an OS on a physical switch.
Unfortunately, due to hoisting decorating top-level functions is a real pain [1].
What should the behavior of:
myMagicFunction();
var myDecorator = require('myDecorator');
@myDecorator
function myMagicFunction() {
// TODO: Make magic
}
be?
- `myDecorator`'s require statement is hoisted above `myMagicFunction`'s declaration so that `myMagicFunction` is always decorated? (Results in a given `var`'s behavior changing depending on whether it is invoked as a decorator, an exceedingly non-obvious behavior)
- Function hoisting doesn't happen for decorated functions (non-obvious, possibly hard to implement).
- Function hoisting happens but the decorator is not hoisted (resulting in a sometimes-decorated function).
These problems don't admit of a simple solution (at least as far as I can see).
