Heater wrote:DavidS,
If only Linux would have stayed away from bloat better.
You are often saying such things. I always wonder what you mean. I take is as meaning that you think there is code in there that is unnecessary or bigger than it need be. Well, what is it you would remove?
Linux systems can be pretty small. I have been using it in small embedded systems for well over a decade now. That's how it ends up in tiny embedded systems like this:
https://www.kickstarter.com/projects/on ... d-by-linux
Certainly it may never be pared down to the size of a RISC OS, Amiga OS, GEM etc. But then it has an awful lot more functionality in it.
And finally, who cares if it's bigger? Memory is huge, now a days. Also very cheap, small, fast and low power consumption. A basic Linux install takes up a fraction of any media I boot it from. It takes a small fraction of RAM when running.
Last I looked at it the kernel source is pretty good, able to be compiled in under 64KB if you do not need much for hardware support. A lot of the GNU userspace is pretty good as well.
Though some things are unneededly large, like many of the hardware supporting kernel modules (46KB of code, and 21KB of data to drive an SB16 sound card, REALY?, etc...).
Then there is the GNU GCC toolchain (which includes support for many more languages than just C). It takes multiple MB of disk space, and that is configured with only bintools, and the minimum for ANSI C and C++, no extras.
Take also the example of:
Code: Select all
#include <stdio.h>
int main(int argc, char **argv)
{
puts("Hello World, Huge aye!");
return 0;
}
A program that if compiled oprimaly would have 8 instructions for init, four instructions to set up for the call to the shared lib (LibC, or what ever the particular linux uses), a branch with link, and 3 instructions to clean up and return. Add to that the data for the string, and the ELF linking information, you have a hello world program that is less than 1KB,
Now compile it with
gcc and see what you get. It is prety huge for what it does.
Just look at the workarounds that we need to use in the way things are done in Linux. Thing that could be done directly in Amiga OS, DOS, RISC OS, and even Windows. Though we find weird workarounds to implement features that the end user expects though is not well suited to a Unix like system.
You will have to give us some examples of "weird workarounds". I can't think of any.
GTK, FrameBuffer device, FLTK, the shared C library, etc.
The shared C lib is a good thing. It is only a kludge when used because the inturupt/trap/swi interface does change, so the compilers can not support simple compiled kernel calls.
I am playing with writing for XLib, as it is the X11 with out the kludge. Though every one keeps telling me I should use the kludge. This turns me off to Linux (and unix in general).
Unfortunately we are forced to use it for now,...
What do you mean "Unfortunately" and "forced" ?
I was over the moon when I deleted Win 95 from my PC's and replaced it with RedHat back in 1997 or so. I have been very fortunate in not having to use Windows ever since.
Certainly nobody "forces" you to use Linux.
I was just making a point. I actualy like n*x systems, and use them as desktop systems even though I know that is not where they truely excel.
My point was that most software is developed to target a small subset of OSes, even in cases it would be very easy to make it truely portable. I often run across software that clames to be portable, though requires this lib, that toolkit, etc. That is not true portability, keeping anything system specific in a couple of SMALL source files, and making it very simpleto replace the system specific stuff is how you go truely portable.
Using these libs and other things just makes that much more that needs to be ported to port a program. There are still some systems in use that do not support dynamic linking, so the extra libraries would have to be staticaly linked to the applications.
...as most of the software development targets this OS, attempting to treat it as a Desk Top operating system
Actually I don't think that is true. An awful lot of software is written for Unix, or should I say POSIX, and is easily run on many other systems beside Linux.
You are agreeing with me. As I stated, these things are in part as it is a unix alike. The unix alikes make up a small fraction of what is out there.
Though yet not many programs are written for anything else. And those that are are often limited to the few systems that have toolkit x, or interpreter y.
There is nothing wrong with targetting a specific subset of OSes, in fact it is a good thing. This is what keeps the coding wars alive, and should encourage every one regardless of OS to attempt to outdo what is being done on the competing OSes.
But what I'm seeing today is that there is a lot of stuff that runs everywhere, Win, Mac and Linux. For example I have in daily use: Chrome, Firefox, Visual Studio Code, Virtual Box, GIMP, Lazarus, qtcreator, Python, node.js, etc, etc. Sometimes I forget which OS I'm using (Yeah, been using Win 10 a lot these past two months, God help me).
And you list a good number of programs that are stuck to the limited number of OSes,
until porters do a tone of work getting other OSes to have what is needed to support these applications. It does not make very good sence to say that programs that run only on a small subset of OSes run on a lot. Most of those need either Win32/Win64 or a unix like enviroment to be present on the target system.
