Some Unlikely 2021 Predictions(lwn.net)
lwn.net
Some Unlikely 2021 Predictions
https://lwn.net/SubscriberLink/840632/5120a4e4b44f7d2a/
63 コメント
SolarWinds was a wakeup call but it was also a special case. I remember when I got the first demo of SolarWinds years ago and the cold sweat feeling when they drilled down all the way into individual calls to the database and thinking 'That's cool, no doubt, but that's a /lot/ of access'.
I've only installed it on dev and qa systems with scrambled, nonsense data.
A little common sense goes a long way.
I've only installed it on dev and qa systems with scrambled, nonsense data.
A little common sense goes a long way.
I don't think these are too unlikely.
Shame about CentOS. Never used it myself, but I know many IT-provider do use it as a base for their infrastructure. Perhaps devs can nudge them to Debian.
Shame about CentOS. Never used it myself, but I know many IT-provider do use it as a base for their infrastructure. Perhaps devs can nudge them to Debian.
> Perhaps devs can nudge them to Debian.
From a management standpoint, we'd love to but, software targeting only RHEL/CentOS is a major blockage right now.
Some hardware drivers (like IB HBAs) also work more performant and reliably on RHEL/CentOS.
From a management standpoint, we'd love to but, software targeting only RHEL/CentOS is a major blockage right now.
Some hardware drivers (like IB HBAs) also work more performant and reliably on RHEL/CentOS.
If you're curious about how the 2020 predictions turned out: https://lwn.net/Articles/808260/
Some big Python shops will move to faster languages with static types, stable package management, stable configuration management and well-defined change management.
I hope that we'll see a raise of crystal (https://crystal-lang.org/) and a serious progress in mypyc (https://github.com/python/mypy/tree/master/mypyc) which provide a nice middle ground.
Similarly Nim (https://nim-lang.org/).
I hope to see Jon Blow's Jai lang released. He's a bright guy who's been griping about performance for years and decided to do something about it. The language has lots of cool features like a way to "compose structs" as well as declare a structure AOS or SOA and have it just work. He's doing private betas and writing a game in it, so by the time it's done, it should be pretty solid. Complies >100k LOC in <1s last I checked.
Except deep learning, most of the exploratory machine learning and data science done with Python is later implemented in Java/Scala.
I've been exploring Swift recently and it has a bunch of advantages: interoparability with Python, statically typed, strong capabilities for defining values, automatic differentiation. There's a lot of inertia though.
I've been exploring Swift recently and it has a bunch of advantages: interoparability with Python, statically typed, strong capabilities for defining values, automatic differentiation. There's a lot of inertia though.
Is there a reason to expect this in 2021 more so than in previous years?
Nope, as Python continues to be popular it just increases the rise of tools to manage Python (e.g. Poetry), increase the scalability (e.g. Dash), executable distribution (e.g. python-build-standalone), improve speed for hot code (e.g. numba.jit, mypyc, Cython), etc..
The more people use a language the more they want to solve the weak points of that language by using that language.
That's not going to go away for Python until people joining fields that make Python popular (data science, automation, web api/back-ends) have another language that's more approachable.
The more people use a language the more they want to solve the weak points of that language by using that language.
That's not going to go away for Python until people joining fields that make Python popular (data science, automation, web api/back-ends) have another language that's more approachable.
For sure 2021 will be the year of the Linux desktop. Seems likely.
If Microsoft ships their Wayland implementation this year, it might be!
Here is a reporting on this, for others, who just like me thought this was a joke: https://www.phoronix.com/scan.php?page=news_item&px=Microsof...
Sadly I predict more Linux users will switch to Apple.
2022 is now the year of the Linux desktop.
The Linux desktop is here, you don't have to use it if you prefer sharing your computer with Apple or Microsoft.
2021 will be the year Linux phones will have reliable calling and SMS.
2021 will be the year Linux phones will have reliable calling and SMS.
“The end of CentOS could have the unintended effect of undermining the demand for ultra-stable ‘enterprise’ distributions in general.”
That seems possible. Perhaps like the UNIX of old, Solaris et al, the ultra-stable ‘enterprise’ Linux distributions will retreat to large enterprise customers?
That seems possible. Perhaps like the UNIX of old, Solaris et al, the ultra-stable ‘enterprise’ Linux distributions will retreat to large enterprise customers?
I don't think so. We have Debian based ultra-stable distributions, namely Debian Stable and Ubuntu LTS.
I'm not sure that RH/IBM is in the position of "nah, they can either pay or go home, we don't care".
This stance will not only start a slow-shift towards Debian and Canonical (Containers are portable, right?) but, will open some gap for Oracle Linux. I bet RH wouldn't like that.
I'm not sure that RH/IBM is in the position of "nah, they can either pay or go home, we don't care".
This stance will not only start a slow-shift towards Debian and Canonical (Containers are portable, right?) but, will open some gap for Oracle Linux. I bet RH wouldn't like that.
>slow-shift towards Debian and Canonical...
This will only happen if no community replacement for CentOS gains traction. I wouldn't bet on that.
This will only happen if no community replacement for CentOS gains traction. I wouldn't bet on that.
> I wouldn't bet on that.
Me neither but, for some of the user base (HPC, Scientific computing, et al.), new model might not be sufficient. We'll see that.
The issue is too deep but, there are some older comments by me:
- https://news.ycombinator.com/item?id=25349371
- https://news.ycombinator.com/item?id=25448600
Me neither but, for some of the user base (HPC, Scientific computing, et al.), new model might not be sufficient. We'll see that.
The issue is too deep but, there are some older comments by me:
- https://news.ycombinator.com/item?id=25349371
- https://news.ycombinator.com/item?id=25448600
It will also only happen if CloudLinux goes the Debian route. Which they won't, as they're launching what looks like a somewhat credible initiative to replace CentOS.
[deleted]
> "We can read this SolarWinds blog entry from 2019 [1] with amusement; it claimed that open-source software makes one's chance of downloading malicious software "much higher". That post has not aged well, but this attack could also happen with free software, which is distributed in binary form through a large number of trusted channels. Malicious code inserted into one of those supply chains could be used with devastating effect; we can only hope that the suppliers we trust are truly trustworthy."*
The side-cut at SolarWinds made me smile. I don't like the last sentence though. We should strive for more than good hope here.
[1] https://thwack.solarwinds.com/t5/Geek-Speak-Blogs/The-Pros-a...
The side-cut at SolarWinds made me smile. I don't like the last sentence though. We should strive for more than good hope here.
[1] https://thwack.solarwinds.com/t5/Geek-Speak-Blogs/The-Pros-a...
These projects are a good start for that:
https://reproducible-builds.org/ https://bootstrappable.org/
https://reproducible-builds.org/ https://bootstrappable.org/
Regarding that GNOME update, do GNOME developers just don't have any competence in UX design? That screencast is suggesting you need to click the activities button in the top left corner to be able to reveal a nav panel that's all the way at the bottom.
Similarly, right now, in current versions, in the file selection interface the Select button is in one corner of the window and Cancel all the way in the other.
Or the annoying unnecessary dialogue when you uncompress from an archive (no I don't want an app-blocking notification that the file extracted successfully).
Similarly, right now, in current versions, in the file selection interface the Select button is in one corner of the window and Cancel all the way in the other.
Or the annoying unnecessary dialogue when you uncompress from an archive (no I don't want an app-blocking notification that the file extracted successfully).
> That screencast is suggesting you need to click the activities button in the top left corner to be able to reveal a nav panel that's all the way at the bottom.
That's already the default way it works, and it's perfectly insufferable. AFAIK almost everyone uses an extension or another that makes the panel a permanent or auto-hiding dock, like any other reasonable desktop OS.
I can't see any drastic change, actually. Apparently the main difference is that the panel is visible at login, instead of being hidden (therefore stumping new users that can only see an empty desktop and nothing else).
That's already the default way it works, and it's perfectly insufferable. AFAIK almost everyone uses an extension or another that makes the panel a permanent or auto-hiding dock, like any other reasonable desktop OS.
I can't see any drastic change, actually. Apparently the main difference is that the panel is visible at login, instead of being hidden (therefore stumping new users that can only see an empty desktop and nothing else).
To me since Gnome 3, it feels like Gnome devs are covering their hears with their hands and shouting loudly to be sure they don't hear their users.
Why would they change though? There are no consequences.
Why would they change though? There are no consequences.
pojntfx also already pointed to some great resources to understand their reasoning.
Also, it's a FOSS project. Which means you can make your voice heard and get involved. Just try and be kind when you make suggestions. Or, even better, contribute yourself: https://www.gnome.org/get-involved/
Also, it's a FOSS project. Which means you can make your voice heard and get involved. Just try and be kind when you make suggestions. Or, even better, contribute yourself: https://www.gnome.org/get-involved/
> Which means you can make your voice heard and get involved.
Unfortunately that's not how the Gnome project has been run. Even back in Gnome 2.x times. There's a famous very funny jwz blog post about this (that I won't link because of some well known reasons).
Unfortunately that's not how the Gnome project has been run. Even back in Gnome 2.x times. There's a famous very funny jwz blog post about this (that I won't link because of some well known reasons).
I'm afraid I'm the kind of naive person that believes in the best intention of people and have not read that blog post. So I will have to be provided with a link to better understand and judge for myself.
If you link to that particular blog from HackerNews, he checks the referer and serves you up a nasty message instead of the blog post. So, instead of providing a direct link, search for JWZ, GNOME and CADT.
Can someone explain to me why I'm getting downvoted for this? Maybe the phrasing was a bit strange, but I just wanted to understand...
The problem is they weren't really kind towards people with suggestions in the past.
I've heard this many times before, but have never made the experience myself. Can you please share a link to examples?
I'm just trying to understand where this bad reputation for gnome comes from.
I'm just trying to understand where this bad reputation for gnome comes from.
That gnome doesn't really listen to end user feedback? I think this is a pretty great example: https://gitlab.gnome.org/GNOME/nautilus/-/issues/244
Patches are available for type-ahead, in particular the gtk-mushrooms fork. If open source is about "scratching your own itch" gnome is making it really hard for developers to do that. There was discussion of burying that features somewhere deep in the gnome registry, all kinds of options, but it's clear that pull requests are not welcome, even if the option is buried deep in some config file somewhere and is only accessible to power users.
That seems to be the case a lot of the time when outsiders try to solve their own problems with a pull request. There's just no room for compromise or for solving your own problems.
Patches are available for type-ahead, in particular the gtk-mushrooms fork. If open source is about "scratching your own itch" gnome is making it really hard for developers to do that. There was discussion of burying that features somewhere deep in the gnome registry, all kinds of options, but it's clear that pull requests are not welcome, even if the option is buried deep in some config file somewhere and is only accessible to power users.
That seems to be the case a lot of the time when outsiders try to solve their own problems with a pull request. There's just no room for compromise or for solving your own problems.
Wow that thread was infuriating and I don't even use GNOME. What a tone deaf response from the dev.
I read through most of the thread and I am very confused by the negative reactions. What was tone deaf in the response!? (I do understand my question is tone deaf by associativity, but I sincerely do not get it)
That's only one example and the issue was closed specifically because it conflicts with their UX designs created by a professional designer: https://github.com/gnome-design-team/gnome-mockups/tree/mast...
As a point of comparison, you may want to look through all the other merge requests that actually do get accepted, the majority of them do: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests?sta...
As a point of comparison, you may want to look through all the other merge requests that actually do get accepted, the majority of them do: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests?sta...
That's fine, and I get that gnome is a platform. The problem is that they're forcing their platform's choices on every GTK-3 app, which makes it really annoying for people who use GTK (not gnome) apps but which don't like the Gnome platform.
The problem is that GTK was used as a generic toolkit, and they've added a bunch of weird customization's to make it work better with their platform. That fucked over a lot of people who used that toolkit on non-Gnome platforms, and for non-Gnome uses.
Most people using GTK didn't sign up to be part of the gnome platform. Firefox isn't a gnome app. They (and everyone else) assumed it was being developed as a generic and cross-platform gui toolkit. Bit of a bait and switch there.
The tight integration between gnome (the platform) and GTK (the cross-platform GUI toolkit) seems an awful lot like a betrayal, like taking something that was for everyone and well.. taking it. Making it all about themselves, and burning the commons so other people can't use it. Or at least like a heavy-handed attempt to force people to write Gnome apps instead of GTK apps.
The problem is that GTK was used as a generic toolkit, and they've added a bunch of weird customization's to make it work better with their platform. That fucked over a lot of people who used that toolkit on non-Gnome platforms, and for non-Gnome uses.
Most people using GTK didn't sign up to be part of the gnome platform. Firefox isn't a gnome app. They (and everyone else) assumed it was being developed as a generic and cross-platform gui toolkit. Bit of a bait and switch there.
The tight integration between gnome (the platform) and GTK (the cross-platform GUI toolkit) seems an awful lot like a betrayal, like taking something that was for everyone and well.. taking it. Making it all about themselves, and burning the commons so other people can't use it. Or at least like a heavy-handed attempt to force people to write Gnome apps instead of GTK apps.
I'm confused how that's related, the issue you're talking about is in the file manager, not GTK. I don't believe any of the primary nautilus maintainers are also primary GTK maintainers, at least not anyone in that issue. (Please correct me if I'm wrong about that)
But, since I've said this before, I'll say it again: If the other people who use the toolkit want to have input, they need to contribute more. AFAIK there are zero non-GNOME devs working full time on GTK. I hope that changes, i.e. I hope the other desktops can find funding to send more designers and developers to collaborate with the GNOME people so everyone can have their say. That is the real issue here, I think it's incorrect to suggest that anything was "taken." It's open source, there isn't anyone who's going to take the code away from you unless you blatantly violate the license.
But, since I've said this before, I'll say it again: If the other people who use the toolkit want to have input, they need to contribute more. AFAIK there are zero non-GNOME devs working full time on GTK. I hope that changes, i.e. I hope the other desktops can find funding to send more designers and developers to collaborate with the GNOME people so everyone can have their say. That is the real issue here, I think it's incorrect to suggest that anything was "taken." It's open source, there isn't anyone who's going to take the code away from you unless you blatantly violate the license.
Maybe your distro patches it, but last I checked typeahead wasn't available in GTK-file-picker. It uses recursive search instead.
https://gitlab.gnome.org/GNOME/gtk/-/issues/839
Also: https://bugzilla.gnome.org/show_bug.cgi?id=748672
The GTK devs were saying that they wanted a flag shared between nautilus and the file picker that would enable/disable typeahead. Unfortunately nautilus refuses to implement that flag, which I think means we're all still relying on forks for that feature.
So you're not really allowed to solve one without solving the other, last I checked.
So yeah, the issues is very much in both, and you can't solve the issue with GTK without solving it in Gnome.
https://gitlab.gnome.org/GNOME/gtk/-/issues/839
Also: https://bugzilla.gnome.org/show_bug.cgi?id=748672
The GTK devs were saying that they wanted a flag shared between nautilus and the file picker that would enable/disable typeahead. Unfortunately nautilus refuses to implement that flag, which I think means we're all still relying on forks for that feature.
So you're not really allowed to solve one without solving the other, last I checked.
So yeah, the issues is very much in both, and you can't solve the issue with GTK without solving it in Gnome.
>So you're not really allowed to solve one without solving the other
The final comments from the developer directly contradicts this claim:
>I'd be happy to review a merge request that added the ability to disable recursive search in the file chooser using a GSettings option ... I was thinking more along the lines of having a key in the file chooser settings schema that would be observed by Nautilus.
The idea there is that the key should be in a standard location read by nautilus (or some other GTK file manager) if it also decides to implement that feature. Edit: I also should note that it appears there was not even initial consensus about this, the other GTK developer seemed to be skeptical at first.
The final comments from the developer directly contradicts this claim:
>I'd be happy to review a merge request that added the ability to disable recursive search in the file chooser using a GSettings option ... I was thinking more along the lines of having a key in the file chooser settings schema that would be observed by Nautilus.
The idea there is that the key should be in a standard location read by nautilus (or some other GTK file manager) if it also decides to implement that feature. Edit: I also should note that it appears there was not even initial consensus about this, the other GTK developer seemed to be skeptical at first.
Their are some striking similarities between how systemd and Gnome interact with the community. Disregard for portability, feature creep, the way they attempt to monopolize their respective 'markets' and the way they treat everyone that disagrees. Those are all worrying. And the company behind systemd and with significant stakes in gnome (RedHat) recently showed how well they treat open source projects that stop being valuable for them as a company.
That's entirely unfair. We contributed a couple of changes to systemd and they went through without problems.
systemd does have a very opinionated code style, but that's not much different from (say) Linux kernel.
systemd does have a very opinionated code style, but that's not much different from (say) Linux kernel.
It seems that "professional designer" means a person who makes changes that are generally bad. Once the UI is perfected, it must continue to change (and thereby become non-perfect) because how else would customers know that they got a new product?
If the professional designer in question really is expected to do something different, such as make usable software, then a review of job performance is sorely needed.
If the professional designer in question really is expected to do something different, such as make usable software, then a review of job performance is sorely needed.
I was only referring to the fact that Gnome developers get such a bad rap for being unfriendly, as the GGP stated.
The link was an interesting read eitherway and I can absolutely understand where the frustration comes from. The users' comments just flew over the developers' heads. Nonetheless it looks more like a breakdown in communication than willfully ignoring with deceitful intentions on the part of the developers in my opinion.
The link was an interesting read eitherway and I can absolutely understand where the frustration comes from. The users' comments just flew over the developers' heads. Nonetheless it looks more like a breakdown in communication than willfully ignoring with deceitful intentions on the part of the developers in my opinion.
There are a lot of issues like that. After a certain point a pattern emerges. I don't have time to find a big list of historical issues. Here are some quick links though.
https://gitlab.gnome.org/GNOME/gtk/-/issues/839
Look at why LXDE switched from GTK to QT.
Take a look at when a bunch of Gnome developers decided theming wasn't okay (as opposed to fixing themes): https://stopthemingmy.app/
Take a look at this bug-request on the transmission torrent client: https://trac.transmissionbt.com/ticket/3685
> I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately.
Take a look at the whole history of client-side decorators, particularly the suggestion that every SDL-based app should implement their own CSD support: https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552...
There's plenty there if you just look around.
https://gitlab.gnome.org/GNOME/gtk/-/issues/839
Look at why LXDE switched from GTK to QT.
Take a look at when a bunch of Gnome developers decided theming wasn't okay (as opposed to fixing themes): https://stopthemingmy.app/
Take a look at this bug-request on the transmission torrent client: https://trac.transmissionbt.com/ticket/3685
> I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately.
Take a look at the whole history of client-side decorators, particularly the suggestion that every SDL-based app should implement their own CSD support: https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552...
There's plenty there if you just look around.
I said this in a sibling comment but, there are also plenty of examples of feature requests that were not rejected:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests?state...
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests?state=me...
If you're going to look at the pattern of historically rejected requests, please also consider looking at the pattern of requests that were accepted.
If you'd like, I can give you a more thorough explanation as to what is actually happening in any of those issues you've linked.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests?state...
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests?state=me...
If you're going to look at the pattern of historically rejected requests, please also consider looking at the pattern of requests that were accepted.
If you'd like, I can give you a more thorough explanation as to what is actually happening in any of those issues you've linked.
Almost none of those are feature requests. I mean yes, the gnome developers do write code, and that code does get merged in. I don't understand what you're trying to prove by pointing that out.
As you can see Gnome is mostly a redhat project these days: https://hpjansson.org/blag/2020/12/16/on-the-graying-of-gnom...
It's not surprising that things get merged when they come from redhat-affiliated developers.
As you can see Gnome is mostly a redhat project these days: https://hpjansson.org/blag/2020/12/16/on-the-graying-of-gnom...
It's not surprising that things get merged when they come from redhat-affiliated developers.
The best way in any open source project to make sure a feature is implemented, is to write it yourself and submit a merge request. I don't think any open source desktop is special in this regard, the same rules apply. I am not sure what you're trying to point out by saying that some developers work for Red Hat, the same rules apply to them. If they want features implemented, they write the code and they submit it upstream. What else should happen here? Should they just stop submitting patches and let upstream stagnate?
>the same rules apply to them
I don't think so. Gnome seems like a bit of an old boys club. I think the post I linked backs that up.
I don't think so. Gnome seems like a bit of an old boys club. I think the post I linked backs that up.
I'm sorry I can't find the link but I remember reading a discussion on a freedesktop gitlab issue tracker in which some developers of other wayland desktops wanted to standarize a wayland protocol extension that everyone but Gnome already used. A Gnome dev showed up and told everyone this is not needed because the problem at hand is solved with dbus in Gnome. Everyone told him that the extension is already widely adopted (not to mention dbus was Linux only at the time and solving this with dbus would cut off any BSD users from that feature). The response was basically 'the only adoption that matters is Gnome adoption and Gnome did not adopt this, so it's irrelevant'.
>dbus was Linux only at the time and solving this with dbus would cut off any BSD users from that feature
I'm sorry but this has never been true during the development of wayland. A quick search shows dbus has been in freebsd since 2004, before wayland even existed: https://svnweb.freebsd.org/ports/head/devel/dbus/Makefile?vi...
The problem with creating additional wayland-only solutions is that they tend to need good, strong implementations in the toolkits first for it to really make sense over a dbus implementation that already exists. (The wayland api is not particularly friendly for application programmers) The person advocating for the protocol is usually the one who has to implement that.
I'm sorry but this has never been true during the development of wayland. A quick search shows dbus has been in freebsd since 2004, before wayland even existed: https://svnweb.freebsd.org/ports/head/devel/dbus/Makefile?vi...
The problem with creating additional wayland-only solutions is that they tend to need good, strong implementations in the toolkits first for it to really make sense over a dbus implementation that already exists. (The wayland api is not particularly friendly for application programmers) The person advocating for the protocol is usually the one who has to implement that.
>I'm sorry but this has never been true during the development of wayland. A quick search shows dbus has been in freebsd since 2004, before wayland even existed: https://svnweb.freebsd.org/ports/head/devel/dbus/Makefile?vi...
Then I must have misremembered something. Thanks for the correction!
Then I must have misremembered something. Thanks for the correction!
The reasoning behind the GNOME UX is described in their HIGs and is quite similar to iOS, with it's pros and cons: https://developer.gnome.org/hig/stable/. GNOME 40 is also developed openly and a lot of live coding is going on right now (see for example https://www.youtube.com/watch?v=P2OhXheV-cw), so if users have UX suggestions there are many ways to contribute and get your ideas out there. You can now also try out the newest GNOME nightlies with GNOME OS, available here or through the "+" button in GNOME Boxes: https://os.gnome.org/
> GNOME 40 is also developed openly and a lot of live coding is going on right now (see for example https://www.youtube.com/watch?v=P2OhXheV-cw), so if users have UX suggestions there are many ways to contribute and get your ideas out there.
Gnome always struck me as a project that doesn't really listen to anyone and just follows their agenda irregardless of how damaging it is to the community.
I find it hard to believe they started listening to the community, but if it's true then I'm really glad they did.
Gnome always struck me as a project that doesn't really listen to anyone and just follows their agenda irregardless of how damaging it is to the community.
I find it hard to believe they started listening to the community, but if it's true then I'm really glad they did.
TL;DR: Gnome devs think phones have superior UI design.
I have been using GNOME 3 daily for a couple of years now. I have gotten used to it, but I still think it is genuinely bad. These minor changes don't address any of my gripes, and in one case makes things ever so slightly worse. Honestly though, I don't think these super minor changes are going to change anyone's mind about GNOME 3.
Back to version numbers, if you are going to make them purely based on date like projects such as Chromium and Firefox have done, why not make the version number a date like Ubuntu does? The major version is meaningless in the normal major version sense and mapping the version number to the release date requires a per-project formula/table.