dnr

The argument (of the second post) is that their behavior will be correlated because they all have (more or less) the same incentives and cost structure.

systemd-resolved can do this, though I haven't played with it too much yet.

Here's a random post I just found: https://gist.github.com/brasey/fa2277a6d7242cdf4e4b7c720d42b...

(Ha, I did the thing where I read the comments before the post, and the post describes how to do this. So what's still missing?)

Would bitcoin be worth nearly as much as it now if Coinbase didn't exist?

Have you made any bad hires that way? I used to think that I could gauge someone's depth of understanding by asking pointed questions about past projects, but after doing that several times and following it up with a simple coding problem that they totally flailed around on, or having a colleague tell me that they failed a simple coding problem in their interview, I realized that some people are just very good at faking understanding at that level (talking about code but not actually coding). Especially if it's on their "own" project that they're familiar with and have practiced responses to.

Thanks for that! I tried logging in and navigating to the page, but kept getting errors at the "Privacy & Notifications" page (maybe because I'm on an old pre-paid plan?). That direct link worked fine, though. (Though who knows if it will actually take effect, or mysteriously lose my preferences.)

The Inkwell puzzles (https://squares.io/p/inkwell) are generally fairly easy (usually around NYT Tuesday level). If you need easier than that, you might have to search for puzzle archives. I remember the old yahoo/crosssynergy puzzles were quite easy.

Also, ask a friend to help! Two beginners can solve harder puzzles than either can individually, since you get the union of your trivia knowledge and also two brains thinking of different sorts of wordplay or cluing angles.

Solve crossword puzzles with your friends, collaboratively: https://squares.io/

(Also great for solving solo.)

I built it because I wanted it to exist, and it's been fun to build. There's a small group of regular users, and I use it regularly myself. There's no monetization, though I have some thoughts about how that could happen in the future.

Solo backpacking (i.e. in the backcountry, not campgrounds) is a very different experience than with friends. The first time I did a longer trip (6 days) solo, I was terrified for the first 24 hours, but then eased into it and ended up having a really good experience. It can be intense, though. Even after the fear passes, other strong emotions might come up. Overall I prefer going with friends but I'm glad I've done some long solo trips too.

This is not actually a problem in practice. I had this misconception too before I started using it, though. I'll explain for Nix, since I've used it, but I assume Guix works similarly:

Packages as defined in nixpkgs don't depend on specific versions of shared libraries. They depend on the library by name, just as they do in any other OS. So a single update in nixpkgs addresses all packages on the system "for free", including ones defined outside of nixpkgs, because they're almost certainly going to depend on nixpkgs for those libraries (I mean, they could duplicate the definitions, but why would they?).

Built packages depend on specific versions. So you just have to be sure to update all your built packages. How does that happen? Well, packages are installed because they're requested by name somewhere, either NixOS system packages, or from home-manager, or from a dev environment. Those names point to packages in nixpkgs. So when you update your nixpkgs version (using nix-channel or flake update or however you're doing it), and then rebuild NixOS or update home-manager, you get updated versions of everything.

If you're using a nix-based dev environment with pinned nixpkgs (with niv or a flake or whatever), you'll have to update that pin as well, for each project. I suppose you could claim that this makes it easy to use old dependencies. Perhaps, but the entire point of pinning the nixpkgs version is to make everything 100% reproducible, bugs and all, all the way down your dependency stack. So you have to make a deliberate choice between trade-offs there, which seems fair.

As far as static linking, nix is essentially static linking, except that you still get the benefits of shared disk space and shared memory for .so files. "True" static linking might be simpler if your dependencies happen to be .so files that also have .a files, but many things aren't, e.g. dependencies among python modules, depending on other binaries to exec, data files, etc. Nix lets you "statically link" all of those too.

I use Deluminate: http://deluminate.github.io/

Is Dark Reader better? Why?

The most promising thing in this area, IMO, is NixOS and surrounding tools like NixOps. They're strange and hard to learn, and you have to do almost everything differently from what you learned, but it is really true declarative configuration of a machine from the ground up, not quasi-declarative where there's always state that gets left out and you can never really trust the diffing/idempotency mechanisms because they're layered on top of things that weren't meant to be used that way.

(If you dig into the details, you will find some "atrocious hacks" as the sibling comment puts it, but because of how it works, the hacks are almost completely encapsulated at build time and those builds are reproducible, so there's much less to worry about when you're deploying/provisioning.)

> When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI.

I used "hub" back in 2013, so it's at least that old. It wasn't official, though I'm not sure why that makes any difference. Searching on google for "gitlab cli clients" shows a bunch, at least some of which have histories dating back to 2013.

> You can mark emails with labels though depending on your Email client. The onus is on you.

But those are local to you and your client. I'm talking about labels that are shared state, that the whole project and the public can see. Those are widely used on github for categorization, triage, communicating the stage of the review, etc. They're undeniably useful to teams. You can put all that information in English text in email bodies, but then everyone has to read a whole thread to understand the state of things, and there's more potential for confusion.

> You can assign a review to someone. You literally just CC them on the email.

Same thing: how do I assign a reviewer so that everyone can quickly and unambiguously see who is assigned to review that PR/patch set? With PR metadata, this is trivial. With mailing lists, it depends on social conventions.

> If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it.

Thank you for insulting my intelligence. I didn't say it's hard, I said that it adds friction.

I'm not claiming that the web-based PR and review UI works for everyone; obvious email works fantastically well for Linux (though I'm not convinced something else couldn't work even better). I do think it works very well for small to medium size projects (which are most projects, after all).

An accurate comparison of the strengths and weaknesses of each model would need to be much more thorough and look at the entire development cycle, for projects of different sizes. I don't agree that that video was anything like that. It seemed like a cheap shot, based on one cherry-picked metric (time to submit an initial patch starting from nothing) that's not particular representative.

Wow, that video feels pretty disingenuous.

- The whole premise assumes that you need to make a new account for each project you contribute to, because they're hosted on individual gitea or similar instances. Some are, but let's be honest, the vast majority of projects are currently hosted on a very small set of services (github, gitlab, one or two others), and most developers will already have accounts on them.

(I get that part of the goal is to eliminate dependency on large code hosting services, and I agree with that. But we should do that with federation standards so people can use individual gitea/whatever instances without making accounts on all of them, not by traveling back in time 20 years.)

- He spends a lot of time complaining about silly password requirements. The complaint is valid but not relevant to the comparison.

- The graylisting thing is an own-goal, sorry.

- He complains that forking the repo and creating the PR require context-switching from the cli to the web and back, but there are cli tools that can fork repos and create PRs for you on github, gitlab, etc. to fix that.

- Let's allow that submitting a single patch, starting from outside the project, is faster for the contributor with an email workflow. But that's a tiny part of the process. There's a lot of things that happen after that patch: the project maintainers have to triage it, they have to review it, make comments on specific lines of the diff, or sometimes on line that aren't part of the diff, and then indicate that the submitter should make changes and try again. The submitter then has to make changes and submit it again. The reviewers, at that point, will probably want to see the diff between the first and second revision.

Triage: The github/gitlab UI for this is not great but acceptable. Viewing a mailing list in my email client mixes discussion and patches. I can't mark threads with labels or priorities. I can't assign a particular review to a particular person and have it show up in their todo list.

Review: Sure, you can reply to a patch posted on a list and intersperse comments, but web uis for code review are pretty decent these days. You can easily see much more of the context when required, your comments and replies on specific lines get threaded even across revisions of the code, each comment thread can have an individual "done" indicator, etc. The review as a whole has a global status of whose turn it is to take an action next. All of these seem much harder by email; you end up just using a lot of conventions.

You can use a web-based review tool with email-based patches, of course, but... why bother? If you're doing web-based review, just do the whole workflow there and it'll be a lot simpler and easier to understand.

Resubmit: Resubmitting a patch set by email posts brand new diffs. How do I see the differences between different versions of the patch? Sure, I can rig up a bunch of scripts to do this, but is it integrated with the review tool, etc.?

- What happens when I become a maintainer? I have to sign up for a new mailing list. And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows.

That's fair. I recall reading the developers' rationale for their decision to do multiple documents and sharing at the document level. They argued that it simplified the mental model, and I'd tend to agree: when I use shared docs I want to be careful with what's private and what's shared, and the UI (the document list on the left) make it easy to do that. Almost every time I've shared something, it's been intended for sharing from the start, so creating a new document is natural. (And the one time that wasn't true, cut and paste into a new doc was just a few clicks.)

One problem with Workflowy for me was that the mobile app(s) were not very good. Dynalist's isn't great either but it's better.

Anyway, the products are more similar than they are different.

Sorry if this is inappropriate, but for people looking for a tool like this or Workflowy, I want to suggest Dynalist, which has the simplicity of Workflowy but also a bunch more features. Cloud-based, always synced, mobile apps, easy sharing, calendar integration, etc. I'm a die-hard vim user but I still use Dynalist because it's so great.

https://dynalist.io

I'm a paying user but have no other affiliation (ask me if you want a referral code though). I just want more people to use it so the creators are successful and keep improving it.

As other people have pointed out, almost none of this comment is accurate:

Google put some effort, not that much, into Unladen Swallow, and the people who worked on it admitted that it didn't achieve the goals they set. The Python community was well on their way to creating Python 3 before work started on Unladen Swallow (so it was not in any way "Python's response"). As other comments pointed out, Google did not hire Rob Pike to "do" Go. Go was initially a side project of a few people and had nothing whatsoever to do with Python. The Go team was surprised when Python users started migrating to it. Google never used Python for web development, with one major exception, Youtube, an acquisition. I also don't understand how Google has "moved on" from Python (this seems unlikely) and how what they use Python for internally has anything at all to do with the fate of Django and Python webdev.

I don't mean to pile on, but I kinda have to ask, what were you thinking when you wrote this comment? Do you believe all those statements, or were you taking huge liberties with facts and making guesses to tell a story that supports a statement you wanted to make? You seem like a valued member of the community and this kinda makes me distrust the accuracy of everything else you write. (And to be honest, makes me distrust more of what I read in general, which is probably good but sad.)

A couple references for history/dates:

https://en.wikipedia.org/wiki/CPython#Unladen_Swallow https://www.python.org/dev/peps/pep-3000/

I started using mkcert for this. It's trivially easy to use and fixes all the weird quirks of http vs https:

https://blog.filippo.io/mkcert-valid-https-certificates-for-...

https://github.com/FiloSottile/mkcert

Does anyone make a fanless case for it yet? I have a 7th gen NUC in a fanless case from Akasa and I love the complete silence. (Performance is as you'd expect. I'd hope a Ryzen 7 would be a step up.)

This looks pretty thorough and is a better stab at quantifying things than I've seen before. Thank you!

I use this probably a hundred times a day :( It makes me so sad.

I've considered writing an extension to kill them all by default, but I'm afraid I'll break some site in a way that really confuses me and end up wasting more time figuring out what happened than I save with the extension.

I concur with the other comments that Fastmail is actually better than Gmail these days: the web UI is much faster and nicer, the Android app is not perfect but pretty decent, filtering and customization options are better.

My only potential concerns are: spam (I still get most email to my gmail address and imported by fastmail, which filter out spam on the gmail side, so I don't have a good sense of their own spam filter), and overall security (their own production security as well as resistance to account takeovers, etc.)

An entire day! I wish it were that easy. My password manager says I have 331 accounts using my gmail address. I figure it'll take me a year to move everything if I spend a couple hours a week. I categorized them into tiers based on importance and still ended up with 63 in the top "important or regularly use" tier and 59 in the next "will probably use again" tier. The lower tiers, I'll probably not even bother with.

I think the idea is that we're in a local maximum for "how good is the current arrangement for society as a whole". Any small change to the arrangement is going to make things worse for one party or another, and probably even make things worse for society as a whole. But there's a chance that a bigger change could get us to an even higher maximum, where everyone is better off, both individually and on net.

It's hard because you can't just jump there, there will be some people or entities that are worse off during the transition. Also there are unintended consequences so things might not go as you expect.

Usually to (attempt to) make changes like this, it has to be a government doing it, because it's a coordination problem and you have to force people to look past their short-term self-interest for a little while.

Huh? I use MicroPython on ESP8266's that I'm sure are way under $5 in bulk these days. Including I2C support and various other stuff, without writing any C. I am a hobbyist but I don't see any reason why the same thing wouldn't work in a commercial product.

I'm somewhat happy with my Pixel 3a, but the aspect ratio is pretty annoying: it's too tall and too narrow, making it really hard to use one-handed (my thumb can't reach that high while I'm gripping it in my palm). It looks like the 4a is similar. I wish they'd go back to the Pixel 1 dimensions, which were pretty perfect.

It's a big jump to go from "this protocol is more complicated than the previous one" to "cut out future generations from system programming". It's not _that much_ more complicated that a competent programmer who's familiar with sockets and bytes can't ever accomplish it.

As discussed at length in another sub-thread here, the complexity solves real problems, it's not for its own sake. But if you're not convinced of that, nothing I say here is going to change that.

·

If you've worked with me, you'd know that I take simplicity as a virtue to an extent that's almost detrimental to getting stuff done. I despise complexity for its own sake. I wish as much as anyone that we could start over and redesign IP, TCP, TLS, HTTP, HTML, JS, and a few more things, with all our accumulated knowledge, into a simple and clean application and content distribution system that's easy to understand and observe. But path dependence :( We have to work with what we've got.

It's the picking out of HTTP 1.1 as some sort of golden age of clean and simple and observable that bothers me. It isn't.

I agree it's incredibly important to dig into layers under (and over) the one you're working at! I'm very grateful for the experience of building a simple unix-like kernel and a simplified TCP & IP implementation as school projects. And I'd encourage anyone to do the same with HTTP 1 or 2 or 3. The difference is that no one thinks that their educational/toy TCP implementation is suitable for production use, while people do seem to (mistakenly) think that about HTTP.

What would you say is the "resident innovative force in computing" now?

I'm a little confused by the reference to healthcare.gov: if Big Web is not the right paradigm to handle a... big web site, then what is?

The misconception is the idea that anyone can easily implement a compliant HTTP 1.1 server, or even client. The protocol may appear simple on paper but parsing it correctly and securely is quite tricky. IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries and remove the illusion that interacting with HTTP bytes on the wire is a reasonable thing to do.

I've been happily using my Panasonic G3 for years for hiking/backpacking/skiing. The key features for me are the small weight and size of the body and lenses, and the electronic viewfinder. I've been thinking about upgrading the body recently, but all the newer G series are much bigger and heavier, and the GF and GX series don't have a viewfinder. What's the best choice for me in the M43 world? (Or which system should I look at instead?)