vault_

- A big queue of PR's for reviewers to review

This is a feature. I would infinitely prefer 12 PRs that each take 5 minutes to review than 1 PR that takes an hour. Finding a few 5-15 minute chunks of time to make progress on the queue is much easier than finding an uninterrupted hour where it can be my primary focus.

- The of the feature is split across multiple change sets, increasing cognitive load (coherence is lost)

It increases it a little bit, sure, but it also helps keep things focused. Reviewing, for example, a refactor plus a new feature enabled by that refactor in a single PR typically results in worse reviews of either part. And good tooling also helps. This style of code review needs PRs tied together in some way to keep track of the series. If I'm reading a PR and think "why are they doing it like this" I can always peek a couple PRs ahead and get an answer.

- You end up doing work on branches of branches, and end up either having to become a rebase ninja or having tons of conflicts as each PR gets merged underneath you

This is a tooling problem. Git and Github are especially bad in this regard. Something like Graphite, Jujutsu, Sapling, git-branchless, or any VCS that supports stacks makes this essentially a non-issue.

Where this breaks down, as I've experienced at least, is that the product management side maintains basically zero awareness of the production constraints engineers are working within. If you've built out a painting production line around spray guns and beige, that has knock-on effects as to what results are attainable. A PM asking for polka-dots next sprint is throwing into question the entire body of practice, but this happens with extreme frequency in software.

Probably a result of the patent dispute over the feature: https://apnews.com/article/apple-watch-patent-dispute-sales-...

I didn't realize they were actually selling a 10 Gbps service tier as part of this branding. It's never been available in my market, so I assumed that they were advertising the uplink capability of the thing my modem was connected to! Happy to see this go, but I'm still shocked to learn that the name was _less_ misleading than I had thought.

Autoscaling seems like a downstream concern from the techniques being discussed here. Autoscaling tends to have a pretty high latency, so you still need a strategy for being overloaded while that extra capacity comes online. There's also a question of how the autoscaler knows what "load" is and when it's "too high." Just going off of CPU/memory usage probably means you're over-provisioning. Instead, if you have back-pressure or load-shedding built into your system you can use those as signals to the autoscaler.

Real products built today have a finite amount of demand, and global cloud capacity is larger than that.

This isn't really true, and it's especially not true when specialized hardware comes into play. If you have a "web-scale" GPU workload, it's not unlikely that you'll hit resource availability constraints from time to time. The question isn't whether cloud capacity is larger than your demand for a particular resource, it's whether cloud capacity is larger than the aggregate peak demand for that resource. Cloud providers aren't magic. They engage in capacity planning, sometimes underestimate, and are sometimes unable to actually procure as much hardware as they want to.

Yeah, I don't think circuit breakers are really the appropriate choice in most of the situations the article is describing. Rate limiting and backpressure seem like better options most of the time.

The way I see it, circuit breakers are safety devices. They're for when you need to keep a system in a safe control region and are wiling to sacrifice some reliability in order to achieve that. e.g. preventing customers from accidentally turning your globally distributed whatever into a DDOS platform or limiting the blast radius when infrastructure automation decides it should delete everything.

Nested replies are definitely better as a way of consuming a post and its comments once and then never thinking about it again. For an asynchronous discussion between several people they get unwieldy after a few rounds of replying. They also make it harder to coherently reference points made cross-tree. That plus algorithmic ranking gives a constant feeling of "gotta refresh to see if there's new stuff" that serves a site like Reddit well, but it makes it much harder to have a longer discussion with more back and forth.

Having recently started participating in a community where most useful discussions are on a PhpBB forum, going back to linear posting was actually refreshing. It's easy to stay on top of because you can check in once a day or so and see just the conversations that have updates since you've last checked them. Threads being sorted by most recently updated means you focus on where there's active discussion. And once you've read those things there's no reason to stick around. "That's it! Get back to doing something useful."

Obviously, this doesn't really scale to a community the size of reddit, but I think it's really pleasant for medium-sized communities.

A doctor knows what his practice is worth and wants every cent he can get out of it - but the next generation of doctor is not going to be able to compete with debt financing what a PE cash-buyer can get.

In my opinion, the physician in this example is a monster. Profit maximization is a choice, not some kind of moral imperative. Am I supposed to have any respect for somebody selling out their employees and patients to vampires so they can retire to a beach or whatever?

The solution I'd want to see for situations like this is to find a way to sell to the people who have a continuing interest in how the business is run: employees and customers. The "exit" that does right by all interested parties would be something like having a newly formed employee coop gradually buy out the founder's ownership stake. To make a tech analogy, you don't have to sell your 0-day to foreign government just because they pay more than the bug bounty program! You don't have to sell out your community to vampires because they're the highest bidders! This is a choice that somebody is making.

It's not "general purpose computing" maintenance, but the service you're talking about does exist, though AFAIK mostly at the very high-end. It's typically for things like home theaters, whole-home audio systems, or smart-home type setups (predating and now merging with current consumer IoT/home automation platforms). Not sure how much that's "maintenance" in the typical sense so much as support for their custom install work, but I bet if you had a Sonos or Lutron system where your installer went out of business you'd be able to find a different guy to deal with it.

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.

This post is from 2011 and the techniques it describes have been superseded by cgroups. One of the followup posts is specifically about them: http://osgtech.blogspot.com/2011/07/part-iii-bulletproof-pro...

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.

(edited for grammar/coherency/tone)

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.

It seems like only methods can be decorated. Is there any hope for decorators on top-level functions in the future?

The relevant xkcd: http://xkcd.com/1252/

I've done this at my university, but in a slightly less obnoxious way.

We have a grid computing environment set up (using Sun Grid Engine) that allows people to run bulk jobs across both dedicated clusters and in spare cycles on lab machines. The way it was set up, CPU jobs on lab machines were set to an extremely low priority, so they don't interrupt legitimate use, and the jobs in some queues were set up so they'd be suspended when real jobs needed to run.

I'd submit hundreds of jobs to the background queue, which would run for a couple of hours and then stop. I also had access to a fairly large number of Nvidia GPUs which were used largely to teach people Cuda and run big simulations every month or so. I was able to use a pretty good portion of my college's compute power without being particularly annoying to other users.

I stopped after a while (maybe 2 weeks), because it was rather inefficient (I mined about 0.04 coins, at the time worth about $8) and because it was a huge pain to maintain. I would probably do it again with a different currency, but it's really not worth it.

It'd be interesting to look at how much of the 20-24 demographic is college students. In the US at least it's pretty normal for parents to pay for their children's phone bills while their in college[1]. Since about half of the 20-24 demographic is likely in college (in the US at least), I'm not too surprised to see that about half of the people in the US have their phone bill payed by their parent.

I'd be interested to see the demographic breakdown as high school, college, or not in school. I think it would offer more insight into a trend.

[1] This is anecdotal. I'm in college currently and most of the people I know are on family plans.

This is pretty cool. The google calendar event to create texts seems like a hack though (even more-so than the rest of it). Is there any reason this couldn't just use the SMS gateways that pretty much every carrier offers?

I was expecting a power strip: http://www.apc.com/

s/languages/language/ and they should be radio buttons ;-)

Which was swiped from the actual life of Salvador Dalí: http://en.wikipedia.org/wiki/Salvador_dali#Politics_and_pers... ;)

It's pretty easy to fabricate a story to support whatever position you want:

You get laid off and along comes unconditional basic income. Your $20K is covering your basic expenses pretty well, but you're bored out of your skull (you sold the TV after you were laid off). Rob says he's getting the band back together and after a while you guys think you're starting to sound pretty good.

A year later your boss calls and offers you your job back. He wants to pay your $6K, you negotiate part time for $4K so you still have time to devote to the band. Your boss agrees since he can just hire another person or two for less than your old salary.

With your extra money you pay for time in a recording studio and new instruments. Your band becomes wildly successful and you quit your job since royalties are now making you wealthy beyond your wildest dreams. And so you rise above your entry level beginnings and tell people stories of how you've achieved the American Dream until you die.

While I agree that most graphing calculators are overpriced and too limited in functionality, I disagree that students should only be given problems that can be nicely worked out on pencil and paper.

There were occasional problems I was given in my high-school calculus class where the goal was to find the area under a curve of a function that was difficult or impossible to integrate by hand. The calculator does it numerically so we were forced to recognize which types of problems could be solved exactly and which could not. Intersections of curves can also easily be solved with a graphing calculator.

Other things like systems of linear equations, probability distributions, statistics, combinatorics, and rapid data entry and processing can also be done really easily on a graphing calculator. These are all tedious to do by hand, and all make an appearance in upper level high-school math classes.

Part of taking a math class should be learning tools to solve your problems efficiently, and exact solutions are often not the most efficient way to do that. Things like Excel, Python, and Maple are all nice but they assume access to a computer and would require significant disruption to lecture flow. With a graphing calculator it's easy for students to do these things themselves (at their desks) without having to give them each a portable computer (which causes other problems with keeping the students attentive) and teach them a programming language.

Chill out a bit. Classes are for more people than the self-taught know-it-all's in the room. Most of those people attend the class because they want to learn the "basic curriculum" and they probably aren't interested in listening to some self-taught guy argue with the professor.

The author of the article is not condemning people for being self-taught; he's condemning them for being arrogant. I would self-identify as a self-taught know-it-all and understand the behavior he's talking about in the article: pointing out minor inaccuracies in things the professor says, answering every question (to the exclusion of others being able to answer), and asking irrelevant "questions" largely just to demonstrate how much better you are than the other students. It's really not that hard to realize that this behavior is disruptive and avoid it.

Syntax is syntax, whether it's Lisp or C. What I mean is I hardly think that a new language is what GPU programming needs to break into the mainstream.

What I believe GPU programming needs is tools that people can easily add to their current environments or that they can easily extend their current algorithms with. NumbaPro, OpenACC, and Thrust allow that.

In addition, the reason it's hard to express structured data and nonuniform computation is because those aren't things GPU architecture excels at. It excels at doing uniform operations over large chunks of memory. I'm sure that Harlan is pushing the boundary of what you can do on a GPU, but it's not going to exceed the limitations imposed by the hardware.