Yeah I've been running EndeavourOS on my 2015 Air (4 GB) and it is so incredibly snappy and efficient now. Makes macOS look like a lurching zombie of an OS.
It's like food: Virtually all food is "processed food" because all food requires some kind of process before you can eat it. Perhaps that process is "picking the fruit from the tree", or "peeling". But it's all processed in one way or another.
But that qualifier in stupid because there’s no start or stopping point for ultra processed versus all foods. Is cheese an ultra-processed food? Is wine?
There actually is a stopping point , and the definition of ultra processed food versus processed food is often drawn at the line where you can expect someone in their home kitchen to be able to do the processing. So, the question kind of goes whether or not you would expect someone to be able to make cheese or wine at home. I think there you would find it natural to conclude that there's a difference between a Cheeto, which can only be created in a factory with a secret extrusion process, versus cottage cheese, which can be created inside of a cottage. And you would probably also note that there is a difference between American cheese which requires a process that results in a Nile Red upload, and cheddar cheese which still could be done at home, over the course of months like how people make soap at home. You can tell that wine can be made at home because people make it in jails. I have found that a lot of people on Hackernews have a tendency to flatten distinctions into a binary, and then attack the binary as if distinctions don't matter. This is another such example.
There actually is no agreed-upon definition of "ultra-processed foods", and it's much murkier than you make it out to be. Not to mention that "can't be made at home" and "is bad for you" are entirely orthogonal qualities.
This doesn't require anything fancy. I haven't used my sound engineering qualification in 14 years and I could do it by hand. You can visually scan through the recorded waveform and look for shapes that stand out. Simple audio processing techniques like using a noise gate to shut off the volume whenever the input level is below some configured threshold can make this even easier.
There are real limitations to this: You can't arbitrarily mix and match HTML and Markdown. As soon as you introduce an HTML block, you're locked out of Markdown syntax.
AsciiDoc lets you mix and match however you want. Or, put differently: AsciiDoc's superiority over Markdown extends even to being better at shelling out to HTML.
While that's true, I'd take Markdown + extensions to allow inline HTML or custom tags over AsciiDoc any day, even at the cost of losing some compatibility - converting that to plain Markdown is usually easy enough.
Not op, but markdown is much more likely to render well in different contexts, without post processing. My editor understands markdown, GitHub understands markdown, the link preview renderer in <random collaborative tool> understands markdown. It’s the lowest common denominator
That's true, and it's why we're all using it. But those different renderers all support different ill-defined interpretations of Markdown. You can forget about all of them accepting raw HTML.
It has sufficient differences to what is already accepted "everywhere" that I would have think about syntax more often than I'd like. That is enough. The minor inconveniences of Markdown incompatibilities are smaller than the inconveniece of AsciiDoc. It simply doesn't offer nearly enough potential advantages to be worth the hassle.
> migrating all the doc that's strewn all over random SaaSes that people dropped it
I would love to be able to share our internal "all the things that are wrong with our approach to documentation" wiki page. It's longer than you could possibly imagine, probably more than 15 years old at this point, and filled to the brim with sarcasm and despair. It's so fucking funny. The table of contents is several pages long.
Literally how art has always worked
reply