Oh, perfect, thanks! I've been using Niri for less than a week, hadn't got to using named workspaces yet, and missed the bit in the docs where it says they can be empty.
Depends on your definition of "a good name". It seems like yours includes "must be a short English word", but doesn't include things like "is easily web-searchable" and "doesn't conflict with existing names". Throwing out the "short English word" criterion opens up a universe of names like "Wubulus" or "Flarnit".
> ...nobody really should be using either of them.
What's wrong with poll(), at least for smaller values of nfds? And what should one use instead when writing POSIX-compatible portable code, where epoll() and kqueue() don't exist?
Fun fact, on openbsd(at least, I don't know about freebsd) select and poll were reworked to use kqueue internally.
The thread is an interesting read as it sounds like the naive approach has negative performance implications, knowing openbsd I suspect the main motivation was to reduce maintenance burden, that is, make it easier to reason about the internals of event driven mechanisms by only having one such system to worry about.
nongnu.org is also run by the same people as gnu.org, but hosts software which isn't currently officially part of the gnu project.
Basically, it's an area for software that is aligned with the GNU philosophy, might one day become part of the GNU project, but isn't officially currently part of the GNU project.
My experience (and I admit I may be too biased given years of prior C/C++ experience) is that Rust's syntax is a necessity, since no other mainstream languages besides C/C++ are as low-level as Rust.
Most mainstream languages have a GC, and don't support distinguishing between values on the stack or references, don't need to deal with lifetimes or don't provide the safety you get with them, etc.
I'm curious though, could you give an example of syntax you consider convoluted, and how you would do it instead?
I do depend on their features, and I see the value in doing that.
For example, at $WORK I had to reimplement Apache's mod_rewrite.c in Rust, and I made it 100x faster for our particular use-case.
I could've done that in C as well, sure, but the simplicity of the C language just moves the complexity to the code itself; whereas, with Rust, I whipped out a prototype in just 3 days, and was able to freely pass around pointers to data, with zero allocations, zero copying, and every time it compiled I knew it was guaranteed to be safe.
You can't get that safety in C. You can't get that speed in Java.
You can't do this in any other language that does not have these features. I absolutely agree that the syntax is horrible... but I see no other way to achieve this.
The obscene complexity of the rust language (like c++) makes a toolchain beyond anything reasonable to code alternatives: that reason alone is sufficient to avoid it.
You can have as many "features" you want, the anti-feature of absurd/grotesque syntax complexity _alone_ buries it.
There is nothing more to say or argue about. This is dead simple.
Too bad the keyboard doesn't work (Firefox with "Search for text when you start typing" on). They didn't do the "event.preventDefault(); event.stopPropagation();" dance.
Naturally. You have enabled a setting for Firefox to intercept the keystrokes before the web page even gets a chance to see them. That means the JavaScript to prevent default action would never run.
Some early dictionaries did in fact do this, and this was also the case with Roget’s project with his thesaurus (most contemporary thesauri arrange the main headings in alphabetical order, thus the title, “Roget’s Thesaurus in Dictionary Form”) where he arranged the words in a tree of classifications.
Most rhyming dictionaries are still alphabetical, but I think it was Webster’s that kept a file of headwords alphabetized in reverse order (so order would be sorted as redro, reverse as esrever, etc.) to facilitate the creation of rhyming dictionaries, but a case could be made that this order could be useful on its own.
Isn't this what enciclopedias are? You have animals in one section, you have countries in another, you have every component in a motor vehicle in another, etc.
Perhaps encyclopaedia is not the word. As a kid I had tons of book like this. I still remember one of my favourites had a whole section on what I believe was housing temperature control and insulation!
