MetaCosm

Thanks for the link to Gocraft, cool stuff.

You misunderstand. There is no optimizing, he built a non-idiomatic library that people love. It has pros and cons -- he is going to maintain it. There is no "fixing" it -- what makes people love it is it being NON-IDIOMATIC.

ADDITIONALLY -- he has built something that is idiomatic and looks to solve the same problem set as the original tool. This is a "have your cake and eat it too" situation.

It is really excellent if you will actually use the pen. I love pen input (I have a Note III and a Surface 2). I love using Hyper-V -- which seems much faster than VirtualBox (on Windows).

I went through like 7 devices prior to sticking with this one -- Macbook Air and Pro, Asus Transformer, X301, Pixel ... and others. None of them had all the things I wanted in one place... the Surface 2 is just about a perfect fit for me.

I doodle on it (pressure sensitive pen is AWESOME), I take hand written notes, I run Ubuntu and CentOS in Hyper-V for work stuff, I run Visual Studio, I play League of Legends (1080p mid-low settings) and it is just my go-to device when I am not on my desktop.

I purchased it on a complete lark -- just to have one, and it is quickly become my go to device when traveling. It is a machine of compromises... it has a "good" screen, it has "good" battery life, it has "good" performance, it has "good" pen input, it has a "good" weight. Not exceptional in any category, but if you want something that places in all of them -- it is perfect.

So, motorcycles -- specifically the fast and light ones... they have the same field of view, they have similar seating, and they are "far more invested in avoiding collisions" -- they are significantly less massive and travel at much faster speeds and are more nimble and therefore able to avoid collisions in tight traffic. They would get their own rules too right?

Seems we need AT LEAST 3 sets of rules. One for slow bicycles, one for fast motorcycles and one for cars? What other separate rule-sets should we have on the road?

Since I am hardly ever a pedestrian, I really didn't give consideration to what a horror the lack of standard behavior of bikes would be for people on foot.

You have literally been collided with by a guy on a bike?

Also, filtering (lane splitting, white lining, etc) is often ticketed as reckless or some peer of it (on a motorcycle). While it often doesn't have its own designation -- if you are caught, you go home with a HELL of a ticket.

DC - 2004 (when I was deeply involved in statistics for DC, crime and otherwise) cyclists where found at fault for the majority (only slightly) of accidents they where involved in: http://www.washingtonpost.com/opinions/bicyclists-are-welcom...

It is my understanding that a new study is underway to see how Capitol Bikeshare (2500+ bikes rented from like little bike vending machines) has impacted this number (very new). Nothing will be publicly released for another year or so, but I suspect the outcome will be a much higher "at fault" rate for unskilled tourist bicyclists making that number even more skewed.

EDIT: Additionally, from reading this thread, it seems like cyclists who don't follow road rules are also a terror for pedestrians.

Wow, that is damning for RTOR. Makes intuitive sense, but damn.

> However, in traffic scenarios, I tend to fairly studiously adhere to the rules of the road. Why? Predictability...

As a driver, THANK YOU! This is the #1 problem with bicyclists, predictability. I drive in DC and I have literally NO IDEA what the hell a bicyclist is going to do -- which makes them little road terrorists to me.

I have watched a rented bike (in DC) ride from pedestrian walkway -- onto street (along side) -- into middle of road, then slow down and ride through a red light -- then stop at the next red light. This was inside of 2 minutes. Very scary from a driver perspective.

Your underlying assumption (which is unfounded as it turns out) is that drivers are (you imply always, maybe you meant majority... both are wrong) at fault. Bicyclists are often found as the CAUSE of accidents due to erratic (and illegal) road behavior, leading to a finding of no-fault on the driver.

1. It isn't a "limitation" of bicycles -- it is "inconvenient". They don't WANT to come to a full stop because it is annoying -- it is annoying for me too, I still do it.

2. Absolutely, this is a HUGE part of it -- bicyclists need to start getting FULL FLIGHT tickets for blowing stop signs and such. Few $150 dollar tickets might get them to stop. Policy departments generally hate dealing with bicyclists for tickets, and this needs to be rectified.

I am OPPOSED to TWO SETS OF RULES. It seems insane to retrain the entire population that bicyclists do X at stop signs while you do Y. At a red light, bicyclists do X and you do Y. I think this will amplify confusion and danger.

I regularly ride my motorcycle, and drive my car in DC. I am terrified of cyclists because their behavior follows NO norms. Some follow traffic signals, some don't. Some ride in the center of lane, some ride the edge of the rode, some ride on sidewalks in with pedestrians. The scariest do all three out of what I can only assume is fearlessness and insanity.

This lack of "normal" behavior is very scary for people in cars and even on motorcycles. We don't want to kill bicyclists! Bicyclists make up 2% of road fatalities in DC, vastly disproportionate to their numbers.

I think for all involved, the cyclists need to become more normalized and less random. Standardizing the (IMHO) bad behavior doesn't seem like the right(tm) answer.

The article has this insane circular logic, "because bicyclists already break the law a bunch, it should be made the law" -- rather than how we deal with it in other spaces "time to crack down on people who break the law". The result is the same, normalized behavior. The author wants to normalize to TWO sets of rules, one for bicyclists -- one for everyone else (so everyone has to know TWO sets of rules) -- I want to normalize to ONE set of rules, the current rules of the road, so everyone can follow ONE set of rules -- and punish bicyclists for NOT FOLLOWING THE LAW. I believe this will be safer for everyone, both in the short term and the long term.

Yep. Give me something built on msys anyday.

That isn't really true, and a lot of adults learn this if they got into trouble as kids. The juvenile system has a bent towards privacy, but that is all it is -- a bent.

You can either have your juvenile record "sealed" or "expunged" but neither is automatic.

Asking for your records to be sealed is possible a number of years after the conviction dependent on location. In most places it is 3 years of no offenses except minor traffic violations and you can request getting juvenile records sealed.

Asking for expungement is much more restricted and not even available in most locations. In the rare places expungement is possible it is a long and involved process.

Now, here is what sucks more -- getting your records sealed may seem like the obvious choice -- you don't want that shoplifting thing following you around. But, if someone pulls your record and sees "sealed" they are likely going to think you did something FAR worse than shoplifting.

Additionally, sealed records don't mean "from everyone forever" -- those suckers can pop up in adult trials if they fit a pattern, if they should apply to sentencing or just if the judge thinks they should.

Don't fuck up too much when you are kid, it will haunt you.

.doc(x) != word. For example, I really like http://www.abisource.com/ on desktops.

Having the ability to open .doc(x) files IS standard, Microsoft Word is not. Lucky we got OpenOffice, LibreOffice, AbiSource and tons of other open source, freeware, shareware, commercial off the shelf software to open .doc(x) on every imaginable platform.

EDIT: I prefer text, because I am a vimmer, but accept opening (and often sending) .docx is a part of the requirements that I can't control.

They made the process of paying for the software a laborious pain in the ass. They are desperately trying to extract money from those who can pay, which sadly drives away those who can pay but don't want an involved process.

I have worked at lots of companies where I had a monthly budget of 10k+ that I could spend on whatever I wanted, but if I wanted any sort of complex deal (can't just put on CC with a line item) -- had to bring in legal and other groups -- instantly killed any interest.

"Licensing is based on the data needed (e.g. all of it vs subset), how it is used (e.g. internal only, external, product integration), etc."

What a goddamn horror show. I simply want a product, I want to pay for it, and I want to use it. Turning on Dropbox for Business was a decision made in about 5 minutes... "You all like it, already using it, awesome! I will get team setup." -- 5 minute later I had given Dropbox $3800.

I really think they are getting in their own way for no benefit. They have created a very high barrier to EVEN HAVING A DISCUSSION about buying the product. So, if I don't know exactly how will use it -- I can't purchase it. Stupidity.

Those ungodly edge cases are what makes vim usable everywhere, and the default of the defaults on so many systems. That trusty vi command that works a certain way has been dependable since the late 1970s.

But, that misses the point of Neovim a bit -- Neovim is about letting the community in (with all the good, and bad that comes with that). I suspect most people won't shift over to Neovim until either (1) They want to actually contribute something and find Vim proper far too daunting, or (2) because of the entirely new plugin model, some amazing plugin is only available on Neovim and it drags them over from Vim.

The Neovim plan seems to be "in months to gain momentum, in years to gain trust" -- which is really the only way you can do it.

The Neovim development path -- by design -- had no chance of upstream-downstream merges. It is a departure, not a premature mistake, but a decision.

The code had to be re-factored to let the community in -- the Vim code is a horrific legacy cruft-fest that terrifies even the most brave developers. But it is a historical working one, which is hard to argue with -- look at those styling commits, they are wonderfully sane.

Wouldn't people in group A.. die?

Bram has said very little. He, IMHO, massively underestimates the communities desire to contribute... Neovim simply tapped in to a community desperate to improve a project they love, and finding no good options on howto do so.

As for "getting behind it if it succeeds" lets hope not! I was a financial supporter of Neovim. I also have run the #vim channel on FreeNode for over a decade. They serve different goals.

Neovim is where "big changes" can happen, gut legacy support, move fast, break shit. It is on Github, it has multiple people doing major contributions, it is being re-factored to make it easier for MORE people to get involved. Neovim wants to be a huge community project, which is awesome.

Vim is -- the default on many systems, shipped with fully working vi compatible mode, has literally millions and millions of users. It can not -- by its nature -- move fast and break shit. Vim has a much, older, slower development process -- from the days well before Github and friends... it might slowly open up -- but not much, because again, millions depend on it. This is also, awesome.

I hope the very best ideas, once they are tested, debugged, and tested again will make their way up from Neovim to Vim, but it will be a very slow process. Neovim gives no thought to Vim -- because it can't -- it has to be its own thing to move forward. Vim gives no thought to Neovim yet -- it is an established, dependable, amazing tool... and Neovim has not yet risen to the point to even be worthy of a response.

"Done In One Week"

Quality, Cost and Scope will be "best effort"

Honestly, it might sound silly, but it would be useful. Give a client an idea of what can be done in a week, lets them know what can be off the shelf and what has the be built, etc. Something like $85 an hour @ 3500 a week. Better than spending a week in meetings arguing about scope.

That article basically agrees with me. Additionally -- notice how it doesn't point to explicit existing examples, but implies "future problems" -- as did the 2006 article.

"In the vast majority of cases, cloud data that is accessible by the end-user will meet discovery needs and obligations."

and

(regarding going after cloud providers) "Serving a subpoena and ensuring compliance can be challenging and potentially expensive. Whether such efforts are worth the expense and effort will depend on the specific needs of each case. Cloud providers are likely to resist compliance with a subpoena under provisions of Title II of the Electronic Communications Privacy Act, otherwise known as the Stored Communications Act (“SCA”)."

Additionally, a director at http://tsemerge.com/ is hardly an unbiased reality oriented 3rd party. The more scared you are -- and the more complex it seems -- the more likely you are to hire them.

On a technical level, I can understand your concerns. I am a developer, and it took me some time to get my head around how it works. But, the bottom line is -- it IS that crazy.

Discovery isn't what you would think from popular culture ... if you served my company with discovery request, "we" (all the lawyers and companies) would have a meeting about it -- you would want to extend your grasp, we would look to shrink it. Most of the time, you would end up with something like "All emails about 'blue paint' between April 2011 and March 2012". Then it is up to ME and my company to find all those emails and provide them to you. Even knowing my email provider would likely be outside the scope. Discovery isn't to FIND a civil issue, it is to find evidence of one already filed issue, so fishing is explicitly not allowed.

Corporate policies are a huge part of the discovery process, what makes it hellish is when you have NO policy around something (like email) because then you have to provide data or prove you don't have it. Our proof is our policy and technical measures.

Our lack of recording data (logging) IS our record management strategy (and a wholly valid one) that massively reduces our costs if we ever get sued.

The "cloud vendor's backup tape" is largely a straw man brought up by engineers rather than lawyers, I think I may have been guilty of bringing it up prior to learning about the discovery process.

Not really, and there is a ton of case law on the topic. The way (civil) discovery works makes the SaaS concern far less of an issue.

Civil cases are NOT criminal or national security -- this is not the CIA, it is not a secret court, it is not being tapped... it doesn't even rise to the level of a search warrant. It is up to the party being requested on to produce the documents. So, if we get a discovery request, we have to deliver the documents to fulfill it.

For example, we have an automatic email cleanup after 90 days -- both technically, and in policy. This means if we are served with discovery, we can show the policy, show we have taken steps to follow our policy and produce the last 90 days of email. Same goes for Hipchat logs.

Now, they could make some crazy play to extend discovery to Google or Atlassian. There are a couple problems with this, the first of which is such an insanely broad request would be flat out denied as fishing. If it wasn't, they would fight it kicking and screaming because they don't want to be involved in every civil case of every one of their of clients. They then would have to actually have the data, which in the no logging situation, hopefully they never had.

Discovery is often used as a tool of attrition, to wear down the guy with the smaller wallet -- run lean (by policy and design) and if you ever get a request for discovery -- you can fulfill it quickly and completely.

Indeed. I suspect companies being started now will opt out of logging more and more. My companies employees work from home the majority of the time. We use Hipchat, Trello, Github, Google Drive, and Email for most of our communications. We limit what we log technically (auto deleted after X days email, no logging on most hipchat channels) and by corporate policy.

We made an active decision to not store / log Hipchat and Email for a few reasons. We have a specific logged Hipchat channels -- but the rest just keep 75 lines for context and that is it. We also never have logged (nor ever will) the 1 on 1 conversations. Employees in a physical location can go outside and rant about a boss, family issue or other random noise -- and this isn't unhealthy, it is normal. We want to encourage open communication and straightforwardness -- and having communications "forgotten" is an important part of that. It also had additional benefits.

1. It limits the nightmare of discovery if we ever get sued, ever word every employee ever said won't be painstakingly scrutinized. Because we want the legal protection, we clearly spell out this privacy in our corporate documents so it is crystal clear to our employees. 2. It allows stuff to be discussed in context and in time and not being picked apart or misunderstood at a later point by other employees. Which encourages honesty and "getting it done". 3. It creates a "separation" of ephemeral communication that have a lower signal to noise ratio (our Hipchat today had many pictures of new desk layouts)... the important data leaves email or Hipchat and makes its way to Trello, Github or Google Drive.

How would you even double-blind for this? Double blind means neither the participants nor the people running the study knows who is on what.

You give half the people Soylent and the other half -- what?

Naturally, they are returned in a uniform manner. To get any rotation (for edge differentiation) would require the ability to handle the cards (which he did not have) or the ability to convince someone to rotate cards (which is what it is alleged they did).

Additionally, Phil Ivey is an astonishingly good poker player (20M+ club, 8 braclets), but is known more as a degen on other games.

Going to do my best to put a quick summary (from memory) on something that took us a long time to get right and was a bit convoluted.

Our units actually would report to intermediaries their maximum interaction boundries, which would then be passed to processes to create something somewhat like a mast, someone like a subgrid -- a dynamic interaction zone. All our units had hard constraints (max speed, etc) and worked in global ticks that represented real time. Then, we would talk to global to stretch all the interaction zones to fill empty space and report back boundaries. Then, our units would work in little worlds until they crossed a threshold, we caused a rezoning among them and their neighbors. So initially, the everything would have to be parsed out into interaction zones, but then they could ignore each other for periods of times until a unit strayed across an edge, and then rezoning took place.

Not sure how well it would work with amped up movement (making it have to go all the way up to global more) and not certain how it would work at the scale of 1 undecillion 329 decillion 227 nonillion 995 octillion 784 septillion 915 sextillion 872 quintillion 903 quadrillion 807 trillion 60 billion 280 million 344 thousand 576 points!

Isn't the fundamental point of concurrency the players?

Couldn't you have X players moving on a global grid? I have built systems with literally tens of millions of players (Erlang processes) moving on a grid (and doing way more, localized threat detection, decision making, moving away or towards, and coordination with other units in X range).

Theory versus reality. The theory of federated XMPP is exactly as you said.

The reality is much more of a mess, with multi-device issues -- routing issues -- federation issues, not to mention a ton of non-XMPP messaging services.