Second this. The "ui" is perhaps useful when learning to use emacs, but every emacs user I've seen after a while has all of it disabled.
I've been using emacs with the "lucid" build since forever, as it's the leanest build that still gets a graphical window working on X11 and see none of the actual "toolkit".
I guess the pgtk build is required nowdays for native wayland support.
Yup, just the other day I was talking about it on subreddit, will repeat here verbatim:
My comment is an honest reflection of long-time Emacs usage. When I started, years ago, I just couldn't wrap my head around the fact that there were no tabs for every file anymore - the concept that was seemingly ingrained into my programmer's brain - almost in every IDE/editor I used before Emacs, I had tabs and a navigational panel on the side. I complained and demanded my tabs, asked on forums and called it "bullshit", when people calmly told me that I truly don't need them. Later I realized - they were right.
Slowly I learned that the wise choice is to remove any distractions - you don't need a minimap, side-panels, complicated modelines, and even line-numbers shown all the time. All that can be activated purposefully, on demand and then toggled off again. These "visual clues" are in fact not so much even distractions but micro-bombardments of your brain neurons - you think they are helping, while in fact they are slowly eating up your neural capacity, to the point that the brain just stops even paying attention to them and they become almost useless waste of your screen estate.
I'm not saying that this all generally true for every case and every user - some prefer certain ways, and it's great that we have a system that is able to satisfy any whim, but it's worth sometimes questioning yourself - am I enslaved by my own mental habits?
On the server side, probably not, but I'd like to point out that old hardware is not uncommon, and it's going to be more and more likely as time passes especially in the desktop space.
I was hit by this scenario in the 2000s with an old desktop pc I had, also in the 10ys range, I was using just for boring stuff and random browsing, which was old, but perfectly adequate for the purpose. With time programs got rebuilt with some version of SSE it didn't support. When even firefox switched to the new instruction set, I had to essentially trash a perfectly working desktop pc as it became useless for the purpose.
It's dumb because a font a allowed to re-interpret the actual image, but in doing so you also frequently change the meaning of the symbol. This is not a problem for text, but for images just changing the color of the fill might completely change the meaning of the sentence.
See the old apple gun vs squirt gun. The same is true also when using stuff like whatsapp on android, where the os keyboard shows you one image from the system theme, but the one which you see inserted in the text is not what you selected, but at least is partially better than sending something without knowing how it will be rendered, which is what most chat messages have realized after trying to simply using the system font.
So at that point, you have to switch to a different custom font just for the emoji block, and you're still limited to what unicode allows instead of just bundling whatever image you want (which is a great excuse to sell new phones with "new emojis" I guess).
> and you're still limited to what unicode allows instead of just bundling whatever image you want (which is a great excuse to sell new phones with "new emojis" I guess).
Except that every chat client now supports stickers, which are nothing but custom images that are guaranteed to render the same way for the recipient that they do for you. The recipient does not need to have them installed.
But stickers have to be their own full message in the clients I know of. Once they start to be integrated into textual messages, clients will have developed all the way to where MSN messenger was in 2003.
I dislike emojis in general when combined with running text. Especially in terminals or character-based interfaces with fixed-width fonts.
On top of that, there are only very few emojis that can be read properly at the same size of the current line height. It works for a few simplified faces and symbols, but that's it.
The fact that emoji fonts override the font color rendering is an aggravating factor. I don't want text to change color behind my choice (it SUCKS with customized color themes).
They feel like a punch in the face to me when I'm reading documentation or even worse when reading code.
Sadly, it's really hard to avoid them nowdays. I'm using a few lisp scripts with emacs to translate the common ones back to ascii for rendering.
I can point out that "Noto Emoji" is a b/w version of Noto Color Emoji, which contains a MUCH more suitable version of emojis that can be used in running text. As noted before, it's only a partial solution as I find most emojis are still not readable when scaled at the same size as the text and when simplified sometimes they also lose the original meaning (just use the damn word dammit!). But at least they don't override the color. On linux, you can force a font substitution with fontconfig to force the b/w version whenever color-emoji is used and can't be customized.
Regular PLA is actually stiffer than PETG/ABS, but it's more brittle (so has less impact strength) and a pure formulation has a lower softening temperature. It's generally not suitable for parts that go under the sun, unless it's some other formulation such as some HT-PLA variant, in which case it's actually a good choice for parts that need to be thin and stiff.
Under most cases, you won't get the same inter-layer adhesion with ABS, so while you get better impact resistance, under most circumstances PETG will yield more durable parts that won't delaminate under the same stress conditions. For outside use under the sun, you should use it's cousin ASA.
To respond to the OP.. 3D printed parts can be incredibly durable when printed correctly. The parts need to be designed for 3d-printing in mind, like most other manufacturing methods. A 1cm-thick 15% filled PLA slab that has been printed vertically might be easy to snap in half with two hands, but it becomes almost impossible to break with bare hands when printed horizontal, and requires a saw to be cut when filled to 50%+. And this using consumer-grade printers.
I'm using 3d-printed parts for work and at home, some in use for almost 7 years at this point, and the only telltale sign is the layered look.
The rods in the design are not 3d-printed, which makes sense (most plastics would be too flexible, and 3d-printing a rod is always more expensive).
Using VR glasses instead of screens is a wet dream of mine, but VR tech has been one of the worst vendor-locked tech I have ever seen.
I haven't keep up lately, but as a linux-only dev, is there any hw combo which would give me full native hardware support and the ability to develop for the platform?
(I don't count linux-on-[android|win] as a solution)
The xreal glasses mentioned in the article are just displays (or at least they can operate in that way). Their website claim it works with basically anything that outputs HD video (game consoles, PCs and whatnot).
As a student I used a ton of warez software in the 90ies. As such, I didn't have any real prejudice back then, and photoshop was the worst of the bunch from my perspective. I held that view for a long time, akin to how I consider autocad from autodesk one of the worst cads you could use despite being outrageously popular.
I have no longer an opinion on it as I didn't use it for such a long time. I'm cycling between krita and GIMP, and GIMP's UI is just fine to me, in the same way I suppose a ton of designers-with-big-opinions are more familiar with photoshop due to all the training they did on it (and probably, _mostly_ on it).
Sure, our expectations about UI patterns are path dependent. However, if a program isn't consistent internally [0] (rather than against the body of software we are familiar with), then the complaint is less subjective.
I get that whoever made and posted that terrible youtube short is annoyed, but if they had done a basic search online, specifically "how to edit a brush in gimp", the first result would have taken them to this page:
It is a general rule that you cannot alter the resources that GIMP pre-installs for you: brushes, patterns, gradients, etc; only ones that you create yourself.
It's okay to be annoyed when something doesn't work the way you want it to, but RTFM before you make a rant about it. It's the bare minimum.
I'm still cycling through wayland and x11, and I also do get 1.5 hours more runtime on average on my old 2nd gen t14s with x11+xmonad+no compositor. It's one of the main reasons I'm struggling to move permanently, as I really don't see any advantage from my perspective as I don't use any desktop environment or feature that would make a compositor actually useful. The only thing I do notice occasionally are black borders due to shadow dropdowns in gtk4 programs that don't respect the system theme I've set.
The frustration for me is then which "flavored" version of markdown you're now using, because the evolution seems to always be "MD is simple and popular" until gets extended with subtle differences. Those subtle semi-random differences in flavors get tiring really fast.
What's the frustration about? Basic things are same everywhere.
If you need complex things, you already have enough skills to figure that out. Also there's almost always a help button around that lists what it supports.
For me the frustration is that you cannot learn markdown once and use it in different places - for non-trivial things you always have to use a reference for a particular flavor.
I've been using emacs with the "lucid" build since forever, as it's the leanest build that still gets a graphical window working on X11 and see none of the actual "toolkit".
I guess the pgtk build is required nowdays for native wayland support.