steventhedev

This is a really good demonstration of the curse of dimensionality[0]

[0]: https://en.m.wikipedia.org/wiki/Curse_of_dimensionality

You are writing this as if security was a newly invented thing. Having done systems level security development for 12 years, anything that can be produced maliciously will be. By using JSON, you've invented a new vulnerability class for malicious deserialization attacks.

Actually, not new. Earliest CVE I found was from 2017, which feels a decade later than it should be. I guess no one thought of pushing JSON over trusted interfaces, and probably for good reason.

The danger I see is that JSON has lots of edge behavior around deserialization, and some languages will deserialize a 100 digit number differently. If the main benefit is removing the broker and the need for rate limiting - it could have been accomplished without using JSON.

I should probably just write it up into a post, but the git mailing list at the time is the source (I remember reading it from the side a few months after convincing our VP R&D to switch from svn to git). We were chuckling around the same time that FB had to reallocate the stack on Galaxy S2 phones because they were somehow unaware of proguard or unable to have it work properly with their codegen.

Anyways:

1. Github benchmark: https://github.blog/engineering/infrastructure/improve-git-m...

2. The original email thread: https://public-inbox.org/git/CB04005C.2C669%25joshua.redston...

3. There's another email thread that gets linked everywhere - but in light of the prior thread, the numbers don't track: https://public-inbox.org/git/CB5074CF.3AD7A%25joshua.redston...

I recall there being a message from someone either at AirBnB or Uber who mentioned that they have a similar monorepo but without the slow git status, but can't seem to find it now - it's likely on one of the other mailing list archives but didn't make it to this one.

Point being that painting this as "the community was hostile" or "git is too slow for FB" is just disingenuous. The FB engineer barely communicated with the git team (at least publicly) and when there was communication, it was pushing a single benchmark that was deeply flawed, and then ignoring feedback on how to both improve the performance of slow blame, commit by repacking checkpoint packfiles (a one-off effort) and also ignoring feedback that the benchmark numbers didn't make sense in absolute terms.

I'm gonna disagree with you there. The difference was with stat patterns, and the person at Facebook who ran the tests had something wrong with the disk setup that was causing it to run slowly. They ignored multiple responses that reproduced very different results.

Nail in the coffin on this was a benchmark GitHub ran two years ago that got the results that FB should have: git status within seconds.

Facebook didn't use mercurial because of big O, they used it because of hubris and a bad disk config.

I can imagine the EU is far more interested in an EU flagged company doing business with Hezbollah who are a designated terrorist organization and subject to sanctions.

If there's one thing you learn quick in fintech - it's you absolutely do not fuck with sanctions.

Please note that this is distinct from yesterday's incident - these are for a different set of communication devices - from what I can see, they went off at 16:58 local time - notably 2 minutes prior to Nasrallah's planned speech on the first incident.

Doesn't matter. Hezbollah are subject to sanctions by the EU as a designated terrorist organization. Presumably, that applies to all companies operating within the EU.

Sanctions violations are very much a "do not pass go" style crime, and this looks like it was an entire batch that was delivered directly to Hezbollah.

Having done nearly 100 technical interviews (with multiple questions each), the bug squash question gave us the biggest signal on candidates.

Our question was far simpler: it was a simple class (java + python variants, no fancy syntax) and ask them to describe what it does, then find the bug, and finally ask them what they would change.

It reflects a true test of what the day to day is, and whether or not the candidate would succeed in the role.

They were only granted that gTLD because in their application they explicitly said they would never allow GA registrations.

Google did extreme evil with .dev, with the blessing of ICANN.

> This long-term investment that began on the mobile-first foundations of the Android Open Source Project has produced a full mixed reality operating system used by millions of people.

Which gives some context to the calls for Google to bring the play store content library to Horizon.

There are a few key things that you get by targeting a terminal for your UI:

* Remote desktop forwarding through tmux, ssh, mosh, etc

* Instrumentation of your UI - simply replay the input

* Screen recording with asciinema

Not to mention that you can target the exact same UI framework across Linux, Mac, Windows, and more.

On the other hand, it doesn't play well with your desktop environment. Taken to an extreme - if all your daily drivers are in the terminal:

* You can't easily tell them apart because they all have the same icon

* Some of those bells and whistles might not be supported in all emulators - tmux and mosh are probably a good baseline.

* Accessibility support is lacking (TFA). This is probably more of a demand side problem than anything else though.

On the whole, it's a decent enough UI target for an inner platform on the level with the web - all we need now is Muon - a wrapper that includes a terminal emulator so you can write "native" terminal programs with their own icons.

Yet another study comparing handwriting with one handed typing. Actually worse than that - they didn't even display the letters typed.

Even if that were somehow ok, they should have seen greater visual engagement for hunt and peck one finger typing (exclusively right index finger).

No mention in their methodology if they allowed students to practice the one word they gave them to write five times either, which further pollutes the data.

Bottom line - poorly designed study produces predictable results and researchers use that soapbox to suggest educational policy.

Keepassxc and syncthing.

I sync two databases across Mac, linux, ipads, and android phones. One for work, one for personal.

The invasion was in response to Confederate attacks on Union forts - starting with Fort Sumter.

Saying the civil war is not about slavery because the invasion was about responding to Confederate belligerence is like saying that someone who died with Covid-19 actually died from heart failure. You might be technically correct (most people's hearts fail when they die), but it's at best pedantic and at worst disingenuous.

100% about slavery (from the mouth of the southern states themselves):

https://www.battlefields.org/learn/primary-sources/declarati...

That was just the first result from searching for "letters of secession"

At an old job I spent my first week on the job documenting the process from a wiki page into a bash script (albeit with some comment sections that said "do this manually"). A year later, one of our devs was up for a laptop upgrade and I convinced him to give Linux a try. I shared my script with him and he was up and committing code later that afternoon. The next week we had a company wide mandate to switch to linux for dev laptops.

Point is that just taking the tiny step of forcing this from a wiki page into code can tip things towards automation. The real difficulty is keeping those scripts up to date. I'm still working on a solution for that (hopefully I'll have something to share in the next few weeks).

These content filtering schemes are usually legally mandated, and the age of 18 is set by law.

More likely than not, this got caught up in a regular job that scans DNS zones for new domains to "filter". It's just a matter of time before this catches anything related to Scunthorpe[0].

[0]: https://en.m.wikipedia.org/wiki/Scunthorpe_problem

brotli on the raw word list gives 17194 bytes. gzip gives 32352.

A lot can be done in 3014 bytes, but what's the difference in code size for the ascii trie vs. a flat list/gzip/brotli?

The fact that it broke anything for anyone is a strong argument that it never should have been created in the first place, alongside .home and .corp.

They were aware of the issue, buried it in the report and reneged on their promise to keep it internal-only. That was the mitigating argument for allowing it despite the known existing usage. Google acted in bad faith and I'd need to see concrete proof to convince me otherwise.

Git is split into two parts: the plumbing, and the porcelain. It's a toilet metaphor. You don't directly work with the plumbing unless you really know what you're doing.

That seems to imply that LSHs are a subset of DRs. Are there LSH techniques that are not applicable to DR?

It seems like this approach could be adapted as a dimensionality reduction technique: select a set of k random hyperplanes denoted p_i, then map each point to a new vector r such that r_i is the distance to the hyperplane p_i. My gut tells me it may be more efficient to reuse existing nearest neighbor approaches in that embedding space than to bucket them and compute the partial intersection of 20 sets.

That having been said, this was a wonderful read, and beautifully presented.

I'm sorry to hear that you got bit by the docker networking thing. It bit me twice in the past. Once with a new server and once when they changed the config format from envvars to json (we were disabling dockers iptables nonsense).

Do you know if they simply encrypted the data in place or if they succeeded in exfiltrating a full copy?

There's an entire class of vulnerabilities caused by having separate verification and parsing logic, typically with fields that usually only one is used, but the format supports multiple. The verifier checks the first one but the parser uses the last one.

It's sad the difference between expiry and eviction isn't explored more fully. There are plenty of posts describing cache eviction strategies that barely touch on expiry issues, and a handful of posts about cache expiry that barely touch on eviction.

Regarding the decorators, there's a reason it's popular: it saves boilerplate. The good news is that it's python, so you can do something like this:

  from pyappcache import RedisCache

  @RedisCache
  def get_slow_thing_v3(thing_id):
      thing = get_slow_thing_from_a_database_layer()
      return thing

  def update_something_slow(thing_id, new_thing):
      get_slow_thing_v3.set_cache(thing_id, new_thing)
      set_thing_in_a_database_layer(new_thing)

With containers, both the kernel and the hypervisor are shared. With vms, only the hypervisor is shared.

It's a matter of having a smaller attack surface. There are plenty of container images that run with root access by default, which is almost full access to the kernel. This means that if the application running in the container is compromised, you need to rely on the kernel enforcing the sandbox between containers. This is a relatively new threat (root not being fully trusted), so beyond there simply being more attack surface, there's likely to be more bugs/vulns out there to be discovered. With effort and care you can safely run this but reducing attack surface is a good idea for defense in depth.

As others have pointed out, mosh doesn't support port forwarding, and because ssh doesn't support udp forwarding, can't easily be used with proxyjump servers.

Story time: I had tmux sessions active on all our servers and would simply ssh into my work laptop from home, so the sessions were never really closed. One day, I decided to upgrade from 1404 to 1604 and closed out all my sessions (including on the servers because I was pushing out a new tmux config). After 5 minutes we started getting smss that the system was down and couldn't write to disk. One of our production servers had been set up with an encrypted home folder and when my session closed out, it closed the encrypted folder. Unfortunately, the ssh folder wasn't outside the encrypted portion, so we had to use IPMI to restore access. That's the story about how we started joking that closing my laptop is a great way to break the production system.

If you're seeing retransmission errors on a wired lan, then you should replace cables and any network equipment until they go away.

A basic assumption of TCP is that retransmission only happens due to congestion. It fundamentally assumes a perfect channel, which is why wireless connectivity doesn't play well with it. There have been many attempts to fix this but they require changes in both the AP and the client, so I don't think anyone has really bothered to implement in common hardware yet.

Weren't Iranian devs banned from github last year[0]?

That aside, I dont see any first hand source for the repo owner being Iranian, only speculation in the comments. The situation is sad, but a reasonable response to a PR that has legal issues. I don't think there's much intelligent discussion that can be had about this.

[0]: https://techcrunch.com/2019/07/29/github-ban-sanctioned-coun...

EDIT: github doesn't show profile location on mobile. My bad.