Is it true that Linux is becoming more and more bloated over time? Will it ever become smaller, or is that impossible?
If you define 'bloat' to mean 'the big quantity of source code in bytes', then yes, Linux is becoming more bloated over time. It will not become smaller because developers and users actually like the 'bloat'.
Sometimes they throw out support for architectures that nobody uses anymore.
As long as there are maintainers, the code will stay. If you don't want it, compile your own kernel -- it isn't as hard as some people think!
>>4
I like how the word maintainer makes it sound as if the thing is in a continual process of collapsing under its own weight. They're like little imps running around to prop-up supports on some ancient yew, or cathedral; the last remnants of a dead or dying culture.
Anyway, version 3.16 (2014) and 4.4 (2016) are more or less still maintained if that's the type of thing you're interested in, and there is nothing stopping you from using an unmaintained version.
>>5
The internal structure of Linux changes over time; there is no commitment for the internals to act as a stable platform for the long-term. What this means is that technologies that directly target internal Linux features needs to be perpetually updated to match the changes when it happens. This is the reason why hardware drivers written for one version of Linux isn't guaranteed to work for later versions of Linux. What is guaranteed is that maintainers cooperate with one another and maintain their specific project to reflect the updated internal Linux structure.
>>6 obvi.
The internal structure of Linux changes over time; there is no commitment for the internals to act as a stable platform for the long-term.
How will they be able to finish the Linux kernel if the platform hasn't been stabilized? What is the estimated completion date of the Linux kernel?
>>8
Linux has had countless completion dates. When a stable version of Linux is published, that version of Linux is complete for its contextual time. When that happens, work continues to update Linux for a later context in time. This is the nature of a general purpose OS kernel that's structured as a monolithic kernel.
>>9 silly.
>>9
Why can't these wannabe "software engineers" (a.k.a programmers) of the Linux kernel finish their work and release a single and final completed version of the Linux kernel? I am starting to suspect that the lack of a deadline is a sinister plot by the programmers to remain employed in Linux development related jobs.
There once was a Daemon named Beastie
Who thought Linux penguins quite tasty
He cooked some like roast pork
On the end of his fork
And baked others in pies like meat pastry
https://forums.freebsd.org/threads/love-if-freebsd-light-up-your-poet-beastie.72986/#post-444892
>>11
You don't understand the fundamental of what is software, you don't understand how this relates to a general purpose OS kernel that's structured as a monolithic OS kernel. All software is subjective towards the needs of the users' subjective context. This means as the users' subjective context changes over time, the users' software is also supposed to be updated to conform towards the user. Now Linux is a general purpose OS kernel and it's structured as a monolithic kernel. As user requirements change, this also means the functionality of Linux is also going to be updated. As a monolithic kernel where everything is aggregated into the monolith, the general internal structure of Linux is also going to go through major changes to support the changing user requirements. This is the nature of any general purpose (very wide user use case) and monolithic OS kernel and Linux is exactly one of this.
To me it sounds like you want a microkernel where the kernel's requirements are minimal by design and therefore the scope for changing requirements remains minuscule.
>>13 subjective.
>>13 Don't feed the troll
>>15 everyone in this thread is a codependent troll, lets be honest.
To me it sounds like you want a microkernel where the kernel's requirements are minimal by design and therefore the scope for changing requirements remains minuscule.
Are there currently any microkernels suitable for desktop use? MINIX is dead at this point.
Depends on how you define Linux. There sure is still a lot very minimalistic distributions but the mainstream ones are quite huge and complex by now. If you are looking for a more conservatice unixlike system you might want to look into the BSDs. You can also build your own without systemd, consolekit, dbus and all that garbage or you could strip down a popular distribution down. You can still get debian down to about 100mb. Admittedly it's not very universally usable then anymore but really rather something for an embedded system that gets updated by switching disk images.
>>18
I'm fairly certain everyone here was refering to the kernel.
>>17
OSX, and DragonflyBSD have hybrid kernels (Haiku, and ReactOS as well, but they aren't suitable iirc). Plan9 has a very small monolithic kernel, but also probably isn't suitable.
>>18
Linux is an OS kernel program.
I know but what would be the point of the kernel getting smaller? Even with most embedded hardware the size is not an issue these days and getting smaller for the sake of getting smaller is kinda stupid. Besides, programs grow. No shit.
Besides, programs grow.
Oh yes. There will be a day when cat and echo have Electron as a dependency.
Linux will never be finished because:
* Linus Torvalds wants a stable job and a good salary.
* Linux Torvalds lives under American jurisdiction, and American spies want to have influence over him to reduce the security of Linux.
>>22
echo is a builtin.
>>24
Where in POSIX does it say that echo must be a built-in?
>>25
Infact it is a builtin AND a native binary on pretty much every system i've seen. The builtin takes precedence unless you specify a path obviously.
>>21
A general purpose OS kernel that's structured as a monolithic kernel isn't going to reduce in size as new versions get published. Someone here is trolling us into debating that Linux should have a final completed version in which there are no more updates to Linux.
>>27
Maybe Linus grew tired of it afterall and wants to end it so he does no longer have to tolerate Kai-Fucking-Sievers?
>>27
It isn't really a debate, he is just saying it over and over again.
These bloat-loving Linux programmers should learn from Ken Thompson:
One of my most productive days was throwing away 1000 lines of code.
>>16 meta-trolling now. p. advanced stuff.
Not only it is bloated like hell, it is full of horrible code that uses goto and other blasphemous things.
>>32
Are you using Linux? What are you using instead of Linux?
>>32
Well it's C. Goto in C is perfectly fine IF and only IF the person writing the code knows what he/she/it/cucumber is doing. IF that's the case it can actually be the optimal solution and improve readability at the same time.
Are there currently any microkernels suitable for desktop use? MINIX is dead at this point.
Isn't the "suitable for desktop use" + "runs on as many platforms as possible" what leads to bloat? seL4 is a microkernel.
It's a least part of the reason i think. If one were passionate enough i am quite certain there would be a metric ton of crap that could be ripped out while having the result still be capable of booting into an useful environment - even a graphical one. It just depends on which kind of graphical ui (aka desktop) is desired. Gnome for example is already dead once you cut systemd (likely the first thing to go if you were aiming for minimalism and very likely a huge offender in relation to requiring kernel bloat on top of that). Messing with the kernel is not needed for that at all.
>>35
Solving many problems with poor abstractions leads to bloat. For the problems you mention busdma, and NeWS are examples of better abstractions even in existing UNIX systems. Beyond this, NeWS has many superfluous features, and missed opportunities for abstraction which might be taken from Morphic-like systems for example. More than this it's not hard to imagine many types of common hardware exposing a common interface. Why not?
>>37
Good point. Abstractions are always kind of a gamble in relation to future developments though.
>>38
Reflexivity (like the meta-object protocol) allows abstraction violation to be integrated into the abstraction. When reifying something essential about the problem or dealing with a (mostly) closed system (arguably like a window system) this becomes less relevant.
I just wonder if the word "bloat" has the specific meaning that those who propose we remove all bloat from our software seem to be insisting it does.
With so many distributions, a number of which claim to be aiming at the minimalist sector of the market, you can see that "no bloat" must mean different things to different people
1. There's Debian, since it's the base to so many distros, some might call debian console minimal.
2. There's distros that aim for "no bloat" in the built from source sense like Gentoo or GNU Mes.
3. There's AntiX, Puppy Linux, and the other minimal linux distros that still have guis but target older hardware.
4. There's ELKS and other Linux targeted at (even) older platforms.
And then there are other philosopers about bloat, like cat-v.org or suckless or bsd or 9front.
And of course it would seem really weird to talk about differing visions of bloat without pointing out both that every version of rnrs begins with "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary," and that each version of rnrs, and mit-scheme in particular, has grown by leaps and bounds over the years.
I think i would be valid to break down "bloat" somewhat like this:
1. Bloat that results from bad design (ie pointless redundancy that could be removed without losing any functionality). This bad bloat.
2. Bloat that results from lack of modularity (ie feature X is not generally needed to make Y work as intended by you but you have to option to avoid it or at least no practical one). This might be bad bloat depending on what level of modularity is deemed reasonable possible.
3. Bloat that results from trying to be technological advanced. This is subjective bloat as it depends entirely on the taste of the person judging. One persons perfectly sufficient is the other persons stone age.
Also maybe:
2a) Bloat that results from using component X that in theory could be modular enough to lose any kind of bloat but where the extend of said modularity would have to be so huge that using it would mean stripping the component down to practically nothing or stripping down would make it equivalent to component Y. This is bad bloat.
2a is what i'd invoke on Debians minimal install (minimal + no package sets selected). In theory systemd could be modular enough to be stripped down the point where it wouldn't be bloat anymore but at that point it would be identical to sysv (or really any kind of simple init system).
>>40
Please stop talking about Linux distributions as if any of them are meaningfully different from one another. They're all the same pig with different lipstick on, and I can guarantee you when you talk like this most of the intelligent posters here will immediately disengage.
>>41
I suspect you'd get more out of asking the converse: How do we write "unbloated" software. I say:
1. Only solve the problems you need to.
2. Using proper abstractions.
If you're not solving real problems at all, you've violated 1. If advanced techniques are required to solve a required problem, so be it. On the other hand if you're optimizing for an issue which doesn't exist you're violating 1. If you're optimizing non-limiting factors to a performance issue, you're violating 1. Libraries are part of your program, if they violate 1 or 2, you do as well. Further an abstraction that is proper to some large class of problems is not necessarily proper to your problem, using libraries can violate 2 even if the libraries are "unbloated".
I don't really want to speak further.
implying all (or most) distros are the same
No, they aren't. Some distros fill a niche (for example, Gentoo, Guix, Alpine, Source Mage Gnu/Linux) and others offer stability and/or a lot of well-maintained packages (Arch/Artix, Debian, Kubuntu). There is also the matter of trust and security; Not all distros have a good track record. Also, maintaining a large catalog of packages takes a lot of effort. That being said, there are a lot of distros that don't offer any meaningful advantages over other distros (which means they are likely worse than others since as I said, it takes a lot of effort to maintain a distro).
>>43
I thought similarly when I was in middle-school, the niche is just lipstick. If you don't want to take my advice it's your loss; I don't care either way.
I am not disagreeing, there is a bit of a problem though: Often times you simply don't know the exact scope of problems to be solved. You rather have a range trying to cover the needs of your userbase as good as possible but hardly any of them will require the whole set of solutions. The ideal case where you can say with certainty that X is in/out of scope doesn't exist. Even thinking of what such a project would look like is bizarre. A static blob with hardcoded everything (any kind of configuration is obviously bloat when can be absolutely sure that every target environment looks the same).
>>42
>most of the intelligent posters here will immediately disengage.
There are none left. See below.
>>43-45
Not a single mention of the kbsd or killumos projects let alone gunug+lunix userland replacements like gentoo/netbsd.
The useful argument is projects like gentoo/netbsd are dead and openrc is still wacky for replacing bsdrc when daemontools does better. A majority of enoch was due to disgruntled bsd devs attempting lunix. A proven bad idea.
Otherwise yes it's just the same bullshit with different package mangers a few special patches and some themeing maybe preloaded mac rules tailored for the distribution packages.
Common bsds are only slightly better there's still tons of overlap and illumoses pull from the same base with a shitty bootstrap. Plan9s pull from the same base and do like the bsd but make it worse not better. Plan9 is going too far for this arguments usecase but it was bumped recently.
Now it's the codependent trolls turn why is this on /prog/.
Interestingly imageboards turned into lunix and textboards into bsd what a shitty pattern.
Bloat is socially constructed. When others demand we concern ourselves with bloat, we should ask what would we be thinking about if we weren't thinking about bloat? Are we being distracted from thinking about that? Does a distraction with bloat keep us working on solved problems? Does a concern over bloat restrict our thinking?
>>46
How did i get lumped into this??? I haven't made a single distro comparsion. At the most i've used systemd as an example of different bloat types.
>>47
The same thing, no, no and no.
At the core i am not really concerned about bloat anyways. What i am concerned about is superfluous complexity. Of course i could be thinking about/doing different things with the time used on this but avoiding complexity usually saves time later on so in the end there's time gained actually.
What happens when noone spends time on "bloat" is quite evident today: Giant heaps of complexity that have tons of bling with no productive value while making it painful to adapt to new usecases or optimize existing ones. On top of enormous resource waste and bad debug abilities in case anything fails.
Bloat --not, lest ye be-- bloated
Often times you simply don't know the exact scope of problems to be solved.
This is probably the hardest problem in software architecture. Having sound principles, and knowing your problem domain helps, but there is no ready made solution here. It requires thinking.
>>46-49 unironically read this as a meltdown followed by attempt to distract from meltdown.
>>52 I see my style hasn't failed yet, in seriousness it's too late to care about anything I posted.
A Djikstra interview: https://invidio.us/watch?v=mLEOZO1GwVc
>>54
Available also from the Dijkstra archive, along with much more material for those so inclined: https://www.cs.utexas.edu/users/EWD/video-audio/video-audio.html
there is no ready made solution here. It requires thinking.
This is one reason why software development is a long, iterative process that costs a lot of money to achieve. OP's thread about Linux having a final version is complete nonsense because of the context of what Linux is.
There is a whole multi-billion dollar industry built around software that will never be finished. Just look at Adobe Creative Cloud and Microsoft 365. They operate on the "subscribe to use" and/or "subscribe for updates" business model, which strongly discourages the finishing of software. If the software were finished, they would not have any more updates to provide, and users would stop paying. To ensure their own survival, they are incentivized to release unfinished software so that their customers would continue to pay $$ in hopes of getting an updated version.
This is one reason why software development is a long, iterative process that costs a lot of money to achieve.
Software takes so long and costs so much because we're busy thinking about how to limit scope? No, that's absurd.
OP's thread about Linux having a final version is complete nonsense because of the context of what Linux is.
Is this a defect of Linux that it can never be finished, or is it just a general property of operating systems? Are there any completed operating systems that I can use?
>>59
It is because hardware keeps changing and operating systems have to support it. If you don't plan to buy new hardware for a while, you can use a longterm release, these receive security fixes for six years after release.
>>58
Software takes long and costs so much because of the nature of solving problems. Solving a problem with software inherently means being able to describe the problem statement and scope in a highly precise manner. It isn't always easy to be able to do this on the sole basis of chatting with stakeholders for a couple of weeks. Having an imprecise problem statement leads to developing a software solution that is likely to be incompatible towards the stakeholder's context.
The good news is that going through the process of producing (well conforming or incompatible) software can increase the contextual understanding on the part of the programmers and system designers. The software developers can further reiterate the process of communicating with stakeholders, producing a software that conforms to the updated knowledge, then applying the software to the stakeholders. This will then produce more knowledge about the stakeholder context allowing the developers to improve their problem statement and problem scope. This software development process can reiterate for as long as needed to increase understanding to the problem statement, this in turn improves the software's ability to solve the stakeholder's problem.
>>60
No, it's because hardware doesn't present a consistent interface, and these bespoke drivers are included in the kernel because it's monolithic, and even excluding the drivers Linux is not complete because the internals and the interface alike are in constant flux as new features are added along with more sophisticated implementations. It grows at such a rate because it tries to solve literally every problem, and to do so using as little in the way of abstractions as it possibly can.
stakeholder
Only body-snatchers use this word; they similarly emphasize that all problems boil down to poor communication. I posit that you sir are a predatory space-alien. Half of software is contracted by Joe six-pack who thinks he wants to make Instagram for deer, and the another third is contracted by body-snatchers like yourself to optimize milking the blood of the innocent (don't pretend like you don't know I know you know). You're looking at maybe a sixth with any problem at all. But if you actually count the problems solved in the crack house of modern software development you might be right, Joe six-pack especially has no fucking idea what might make a good Instagram for deer without seeing it, he lacks this level of abstract thinking, but none of this is essential to the problem.
>>59
In the real world, there is no perfect solution: all real world solutions are a matter of picking and choosing tradeoffs to apply to a problem. This means there will always be problems to go with any fathomable solution. Linux is a general purpose OS kernel that's structured as a monolithic kernel. The monolithic kernel structure implies many kinds of problems and benefits according the the nature of all solutions being a matter of tradeoffs. All software has the nature of being subjective towards the users' subjective context and this means software needs to be updated over time as the users' context changes. Linux is not exempt to this nature of software being connected to users.
>>62
What did you mean by this?
>>63 The customer is usually ignorant of what they want.
>>64 What did I mean by what exactly.
>>65
In fact I would argue that most people don't even want an operating system, they want something to check their facebook posts or run their canvas rendered website for the dog shop they run and take whatever's most accessible to them. Most would never even consider alternatives outside of some quest for novelty.
>>62
Linux's interface is very stable, they have a strong commitment for Linux interface to be stable. Ancient software that targets Linux's interface are perfectly able to run on today's Linux. You can't expect Linux's internal functions to be stable as there is no commitment for the internals to be stable.
>>67
Backwards compatible external interface is not the same thing as a stable interface. Actually backwards compatible is in many ways even worse than stable because this means you can only add new shit.
>>68
The Linux external interface is a stable interface.
In fact I would argue that most people don't even want an operating system ...
What do they want then? A computer screen that acts as a thin client?
>>69
Since when 15.14? https://man7.org/linux/man-pages/man2/syscalls.2.html
>>70
>>70
No, they don't care, it could be and they wouldn't mind, that's the point. The operating system isn't designed to their subjective needs or whatever, in fact it's not designed at all.
>>70
People want a magic box that performs the magical feat of displaying information, watching and sharing videos, and video communication.
>>71
The process of deprecating a Linux syscall is a rare and well publicized process. This means the Linux external interface has always been a stable interface, everybody can rely on the interface to perform as documented, everybody is notified a long time in advance for the event of deprecating a syscall.
The Linux penguin is an infantile logo that makes Linux look like a toy. There is a PR problem. Similarly for the BSD operating systems. Why would anyone use a product made by organizations that associate themselves with demons?
>>72 undesigned heh
>>62
Maybe you could make a case for banishing all architecture specific code to drivers, although I am not sure if it would work. But that's not how Linux is today, therefore new architectural features, and errata from hardware, keeps changing it, even if you ignore the drivers.
>>73
And that's what they get. Linux is used in billions of smartphones and none of their users are complaining that Linux is bloated.
>>1
Linux can only become smaller after it is ported to Scheme.
Linux is used in billions of smartphones and none of their users are complaining that Linux is bloated.
That's because the users are kept ignorant. All they are shown is a shiny user interface that hides all the rotten filth underneath. "If I can't see it, it doesn't exist!"
>>79
Because it is not a real problem. It does not cause any issues. Nobody cares that you think there is too much code. Go do something productive with your time instead of getting upset over something that is proven to work.
Besides saying that "Linux is used in billions of smartphones" is fairly misleading. Of course in a strict sense it is (Linux is really just the kernel) but whole environment is not much like what one would expect at all. Even those parts that are in fact somewhat familiar are usually covered by alternative solutions. It's obvious Google tried to avoid GPL whereever possible and the sole reason Linux being used for the kernel is likely mostly due to missing alternatives at the time.
It is not misleading. We are talking about Linux. Everyone so far in this thread talked about Linux. If you want to talk about GNU/Linux distributions, say so. But don't do this pathetic "akshually, despite everyone understanding that we were talking about Linux, what if we were actually talking about GNU/Linux, wouldn't that distract you for another 80 posts from realizing that I am a useless little piece of shit who is only here to waste your time?".
>>82
Wow, the hostility is strong in this one. All i am pointing out is that Linux in a smartphone context is fully interchangeable and mostly a product of the circumstances. Of course there isn't anyone complaining about it (why would they?) but it still isn't much of an accomplishment for Linux to power Android.
>>82
Oh and by the way: Noone cares about your silly little feelings and wishes. Learn to deal with it.
>>74
So by stable you actually mean neither backwards compatible nor stable, but slowly unstable.
But that's not how Linux is today,
This is the topic of discussion.
Linux is used in billions of smartphones and none of their users are complaining that Linux is bloated.
This is much like billions of people walking on a bridge completely ignorant of its safety. But ultimately these people don't matter. This thread is concerning the engineering of bridges not sociology. The only reason I even mentioned how little the user cares originally (>>66) was exactly for making the point that none of this is about them, they accept what they are given.
>>80
What percentage of the Linux kernel is proven? The CVEs seem to be a counter-example to any meaningful constraints being held. (also trolling is fun.)
>>81
You (the person who keeps mentioning the userland) should be sent to a prison library. If you're reading I hate you. Please, god, read a book instead.
>>85
Of course i am reading. I can tell you with certainty that there isn't any "the person who keeps mentioning the userland" though. It's in your mind my friend. If i were you i might consider the fact that Linux (as in kernel) is a really boring non-topic to most sane persons but then i am not some bitter nerd with an axe to grind also.
As for "reading a book": Why would i do that? I've been there, done that and all such. If i were in your position (i.e. passionate about the size of some codebase) i'd go and do something about it (like trim it down or just write my own version) instead of becoming all emotional ("hating" people that look at it from a different perspective). What do you even expect to gain from it if people were to straight up agree with you anyways? I'll tell you what it would gain you: A whole lot of nothing. Funnily enough that's likely the exact same thing you've done to solved your supposed problem.
>>86
I'm not passionate, I'm just having a good time.
If userland doesn't matter: while(1); and /thread. It's not going to get any safer than that.
>>85
This is a rather convoluted way to say microkernels are superior without saying it lmao.
Not mach though syscall switching is garbage on mach kernels, proven bad design for performance with little to no gains but allowing the monolithic microkernel debate to hold waters it doesn't deserve.