Davin McCall, a software developer, writes about init systems, systemd alternatives, the C/C++ memory model, and his Dasynq library.
HN commenters welcome his alternatives to systemd and link his posts on the C/C++ memory model; he also joins the discussion himself.
> If you're willing to fiddle around, there are a few good themes that don't waste so much space.
The point of this "first impressions" exercise was to explore the happy path.
> It's not just Gnome that does that. There's an entire generation of designers that's cargo-culting mobile designs at the moment. Breeze, KDE's default theme, is equally space-wasting.
I would agree with that sentiment, though I didn't want to get into that flame war today. I think a lot of other people have already written extensively on this subject and I don't feel I can contribute anything new. Here are some relevant articles...
Several of these are about CSDs, which I think are a big point of contention with respect to the design philosophy of GTK/Gnome 3.X. This list does not include much about the KDE/Qt side, which I'm less familiar with.
I would certainly like to expand the side of this list on the "Pro Gnome" side in the interest of a more fair and balanced debate.
Pro Gnome 3.x:
Client-Side Decorations Initiative - https://wiki.gnome.org/Initiatives/CSD
Restyling apps at scale - https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-at-scale/
Introducing the CSD Initiative - https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/
Against Gnome 3.x:
Why do we keep building rotten foundations? - https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/
GNOME (et al): Rotting In Threes -…
> Given that C++ now has a defined memory model, it might very well be that it's now impossible to implement C++ in a standard conforming way on exotic architectures.
Also C has a defined memory model since C11
> https://davmac.wordpress.com/2018/01/28/understanding-the-c-c-memory-model/
and it is the same as the memory model from C++11:
> https://en.wikipedia.org/w/index.php?title=Memory_model_(programming)&oldid=834038513
"After it was established that threads could not be implemented safely as a library without placing certain restrictions on the implementation and, in particular, that the C and C++ standards (C99 and C++03) lacked necessary restrictions, the C++ threading subcommittee set to work on suitable memory model; in 2005, they submitted C working document n1131 to get the C Committee on board with their efforts. The final revision of the proposed memory model, C++ n2429, was accepted into the C++ draft standard at the October 2007 meeting in Kona. The memory model was then included in the next C++ and C standards, C++11 and C11.".
late reply, I know - I only just saw this discussion - I didn't post this story to HN myself. However:
I recently wrote a blog post discussion why I created Dasynq, here: https://davmac.wordpress.com/2017/12/17/introducing-dasynq/
Though I don't specifically discuss boost::asio there, I believe some of the points made there apply. Also, last time I checked, boost::asio mandated linking with threads library (at least for some features) whereas Dasynq doesn't, and boost::asio didn't offer support for watching POSIX signals or child process termination (Dasynq does). Finally, the boost::asio multi-threading model is awkward, for reasons I try to explain here: https://davmac.wordpress.com/2016/06/18/boost-asio-and-resource-deallocation/
One potential problem is if Gnome make breaking changes, it's hard for Canonical (or anyone) to use it as a base for their own UI. I've not experienced this first-hand, since I haven't used Gnome or written GTK+ apps since the 2.x days, but judging by what I've seen online they like to break APIs at each release, drop working features if/when their opinions change, and be semi-hostile to any use-case other than their own default settings ("brand"), e.g.
https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/
https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/
I suppose Canonical are big enough to have their needs taken into account, unlike other app authors.
systemd has made packaging easier, and it's good at full process management, but still, it is nice to have alternatives in major distros.
Even though I'm a Gentoo user, I still prefer void's runit or openbsd's rc.d system when it comes to simplicity, over OpenRC.
Also, dinit looks really promising as well:
https://davmac.wordpress.com/category/dinit/