I support anti-dox/and security practices by cleaning up repo history and rotating where you can, as long as your safe with the assumption that anyone with a copy of the history could push it back to central at any point.
But I really don't like the trend of some folks "need a clean history" and then disabled merge commits.
It's like they are saying "cool snap shot system you got there, id hate for it to be use to take a bunch of incremental snap shots with specific notes attached to each one. Why don't you let me bundle those all together real purdy like and no one has to know it took you 20 commits to fix that decade old bug."
I have literally never heard a reasonable claim that needing a "clean main branch" is more useful in a retro or bisect.
>"cool snap shot system you got there, id hate for it to be use to take a bunch of incremental snap shots with specific notes attached to each one. Why don't you let me bundle those all together real purdy like and no one has to know it took you 20 commits to fix that decade old bug."
It’s more like saying “in any writing process, revising is going to lead to better finished output.” It is absolutely true that no one needs to know that it took you 20 commits to fix that bug. It’s much easier to review 3 commits, one of which contains the refactoring done as part of the fix with the other two each containing changes that address distinct pieces of the bug. The structure of the change is clearer, and the structure of the attached notes will be clearer as well.
I don't think all writing process produces the same kinda of output, the editing of code itself is metadata I find more valuable and an artificially straight line.
It depended on the release. KDE 3.5.10 from Debian Sarge's backports was rock solid and more stable than several others. Ditto with SuSE, which had a golden stability. Red Hat was a disaster.
SuSE employed several KDE developers at the time while Red Hat employed many Gnome developers. In fact, Gnome was inofficially a Red Hat project back then.
We have a single harbor instance at work, backed by PG. The folks ran into some sort of performance issue during their testing (not documented) and their solution was to use cloud native pg, run two postgres, and add additional second layer of connection pooling.
We eventually hit a bug in a combination of certain images, docker desktop (not even supported by us), and permissions. The error looked related to the connections, so I suggested the pooler be bypassed as a test. They ignored the suggestion for two weeks until it was the last thing to test.
Sure enough bypassing the pooler helped stabilize the connection from harbor during image uploads.
Now I need to talk to them about properly vertical scaling PG before we try and run two with replication, in the same kube cluster, in the same physical data center.
I get why people blame indentation like this. I don't think it's right or wrong to ignore the tooling that directly addresses minor issues with indentation or matching braces honestly.
That said, my preference is to use the tools built into my editor and available on the CLI or web to assist and fix formatting and syntax. You get instant feedback on incorrect formatting, and I generally find that synthetic scope mistakes (regardless of method) are eliminated.
Appreciate the recommendation for the quantum thief. I really enjoyed accelerando which was a recommendation from a friend so I look forward to checking this one out. If it's good I'll share it with the same friend who taught me about accelerando.
Not the first time I've come across great recommendations in the comments of HN!
>WASHINGTON, May 12 (Reuters) - Artificial intelligence company Anthropic on Tuesday released an expanded suite of features for lawyers using its Claude AI assistant, including tools for specialized legal topics and access within Claude to other legal research and AI products.
If there were a particular subset of people that were the absolute least likely to ever revolt against anything it could be no one other than the lawyers. They've trained their entire careers to play by rules so esoteric that people like us need to hire them just to interact with those rules safely.
Big tech went from cool corporations to enemies of the people after they made journalists less relevant. The journalists fought back. I can definitely imagine the same happening with AI and lawyers, except that lawyers are far, far more powerful.
Not lawyers-- judges. Judges, in my experience, don't take kindly to anything or anyone infringing on their power.
Edit: I've met a ton of attorneys who are bullish on LLMs preparing work for them (kinda like robo-paralegals, albeit ones apt to spout bullshit). Judges, being human (and lazy by dint of evolution), would probably lean on LLM-based analysis too. I cannot imagine they'd ever stand by and let decisions be made by a non-judge.
In fact, I'll bet someone makes a bundle selling AI arbitration services that do just that. Got a beef with BigCo? What could be more fair than letting HAL settle the matter?
If I had the sense God gave a gerbil, I'd already have Claude writing up a patent application on this. (Edit, too late: https://www.adr.org/ai-arbitrator/ )
Laser projectors already include green lasers made by the same principle, but made from separate semiconductor lasers and non-linear crystals.
With this technology, which integrates the non-linear crystal with the semiconductor laser, it may become possible to make cheaper laser projectors, either by making an integrated green laser, or perhaps even an integrated triple laser, for all 3 primaries, but the difference in cost will not be great, because the green laser is a rather small fraction of the total cost (though it may be more expensive than the red and blue lasers together).
reply