BoingBoomTschak

You work to live, you don't live to work.

As someone who did enough of both (in fact, Tcl was my gateway to Lisp), I'd say yes and no.

Classical Lisp (Scheme/CL) has much more elegant core concepts/semantics, but often much more clunky stdlibs and small/outdated batteries. This shows in unexpected places like the way homoiconicity has a big caveat: comments break the "code as tree" contract, forcing you to revert back to the useless "code as string" middle ages.

I know that because I had a need to hack together an horrible replacement for the thing I miss the most from Lisp: quasiquoting (https://git.sr.ht/~q3cpma/tcl-misc/tree/e4ba1bb4fcca729337b9...).

------

So, despite the fact that I'd probably recommend Janet to people who want Tcl without Tk, these days, I still like it. Do note that compared to its competitors (Ruby, Python, Perl), its POSIX support is _really_ bad. There's no way in core to do signal handling or open a UNIX socket (and dead TclX that doesn't use namespaces isn't a replacement). Even SBCL has sb-posix.

Didn't expect Wayland support that soon!

> too many smart people are failing.

Sooner or later, people will have to realize an uncomfortable truth: intelligence, while important, is overrated compared to willpower.

From the creators of Go: https://9p.io/magic/man2html/2/thread

cf https://news.ycombinator.com/item?id=48894637#48895160

And you're okay using very flexible newspeak like "xenophobia" as a rhetorical bludgeon to shut anyone who doesn't want a slow genocide?

Cool stuff.

What about the enterprise version (https://lain.wiki/images/5/53/CoplandOS.png), though? :^)

Such a classic societal fail most people can't seem to recognize. The point isn't to read, it's to read because you want to, not because of a stick/carrot.

RMS makes the same mistake in thinking that disallowing proprietary software in repos is better than giving the tools to avoid it and education about what is compromised in the process.

  A man may be a heretic in the truth; and if he believes things only because his pastor says so, or the assembly so determines, without knowing other reason, though his belief be true, yet the very truth he holds becomes his heresy
  ― John Milton, Areopagitica

Good job and clean website interface! Something as exhaustive as this is clearly needed.

Some remarks:

1. Why does the CoW button remove XFS from the list? Even https://github.com/fenio/modern-fs-benchmark/blob/main/scrip... mentions it has reflink enabled

2. If you have the time, adding XFS + mdraid + dm-integrity [1] (in bitmap mode) as a comparison point against ZFS RAID-Zx might be an interesting data point. That's what I run, personally.

3. Did you give some thoughts to the I/O scheduler choice? Might matter a lot in some cases.

[1] https://www.kernel.org/doc/html/latest/admin-guide/device-ma...

Wall-E future here we come. Soon the people loader that lifts you from your sofa and plops you into the seat!

I don't know how to say nicely that you don't realize how ignorant about the field you must seem to anyone who isn't. You'll have trouble finding such comparison for the same reason you won't find a "caterpillar vs motorbike" speed test easily. Everyone in the target market including Apple knows hardware encoding will never be about output quality.

Anyway, here, I'm feeling nice. Some guy comparing the M1 Pro's HEVC encoder vs x265 (amongst others): https://colinmckellar.com/2024/01/11/video-encoder-compariso...

Here's the only graph you need to look at if you don't want to bother (encoding time vs file size at fixed perceptual quality, log scale axes): https://colinmckellar.com/wp-content/uploads/2024/01/VMAF_90...

> Nothing prevents a vendor from implementing a high quality hardware encoder

Uh yes, it's called reality. Advanced video coding techniques are just too complex, full of serial and branch heavy algos to work in decently sized and priced ASIC or even in GPGPU. Which is the reason none exists outside of very expensive special stuff for professional render/streaming farms.

Not even mentioning that few coding tools are shared between codecs, so while you only need 1 CPU to handle all of them, you'd need almost an ASIC per codec...

HW and SW encoding are not comparable with regard to quality (for the same size, obviously) though. That's kinda what I meant with my quip.

I think software with a strong focus on SIMD really favours x86 over Apple, since AVX2 support was pretty uniform and AVX-512 (except Intel's fiasco) has been supported for a while, while the post-NEON landscape is strange in ARM country.

From what I've been able to gather, Apple only supports SME and the small "streaming" part of SVE2 required by SME since the M4. Which seems to be mostly useless for video encoding (I only see NEON/SVE in https://gitlab.com/AOMediaCodec/SVT-AV1/-/tree/master/Source... or https://github.com/Multicorewareinc/x265/tree/master/source/...) it's basically a GEMM engine.

So basically, video encoding is a bad show for Apple who seem to be saying "use crappy hardware encoding and buy amd64 if you need more".

Very hard to find benchmark data. Found https://openbenchmarking.org/vs/Processor/Apple+M4+Pro,AMD+R... that shows a good x265 performance at 1080p but not 4K. Guess the wider SIMD units matter more there.

1. I didn't manage to find a non trivial (i.e. Hello World) example anywhere on the website. That should be one of the first things greeting my eyes, especially since the colloquial Lisp family is so large you can't easily infer the syntax.

2. A Lisp without Emacs support other than syntax highlighting?

Or funnier version: "don't worry, we're not Alpha".

If you want one I continue to really trust almost blindly: Genelec (Finnish pro audio). Not even that expensive for what it is.

No control for prosperity. Lifelong comfort insidiously cripples any people on all these levels.

For a fun novel on the very subject, read The Dosadi Experiment.

The day I can furnish my NAS in SSDs for roughly the same price as HDDs probably won't come before any current filesystem is obsoleted for some reason or another, methinks.

What a wonderful surprise! The nearest thing seem to be modern (v5) XFS + dm-integrity, I'll have to see a comparison once it's stable enough.

A thing ZFS suffers from is fragmentation (no way to defragment in-place nor preallocate so stuff like bittorrent doesn't play well with it), which it justifies with its CoW design, wonder if/how it mitigates the problem.

I think he means that if the OS knows about locking, it can manage a list of "waiters" to quickly know which thread to wake (resp. let sleep) once (resp. before) the lock is released.

A bit like what classic UNIX does with wchan, but between the kernel and userspace this time. Related: https://rdmsr.github.io/writing/turnstiles/

I think Linus says it well: https://www.realworldtech.com/forum/?threadid=189711&curpost...

Is Marginalia the only real competing search engine?

Finally, the Butlerian Jihad is entering the Overton window.

One thing I've desperately wanted from git worktrees is to use reflinking in some way to lower the cost of copies.

I just found https://github.com/josharian/git-cow-worktree that doesn't inspire confidence.

There's "just like" and "just like". Understanding what allows you to stand out and making sure you don't throw it away is important, but so is avoiding stagnation. After all, creation is the essence of art.

Even if the succeeding effort is just adding polish and streamlining your previous sound, it's something different in my books.

In any case, in all the music discussion I've been, "artist that keeps making the same album" has always been a strong criticism very much like "one trick pony".

Would you say the same about more obviously artistic mediums? "Oh, their second album sounds exactly like their first which I liked!" isn't a compliment, usually.

The article sensibly asks if the (intentionally or not) cherry-picked stats about automated driving (fair weather only, limited to specific areas that aren't especially difficult) is valid then cites a study that really massages those stats in a dubious way (e.g. only counts as a crash if the airbag triggered, no mention of weather). Hmmm...

Another thing I'd really like to know: let's suppose that these are indeed safer than the average driver. Is it also the case for the median driver?

Yeah, it's just "new technology". Like those Flock cameras, I guess.

> I have NEVER seen a single person accuse anyone of being a bad person for still preferring to drive a car manually

Just read further in this thread, will you?