matthewbauer

> Team members in low-wage regions being in golden handcuffs and sticking around because of the compensation even when they are unhappy. We believe that it is healthy for the company when unhappy people leave.

What??? Only in SV could a company get away with saying it’s “healthy” to not pay people their value. Usually, golden handcuffs refer to retirement and other benefits, not base compensation.

Google isn’t remote-only, although I bet plenty of people are angry that they do the same work as someone who lives near an ocean, but get paid less.

Here’s a question I had on GitLab’s policy:

Let’s say I move to SF for a few months starting out at GitLab. I then move back to a lower cost of living area, for family reasons. Is the paycut immediate, or is there some room for negotiation? Surely very few people are going to be happy have a loss of pay.

Did you try a counter offer? I would think they would be flexible on this if they are in fact paying people in SF and NYC that much.

I wonder if anyone has tried moving to NYC/SF for a year and then moving back to lower cost of living. Would these remote-only companies really give you a paycut?

I'm pretty sure they use libressl now.

This would have been helpful weeks ago. Now I fear that Americans are set in their coronavirus way - we expect grocery stores to sanitize every item but don't think twice about walking right in front of a cashier with no mask!

Shouldn't any covering help? Like catching 50% is much better than 0%, even if the N95 can catch 95% of particles.

I thought Git was Git for data.

It doesn't require nearly as much storage as you think. For zig, there's only 3 standard libraries (glibc, musl, mingw) and 7 unique architectures (ARM, x86, MIPS, PowerPC, SPARC, RISC-V, WASM). LLVM can support all of these with a pretty small footprint and since the standard libraries can be recompiled by Zig, it really only needs to ship source code - no binaries necessary.

I would be really surprised if Ubuntu had issues that Manjaro or Arch don't have. Debian and Ubuntu is usually pretty ahead on testing different hardware combinations. Most likely this is some hardware-specific issue and you don't own the same hardware as GP.

Doesn't wx just use GTK under the hood?

Git rerere can help with multiple identical conflicts.

Recently there has been a push to remove user agents since it tends to make tracking easier. You should make sure firefox is still identifiable.

I suppose if you happened to previously have code with the string 'use strict'; at the top, and did non-strict things below, it would break. In a very small scale, that does break backwards compatibility.

I think you may not realize how many bugs NASA programmers are making. For instance, see the fairly simple mistake made on Deep Impact spacecraft:

https://en.wikipedia.org/wiki/Deep_Impact_(spacecraft)#Conta...

There are no doubt more, that don't cause the loss of an entire spacecraft.

It could mean that in a close vote like this, the result was due to random chance and not the will of voters. This does happen in fptp as well but not to this extreme.

Perhaps Bitfinex is padding reported tether trades to make it look less risky?

Nice analysis!

But if it’s really just too loud, isn’t there some way to muffle the sound? I suspect it would be expensive but certainly not ridiculously so.

Yeah, Emscripten does support exceptions, but I don't think Emscripten creates WASI yet? It would be useful to separate out the exception handling from Emscripten to a runtime library so that other projects could use it, without relying on the entire Emscripten toolchain.

I suspect we'll get exception handling at some point, but for now so much stuff just does not work without it. The whole idea of WASI is that it is not JavaScript-specific, so needing some JavaScript code just to get this basic feature is kind of surprising.

I don't think this exists yet, but it is definitely possible to write a WASI runtime in pure JavaScript. A precursor to WASI, jfbastien's musl fork, had one:

https://github.com/jfbastien/musl/blob/wasm-prototype-1/arch...

Exceptions still don't work! That ends up making lots of C++ code not compilable.

But how do you test lamba_handler then? Without a way to run lambdas locally, this sounds like a big black hole in your infrastructure.

Considering the Kochs a level below Epstein is pretty disgusting. I don't think anyone in the Koch family or Koch industries has ever been accused of breaking any criminal laws - although their factories regularly break civil laws. This so called lawyer is intentionally blurring that line. This is definitely a new low for Lessig. We should expect more from influential lawyers.

- The "Pain point: no concurrency" thing seems wrong for Nix. By default, Nix isn't using any hooks at all, and it should be concurrent. The confusion might come from the fact that NixOS does have something kind of like hooks, but nothing makes you use them.

- The QEMU results are highly misleading, because there are tons of different configurations possible with QEMU. Nix builds all QEMU architectures while the Alpine one only is getting qemu-system-x86_64. It's apples to oranges.

- The Nix docker image is not actually running NixOS, but instead running Alpine. It just has the Nix package manager installed on top of that.

Initial jobs reports are rough estimates that come out fairly quickly. Over time they get revised either up or down as more data becomes available.

That would work better. It probably still requires some curation. For instance CVE patches, configuration changes, and added platform support usually won’t include a version change. Just using the first commit may mean you miss those changes.

I have a quick mockup of something like this in Nix:

https://gist.github.com/matthewbauer/7c57f8fb69705bb8da9741b...

It keeps makes past versions of packages available to you, but does not really help with discoverability.

I think a tool like that could be very useful! The main issue with basing it off of Git commits is that there is no guarantee that the last commit with a given version is actually a good version. Consider the case where a-1.0 depends on b-1.0 and b is updated to b-2.0 in a commit so that a is not compatible with b-2.0. Even though a-1.0 is still around, it's not going to work until we update it to a-2.0, so you need some more complex constaint solving on top of your commits to figure out what works.

I would prefer doing it based on the 6-month release channels, so you get multiple version for every 6 months. You end up with some gaps between versions, but also have more guarantees everything actually works together. Basically "nix search" with multiple channels.

I actually had to do something similar with GHC versions for a project of mine. It turns out you can run Nixpkgs all the way back to the first release in 13.10 (LC_ALL=C is needed). Obviously not that long ago right now, but it should continue to work as time goes on & give us 10+ years.

https://gist.github.com/matthewbauer/ecdb665f84b7f6100f3f6e3...

It's hard for me to believe (3) could be worth it. Do any cards give more than 2% in cashback?

That comes at a cost of lots of volunteer hours. I’m not sure if it would scale to NPM’s massive size.

GitHub uses an insane amount of caching. I bet that’s why some aren’t 500. But probably will be in a few minutes once it expires.