Kilenaitor

He did not lie about the legs. He said they were coming soon. No different than any other marketing video about a sill-in-development, upcoming feature.

No. They testified that a single person wouldn't be able to.

> The court-appointed expert asked who at Facebook would be able to answer the question: where is all the information on a single user stored. > > "I don't believe there's a single person that exists who could answer that question. It would take a significant team effort to even be able to answer that question," answered Zarashaw.

https://www.businessinsider.com/meta-doesnt-know-where-all-y...

The transition to Eden has been... weird. Like, I'm sure it's actually meaningfully better in certain metrics but yeah the fact that rebasing from one local commit to another local commit requires a bunch of network I/O is non-obvious and slow... Checkouts feel so much slower, too.

Further slowed by HHVM deciding to crash itself after a "large" rebase to download type checker saved state remotely because that'll somehow be faster than rebuilding it locally is...

We've been making developer experience optimizations _long_ before they started demanding high salaries. The whole reason to go from assembly to C was to improve developer experience and efficiency.

It seems fairly reductive to dismiss the legitimate advantages of increased productivity. It's faster to iterate on ideas and products, we gain back time to focus on more complex concepts, and, more broadly, we further open up this field to more and more people. And those folks can then go on to invest in these kind of performance improvements.

Is "the math stuff" all the optimizations being performed e.g. vectorizing multiplication?

Not trying to sound dismissive here but the core math the post is working with is actually a pretty straightforward matrix multiplication.

The bulk of the discussion focuses on optimizing the execution of that straightforward multiplication algorithm [triple-nested for loop; O(n^3)] rather than making algorithmic/mathematic optimizations.

And again, specific questions are easier to answer. :)

Which parts are you unable to read and understand? I'm sure some of us here could help explain if you have specific questions or hangups.

There's always been a tradeoff in writing code between developer experience and taking full advantage of what the hardware is capable of. That "waste" in execution efficiency is often worth it for the sake of representing helpful abstractions and generally helping developer productivity.

The real win here is when we can have both because of smart toolchains that can transform those high-level constructs and representations into the most efficient implementation for the hardware.

Posts like this demonstrate what's possible with the right optimizations so tools like compilers and assemblers are able to take advantage of these when given the high-level code. That way we can achieve what you're hoping for: the default being optimal implementations.

When did Facebook say only criminals have something to hide?

I work at a big tech company (not MS, though). The short answer is it really all comes down to prioritization.

In my experience, we do have the same kinds of tools for surfacing those issues. Granted, they do tend to differ per function or even per org, although there are some standardized ones you can plug into to get e.g. issue aggregation, stack traces + metadata, etc. Granted... a lot of the time that requires a team to 1. actually plug into this infrastructure (otherwise it can either bubble up as an unknown exception or, worst case, get swallowed by a try/catch) and 2. actually pay attention to things once they do plug in.

The other problem is not just the high scale of traffic (or 5XXs or errors in general) but that high traffic is usually due to a myriad of products, features, etc. And there's just simply too much work for too few people. So, we prioritize based on severity of the inherent issue (e.g. privacy/security issues go to the top) or, if that's equivalent, number of affected users take priority. Which just means low-severity, low-impact bugs almost never get fixed. Especially if they have a workaround that can be surfaced e.g. when someone reports the issue to support.

Happy to elaborate further if that doesn't make sense. I also want to clarify that this explanation isn't meant to be some perfectly valid reason as to why this kind of work doesn't get prioritized. I agree a lot of times big companies fall short here, including where I work. This is just one of the many tradeoff that get made when there is more work than people.

That's literally the only reason I use it. It's fantastic.

mosh by default doesn't support native scrollback. The way mosh is implemented (by default at least) is to just paint the screen locally with the remote "view".

If you try to scroll back in your terminal locally (literally scroll up with a mouse/trackpad), it will scroll up your local terminal instead of scrolling up in the remote view. So your scrollback is literally capped at the vertical height of your local terminal window.

This is super annoying if you want to see long output of a previous command or even see what the output was of the command you ran five minutes ago.

ET solves this by basically doing ssh under the hood. So you have real scrollback by default. It's REALLY nice and is one of the primary reasons I use ET.

---

As far as tmux control mode, in essence, it allows you to control tmux via your native terminal commands. On iTerm for example, you can use the key command to vertically split the (iTerm) terminal and tmux will actually hijack that command it do it in tmux. So you can use your native terminal multiplexing commands instead of the tmux key commands.

I only know of iTerm 2 that supports this functionality, just as a heads up.

> That makes it worse.

In what way does re-licensing their most popular packages make it worse? It says they're evaluating. Doesn't say no and as demonstrated here it doesn't mean they wont change their mind later.