finnyspade
USB-C to be specific
While yes it's an uncomfortable transition period, the idea of a common socket for all connections is amazing! This isn't Apple killing USB in favor of thunderbolt (which happens to run over the same connector), it's apple using the latest USB spec.
https://manishearth.github.io/rust-internals-docs/rustc/dep_...
Note that as per:
https://manishearth.github.io/rust-internals-docs/rustc/dep_...
The DepGraph that we actually care about is specialized to talk about DefIds. In rustc, DefIds are attached to the following things:
https://manishearth.github.io/rust-internals-docs/rustc/hir/...
This means dependencies are analyzed down to local variables and uses. But even beyond that it tracks things such as borrow checks, linting and more!
function IdentityMonad(v) {
this._v = v;
}IdentityMonad.prototype.bind = function(f) {
var o = f(this._v);
if(!(o instanceof IdentityMonad)){
throw new Error("function must return IdentityMonad");
}
return o;
}The error is really solid at showing a type mismatch. Which is of the form "I wanted X but you gave me Y".
> that the hint be way off is actively harmful That's true and they could probably do a bit better for type mismatches on type variables vs concrete types
> just dumping the raw error What's the difference between a "raw error" and something else. If the hint was accurate would it still be a "raw error" because it's not styled like those elm errors? Any more info (aside from a better hint which I concede should be better) would have to be an actual explanation of static typechecking which seems a bit extreme.
All I'm saying is while this error isn't a paragon of what all good error messages should be, it's no more cryptic than any other similar error. Even the nicely formatted elm errors say essentially the same thing.
22 println!("trait: {:?}", i);
This error message is fantastic! On line 22, i is of type T which does not implement Debug. The hint is off, but the actual error is super useful.
Turns out if you google "Rust e0277" which is the error code he got, this is the top result: https://users.rust-lang.org/t/generics-or-how-do-i-solve-an-...
Which contains the same solution to his problem.
TL;DR Nothing to see here, just a case of "let me google that for you"
The harassment stuff isn't a zero tolerance thing. They even told us to go ahead and ask out other employees if you're interested, but just don't press if you get a no.
It's pretty clear he accessed data he shouldn't have, and for that a zero-tolerance policy makes total sense.
Is Facebook supposed to somehow know the video was uploaded to YouTube before? That would require Facebook to have an index of all the content on YouTube (an unreasonable proposal).
The next best thing is to allow takedown requests which they do!
The same thing can be done by reposting on Vimeo or any of a million sites. There just is no technologically and legally sound method to detect this sort of behavior.
If you don't want your video to be reposted by someone else, post it yourself. That's not to say it's okay for pirating to happen but this isn't Facebook evil, it's people.
One might blame Facebook for prioritizing it's native videos over embedded YouTube content but their policy on that is very public and the user experience IS better.
Why is Facebook being demonized?
1) Guess how those Instant Articles are formatted? HTML. Guess how those articles get to the app? HTTP.
This is misleading because it seems to equate pulling in content with loading an article. By loading these articles into the app (as opposed to launching a browser), Facebook gains the ability to do the following:
- Provide the basic styles from app-install time. Most of your css doesn't need to be downloaded.
- Skip app boot time. App's take a while to cold start, meaning I don't have to start safari before I start the web request.
- Prefetch. I don't know if they do or will do this, but facebook could reasonably prefetch articles and their resources before you click
2) Stop buying into the ‘native is better’ myth. (It’s just different.)
Another phrase for "different" is "better at different things". It turns out that the app model provides some amazing guarantees that the web can't match (and vice-versa):
- Preloaded styles and logic. Content changes, but presentation stays the same. Only download content. (no caching is not a valid solution, because exercising new parts of the code would require a download. Though some appmanifest magic may let you get pretty close)
- Cheap library inclusion. If an app is an extra MB or so it's no big deal most of the time. You can use that to load in libraries that vastly speed up developer work and can do "progressive enhancement" by supported new APIs on old OS versions. Libraries are way more costly on the web as the author points out.
- Consistent (with the OS) UX and much cheaper animations
- Lower memory footprint
These things do matter! The web is amazing, yes. No, it's not dying, but there is value in native apps and they're not equivalent. Smart engineers will make the choice based on their needs which is what both facebook and these news sources are doing.
I would wager it helps the windows phone users and doesn't hurt other people. Also it's coming to windows 10 I believe.
When connecting to a password protected router you are given an UNCHECKED BY DEFAULT option to share the password with your friends. What this means is, the user can deliberately share the password they know.
This is just as secure as any other system because once you give a user a password they could share it if they chose. Nothing here is "automatic" no data is being proliferated without user consent. If your employees leak your password this way, then it's the same as leaking passwords otherwise.
Again this not an opt-in-by-default scenario. It requires a user knowing a password to actively choose to share for each router independently.