Raspberry Pi Forums

If only Linux would have stayed away from bloat better.

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.

Unfortunately we are forced to use it for now,...

...as most of the software development targets this OS, attempting to treat it as a Desk Top operating system

CarlRJ wrote:...]There is a version of UNIX that is a great desktop operating system, by the way - it's called Mac OS X. So many years were heralded as "this is the year of Linux on the desktop", but Mac OS X got there first, and Linux still hasn't made it there in any real volume. And I don't feel in any way forced to use UNIX and Linux - rather I feel incredibly lucky to get to use such a well-designed operating system every day....

gkreidl wrote:

CarlRJ wrote:...]There is a version of UNIX that is a great desktop operating system, by the way - it's called Mac OS X. So many years were heralded as "this is the year of Linux on the desktop", but Mac OS X got there first, and Linux still hasn't made it there in any real volume. And I don't feel in any way forced to use UNIX and Linux - rather I feel incredibly lucky to get to use such a well-designed operating system every day....

http://www.techrepublic.com/blog/10-thi ... than-os-x/

This is one area of OS X that I simply can't figure out. Why didn't Apple just migrate the Linux coreutils over to OS X? There are projects aimed at getting coreutils to compile on OS X, but it would have made more sense to have this by default. The coreutils package is a huge toolkit that contains nearly every basic command you need. OS X had to reinvent that wheel.

CarlRJ wrote:

gkreidl wrote:

CarlRJ wrote:...]There is a version of UNIX that is a great desktop operating system, by the way - it's called Mac OS X. So many years were heralded as "this is the year of Linux on the desktop", but Mac OS X got there first, and Linux still hasn't made it there in any real volume. And I don't feel in any way forced to use UNIX and Linux - rather I feel incredibly lucky to get to use such a well-designed operating system every day....

http://www.techrepublic.com/blog/10-thi ... than-os-x/

Interesting list. Some valid points, and some fatally flawed. He complains:

This is one area of OS X that I simply can't figure out. Why didn't Apple just migrate the Linux coreutils over to OS X? There are projects aimed at getting coreutils to compile on OS X, but it would have made more sense to have this by default. The coreutils package is a huge toolkit that contains nearly every basic command you need. OS X had to reinvent that wheel.

Oh. My. God. Seriously? This guy thinks Apple reinvented the wheel? Mac OS X, being partly based on FreeBSD, contains most of the FreeBSD "userland" (the contents of /bin, /usr/bin, etc.). Largely the same utilities found in GNU's coreutils, except these ones have their origins in BSD going back to the 70's and 80's and Bell Labs before that -- GNU COREUTILS REINVENTED THE WHEEL BY COPYING THESE BSD UTILITIES AND THEIR AT&T COUNTERPARTS. Like I was saying, there are a whole bunch of Linux fans who don't understand history and think Linus Torvalds and Richard Stallman said, "Let there be light" and created the world. That's not the way that it happened.

Heater wrote: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.

Heater wrote:Sometimes I forget which OS I'm using (Yeah, been using Win 10 a lot these past two months, God help me).

GNU COREUTILS REINVENTED THE WHEEL BY COPYING THESE BSD UTILITIES AND THEIR AT&T COUNTERPARTS. Like I was saying, there are a whole bunch of Linux fans who don't understand history and think Linus Torvalds and Richard Stallman said, "Let there be light" and created the world. That's not the way that it happened.

contradictory?

I think biggest kludges in popular Linux distributions are D-Bus, PulseAudio and NetworkManager.

CarlRJ wrote:

gkreidl wrote:

CarlRJ wrote:...]There is a version of UNIX that is a great desktop operating system, by the way - it's called Mac OS X. So many years were heralded as "this is the year of Linux on the desktop", but Mac OS X got there first, and Linux still hasn't made it there in any real volume. And I don't feel in any way forced to use UNIX and Linux - rather I feel incredibly lucky to get to use such a well-designed operating system every day....

http://www.techrepublic.com/blog/10-thi ... than-os-x/

Interesting list. Some valid points, and some fatally flawed. He complains:

This is one area of OS X that I simply can't figure out. Why didn't Apple just migrate the Linux coreutils over to OS X? There are projects aimed at getting coreutils to compile on OS X, but it would have made more sense to have this by default. The coreutils package is a huge toolkit that contains nearly every basic command you need. OS X had to reinvent that wheel.

Oh. My. God. Seriously? This guy thinks Apple reinvented the wheel? Mac OS X, being partly based on FreeBSD, contains most of the FreeBSD "userland" (the contents of /bin, /usr/bin, etc.). Largely the same utilities found in GNU's coreutils, except these ones have their origins in BSD going back to the 70's and 80's and Bell Labs before that -- GNU COREUTILS REINVENTED THE WHEEL BY COPYING THESE BSD UTILITIES AND THEIR AT&T COUNTERPARTS. Like I was saying, there are a whole bunch of Linux fans who don't understand history and think Linus Torvalds and Richard Stallman said, "Let there be light" and created the world. That's not the way that it happened.

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.

#include <stdio.h>

int main(int argc, char **argv)
{
 puts("Hello World, Huge aye!");
 return 0;
}

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.

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.

...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.

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).

Now compile it with gcc and see what you get. It is prety huge for what it does

pi@raspberrypi3:~ $ cat hello.c
#include <stdio.h>

int main(int argc, char **argv)
{
 puts("Hello World, Huge aye!");
 return 0;
}
pi@raspberrypi3:~ $ gcc -Os -Wall -o hello hello.c
pi@raspberrypi3:~ $ strip hello
\pi@raspberrypi3:~ $ls -l helloc
-rwxr-xr-x 1 pi pi 2992 Aug 27 16:57 hello

There is nothing wrong with targetting a specific subset of OSes,....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.

Heater wrote:DavidS,
OK. I get this on a Pi 3:

Code: Select all

pi@raspberrypi3:~ $ cat hello.c
#include <stdio.h>

int main(int argc, char **argv)
{
 puts("Hello World, Huge aye!");
 return 0;
}
pi@raspberrypi3:~ $ gcc -Os -Wall -o hello hello.c
pi@raspberrypi3:~ $ strip hello
\pi@raspberrypi3:~ $ls -l helloc
-rwxr-xr-x 1 pi pi 2992 Aug 27 16:57 hello

Less than 3K. Not bad. Of course that is the ELF file size. I suspect it takes less space in memory once running.

What are you compiling on such that the executable file is 1K?

I would not call GTK a "cludge". It's an abstraction layer for graphical stuff. It makes writing programs for X11 easier. It enables code using it, like GIMP, to be portable to other operating systems. Of course if you don't care about allowing more people, using different systems, to use your code it's an overhead. But the why use X11? You probably don't need the features it provides, it's an overhead, just write to the frame buffer. Err, ..see below.

I would not call the frame buffer device a "cludge". Again it enables code using the frame buffer to be used on different architectures with different graphics cards. I have code that uses GLES and the Qt library that runs just as well on a Pi or a PC. Thanks to the frame buffer device. Again, perhaps if you don't care about the usability of your code it's an overhead.

No idea about FLTK. I suspect the same applies.

Write code to the raw X11 API if you like. I don't know why you would want to make the extra work and complexity for yourself for little gain. Or limit the platforms your efforts can run on. It's like writing in assembler when we have pretty efficient high level languages.

There is nothing wrong with targetting a specific subset of OSes,....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.

I think this is a good point. There is no way I'm going out of my way to try and target everything. But if with use of GTK, SDL, Qt, whatever I can reach 99.9% of people in the world that is quite OK for me. I'm not about to try and cover RISC OS or whatever obscure thing a few people maybe using out there.

As long as what ever toolbox cals you use are confined to a few files, that are only the system specific stuff, it should be easy to port.

And again XLib is supported on way way more systems than any of those toolkits.

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.

Quite so. Thing is, things end up running on different platforms because users of those platforms want them to. Take node.js as an example. Originally node only ran on Linux/Unix, basically POSIX, systems. People wanted it to run on their Windows so they stepped up and made it so. It helps a great deal if the program is written to some common API, like GTK, QT, SDL, etc. If the users of whatever obscure OS don't want to do that then they have to go without.

But you raise a serious point. We have had computers around for half a century and more. And still today it's not possible to write a program and have it run on any machine with any OS. Once you get past "Hello World" it gets tricky. Anything graphical and you have a problem.

This inefficient and scandalous situation perpetuates because all vendors want to lock in their customers to their systems.

Ah well.

There are a lot more platforms out there that support XLib than GTK or QT. And it is a lot easier to port XLib to other OSes than it is to port GTK or QT to other OSes.

Thus writing something to dynamicaly link against XLib is more portable than writing something with these toolkits.

If that were truely all that the framebuffer device did I would agree.

I do not want to limit my code to the few platforms that support the toolkits that you would recommend. XLib is more widely supported than any of them (with the possible exception of FLTK).

Heater wrote:DavidS,

I'm not sure what you mean by "inline puts". The output of puts() may go to a console, a file, a socket, a serial port. Depending on how I run the program. The compiler correctly generates a call to puts(). That means I can use something other than libc if I want. Or even provide my own puts() function in a module I link to. Also it makes the code smaller

I don't know about a 1K executable or 688 bytes executable file size. Makes no odds. The code generated is only 5 instructions plus whatever it takes for the string. I bet this takes only tens of bytes in memory at run time.

There are a lot more platforms out there that support XLib than GTK or QT. And it is a lot easier to port XLib to other OSes than it is to port GTK or QT to other OSes.

True enough. But what if I want my program to run where there is no XLib? Say Windows or Android. Or perhaps an embedded system with no Windows at all, just a frame buffer, or what about systems not even running Linux with no XLib and no frame buffer?

XLib is not a cross platform solution. Things like Qt and GTK are.

Thus writing something to dynamicaly link against XLib is more portable than writing something with these toolkits.

Not thus at all. See above.

If that were truely all that the framebuffer device did I would agree.

What does the frame buffer device do that you think it should not do?

I do not want to limit my code to the few platforms that support the toolkits that you would recommend. XLib is more widely supported than any of them (with the possible exception of FLTK).

How are you going to run your program on Windows without a X Window manager installed? Might as well use Qt and skip that.

DavidS wrote:Linux itself is a great system. That is Linux (which is a kernel) and the GNU CoreUtils (or other equilivent). Also the X Windowing System is a great GUI, and OpenGL is a great graphics library. There are even some very good Window managers.

It is possible to set up an entire Linux System with kernel, CoreUtils, a shared C library, X11, a desktop enviroment, OpenGL, and the most used day to day programs in under 2MB of disk space. Though once you add GCC things begin to get huge, or adding this toolkit, that toolkit, this support lib, that support lib, etc.

GNU+Linux+X11 is great, it is everything that is now required on top of that that is an issue.

So my hat is off to Linus for his kernel, and to Richard Stallman for founding the GNU project that provided much of the user space programs used in Linux.

==========================================

While Linux provides the most supported kernel today, there is also MINIX 3 now. In many ways MINIX 3 is a better designed kernel, with a mostley BSD userspace. And best of all it uses CLang for its C compiler.

MINIX as of version 3 is able to support shared libraries, and as such anything targeting Unix Like systems can be ported with out to much effort.

=========================================

Linux is the kernel that brought us very much. It was the open source alternative when BSD was having leagle trouble, and the Hurd kernel had not gotten off of the ground. There is a lot of positive to say for Linux.

The puts(); function is a special case, that is equilivent to sending fputs to the console.

pi@raspberrypi3:~ $ gcc -static -Os -Wall  -o hello hello.c
pi@raspberrypi3:~ $ ./hello
Hello World, Huge aye!
pi@raspberrypi3:~ $ ./hello > temp.txt
pi@raspberrypi3:~ $ cat temp.txt
Hello World, Huge aye!

The only to write to a file from puts(), is if the OS redirects the output, and that hase nothing to do with the program calling puts().

Most of the time we may have more than enough, as most software is somewhat small, and running idle 99.99% of the time. Though that one task that takes a lot of RAM and pushes the CPU to the limit will be the one that all the others make worse, either because of running out of memory and having to page out to disk (slow slow), or because they take away that small bit of time that makes the difference between it being usable and not.

QT or GTK without any support? Just an HW framebuffer? Never heard of that, interesting.

Heater wrote:DavidS,

The puts(); function is a special case, that is equilivent to sending fputs to the console.

This is not so. From the ISO C standard "puts() writes the string s and a trailing newline to stdout."

Like so:

Code: Select all

pi@raspberrypi3:~ $ gcc -static -Os -Wall  -o hello hello.c
pi@raspberrypi3:~ $ ./hello
Hello World, Huge aye!
pi@raspberrypi3:~ $ ./hello > temp.txt
pi@raspberrypi3:~ $ cat temp.txt
Hello World, Huge aye!

The only to write to a file from puts(), is if the OS redirects the output, and that hase nothing to do with the program calling puts().

Exactly. So the operating system decides where the output goes. You have to make a call to the OS. You cannot in line it.

Most of the time we may have more than enough, as most software is somewhat small, and running idle 99.99% of the time. Though that one task that takes a lot of RAM and pushes the CPU to the limit will be the one that all the others make worse, either because of running out of memory and having to page out to disk (slow slow), or because they take away that small bit of time that makes the difference between it being usable and not.

I do agree. That is why it makes no sense to be working hard to optimize most code for time and space. If on the other hand you have code that takes lots of RAM and sucks CPU performance then perhaps it deserves looking at. A graphics engine or example. Especially if it is code that expected to be running for long periods or all the time on your system.

QT or GTK without any support? Just an HW framebuffer? Never heard of that, interesting.

Certainly people have built embedded systems with no Linux or whatever and tweaked Qt to write directly to their hardware. That means the same code can run on such a system or on Windows, Mac, Linux.

Do you have an example of a program written to XLib that I can compile and run under Windows with whatever XLib library I need to install?

/************************************************
 * Compile with:                                *
 * gcc xwin0.c -o xwin -L/usr/X11/lib -lX11     *
 ************************************************/

#include <stdio.h>
#include <X11/Xlib.h>

int evtlp(Display *ds);


int main(int argc, char **argv)
{
  Display *ds;
  int screen;
  Window myWin;

  if (!(ds = XOpenDisplay(NULL))) {fputs("No Connection to X",stderr); return 1;}
  screen = DefaultScreen(ds);

  myWin = XCreateSimpleWindow(ds,RootWindow(ds,screen),0,0,400,400,1,WhitePixel(ds,screen),BlackPixel(ds,screen));
  XSelectInput(ds,myWin,ExposureMask | KeyPressMask);
  XMapWindow(ds,myWin);

  evtlp(ds);

  return 0;
}


int evtlp(Display *ds)
{
  XEvent evt;

  while(1)  XNextEvent(ds,&evt);

  return 0;
}

PeterO wrote:Is there a point to this diatribe ?
PeterO

PeterO wrote:Is there a point to this diatribe ?
PeterO

DavidS wrote:If only Linux would have stayed away from bloat better.