Linux Developers Asked To Distance Themselves From RMS

[zester]

I don't get what avoiding GPL or LGPL code has to do with refactoring. Maybe that wasn't the intention, but with the part I quoted and some other pieces later, it sounded A LOT like you are trying hard to avoid the GPL, and also makes me wonder why do you keep the Linux kernel instead of using Minix or a BSD.

Avoiding the GPL/LGPL wasn't exactly intentional at first it just worked out that way, and I figured why not just go with it, and create a system that is Open Source and friendly to all developers regardless of there preference for OSS or Proprietary Code.

Refractoring in my case is far more broad, as almost nothing on my system even resembles traditional Linux, the first screenshot is the root directory.



Linux From Scratch, has 50+ packages and that just for a Basic Command-line Distro. My package count is at 32 and even includes Wayland
and everything needed to build an Application Development Toolkit comparable to Qt. Those 32 packages provide everything needed to build a full desktop environment, and 99% of it is cross-platform.


Supports: Windows XP, Vista, 7, 8, Linux, Mac OS X, FreeBSD
iOS, Android, Blackberry QNX.

x86, x86_64 and Arm

Minimum system requirements: 75 MHz CPU and 8 MB RAM



Lastly I want to build a better distro not a crippled one "Minix and the BSD's" kernels are not on the same level as the Linux kernel.

[zester]

Maybe because 78 lines and 4 headers is too much for "true", or 124 lines/7 headers for "tty"?
No, I'm not joking: that's the linecount (wc -l) from coreutils 8.22.
In toybox, those commands are 21 and 32 lines, respectively--including the kconfig information.

(Both include standard copyright notices, wihitespace, and so on.)

I like the comparison of code bloat given by the author of linenoise https://github.com/antirez/linenoise

Line editing with some support for history is a really important feature for command line utilities. Instead of retyping almost the same stuff again and again it's just much better to hit the up arrow and edit on syntax errors, or in order to try a slightly different command. But apparently code dealing with terminals is some sort of Black Magic: readline is 30k lines of code, libedit 20k. Is it reasonable to link small utilities to huge libraries just to get a minimal support for line editing?

linenoise is Under 1,000 lines of BSD license source code.

[monraaf]

Yellow and blue make green...... no, Blue and yellow make green.

Merry Christmas kiddies! More pics please!!

[mrugiero]

I am doing something related. Granted it has nothing to do with this story or RMS. Mine is more of a re-factoring attempt.
There isn't any GPL or LGPL code with the exception to the Linux Kernel.

I don't get what avoiding GPL or LGPL code has to do with refactoring. Maybe that wasn't the intention, but with the part I quoted and some other pieces later, it sounded A LOT like you are trying hard to avoid the GPL, and also makes me wonder why do you keep the Linux kernel instead of using Minix or a BSD.

Maybe because 78 lines and 4 headers is too much for "true", or 124 lines/7 headers for "tty"?
No, I'm not joking: that's the linecount (wc -l) from coreutils 8.22.
In toybox, those commands are 21 and 32 lines, respectively--including the kconfig information.

(Both include standard copyright notices, wihitespace, and so on.)

Still, refactoring exists. You don't need to always start a new project with a different project with a different license (sometimes, with a different license it won't fulfill the same need), but rather fix/rewrite what is wrong.
Also, if they include copyright notices, that might explain up to 20 lines of difference, as the copyright notice for GPL software is usually big. That's not what counts, as in the moment you know it, you cease to read it, and it doesn't get in the way of maintenance.

[Ibidem]

u could maybe but why would you want to, out of hate against rms?

Maybe because 78 lines and 4 headers is too much for "true", or 124 lines/7 headers for "tty"?
No, I'm not joking: that's the linecount (wc -l) from coreutils 8.22.
In toybox, those commands are 21 and 32 lines, respectively--including the kconfig information.

(Both include standard copyright notices, wihitespace, and so on.)

[gens]

Faster system ? (I don't say it will be faster, but I would really like to see some benchmarks on PTS)

it wouldn't

[zester]

I like gzip, let's me compress single files with the same algorithm as zip files without the extra overhead. when I compress multiple files I usually just pipe the resulting tar file to the compress program so I can pick what algorithm to use since there's a lot zip doesn't support.

My needs are fairly basic in regards to zip, and last I checked via programming I think you have to use libtar-ng for archiving and gzip for the actual compression. That would be an extra step for me with no real added benefit in my use cases. Just a personal choice, and a little bit of lazy.

But other than personal taste I have nothing against bzip2 or gzip.

[pouar]

Why does it always have to be about "hate" is it not possible for others to have a difference in opinion?

If you take the LFS http://www.linuxfromscratch.org/lfs/view/stable/ and in particular the "All Packages" page http://www.linuxfromscratch.org/lfs/.../packages.html

1. Autotools, I use "Premake" (Easyer and More Control)
2. Bash, I use "Lua/Luajit" for most things related. (Lightweight, Easy, More Control)
3. Bison and Flex, I have the "Dragon Book" I normaly use Lemon or Peg (Easyer to use)
4. Bzip2 and Gzip, I use plane zip files (Cross Platform, Easy to Use, Does Archiving and Compression)
5. Coreutils, Everything about CoreUtils in my opinion is outdated and can be replaced with scripting, in my case (Lua)
6. Diffutils, I use Fossil that gives me DVCS, Wiki, Diff, .... in a light weight integrated package.
7. Expect, Not needed for anything other than as a dependence for another peace of software, Scripting is a better alternative.
8. File, Findutils, Gawk not used all that much anymore and Scripting is a better substitute.
9. GCC, GDBM, I use LLVM and its companion packages (are or will be a better alternative).
10. Glibc, I use Musl its smaller, faster and easier to maintain.
11. GRUB, I boot strait from UEFI
....

There are alot of better alternatives to GNU Tools and Library's.

I like gzip, let's me compress single files with the same algorithm as zip files without the extra overhead. when I compress multiple files I usually just pipe the resulting tar file to the compress program so I can pick what algorithm to use since there's a lot zip doesn't support.

[zester]

u could maybe but why would you want to, out of hate against rms?

Why does it always have to be about "hate" is it not possible for others to have a difference in opinion?

If you take the LFS http://www.linuxfromscratch.org/lfs/view/stable/ and in particular the "All Packages" page http://www.linuxfromscratch.org/lfs/.../packages.html

1. Autotools, I use "Premake" (Easyer and More Control)
2. Bash, I use "Lua/Luajit" for most things related. (Lightweight, Easy, More Control)
3. Bison and Flex, I have the "Dragon Book" I normaly use Lemon or Peg (Easyer to use)
4. Bzip2 and Gzip, I use plane zip files (Cross Platform, Easy to Use, Does Archiving and Compression)
5. Coreutils, Everything about CoreUtils in my opinion is outdated and can be replaced with scripting, in my case (Lua)
6. Diffutils, I use Fossil that gives me DVCS, Wiki, Diff, .... in a light weight integrated package.
7. Expect, Not needed for anything other than as a dependence for another peace of software, Scripting is a better alternative.
8. File, Findutils, Gawk not used all that much anymore and Scripting is a better substitute.
9. GCC, GDBM, I use LLVM and its companion packages (are or will be a better alternative).
10. Glibc, I use Musl its smaller, faster and easier to maintain.
11. GRUB, I boot strait from UEFI
....

There are alot of better alternatives to GNU Tools and Library's.

[doom_Oo7]

u could maybe but why would you want to, out of hate against rms?

Faster system ? (I don't say it will be faster, but I would really like to see some benchmarks on PTS)