Author of libgrapheme here: Both collation and normalisation are non-trivial and have many gotchas thanks to the way the Unicode consortium likes to write their specifications. I sometimes get the feeling that they don't even care about implementers and just document what is done in the reference implementation ICU.
The only sensible normalisation one can implement is the full decomposition (NFD), and maybe the full composition (NFC). You rely on the full decomposition if you want to collate correctly, which is a problem because the amount of memory needed to store the decomposition is unbounded in general. I don't want to make the libgrapheme users jump through hoops, and I also don't want to do any memory allocations in libgrapheme either.
There is an idea floating in my head on how to solve this, but I'm currently busy finalising Unicode 15.1 support (Unicode 16.0, released on the 10th, will be trivial to upgrade to) and releasing my already fully-compliant implementation of the Unicode bidirectional algorithm.
I see, thanks for replying. I agree, Unicode specs are hell to work with (I tried doing a auto-codegen thing based on them and just gave up due to the size of tables generated and the seemingly-arbitrary edge cases). libgrapheme looks pretty good otherwise, I'll keep an eye on it for whenever I have to wrangle with Unicode on a low level again (hopefully not for a long time).
Thanks for your work on packaging my library. Please let me know if I can make the process simpler for you; I take great care to make packaging as simple as possible for the packagers. Likewise I have no sympathy for those writing software that is almost deliberately hard to package.
Look at sndio if you want to see how sound should be done. Excusing the horrible mess pulseaudio is with the horrible state of Linux Audio doesn't cut it, when OpenBSD has been offering a superior and simpler alternative for years!
It doesn't reinvent the wheel and for anything more complex you can always use JACK, like if you really want to go low-latency.
> Excusing the horrible mess pulseaudio is with the horrible state of Linux Audio doesn't cut it,
The problem is that most people complaining about Pulseaudio don't offer realistic alternatives. Saying Pulseaudio sucks and that everyone should use ALSA is a joke. Pulseaudio does a plethora of things that ALSA does not handle. Not to mention that ALSA is a low-level system, and PA actually sits on top of ALSA.
In all of the vitriol that people spew about Pulseaudio, this is the first time that I've seen anyone point to sndio. I think that says something about the "pulseaudio complainers" crowd.
That said does sndio provide the following features:
- Support for bluetooth audio devices
- Support for streaming audio over a network.
- Support for user-land mixing of audio sources (i.e. don't need root).
- Mixing of multiple audio streams at the same time (e.g. Can your system play an alert sound without interrupting your music?)
I realize I'm replying to a 2 weeks old comment, so nobody will read this ever, but from your list sndio supports: streaming audio over a network, user-land mixing of audio sources, mixing of multiple audio streams at the same time,
and per application volume settings.
> Per application input/output source settings
No, but the input/output device is selectable per application via the AUDIODEVICE environment variable.
> bluetooth audio devices
OpenBSD has no bluetooth support, so no. I'm also wondering why the kernel wouldn't create audio devices from these that the userland daemon can then just transparently use? Does an audio daemon need special support for bluetooth audio devices?
When I saw the new Ghostbusters trailer in the cinema (yes, I still go there), I thought it was a parody film. I'm not kidding.
Nowadays, people always try to find ways to be offended. A women-led movie got bad ratings? It must be the patriarchy!
Nobody wonders if it might have been just a bad movie, as I, as a man, also enjoy women-led movies (I mean movies in the cinemas, not what you think :P). Hoewever, the new Ghostbusters just looks like a big horrible painful joke, and that's why the ratings tanked.
Given it's so hard to even assess statistically, how many men are among movie raters, this entire article stands on weak feet.
I disagree VEHEMENTLY. Sent is a godsend if you want to write a simple presentation without the bullshit. And if you use sent, the constraints placed on you force you towards making good slides.
Disagree all you like. The same is true of org-mode with reveal, or Marp, or any of myriad other tools. There's no magic to suckless software. It's just a lot more opinionated than most, a trait which plainly suits you well.
Who called it useless? But ascribing rampant NIH to suckless is hardly a strain on credulity; otherwise they'd just use FreeBSD, instead of reinventing it piecemeal on the Linux kernel.
You did describe it in a way that implied it was useless if NIH wasn't your thing.
And no, I don't argue that NIH doesn't exist in other suckless projects, merely that it isn't the rationale for sent. Sent has some solid advantages over anything else out there, at least for me.
I don't agree that the implication you ascribe is present, or that sent isn't primarily motivated by NIH in the same way that more or less all of the suckless repertoire appears to be, but reasonable people can differ on such points without acrimony. In any case, I'm glad you found something that suits you.
Well, then. I'm sorry for reading that implication in, and glad that we could come to understand each other better.
HN is a lot like Youtube comments: There's a lot of arguing, but sometimes, people treat each other decently. It's honestly kinda surreal, coming from 4chan, reddit, or tumblr.
Yeah, I agree. Though, Vulkan is meant to be low-level, kind of like an ASM for Graphics Cards.
The euphemism of the article's title is too much though imho.
So can one assess this is a racial problem after all?
For years, liberals tell us the high poverty of negroes and hispanics was due to lack of education. If it's not education, what is it then? And why are Asian-Americans not facing the same issues?
I suspect it's a racial identity issue. The best way to understand this point is looking at the mainstream media and how the different races are portraied. Only an idiot would ignore this influence on people, especially because the USA are by far the biggest TV consumers.
If you start judging me for asking these questions or downvote me without giving a reason, you should be ashamed of yourself. Reasons for downvoting are welcome though, so keep them coming! :)
The only sensible normalisation one can implement is the full decomposition (NFD), and maybe the full composition (NFC). You rely on the full decomposition if you want to collate correctly, which is a problem because the amount of memory needed to store the decomposition is unbounded in general. I don't want to make the libgrapheme users jump through hoops, and I also don't want to do any memory allocations in libgrapheme either.
There is an idea floating in my head on how to solve this, but I'm currently busy finalising Unicode 15.1 support (Unicode 16.0, released on the 10th, will be trivial to upgrade to) and releasing my already fully-compliant implementation of the Unicode bidirectional algorithm.