- 118 Posts
- 508 Comments
1·1 day agoI think it is very likely a few very big components and many, many very small ones.
This is a very common pattern. But that is hard to verify without examining all these components.
I would expect the Fat Head of most used open source projects to make up the vast majority of the open source code included in apps. It is not a common practice to include 1000 small projects into a code base for an app, or even 100.
Not usually 1000. But nowadays apps really do have a lot of dependencies - often more than 100.
An article about this:
https://wiki.alopex.li/LetsBeRealAboutDependencies
Rust apps also have been criticized for this. The thing is that when building a Rust app, every direct and indirect dependency is fetched and built locally. That makes them very visible. But the same happens e.g. with Debian systems with installing C or Python libraries, which bundle many pre-compilef dependencies, which is faster, and not as visible.
If an app includes 50 well-known big projects and 1000 small projects, the sum result can still be that small projects make up for a large fraction of the code.
It does not need to be an even distribution, it can be a “long tail” distribution.
And FOSS code is inherited often. Some years ago, a bug in a string-to-floating point connversion routine was found. This affected, if I remember correctly, PHP. But it turned out that many more languages were affected.
Similar with the TimSort algorithm, which was written by Python’s Tim Peters.
1·1 day agoSounds like hell is freezing over…
But you might have noted that weather patterns are becoming a bit strange recently.
2·1 day agoSo, they are making their own code open source? Did that happen since this announcement in August 2021?
Or are they stating that they want to use publicly available open source code without returning much?
Well, hobbyist projects are surely not the only pillar of the open source systems, and big projects like the Linux kernel matter immensely, too. But the article author does not deny that. He makes a point that the hobbyist projects are very important, too. Without them, there would be very little desktop software. I’d guess that much of KDE is hobbyist-powered.
And apart from that, financial support for projects important for infrastructure is a popular talking point. But I don’t see that happen much. Where are the SW engineering jobs for maintainers and contributors of real time Linux, messaging middleware, things like Ceph and file systems, FLOSS browsers, conference software, and so on? And now there are calls that the FLOSS community should care for security in infrastructure and industrial applications. If this were serious, one could simply pay the people who already do that (and massively hire more of them).
Guix vs Nix will be an interesting example. Nix has a way bigger user base right now but it has the whole Anduril & governance issue.
Guix has a way better configuration language and one can learn in an afternoon enough to use it productively.
What is your experience with guix like?
I am mainly using Guix as a package manager on top of Debian stable (and on top of my Arch install running in a vm). I use it mostly to have a reproducible development environment for my free time projects (which use Rust and Guile), and it works very nicely to that. It is also certainly a nice way to distribute software as source, with very little effort (just putting the own package definutions into a channel repo).
Does getting away from systemd affect things?
I have also started to run it directly on my PC as a base system. After replacing the NVidia GeForce card with an AMD Radeon one, I had no issues.
The configuration and init system work well - the only thing I would have to do is to write my own stumpwm(*) init script, which I didn’t have time for, so I use, as a fallback, i3wm and Gnome or XFce2, what I use at work, too.
(*) Stumpwm is a highly configurable tiling window manager written in Common Lisp. Similar to i3, but using key chords, and window manager actions are just lisp functions one can program and extend - they are called via key chords like Emacs commands.
In respect to the init systems, I have to confess that I am mostly agnostic. As long as it works, I am fine. I think Guix is the more modern and better approach.
The insight that a majority of open source projects are small contributions by hobby developers, and that it is their summed joint effort what matters, is very interesting.
This is part of a discussion that FLOSS development should be “funded better” to secure digital infrastructure.
What if the majority of contributors
(1) are not motivated by money in the first place, and
(2) don’t have time to work more?
Another thought: I think that one reason why the proportion of open source code grows is also software quality:
Companies would love to own all their code. So, when they employ people who work on proprietary code, the amount of proprietary code should grow, shouldn’t it?
Except that companies have mostly very short-term goals. And this affects quality: A lot of proprietary code has quite shit quality and is not really maintainable. Which has the effect that either the project dies, or becomes very slow to develop further, because of tons of technical debt.
FOSS projects do not have this constraint on short-term returns, so they often have better quality. Which makes it more likely that these projects live and prosper a bit longer. The short-term difference might not be even large - but the process goes year for year, round for round, and it becomes an evolutionary advantage.
In the end, everyone uses that Finnish students former hobby kernel project, and nobody uses Windows 95 - or wants to use its shitty successors.
(And this is why I also think that Guix will win in the long term: The capability to automatically re-produce all components of a program or system from freely available source is, in the long run, an overwhelming evolutionary advantage.)
Here a summary on Guix I posted a while ago:
But also one can’t rewrite many many complex apps by themselves.
Well, ressources are limited. Especially the amount of stuff other people will do for free in their free time.
My point is it wouldn’t be an issue as much if there wasn’t as much fragmentation. If it was easy to write for both qt and gtk at once then people wouldn’t have to complain about one or the other all the time.
Specifically with this, I don’t see the issue. Qt apps run fine under GNOME and vice versa.
But sometimes unification across the desktop is something some people want.
Yeah but these same people are not going to do anything about it.
In theory, it would be nice to get some solid public funding for making desktop apps more accessible. With our rapidly aging population in Japan or large parts of Europe, that would absolutely make sense. But I don’t see the job offers for SW engineers to do that.
I don’t think you can just invalidate what I’m saying with the just go write it then.
Well, I get that you want that.
But who should do that? On whoms time? With which money? Or for free?
Even things like the real time Linux project, which is extremely relevant for industry (including defense) is not funded in any sensible way.
Myself, I am an expert in signal processing and renewable energy topics. It is extremely relevant for energetic independence of Europe, and climate protection. That’s not funded either. What is funded instead are “audio sound design” for combustion engine cars (that is, artificial simulation of engine noise). And this is bad politics - not something FOSS developers can solve by putting in more work for free.
Now there are wishes that “open source developers” put more (free) work into software security. Who exactly should do that?
I think most desktop stuff like KDE is done by people in their free time. They already do great work, including in the domain of UI. The negativity you transpire is unwarranted. These people do A LOT.
These people have a life outside programning, other responsibilities, and other things to do. Complaining about them not doing even more work will not motivate them.
Lots of foss projects that look ugly and are not designed with ui in mind because it’s made by devs who are used to doing lower level stuff.
Maybe I am one of these developers because my domain is signal processing.
I don’t care. I write mostly CLI apps.
Plus the fragmentation of qt and gtk.
I don’t care whether something is qt or gtk. I use what fits me. I might write a GUI in Swing or,JavaFX because it fits nicely with Clojure or Common Lisp on the JVM, or I might write a Rust app with a Racket GUI because it is actually native and cross-platform. It is so liberating not having to deal with corporate bullshit.
It is not that I am an enemy of aesthetics. Actually, I like to do art! But I do that in wood and metal and other materials - not on the computer.
Winning would be easily building applications that could be native across DEs and actually look nice.
And about winning and having apps that suit your taste: Go ahead and write them. Scratch your own itch - that’s how great FOSS software is created. But don’t expect from others to spend THEIR free time on things YOU want. In return, you can do anything you like.
Depends on the license.
And yes, you could say that the relationship between companies and open source contributors is a bit parasitic at times. But a part of them don’t care because for a start, they are not motivated by money to write open source software.
Nail on head! Exactly!
Here a summary I posted a while ago:
I think that one reason why the proportion of open source code grows is software quality:
Companies would love to own all their code. So, when they employ people who work on proprietary code, the amount of proprietary code should grow, shouldn’t it?
Except that companies have mostly very short-term goals. And this affects quality: A lot of proprietary code has quite shit quality and is not really maintainable. Which has the effect that either the project dies, or becomes very slow to develop further, because of tons of technical debt.
So, the company eventually will resort to rewrite that project. But that is like walking on a threadmill; it always takes a long time until a rewrite of an old project matches the predecessor projects features and stability. And the current GenAI craze will only make that threadmill rotate faster…
FOSS projects do not have this obsessive constraint on short-term returns, so they often have better quality. Which makes it more likely that these projects live and prosper a bit longer. The short-term difference might not be even large - but the process goes year for year, round for round, and it becomes an evolutionary advantage.
In the end, everyone uses that Finnish students former hobby kernel project, and nobody uses Windows 95 - or wants to use its shitty successors.
(And this is why I also think that Guix will win in the long term: The capability to re-produce all components of a program or system from freely available source is, in the long run, an overwhelming evolutionary advantage.)
I think that one reason why the proportion of open source code grows is software quality:
Companies would love to own all their code. So, when they employ people who work on proprietary code, the amount of proprietary code should grow, shouldn’t it?
Except that companies have mostly very short-term goals. And this affects quality: A lot of proprietary code has quite shit quality and is not really maintainable. Which has the effect that either the project dies, or becomes very slow to develop further, because of tons of technical debt.
FOSS projects do not have this constraint on short-term returns, so they often have better quality. Which makes it more likely that these projects live and prosper a bit longer. The short-term difference might not be even large - but the process goes year for year, round for round, and it becomes an evolutionary advantage.
In the end, everyone uses that Finnish students former hobby kernel project, and nobody uses Windows 95 - or wants to use its shitty successors.
(And this is why I also think that Guix will win in the long term: The capability to re-produce all components of a program or system from freely available source is, in the long run, an overwhelming evolutionary advantage.)
Another aspect is that re-installing systems every few years prevents them from becoming messy. You can tidy your system up yourself if you know what you do, and keep detailed record of changes, but most people don’t do that.
2·4 days agoCopilot told him: “you are absolutely right!”
Don’t know exactly, but I heard you can use clonezilla to move it into a vm image. That way, it is not any more bound to your current hardware and you can use it later if you need to access anything.
I would agree with that.
Especially, “being 70%” finished does not mean you will get a working product at all. If the fundamentale understanding is not there, you will not getting a working product without fundamental rewrites.
I have seen code from such bullshit developers myself. Vibe-coded device drivers where people do not understand the fundamentals of multi-threading. Why and when you need locks in C++. No clear API descriptions. Messaging architectures that look like a rats nest. Wild mix of synchronous and async code. Insistence that their code is self-documenting and needs neither comments nor doc. And: Agressivity when confronted with all that. Because the bullshit taints any working relationship.