procrastitron

11 日前議論

Passing the senate back then was because of shenanigans; not popularity.

They played tricks with the “unanimous consent” procedure where senators didn’t know it was happening until after it was too late to object. Multiple senators said afterwards that they were opposed to it.

procrastitron

8 か月前議論

This was exactly what I thought of as well.

Garfield’s version seems more complicated since you have to calculate the area of a trapezoid instead of the area of a square, but conceptually they are the same.

procrastitron

2 年前議論

> code.google going away, without the excuse that google itself was going away, after I had started to rely on it and link to it in docs and scripts all over the place

It didn't go away, though. It got archived and that archive is still up and running today. Those links you put all over the place should still be working.

> If google had said "The purpose of this service is an academic goal of Googles, not to serve users needs. This service will be shut off as soon as Googles academic purpose is met." I would not have used it.

That's not an accurate representation of what DannyBee said. Moreover, what DannyBee did say is in line with what Google itself said was its goal when the service launched: https://support.google.com/code/answer/56511

"One of our goals is to encourage healthy, productive open source communities. Developers can always benefit from more choices in project hosting."

> Effectively, Google harnessed users for it's own purposes without their consent by means of deception.

This does not appear to be a good faith argument.

None of what DannyBee said in their comment aligns with that interpretation. Neither does that interpretation line up with Google's publicly stated goals when they launched Google Code.

procrastitron

2 年前議論

That’s already been a thing for several decades: https://www.uscis.gov/military/naturalization-through-milita...

procrastitron

3 年前議論

Any argument of the form “if you knew that all along you’d be rich by now from playing the stock market” is fundamentally flawed because it overlooks one of the most well known dangers of the stock market:

    “The market can stay irrational longer than you can stay solvent”

It absolutely was obvious ahead of time that most of the competing streaming services would fail because they couldn’t possibly recreate the infrastructure of Netflix, but it was not possible to predict when they would fail.

For a concrete example, before Paramount+ launched I predicted that it would be dead in less than a year.

Clearly I was wrong because it’s still going 2 years later. I still think it will die relatively soon, but predicting exactly when is virtually impossible.

procrastitron

3 年前議論

No it doesn’t.

They would have to earn $10 million dollars or more in annual revenue to be affected.

procrastitron

3 年前議論

https://explore.zoom.us/en/terms/

I misremembered; it’s 16, not 15

procrastitron

3 年前議論

The Zoom arbitration agreement includes a specific clause for that which lets them combine separate claims together and only arbitrate 15 of them.

From a consumer perspective it really is a no-win situation. The agreements are specifically designed to make the process as one sided as possible.

procrastitron

3 年前議論

Rebases are supported; you have to do the rebases through git-appraise in order for it to know that the original and rewritten commits are related.

procrastitron

3 年前議論

This one does. You can comment on any line in any file.

procrastitron

3 年前議論

Perhaps this wasn’t clear enough, but I was making an explicit distinction between dependency injection and dependency injection frameworks.

Dependency injection makes code easier to test, and I’m a big fan of dependency injection.

What I’m opposed to is the frameworks that automate (and often hide) the construction of the dependencies.

As someone else said in this thread “explicit is better than implicit”.

procrastitron

3 年前議論

Dependency injection frameworks are a horrible idea.

They optimize for the wrong thing; making code easier to write but harder to read and edit.

Writing code is a one time cost whereas reading and editing it is an ongoing effort, so dependency injection frameworks are optimizing for the uncommon case at the expense of the common case.

Compile-time dependency injection frameworks are a big improvement over runtime dependency injection frameworks because you can at least read the generated code, but they are still a lot worse than manual dependency injection when it comes to editing code.

procrastitron

3 年前議論

How does this compare to age: https://github.com/FiloSottile/age ?

procrastitron

4 年前議論

“Is there a way to do what you're suggesting with identities”

There are certainly solutions, but I don’t know what the best solution is, hence why I called it an open problem.

An example solution would be something like having your identity be a hash of your initial public keyset, making each key have a set expiration date, adding new keys by signing them with one of the existing keys, and then storing all of the rotation operations in a transparency log.

“the only way to solve this without centralized providers is with blockchains”

That’s not true; you probably want a transparency log, but that doesn’t require blockchains.

procrastitron

4 年前議論

“All of the core decisions here are solid (pub key identities…”

I agree, except for the bit about public keys as identities.

I think public key identities are a step in the right direction, but there’s still a gap between that and what the ultimate solution is going to wind up being.

We need to have some layer of indirection between user identities and public keys so that users can do things like rotate keys, have multiple keys, and recover their identities.

I don’t know what the right solution to that is; I think it’s an open problem and probably one of the most important ones to solve. Keybase probably came closest to a good solution, but it wasn’t decentralized.

procrastitron

4 年前議論

You can do that with git-appraise: https://github.com/google/git-appraise

procrastitron

4 年前議論

Indeed, ~1000 worldwide had any sort of hepatitis at all, whereas over 400 have died from Covid in the U.S. alone.

Even if their theory is right about isolation being the cause of the hepatitis cases, then it was still the right thing to do in terms of risk vs. reward.

procrastitron

4 年前議論

Overall that looks really nice, so thanks for sharing.

A bit of unsolicited feedback; listing the seat post options based on rider height (regular for shorter than 6’3”, and extra long for taller than 6’3”) is wrong.

Seat post height is based on how long your legs are, not how tall you are. If anything, you should list that by inseam.

As it is, I would have no idea which option is the most appropriate.

procrastitron

5 年前議論

Thanks for the pointer; I had never heard of sparkleshare before.

It sounds like it addresses roughly the same use case, but I couldn’t find any technical details about it in its docs in order to see how it compares.

procrastitron

5 年前議論

I built a similar tool a couple of years ago here: https://github.com/google/git-sync-changes

Both save uncommitted changes in a hidden ref.

Based on the README, the differences seem to be:

1. dura runs as a daemon while git-sync-changes is a one shot execution.

2. dura saves locally, while git-sync-changes syncs with a remote repo.

3. dura only does the save and the restore is manual, whereas git-sync-changes does both steps automatically.

I’m glad to see more people exploring this space. I think there’s a lot of untapped potential in tracking pending changes similarly to how we track committed changes.

procrastitron

投稿

Distributed Management of Git Forks

A tool to automatically generate navigable call graphs from Java bytecode

SAP significantly boosts service costs, angering customers

Plano, Texas ranked as best city for building personal wealth

1.3% of web pages altered in transit

A compiler from Higher Order Logic to hardware (with a detailed survey of the field)

コメント