alwaysbeconsing

The most reasonable conculsion (though tentative) seems to be that SSRI and the more "traditional" option may help some, while psychedelics may help others. (And we have to imagine other drugs in the future will be found.) The trick will to figure out which person will respond to which. But I think all can agree having more options is better.

To borrow from Samuel Johnson, it's worth having read, but not worth reading.

To counterbalance your anecdote this is not among my friends and family. We swap books regularly and enjoy the recommendations. Of the prior 10 books I read all came from friend recommendation, and I enjoyed each one.

Very cool, very ambitious! I will keep my eye on this; good luck!

I was thinking could use abbrevs but it must expand word chars, not spaces.

Why are you using `string=` to compare symbols?

Surely it would be better to use a purpose-built "long space" character, as would be done in typesetting. Em Space U+2003 might be a good candidate.

Looks like the hardcover and the ebook updated but not the paperback edition.

I can offer that I am constantly online and using Kagi across my devices for all searches and so far have not come close to using up my quota.

Personally privacy is a strong concern for me; I have many aspects of my digital life set up less conveniently in exchange for privacy.

In this case though we've have on one hand a product that definitely does aggregate data about searches, and doesn't do what I need very well; and the other a product that could, but does not currently aggregate data, and does an excellent job serving my needs.

And importantly there is no option of a product, available now, that is verifiably prevented from aggregation. Even a VPN unless I disconnect and get a new random IP between every individual search does not provide that protection. (And then browser fingerprints even.)

Yes, the desktop app and in-browser are the same if the workspace has been moved to the new design.

As a technical person the thing I hope for most is that my direct manager does not try to get involved in technical topics. They need to understand the nature of the labor of course, but they do not need to be thinking about which DB we use or trying to interpret log messages. They are my interface to other managers and other parts of the business. I can and will talk to the other technical people myself.

> Version 4 is completely randomly generated (hence, it has more entropy) and is what most web systems seem to use. It has 16^32 = 2^128 bits that guarantee uniqueness and has an insignificant risk of collision.

Small correction here but it is not 128 random bits entirely: 6 bits are reserved for the version marker.

A alternative that is builtin might be an skeletons (and abbrev) or tempo? Also see the newer implementation, tempel: https://github.com/minad/tempel

> the reasoning was like "we do not want to force an external dependency"

It was not the optimal solution, agreed. The reason was actually that a significant technical complexity was found while trying to adapt the existing modes. The syntax table vs. tree-sitter parse tree was simply too divergent for a mode to be just switched from one to the other. So the decision which I don't think anybody was completely happy with, but considered the only feasible way to move forward, to have new modes with tree-sitter.

You can see some discussion here: https://old.reddit.com/r/emacs/comments/15g9cna/why_is_emacs... and quick link to the mailing list thread: https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg01...

On Apple OS also two alternative browsers rising: Arc https://arc.net and Orion https://browser.kagi.com Both making nice progress with their own strong points.

It's a nice release. Headliners aside, a lot of little improvements that make a big difference. `mouse-drag-and-drop-region-cross-program` and `dnd-indicate-insertion-point` might be my favorites that category. Making dragging text into GUI Emacs work as it does for other programs.

> Without more details about what this means and how it's done

The article seems to be based on a review of the privacy policies rather than sniffing actual collected data. We can conclude the policy leaves openings for them to do it, but it may not in fact be done at this time.

I think they mean that the used car market gave them a good sale price on their 2021.

There's no inherent reason it must be a profit-making business. Organizeing as a cooperative, mutual insurance is also an option. Granted that any version still must set rates that cover expected payouts.

They seem to be specifically referring to the compiler error (as in, prevents compilation) for unused local variables. See discussion here: https://github.com/ziglang/zig/issues/335#issuecomment-10011...

The part that's often missed is the future outcome, when someone returns to this code to fix a bug or add a new feature. I believe it's incumbent upon those of us with some experience to ensure maintainability is part of the considerations.

I do agree that "social media is uniformly bad" is too broad a stroke. That said, humans aren't exactly the best at discriminating something that feels good from being unhealthy or at least unproductive.

Kagi does not have regex but it does have some basic booleans, wildcard, and most important, exact word searching that actually has an effect: https://help.kagi.com/kagi/features/search-operators.html#se...

(Not affiliated with them except as a very happy customer.)

I agree that consistency across the codebase is important for its long-term health. There's a few things I can think of that will help you make this kind of PR comment successfully. First is that they should never block the PR from being merged, (although see second point).

Second is that they should be deployed judiciously: if you're making dozens of them on one PR then something is wrong either with the PR or with you. If it's you, then figure out which 2-5 or so (depending on the changeset size) are most important to you and let the other ones go. If it's the PR, then pulling the author aside and working with them to understand the codebase style, and helping them push a revised changset, is a better route than carpet-bombing their PR. (And you'll probably want to follow up that pairing beforehand for the next couple of PRs they do.)

Third is how to express them: the examples in the article are pretty good in this regard. Remember that these are optional improvements, and some of them can be subjective even if they're backed by common practice in the codebase. Be friendly rather than curt with your colleagues. And give some justification for your suggestion. If you can't come up with a good justification, it might be a sign that the comment isn't worth making.

On the receiving side, also try to take the comments in a friendly spirit. It's easy and natural to react negatively to any kind of comment on something you've worked on. But let that pass and don't make it part of your outward response. And most of all try to remember the suggestions reviewers make, so that they're not forever saying the same thing on your PRs. And if that does arise for some reason, it's again cause for a side conversation.

Has anyone explored using a technique like a Bloom filter or partial hash matching (like haveibeenpwned does) as a preliminary step for CRL lookups? You could do a cheap initial query, and if you get a negative, you're good. You only have to do the full expensive one if you get a positive, to ensure that it's a true positive. Which should be rare since most certs that are presented won't be revoked.

I generally appreciate TechDirt but this is a very weak argument, the logic is inverted. That some people who are opposed to LLMs were wrong to attack a tool that has nothing to do with LLMs does not allow us to conclude they are wrong about LLMs.

Right, but again, you can do exactly that with breakpoints (especially if they can print and then auto-continue), and you can change your output, adding or disabling them while still running.

Interesting. This probably varies by tech stack, but in my experience debugging concurrent/async stuff is where I will actually lean away from the debugger for fear of that kind of timing skew.

I find this take odd. To me, debugging with breakpoints is just a more powerful and flexible version of thinking about where to put printfs. You still have to think carefully about where to put the breakpoints, too.

If I sprinkle a couple of prints and my hypothesis about what state I need to see is wrong, then I have to do another build and run cycle to get more information. If I'm stopped at a breakpoint I can dynamically and interactively root around without having to go through the whole scenario again.

Maybe this is just a different mode of using the debugger than what's being argued against. I will say that stepping through is really only fruitful in my experience when there's an extremely narrow region of code that I've identified as causing the problem.