If you need an example of a germanic language that has a very regular phonetic spelling I think Dutch is a better example than German. German has a lot of idiosyncrasies, because the spelling tries to preserve the etymology of the words. In Dutch they don't bother trying to preserve a word's history, everything is written as it sounds. (With a handful easy to memorize exceptions)
I get it that gnome is nowadays an experimental desktop environment, that tries a lot of new approaches.
I just don't understand why many distributions use it as their default DE.
I am fairly sure the people behind Gnome don't actually really know what they're doing when it comes to HID and Ux.
Gnome terminal for example will offset the right click contextual menu with a new line of bin/hex/oct representation of a number that you happen to have selected. By default, no it can't be disabled.
Good luck with the muscle memory to hit the contextual menu items now that everything is shifted down.
When I was in the GNOME bubble, I too thought GNOME was the be-all and end-all of Linux DE usability, with everyone else being savages slapping together UIs without so much as a style guide. Perhaps at some point this may have been partially true.
Today, all major DEs are fine. Plasma did not crash once since 2019 for me and I think its UX is quite nice, in the case of Dolphin in particular visibly better than GNOME's. At the same time, GNOME had routine issues with extensions, semi-frequent crashes, and odd non-compliant bits like refusing to use tray icons, breaking apps that depend on them, and the last time I checked, scaling was a mess.
I do think the GNOME/libadwaita ecosystem is a fantastic achievement and agree with many of their ideas, but it would be dishonest to say all other DEs are inferior and don't deserve any consideration as a default.
Only KDE and Gnome offer proper Wayland support making them in my eyes the only truly modern DEs on your list. Out of these two, Gnome is the only one that doesn’t glitch constantly. It’s true that Plasma finally stopped krashing every time you look at it funny but it’s still a bloated, glitchy mess of a DE. You really can’t count on KDE to provide updates without introducing major bugs and stability issues as proven by recent Plasma 6 release. Believe me I hate Gnome for how poorly managed and anti user it is but at the same time I see no real alternatives.
I don't think this is true, I haven't gotten plasma crashes for a long time now. Even early into Plasma 5 it was stable.
Also bloat is so very debatable. You can't on one hand complain about Gnome being unusable and then turn around and say Plasma is bloated. Uh, that "bloat" is the difference between the two!
The difference between the two is that Gnome is at least trying to constantly deliver stable and high quality desktop experience. I don’t like the way Gnome works, I don’t like the way their organization is run but I like when my computer just works. I don’t have time to fuck around with buggy Plasma widgets. I was a Plasma 5 users for two years until 2022 and I still use it on my Steam Deck occasionally. My opinion is based on experience.
GNOME is well know for breaking often backwards compatibility, especially in regards to extension.
The only criteria which I'd thick next to de GNOME DE in consistency, would be: aversion to customization, opinionated, 80% done in perpetuity, and liberal use of space (low information density)
While the author dislikes extension functions in kotlin they enable one feature that Java doesn't have: With them you can create domain specific languages within kotlin that are quite ergonomic.
- Jetbrains has built a nice reactive js wrapper with them.
- The gradle configuration is written in a kotlin dsl.
They can be used to specify configuration and add meta information and thus replace Java annotations.
That is my kotlin "killer" feature because I personally don't like annotations.
Java's language design has always been "pedagogical" (or patronizing) to not give the developer to much power to create to much abstractions and complexity.
So it's not just its age but also this philosophy that has made Java a rather inelegant language ( compared with e.g. kotlin)
My reason for switching from gnome to KDE was that it was not possible for gnome to manage more than one Bluetooth adapter. A scenario that quickly occurs when you use a docking station. KDE had no problem with that. Another thing is the crusade against tray icons by gnome.
So yeah, I like the cleanliness of gnome actually better than KDE, which is really a bit messy. But when this "cleanliness" comes at the price of stripping away essential functionality, there's no choice.
Great idea. I'd suggest turning the clock 180°. Since we are used to having the clock wrap around on the top not the bottom. There is a saying (at least here in Germany) it's "5 to 12" meaning it's time to act now, which is what your clock is trying to symbolize. That would work better if the "12" was in its usual (top) position.
The clock does wrap around at the top, but the problem comes about when the smallest hand gets to the bottom (the value 0x80). Flipping it would be confusing as that would make the 0x00000000 position be at the bottom.
The 2038 problem comes about because of overflow in a 32bit signed int, so the top byte (smallest clock hand in this case) effectively only has 7 bits instead of 8, when it goes above 0x7F is when the int is interpreted as negative.
The easiest 'fix', if it's even necessary, would be to make the smallest hand go all the way around in 128 ticks instead of 256. But really this micro blog post could just use an explanation of that to aid the visualization.
The problem with doubling the speed of the small hand is that it would subtly imply that unix time will wrap around to 0, Jan 1st 1970, which is a common misconception and of course not true - it wraps to somewhere in 1901.
I've considered annotating the left side of the dial with the negative numbers also, e.g. ff (-01), etc., which would make it clearer that there's a discontinuity at 80, but it's also a lot of visual mess and on balance I prefer the cleaner look.
I hope that anyone wondering "why 0x80" will be curious enough to go read the linked wikipedia article, which goes into much more detail.
Or draw the left half of the clock face differently to make it clear there's something different about that region.
Some gauges do something like this. Tachometers often have RPM bands marked in yellow and red. And here are two pressure gauges that do it in different ways:
The clock does wrap at the top though, mostly. If you watch the green/teal hand do a full rotation, the moment it hits the top, the number on the dark-purple hand will increment by 1. Same goes for every other pair of hands.
The problem is just that signed integers don't wrap at 0, they wrap at whatever their min/max point is - which, hopefully, my clock helps convey, along with the accompanying text. I think flipping it 180 degrees would make it less consistent overall. Maybe I'll add some more words to the blog post, heh
Something I could do is add 0x8000_0000 to the number that I'm displaying. Then the final wrap point is at 0, when the small hand points up. I'll have a think about this, and I may well do it, but it slightly goes against my goal of visualizing the signed 32-bit integer representation of unix time - I'd be visualizing a different number! (as an unsigned int)
Wrap around on the top only makes sense with a 12 hour clock. I found a cheap 24 hour analog clock and my biggest problem with it is that I feel midnight should be at the bottom and noon should be at the top. I want to print a new back graphic for it every time I look at it.
Having pondered the unix clock for a bit. it does not correspond to a day in any axis, which is fair enough, but it also means I have no real feel for whether the top or bottom should be the cycle point, I would say bottom to match other gauges.
I wonder about having a second ring of ticks on the outside, coloured to match the hand representing the position of the most significant byte, that has 0x80 at the top.
This preserves the idea that all hands pointing to the top = midnight.
I have to admit never really dug into Julia.
When it was new I read about it as I was looking for a replacement of python/numpy.
But then I was really repulsed by the fact that array indices don't start at 0.
I plan to train an NLP bot from Hacker News 1-based indexing discussions to automatically generate the mandatory thread on it so that nobody ever has to participate in it again. It's so unoriginal that it's a better fit for ML automation than a human brain.
Also these comments just tell us about the background of the commenter, and nothing else. Anyone who has had to translate numerical or scientific algorithms into both C and pre-array syntax Fortran finds Fortran’s 1-based indexing to be a more natural fit, I would suspect.
In practice, indexing is the least of anyone's problems. I switch between 0- and 1-indexed languages a lot and it's never an issue, I don't even have to think about it.
I disagree. When immersed in a language it doesn't tend to be an issue, but switching between them absolutely is. Over my career I've had to deal with a ton of off-by-one bugs in code that was prototyped in Matlab then ported to C++. My hope with Julia was that the language was fast enough that you wouldn't have this divide between prototype and production, but given the overhead in using it anywhere but a REPL, it doesn't look like things are going to work out that way.
On it's own, 1-based indexing certainly isn't enough to keep me from using a language though.
This really isn't a big deal. I switch between C/C++/R all the time and mixing zero/one indexing isn't some huge mental burden or source of intractable bugs--you get used to it after a few days.
