>The command for bringing up a network device is now ip link set dev eth1 up vs the older ifconfig eth1 up. Does this really look like progress?<p>I mean... what does progress look like? The old syntax is less words, but it's still something you have to memorize. Why is this new syntax worse?<p>FWIW, I believe the newer syntax more closely resembles what you have with Cisco network equipment. It also supports newer functionality like net namespaces, and uses newer kernel interfaces. None of those advantages are mentioned in the article that I can see...<p>>autoconf has its warts<p>This is the single most charitable interpretation of autoconf's problems I've heard in my life.<p>> in fact according to this[1], meson authors claimed it to be one of their goals to force users to have a bleeding edge version of python3 installed so it can be universally assumed as a given.
> [1]: <a href="https://kevstras.com/programming/2017/12/18/meson.html" rel="nofollow">https://kevstras.com/programming/2017/12/18/meson.html</a><p>I tried and was unable to figure out what they mean by that. Am I stupid or does that article not say that?<p>> Built with debug information, it takes up 434 MB of my harddisk space as of version 3.9.3.<p>Then... don't build it with debug information?<p>> It's primary raison-d'etre is its support for the Microsoft (TM) Visual Studio (R) (TM) solution files, so Windows (TM) people can compile stuff from source with a few clicks.<p>It exists because it was created to be the build system for a specific project. I don't even know if it began life with Visual C++ project generation support.<p>--<p>All in all this feels like run-of-the-mill cynicism. Some valid points but a complete failure to acknowledge why things are the way they are. Some days I wish HN had a downvote button.
> Microsoft (TM) knows better and sees backwards compatibility as the holy grail<p>This is true, they have a regrettable habit of inventing a new GUI toolkit every few years, but they're good at ensuring the old ones still work.<p>> While the traditional buildsystem used on UNIX, autoconf, has its warts, it was designed in such a way that only the application developer required the full set of tools, whereas the consumer requires only a POSIX compatible shell environment and a make program.
>
> More "modern" build systems like cmake and meson don't give a damn about the dependencies a user has to install<p>True, you have to install CMake to build packages that use CMake, but I'm not sure it would be possible for CMake to generate a shell script the way autotools does, without losing either its scripting power or its portability to non-Unix platforms (e.g. Visual Studio). Personally though I don't score this very high up the list of things wrong with CMake. [0][1]<p>[0] <a href="https://news.ycombinator.com/item?id=24565266" rel="nofollow">https://news.ycombinator.com/item?id=24565266</a><p>[1] <a href="https://news.ycombinator.com/item?id=24203172" rel="nofollow">https://news.ycombinator.com/item?id=24203172</a>
> Even worse, due to the irritation the GTK+3 move caused to developers, many switched to QT4 or QT5, which requires use of C++, so a typical linux distro now has a mix of GTK+2, GTK+3, GTK+4, QT4 and QT5 applications<p>I agree on several points he makes about GTK+3, not so much on the theming issue, but it's arguable that the reason most distros have a mix of gtk/qt by default is not because gtk+3.<p>Now pretty much every kde-based distro that wants to ship with firefox/chrome by default, <i>has</i> to bring up gtk. iirc ubuntu studio shipped with both qt and gtk because of the plethora of applications it offered, way before gtk+3 was a thing.
The problem with the systemd showcase is that it is progress, it just doesn’t look like it on the surface.<p>When you use “kernel names” you’re implicitly relying on the fact that your network cards initialize in the same order on boot which isn’t guaranteed. It’s the same reason you should prefer disk UUIDs over /dev/sda. For a long time sysadmins have used udev to pin eth0, eth1, etc. to specific network interfaces to solve this problem but it’s clunky.<p>systemd changed this in a very elegant way. The BIOS already assigns fixed names to network devices! If you use those you don’t have to query the device for its MAC to figure out its identity like we do with partuuids and diskuuids. The crazy names come from your vendor — nothing stops them from being eth0 eth1. Dell uses eno1 ens1 and enp0s1 depending on the kind of card.<p>Now by default network device names are fixed and if you want eth0 eth1 like you’re used to the process hasn’t changed.
Autotools vs cmake is just no contest from a developer’s perspective. I set up one project with autotools a few years back and the experience was horrible: lots of weird incantations, obfuscated syntax, piles of m4 macros to do what feel like straightforward things, and just a general feeling that I was being forced to learn obtuse technologies for basically no purpose.<p>Cmake isn’t always the easiest thing either but it’s a vast improvement over autotools.
Did the author just make baseless accusations that high churn in the Linux desktop eco-system is a conspiracy?<p>Haven't there always been a high churn? And shouldn't we expect to that to continue until the "Year of the Linux Desktop" finally happens :)
Do we really want "the year of the Linux desktop" though? I can only imagine if Linux went mainstream (for non technical users), big corps would be scrambling to put tons of black boxes and DRM enablement into the core OS
>I don't like the state of software other people wrote<p>The idea of a Linux desktop is stupid to the core, and has crippled Linux more than anything Pottering will come up with next.<p>Everything past the kernel is software you choose to install and use, stop using it if you don't like it and learn to deal without it.