In that talk he called C “the worst language” and said he chose it to troll the industry. How does that support your point?
He also said that you should choose “least privilege” whenever possible. That is precisely the value that Rust brings over C. So how does that talk support the idea that C is more secure than Rust?
I have seen stats that both Linux and ChromeOS have around 3.5% market share.
If ChromeOS continues to converge with proper desktop Linux, I consider it a distro which makes 10%+ possible this year.
The wild card for me is Linux gaming. It may not grow fast but it totally could.
Which had me wondering for the first time I hearing about “The Year of the Linux Desktop”, what percentage do we have to hit for this to be the year?
I don’t really expect us to hit it but, for the first time, I feel like it is possible.
You can do this, and I have, but there can be issues during the switch if you are not careful.
The machine I use as my Jellyfin server used to be Manjaro and is now vanilla Arch ( having migrated it from Manjaro to Arch in place ). It still has a few quirks though. The quirks do not matter for what I use it for ( it is rock solid for Jellyfin ) but anytime I have to reboot or use the desktop, I am reminded. Nothing too serious and nothing I could not fix with a little time of course. That machine is purely functional though and I do not want to spend any time on it. Since my video is all on a second drive, I will probably nuke it and do a fresh EndeavourOS install one of these days. It would be much faster to re-install Jellyfin than to fix all the little warts. The other Manjaro systems I had were replaced with fresh EndeavourOS installs.
Linux is tribal for sure. But the Manjaro issues are real ( as a past user ).
There are many cases where Manjaro causes problems. For example, a package mag already be in Arch but not yet in Manjaro. Or perhaps the Manjaro package is not a high enough version number. If another Arch package requires this first package, in Arch it would grab the Arch package. The Arch package will be maintained over time. In Manajaro, the package is not there and so the AUR grabs it from the AUR as well. Perhaps it is even the Git version with an unclear version number. Over time, the AUR dependency breaks or becomes unmaintained. Even once Manjaro has the package, it may not migrate it because of the version numbers. Now things are broken. This exact thing happened to me on Manjaro where my GIMP ended up using GEGL from the AUR. My system was broken for months.
An even worse problem can happen when there are alternate dependencies. Sometimes in the AUR you will have multiple packages that fulfill a dependency. In Arch, you can see if one is from the actual repos and one is itself from the AUR. Again, if you choose the one in the repos, it will work and stay supports. In Manjaro, neither may be coming from the actual repos in which case it is easy to choose the wrong one. This sets you up to have package conflicts. In Manjaro, I would never know that the other option had now been added to the repos. More than once, I had the dependency that I had chosen break when the other would still have been fine.
Ok, this is getting long and that was just a couple of scenarios.
Suffice it to say, when I used Manjaro, I got the impression that the AUR broke all the time and that using the AUR broke my install from time to time. Now that I use Arch, I do not have those issues and I realize that it was Manjaro all along.
I used to be a huge Manjaro fan. There were many ways it let me down, some of which were just bad governance.
The biggest problem though is the AUR. Manjaro uses packages that are older than Arch. The AUR assumes the Arch packages. This, if your use the AUR with Manjaro, your system will break.
It is not a question of if Manjaro will break but when. Every ex-Manjaro user has the same story.
For me, EndeavourOS is everything that Manjaro should be.
If you are a Linux user and like commercial games, you probably would prefer them to work on Linux.
“Market share” on Linux aligns the vested interest of game makers and Linux game players. If the company thinks it can make money, it will do more to allow games to run, or at least do less to stop them.
As a long-time Linux user, I feel like it says something about the maturity of desktop Linux that it is good enough now for the kinds of users that find LibreOffice insufficient.
I realize that the major point of GIMP 3 is the port to GTK3. That said, I feel like colour spaces are what people have been waiting for and probably the most significant deficiency that keeps GIMP from being treated as a professional tool.
If they are really this close, why not set the GIMP 3 release date for when colour management is ready?
Non-destructive editing will be huge as well. GIMP 3 is really going to be a crazy leap forward. It is going to be amazing to finally get access to all this work that has been walled off for decades.
The bug situation sounds terrible. Honestly though, they should just get 3 out and then make bug fixing the number one job until it gets into better shape.
Not only is it a small team but right now there are basically two different projects ( 2 and 3 ). With only one code base, perhaps the pace of progress can improve.
Hopefully the move to GTK4 is easier.
It says “ready by the end of 2024” so not quite there yet. Still, a very good development for sure.
You can remove the /s.
With GNOME and KDE going Wayland only, it is all but over for X. Qt, GTK, and Electron already work on Wayland so most apps are ready. Cinnamon, XFCE, Enlightenment, and MATE all have Wayland plans now. There are a few compositor libraries that other window managers and desktop environments can leverage.
NVIDIA is slowly getting their act together. Many of the legitimate complainants are being addressed. There are desirable features starting to appear that are Wayland only. Even non-Linux systems are adding Wayland support.
It is hard to believe after so many years but I think that, by Christmas 2024, most Linux users will have stopped using X and maybe even stopped talking about it.
Like the other SVN, the author has been around forever in the Linux space. And yet his articles always come across like somebody that first discovered it a few months ago.
Somehow I find myself rankling at even his smallest editorials as well. Take this one: “Then, there's GCC Front-End for Rust, which can be loaded by the existing rustc frontend, but benefits from GCC optimizations.” Ok, sure, as long as we do not mind losing all the LLVM optimizations. Why not just say that Rust uses LLVM today and that there is a project to allow the use of the GCC-backend as an option? Leave it to the reader to decide which ecosystem or optimizations they prefer as this article is not even about that. It is like he Googled Rust and added everything he could find to the article. I can think of a reason to use the GCC version of Rust with the kernel. If you are using GCC to compile the C parts of the kernel, you also need LLVM for Rust. A GCC based Rust would eliminate that requirement. Presumably this also allows both the C and Rust code to target the same platforms. GCC and LLVM platform support is not the same. Those would be relevant points but neither of those is about “GCC optimizations”.
That is just one example.
Basically, I find his articles to be as misleading as they are informative and that is not what I want from the technical press.
You got out before it answered the question for you. Manjaro will eventually break terribly. It is only a question of when.
How heavily did you use the AUR? In my experience, if you use a lot of AUR packages, Manjaro will break frequently. You probably thought the AUR was way less stable than it is.
I agree with every aspect of this comment
I have the various latest release of EndeavourOS running on a 2008 iMac and a Dell laptop that I cannot remember the model of that is even older.
Look, everybody is entitled to their opinion and I respect yours. I have posted enough that it is just going to look combative and so I think this will be the last one. That said, this feels like the kind of “then why don’t we just allow murder” straw man that gets used when we want to argue emotions instead of facts. Yes, breaking your arm sounds very unfair. Is that a good analogy?
I think a much better analogy would be me signing an employment agreement that places restrictions on my freedoms that I otherwise have as a citizen of my country. Who cares what restrictions. Maybe I cannot drink at work. Maybe I cannot travel to certain countries. Maybe I cannot play video games on the work computer ( even at home ). Maybe I am not allowed to express certain political or religious views with customers. Or maybe there is a public article showing that all our competitors are better than us and I am not allowed to tell customers about that article. Let’s take that last one and assume I am American ( I am not but we need a legal framework we may all know ).
Has my company taken away my 1st amendment right to free speech? If I say something they do not like, they will take away my job and all the income I wanted from it in the future. Is that fair and ethical? It certainly hurts me. How is that not massively illegal under the US constitution? Surely employment law is less important than the constitution. How is it morally ok and not totally against “the spirit” of a free society?
Well, I have not lost any rights. I remain free to say what I want. However, there can be consequences. In this case, they are consequences that I have contractually agreed to. The First Amendment and my Employment Contract are not the same thing and they grant me different rights and impose different obligations. I am free to share the damaging article but, if I do, my employer will stop paying me.
Free Speech Absolutionists may insist that I not be fired for acting against the interests of my employer. Most of the rest of us understand that this os ok as we have to balance the interests of all parties of we want a system that works well overall. We also understand that no rights have been lost.
I see this as very much like that. Red Hat is not adding any new restrictions to the copyright license and, as such, they are granting you full rights as per that license. Legally, Red Hat is granting you the right to redistribute their code when they give you code licensed under the GPL. Simultaneously, they ask me to agree to a subscription agreement ( like an employer asks me to agree to an Employment Agreement ). The subscription agreement outlines what Red Hat will do for me and what I must agree to do in return. I do not have to agree to the subscription agreement. I can CHOOSE to because it offers something I want. In doing so, I may have agreed to some constraints on my otherwise fundamental rights or more general legal agreements.
So, I do not think Red Hat is threatening to break your arm. They do not harm you in any way other than to stop doing nice things for you in the future.
What I see in the reaction to Red Hat is a bunch of people that think they should be able to break their employment contracts but still keep getting paycheques from their employer.
If we still disagree, that is fine. I think this post fairly explains my position.
“Are they….justified”?
Somebody thought the need for a new package manager was great enough to spend time creating one. That person at least must think it is justified.
We, the users, have not chosen just one of the options to be the standard. Does that “justify” that they all exist?
In the short term, the popularity of Linux is certainly hurt by the complexity of the ecosystem and the lack of standardization. As a product, it would see better adoption of it were more standardized. Without writing a book about why, there is no doubt about this. The short version is that, today, Linux is many products, none of which can compete as effectively as one would and all of them are impaired by the confusion this causes.
In the longer run though, it is almost certainly one of the great strengths of Linux. Linux is many products and as a result, it can target and effectively fill almost every niche. That is going to make it very hard for alternatives to compete at some point. Once Linux knowledge and Linux applications ( yes, I know ) become more mainstream, this compatibility between options becomes a strength. I can have my own operating system that is just the way I want it, but it still runs Docker and Stream ( as examples ).
Think of the cereal aisle at the grocery store. If I want to introduce a new cereal ( or pasta sauce or whatever ), coming up with one that has 10 flavours is not going to work ( without immense marketing muscle ). None of them will sell well enough and probably all of them will get pulled from store shelves. I would be better off launching one. However, once I have a mature market position, I can have not just the regular version but the whole wheat version, the honey nut version, the cinnamon version, the holiday version , etc. They will collectively make each other stronger and all potentially sell well ( again, think pasta sauce flavours if that makes more sense to you ).
This is why there was The Tesla Roadster at first and now there are the Model S, Model 3, Model X, Model Y, and maybe the Cyber Truck.
Linux is not a “product” though. It is an Open Source program. While any given Linux distributor ( distribution ) may think like I outline above, collectively the Linux market is fragmented. Linux is a mix of commercial, community, and individual interests all scratching their own itch.
I am super interested in Chimera Linux right now and fairly negative towards Ubuntu. This makes me part of your problem though. Chimera Linux makes “Linux” less predictable, more confusing, and more frustrating for new and potential users. Pushing everybody to Ubuntu would be a better market strategy. That said, I personally want to use Chimera Linux and, while I say that I want Linux to succeed, I also secretly hope that Ubuntu will fail. Chimera Linux uses a package manager used by only one other Linux ( and in fact they use different, incompatible versions of it so really they are unique ). Clearly, my priorities are mid-aligned with the premise of your question.
So, what does “justified” mean in the Linux space.
Red Hat does “subscribe” to the software they ship and fully complies with the terms specified for them to do so. Again, rhetoric completely at odds with the facts.
Let’s be explicit about the “loophole” that keeps getting talked about. What is it?
The GPL outlines a bunch of freedoms that you get when somebody distributes software to you. It does not provide any rights to anybody that has not been given software. Is that the loophole?
Red Hat provides CentOS Stream to everybody and so it, along with all its source code and everything else is available to the public. Only RHEL subscribers have any rights to RHEL because they are they only ones that get it from Red Hat. The public has no inherent right to RHEL, code or otherwise. This is of course compatible with the GPL and not in some nuanced tortured way but of course with its core purpose—to grant freedoms for software that you use ( have been given ). Is that the loophole?
The GPL talks about the rights you have regarding software you have already received—that you use—not software you may or may not receive in the future. Is that the loophole?
Importantly though, we are not talking about an individual package covered by the GPL. We are talking about RHEL, which is a collection of software of which less than half is even GPL licensed. On that basis, I submit that the following text ( extracted from the GPL itself ) might be the “loophole” that you are referring to:
“Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.”
Again, that language is quoted directly from the license.
Is that a loophole? Because it seems like a very specific provision to me. Did the authors of the GPL say that the GPL does not extend to all of RHEL by accident?
Does the fact that Red Hat provides not one but two explicitly free Linux distributions for free including one ( CentOS Stream ) that includes all the work they do on their flagship product with changes often appearing in the free community version before they appear in their paid product sound like a good direction for the OSS ecosystem? Yes. Yes it does. If every company contributed in the way that Red Hat does, the world of Open Source would be dramatically richer.
Does giving cover to other commercial entities not just to collaborate and use the same source code but to shamelessly make exact copies of another product while giving nothing at all back sound like a good direction for the Open Source ecosystem. Well, no actually. Not in my mind. This sounds attractive and beneficial to you?
Based on this episode, I have to say that the GPL itself is starting to come off as less beneficial in mind and less of a good direction for the Open Source ecosystem. The differences between Free Software and Open Source are starting to matter more to me.
Other than having to know Rust, adding Rust to a C code base is not difficult. They play well together.
There is no need to rewrite old code but, once Rust is there, you are free to.
Linux is a bit of a special case as you cannot just blindly use the Rust standard library.
Having to have a Rust tool chain to build with may or may not be an issue.
For some use cases, like BSD or the Linux kernel, platform support is also a consideration.