BenLloydPearson

It's been years since I used/administered IRC, but I also think there are common misconceptions about what IRC actually is. At it's core, IRC is an incredibly basic tool, and most of the end-user features come from layering additional services on top of IRC, both at the client and server levels. These services can be pretty complex and cumbersome to manage, and in my opinion, never quite seem to solve the problem exactly. Persistent chat history is certainly the most glaring example.

At the risk of becoming a meme, it's similar to how practically nobody uses Linux alone; it's almost universally accompanied by something like GNU.

I think part of the point the author was making is that rendering and interacting with the server can vary depending on the client you build. You could have a CLI client or a React client and build them with two completely different goals in mind. For example, monitoring and botting channels vs. end-user experience.

I came for the pithy title, I stayed for the unique, yet simple, approach the author took and how they explained the examples.

I've started contributing to programming.dev

Are you me? I occasionally have to touch CSS while working on technical docs and just spent more time with CSS than I have in a couple of years. Reading this article completely opened my eyes to how much has changed in this space. I thought I was cool for using flexbox last week.

We just launched a free forever SaaS offering that is competitive to Slack and includes kanban boards for project and task management and a few other bells and whistles for software developers. You should give us another look!

From the article:

One of the most notable and enduring Linux desktop paradigms has been desktop effects: the coupling of various desktop environments with graphical niceties, also known as “eye candy.” With the advent of the XComposite extension in the mid 2000s, mainstream eye candy was taken to new levels through a small project called Compiz which used the texture from pixmap extension to apply hardware-accelerated effects to windows on the fly.

Partial implementations of it have been developed for Enlightenment a couple times over the lifetime of E17 and onwards. However, none of these are great solutions in today’s modern world of GLES/EGL, Wayland, and embedded devices. Currently, Compiz uses Xlib internally as well as GLX, enforcing a dependency on X11 and the Xserver. Furthermore, given the server-side location of the effect handling, this will not play too nicely with the client-oriented Wayland protocol.

And so it was, armed with this knowledge, that a pair of procrastinating-yet-ambitious Samsung Open Source Group graphics engineers set out to improve the Wayland world with client-side, window, post processing effects. The goal: implement wobbly windows using the client-side decoration region and a lot of elbow grease.