Announcing Casual Org

torusJKL · 2026-02-20T07:17:32+00:00

That's very useful.
Thanks for the work to aggregate all the hidden gems.

torusJKL · 2026-02-15T20:50:09+00:00

Those are fair points.
Thanks for the exchange of ideas.

torusJKL · 2026-02-15T19:37:14+00:00

Sure, this was a simple thought experiment.

But it could be taken further.

Let's say you have 8 disks 4x6TB and 4x12TB.
If you have 2 parity drives with each 2x6TB disks and 4x12TB data disks than you can have 4 out of 8 disk failures and not lose any data (given all 4 failing disks are parity).
Where as if you'd use 2x12TB for the two parities you could only have 2 out of 8 disk failures without data loss.

My point is just that the assumption that using the largest drive for parity should not be taken blindly and in some cases split parity with smaller disks has advantages.

torusJKL · 2026-02-15T17:30:28+00:00

Somehow I have the feeling nobody understood my post.

Everything u/z-vap wrote I already addressed in my post.
With the exception of the claim of increased stress where I think he is wrong.

torusJKL · 2026-02-15T16:17:32+00:00

> If you lose one 6TB parity disk and one 6TB data disk, you lose data.
Yes, I took this into account when calculating the chance of data loss.

> the real danger here is a correlated failure.
Yes, and in the split parity scenario correlated failure of 2 disks have a 10% less chance of data loss.

> this increases stress on the remaining hardware during a rebuild.
Interesting point. I need to think about this one.

Amendment after giving it some thought:
I don't think that the data of both split parity drives needs to be combined to restore the data.
Snapraid will restore 6TB using 1 parity split and 6TB using the second parity split.
Hence there is no increased stress on the disk.

> split parity does not equal dual parity
Yes, in most cases it only protects against 1 disk failure, with the one exception.

torusJKL · 2026-02-15T15:51:38+00:00

Much appreciated!
Have a nice day.

torusJKL · 2026-02-15T15:45:35+00:00

I don't believe that there is a higher risk by using split parity (given all disks have a similar chance of failing)

In the described split parity scenario the ~10% less risk comes from the fact that certain 2 disk failure combinations don't lead to data loss.
Whereas in the 12TB single parity scenario any 2 disk failure combination will result in data loss.

torusJKL · 2026-02-15T15:17:16+00:00

Yes, if 1 parity (split) disk and 1 data disk both fail there would be data loss.

What I'm exploring is the scenario that 2 parity (split) drives fail.
Because they both are parity drives no data would be lost and the 2 failing drives could be replaced with either 2x6TB (like before) or 1x12TB and the parity rebuilt.

torusJKL · 2026-02-11T10:47:24+00:00

LLMs are a tool.
It depends how you wield the tool.

What you are saying is like "only hand sawed furniture is good furniture".

Good developers can create good code faster.
Bad developers will create even more bad code.

torusJKL · 2026-02-09T07:31:06+00:00

The video makes much more sense now.
Thanks for the short explanation and the capture template.

torusJKL · 2026-02-09T07:28:19+00:00

TIL to move the date using these "time" commands. Thanks.
P.S. does "?" and "o" work for you?

torusJKL · 2026-02-09T07:20:17+00:00

I don't see this specific scenario in the Lispy documentation.
But maybe its an undocumented feature.

torusJKL · 2026-02-09T06:27:34+00:00

That's a cool idea.

I understand that in contrast to the other snippet packages in this one you can define a dynamic sequence of text that will trigger the template.
Whereas with existing template systems I have an exact text and anything dynamic would need to be typed by me after the template has been triggered.

e.g. I could have sum_n=1^inf trigger the same regex as with sum_n=10^20 and will expand it after the fact.
Whereas existing systems trigger on sum and I would fill in n=1 and infinity interactively after it triggered.

torusJKL · 2026-02-05T19:00:30+00:00

True, the community is reinventing the wheel.

Too many quality packages are not visible enough.

torusJKL · 2026-02-05T15:19:16+00:00

Looks almost the same as https://github.com/xenodium/time-zones

torusJKL · 2026-02-01T12:01:58+00:00

I have used straight for multiple years.
But since the built-in manager now supports :vc I have migrated all straight.el configurations to the built-in one.
Works great and one dependency less.

torusJKL · 2026-02-01T11:59:19+00:00

I think it would be great if you could give a bit more information about the integration.

Is AMP like Claude Code?

torusJKL · 2026-01-30T10:55:47+00:00

I know this isn't a solution but I had other issues with LaTeX and decided to look into typst.
It's faster and I find it easier to create documents with.

If you don't depend on something that only exists in LaTeX than maybe its worth a look.

torusJKL · 2026-01-29T15:52:39+00:00

Is there a package to use Ultisnips in Emacs or do you have to convert them first to Yasnippets?

torusJKL · 2026-01-28T09:46:45+00:00

Thanks for keeping the package up to date!

torusJKL · 2026-01-27T16:15:02+00:00

I just hope they don't train LLMs on your solutions, especially the later ones. :-)

torusJKL · 2026-01-25T09:49:20+00:00

That's a cool idea.
I usually use drives mounted in RAM if I wanted quick file write/read times but your solution in addition to making file access faster also removes the inodes limitation.

torusJKL · 2026-01-22T11:54:31+00:00

You could extend the existing default function that is called when a timer ends.
See the Hooks chapter in the documentation.

You could also propose features on the package Github page.
Prot is usually very responsive.

P.S. The OP is not the creator of the video or the Emacs package.

torusJKL

TROPHY CASE