As a long-timer, I've noticed this as well. Python3 is perhaps the most disappointing of these. I was very hopeful in the beginning, but it's been years now, and for plain old "getting shit done" work, it's just not as good as Python2. It's true that lots of libraries are now no longer supported for Python2, but "ha ha, we took your libraries away" isn't really an appealing argument for 3 when you're just trying to get your work done. It's maddening.
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
You've been downvoted but I agree. We've had a decade of mainstream Linux based smartphones and it sucks. Locked bootloaders, bloatware, proprietary hardware drivers that don't get updates... this is what mainstream Linux usage looks like.
"Year of the Linux Desktop" makes people daydream about a world in which everybody is a console cowboy using and loving FOSS software. That's what I used to believe in, but Android convinced me that's a fantasy. If Linux ever won the desktop it would be a pyrrhic victory, like Linux 'winning' smartphones with Android or DVRs with Tivo. Software for the masses would still be locked down proprietary trash, no matter what kernel was used.
> 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
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.
Now pretty much every kde-based distro that wants to ship with firefox/chrome by default, has 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.
Also FWIW gtk is not difficult to build/package, distros like Void Linux no longer have Qt 4, and gtk2 should be an uncommon dependency with GIMP, Inkscape, and Firefox dropping it or already having dropped it.
> 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
I mean, even on my Windows and Mac machines I have software using GTK2 (GIMP), GTK3(Zim, Geany), Qt4 (various proprietary software), Qt5 (Strawberry, music player, etc)... plus a ton of other toolkits (Juce, Fltk, TKinter, the various Windows APIs, Cocoa, ...). And unlike linux every app has the DLLs duplicated.
The problem with the systemd showcase is that it is progress, it just doesn’t look like it on the surface.
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.
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.
Now by default network device names are fixed and if you want eth0 eth1 like you’re used to the process hasn’t changed.
Most systems that aren't servers only have one Ethernet adapter, which you used to be able to count on being named eth0. "Predictable" is a huge misnomer. They're stable, sure, but they couldn't be further from predictable.
>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?
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?
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...
>autoconf has its warts
This is the single most charitable interpretation of autoconf's problems I've heard in my life.
> 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]: https://kevstras.com/programming/2017/12/18/meson.html
I tried and was unable to figure out what they mean by that. Am I stupid or does that article not say that?
> Built with debug information, it takes up 434 MB of my harddisk space as of version 3.9.3.
Then... don't build it with debug information?
> 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.
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.
--
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.
>What has to do the Cisco network equipment with Linux?
What must it have to do with Linux? It's industry-standard networking equipment. Is that not a decent enough reason to take inspiration? Network professionals already know Cisco.
>Why All the BSD’s do similar things without changing the user interface?
¯\_(ツ)_/¯
Linux isn't a BSD, and it isn't run like one. The only positive thing I can say is, if you prefer the way *BSD is it remains a completely reasonable option in 2020.
> Because he linked directly the Poettering’s article explaining all you said.
And promptly disregarded all of it, which does not make matters any better for him to be honest.
The question is, how is it better? When you have something that works, replacing it with something that's just not worse is unnecessary churn and work for everyone. It shouldn't be replaced unless its replacement is somehow better.
> It also supports newer functionality like net namespaces, and uses newer kernel interfaces.
Why couldn't these have just been added to ifconfig? Surely it could have been ported to the new kernel interfaces. As for features like net namespaces, the syntax should have been added in a backwards-compatible way instead of rewriting it all.
You could ask the same questions about any user interface change. Surely you can just kept grafting new limbs onto existing bodies, but a command like ip actually does make sense when you look at the breadth of things jammed into the new command structure.
The article we’re talking about questions what “progress” is and points out things that actually have serious advantages, often technical in some regard, but then disregards those advantages and talks about minor inconveniences like 70 MB disk space footprints and a couple new commands to remember.
I acknowledge that that's a limitation of ifconfig today. My point was that we should have just modified ifconfig instead of completely replacing it with an incompatible new tool.
> Microsoft (TM) knows better and sees backwards compatibility as the holy grail
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.
> 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
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]
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.
Cmake isn’t always the easiest thing either but it’s a vast improvement over autotools.
There's definitely one advantage to autotools, though: anyone who wants to compile a program that uses CMake needs CMake on their system, but you don't need autotools to compile a program just because its build process was set up with it.
29 comments
[ 4.9 ms ] story [ 72.3 ms ] thread"Year of the Linux Desktop" makes people daydream about a world in which everybody is a console cowboy using and loving FOSS software. That's what I used to believe in, but Android convinced me that's a fantasy. If Linux ever won the desktop it would be a pyrrhic victory, like Linux 'winning' smartphones with Android or DVRs with Tivo. Software for the masses would still be locked down proprietary trash, no matter what kernel was used.
Just wait til all web sites run WASM and WebGL to draw their content, so you can't even copy or hide the text on your screen.
Maybe: AppImage, snap, flatpak, docker or one of the others will eventually win out.
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 :)
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.
Now pretty much every kde-based distro that wants to ship with firefox/chrome by default, has 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.
I mean, even on my Windows and Mac machines I have software using GTK2 (GIMP), GTK3(Zim, Geany), Qt4 (various proprietary software), Qt5 (Strawberry, music player, etc)... plus a ton of other toolkits (Juce, Fltk, TKinter, the various Windows APIs, Cocoa, ...). And unlike linux every app has the DLLs duplicated.
It causes exactly zero problems.
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.
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.
Now by default network device names are fixed and if you want eth0 eth1 like you’re used to the process hasn’t changed.
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?
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...
>autoconf has its warts
This is the single most charitable interpretation of autoconf's problems I've heard in my life.
> 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]: https://kevstras.com/programming/2017/12/18/meson.html
I tried and was unable to figure out what they mean by that. Am I stupid or does that article not say that?
> Built with debug information, it takes up 434 MB of my harddisk space as of version 3.9.3.
Then... don't build it with debug information?
> 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.
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.
--
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.
What has to do the Cisco network equipment with Linux?
>It also supports newer functionality like net namespaces, and uses newer kernel interfaces.
Why all the BSD’s do similar things without changing the user interface?
>None of those advantages are mentioned in the article that I can see...
Because he linked directly the Poettering’s article explaining all you said.
What must it have to do with Linux? It's industry-standard networking equipment. Is that not a decent enough reason to take inspiration? Network professionals already know Cisco.
>Why All the BSD’s do similar things without changing the user interface?
¯\_(ツ)_/¯
Linux isn't a BSD, and it isn't run like one. The only positive thing I can say is, if you prefer the way *BSD is it remains a completely reasonable option in 2020.
> Because he linked directly the Poettering’s article explaining all you said.
And promptly disregarded all of it, which does not make matters any better for him to be honest.
The question is, how is it better? When you have something that works, replacing it with something that's just not worse is unnecessary churn and work for everyone. It shouldn't be replaced unless its replacement is somehow better.
> It also supports newer functionality like net namespaces, and uses newer kernel interfaces.
Why couldn't these have just been added to ifconfig? Surely it could have been ported to the new kernel interfaces. As for features like net namespaces, the syntax should have been added in a backwards-compatible way instead of rewriting it all.
The article we’re talking about questions what “progress” is and points out things that actually have serious advantages, often technical in some regard, but then disregards those advantages and talks about minor inconveniences like 70 MB disk space footprints and a couple new commands to remember.
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.
> 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
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]
[0] https://news.ycombinator.com/item?id=24565266
[1] https://news.ycombinator.com/item?id=24203172
The idea of a Linux desktop is stupid to the core, and has crippled Linux more than anything Pottering will come up with next.
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.
Cmake isn’t always the easiest thing either but it’s a vast improvement over autotools.