Discover (verb) find (something or someone) unexpectedly or in the course of a search.

The majority of surprising discoveries fall into two categories:
. A contradiction of previously held notions,
. Unanticipated finding

It's largely the lottery phenomenon: "There's 10^6 dollars behind one of these doors" "Number 2" *cheers* But you knew the prize was there, you knew it was behind 1/3 doors, so why does *anyone* have a reaction to the correct selection?

Powered heavier-than-air flight was a "discovery" when we simply stopped doing it the wrong way.

Black holes would test the validity of many models, but nobody knew for sure if they really existed. Across those camps were different camps that varied on whether a black hole would be detectable. We were "surprised" at the ways we were able to discover black holes, not for the result but for the pass-on implications of the methods used and the models tested.

Exoplanets: The presence of accumulated rock or gas around a distant star... Literally: "Look, more rock/gas!"

Generally, we "discover" them by looking at where we think they will be, often clued in by previous data: "There's something behind this single door, or there isn't".

The gas, dust and rock themselves are completely tedious, but the implications of them being present in the necessary combination in the right orbit around a good star close enough to ourselves has the *potential* to provide opportunities for further investigation, and it's against the odds by more than 1/3.

In this way, they are "discoveries" the way any piece of land that someone intentionally traveled to was a "discovery" - Africa, India, America... There were people already living there, but it was still a discovery to those who confirmed that the place they'd been told was there ... was there.

So if you are testing some random property of bricks that involves your throwing them, and you record the right values of data, you could easily "discover" that bricks do in-fact experience some degree of lift as they fall, but that their other properties are more than enough to defeat it, and so they don't fly very well.

But it's not going to make the press unless you have some previously unknown or novel extra revelation, insight or finding that comes with that piece of "news".

I'm not convinced that the majority of what I see on laptops either when I was on the shuttle's or when I'm on caltrain or bart, was actually work related. When I worked at blizzard, I probably spent less time with hearthstone on one screen than I see it in commute-tops :)

Last count, Google has over 50,000 employees in the bay area with its campus expanding all the way from Mountain View down into San Jose now. Facebook has under 15,000. Redwood City, 2014 Population: 90,000, just saw the opening of giant 6+ story apartment complexes that increase its population nearly 20% over a few months.

Cisco has over 60,000 employees in its massive 3-city campus at the north end of San Jose.

But the RV campus was previously lining El Camino Real in Palo Alto outside Stanford, it just wound up in East Palo Alto because they got kicked off the Stanford property.

Google, Facebook, and Apple all need their asses kicking for this stupidity of putting tens of thousands of employees into single buildings because it makes for "better creativity". Really? 2 hour commute each way makes people more creative? It makes them earn a ton of money of which they see none because of rent and living costs beyond ridiculous.

2 bed apt within 40 minutes of google is likely to set you back ~$3000/month.

With my Verizon contract ending days before the new 'droid phones came out and with a 30-day return policy, I accepted the Windows phone to give me something to blog-rant (brant?) about until the droid phones arrived. The experience was amazing until Ballmer killed the device by announcing the merge-to-windows-8.

Metro wasn't a cosmetic touch up of Windows, it was a do-over. It was a UI entirely built around the phone/tablet from the very ground up, and it was as delicious, delightful, intuitive an experience as you could have wanted.

It comes down to this: Desktop OSes, iOS and Chrome have displays based on "panels", "windows" ... display elements. Metro was philosophically entirely button based. It sounds trivial/trite, but fundamentally anything the user could see had an interaction property.

Until they started merging it into the Windows UI for "all device support".

That's when people started letting their desktop developers influence their mobile design and you started seeing apps simply ported so that they were "operable" under Metro, or didn't bother.

In every other touch UI, you have to learn/guess what gestures/touches you can make for any given presentation, like playing a flight sim without a keyboard guide, or playing a text adventure and having to guess the author used 'anthracite' instead of 'coal', vs playing a point-and-click game.

In Metro, everything on screen was touchable, everything you could do was on-screen aside a couple of global gestures/physical buttons.

This lead to consistency, this lead to a short learning curve for almost any app.

I'm really, really glad to have had the experience.

I don't /miss/ my Windows 7 phone because ultimately they killed it, and the last few months weren't much fun.

But I do miss the best of Metro and every time I use a droid or ios phone ... I want to kick Ballmer in the Ballmers.

What advertisers pay Facebook for/get from Facebook is an ad-matching service, NOT your data.

"Show my ad to 20-29 year olds in Boston who are members of the Red Sox Fan Club group. Here's the text and images".

And finally, Facebook hosts the text and ads.

Data given to advertisers: 0.

[Full Disclosure: Facebook Production Engineer 2014-2016]

Not only is the second secondly not a secondly, there was supposed to be a thirdly in-between 2 and 4: The "character" as perceived by a "player" explicitly uses materiels created by Blizzard for the purpose of representing the "character" identified by that name - the model appearance, etc. LightsHope does not attempt to "recreate" the character, but actually exploits Blizzard's original material to make the character visible.

LightsHope isn't a MUD that you can log into and play text-only; it's not a wow-clone that provides its own community-contributed models and assets and nor is it a wow-emulator in the sense that you can access it with a 1st or 3rd party client program to play the game. It *explicitly* requires the Blizzard game client for its code AND materiel assets. If you do not have the Blizzard-created assets that comprise the layout of stormwind zone and cultural objects (buildings, etc), then you would not be able to play there in lightshope.

It doesn't break down like that.

I didn't say the npc names are copyright. I said "simple things like NPCs that have the same name as WoW": They are set in the same locations, they have the same lore and back story. No provision whatsoever is made to avoid infringing on any copyright that Blizzard might have; indeed, the exact opposite is true.

Consider a character called "Wynne Larson" in the city of Stormwind. Firstly, the entire fantasy setting is one created by Blizzard, not coincidentally, not accidentally, but deliberately, specifically leveraging Blizzard's text and binary materiels - that is art, textures, meshes, navmeshes, colliders, props, npcs, animations, rigging, shaders, sound effects, music, triggers, interactables, achievements and all the ip such as lore etc, without permission.

Secondly, the NPC in every way attempts to recreate the original character designed and created by Blizzard: The name explicitly references a character of that name in the Warcraft IP including accessing the visual model used by Blizzard in World of Warcraft. Not coincidentally or accidentally but explicitly and deliberately. The LightsHope dataset specifically instructs the WoW client to render the exact same model, in the same setting with the same behaviors, same items, same dialog, etc, as that in World of Warcraft.

Secondly, the fact that the "server" comprises some number of independent works of code has no bearing: it is part of the whole "game system". I could give you countless parallels or analogies, but I'm going with a tounge-in-cheek fun one, ok? If you pay for next-day UPS delivery it does not buy you permission to board the driver's vehicle and find the package for yourself.

It comes down to some very fine detail, which is basically that Lights Hope is entirely dependent on the use of the WoW client and its data. There are no character models in LH that weren't create in whole by Blizzard Entertainment. Those portions of content that were input by LH authors attempt entirely to duplicate material originally created by Blizzard Entertainment, and specifically does so using tangible assets created by Blizzard.

This inability to see the drawing of a parallel between data/ideas and concrete items shows now effort or ability to comprehend the copyright issue. The coward can safely be ignored.

The Warcraft lore/IP is not public domain and this project was based on a server emulator (MaNGOS) using Blizzard's client. So - the art, the zones, items, npc models, character models, etc, are all Blizzard's. Some of the content, such as NPC dialog, etc, had to be recreated, but since the goal was to recreate the material content of a still-in-development, still-in-operation product - and courts do not accept 'its not what it was' as a legal argument for discontinuity/abandonment - then simple things like NPCs that have the same name as in WoW ... is clearly an infringement of copyright.

LightsHope is a derivative of MaNGOS, a server emulator. This isn't a fan-recreation, you need Blizzard's client software and data to be able to play.

All the actual original creative and engineering work, creating and designing the zones, building the systems to support it, server, client and client/server, was done by Blizzard.

This is *very much* a direct violation of Blizzard's IP, copyright, trademark and etc rights.

As for Blizzard, they continue to actively develop the product, they've engaged the community in discussions about legacy and vanilla servers.

Contrary to the way "my chalice of leaving mom's basement" posts like this represent things, Blizzard are actually receptive to mimicry and fan works. Take a look at "Dungeons 3" sometime, and bear in mind that's #3.

There is a point at which Blizzard have to take action if they want to protect their ability to continue operating their business and having the ability to develop Blizzard quality games ... like WoW.

Dear Sir/Madam, I forced the lock on your back door this morning to find this house abandoned. I had to force the lock because you did not offer access to the tv or coffee machine and this exclusion creep was forcing me to use the space in a way I never intended to.

If you offer public access to your rooms, we can talk.

I made no such suggestion, however you made a very large assumption based on my terseness.

... making the difference between "return the evaluation of this expression" vs "don't" is such an improvement in software development practices.

Rust is interesting, the way that that wreck on the 101 is "interesting".

There are three main types of computing environment:

- Monolithic single process,
- Complex single process,
- Mixed processes

MSP: written in a low-level language (asm, c, c++), typically a very finely tuned process that may use CPU threads for parallelism in a very carefully managed way, probably implementing its own scheduling etc. Non-deterministic operations like OS/Kernel interactions are generally very, very carefully supervised, custom memory management all over the place, etc, this is the core focus of the system and every effort is made to strip the OS down to preserve cache and determinism,

CSP: possibly written in a less high-level language or one that uses a VM, or incorporates lots of disparate libraries, less to no focus on determinism, often heavy interaction with the os (file access, etc), non-organized thread organization (typically task-specific threads), cache/memory efficiency may be optimized for algorithms or routines but the overhead multitasking isn't a major factor,

Mixed: The system is expected to run a large number of processes/services and the process has no expectation of determinism, everything from assembly to python-implemented-in-bash.

The design of Windows means that it's hard to build an MSP on Windows but it's feasible now with some of the server versions. These are usually extreme cases like High Frequency Trading but also all kinds of realtime systems.

CSPs are your "performant" industrial server process, from game servers to web servers. They probably take huge amounts of RAM for granted, but you'd probably get fired if you logged in on one and started using CPU.

Mixed: everything from your mundane intranet server, mail machine, firewall, to desktop computer. There's a ton of stuff running and unless someone logs in and uses 100% cpu for a couple hours people probably wouldn't notice even high amounts of contention.

For all of these solutions we follow one model: Everything competes for time on the same CPU: Scheduler, Kernel, OS and Processes.

We've moved some tasks out to co-processors which have been reabsorbed into the CPU: MMU, FPU...

Now we have complex chips with multiple cores and ... thread assignment is done in code, in competition with the code-threads that should be running?

In the MSP case: The OS is essentially a forced hit you have to take on your processor availability: you know that every so often it's going to pop in and steal some cycles determining that ... you should carry on doing what you were doing, sorry for messing up your cache line.

In the other cases, especially when there are a lot of processes, you get a gradual degradation caused by the system taking longer to make decisions about what is fair, while it is, itself, obstructing work from being done.

We need the ability to have a Kernel-Core or a Scheduler-Core with custom instructions that can do things like tell memory to go zero a page for us rather than writing zeros to memory... That can get special state information about the CPU cores to make smart decisions about what to run, instructions only available on those cores.

Putting the kernel on its own core gives us a security barrier, and again allows us to dedicate instructions.

We're over due for this architecture. We're already trying to do this with containers and hypervisors, but CPU vendors are just like "*shrug* we'll sell you more of the same"...

The most obvious change needed in the US is that voting needs to not be optional: Bump individual tax rates by 1-2% and make voting get you it back.

We should also look to make the campaign durations shorter so that they don't have the time to get into mud-slinging and filth and focus on issues.