On Sat, 03 Oct 2020 15:26:51 +0800
Xi Ruoyao via blfs-support <[email protected]>
wrote:

[putolin]

> 
> Perhaps yes.  There are at least two examples, glib logging level
> patch and coreutils i18n patch, in the book.  The upstreams just
> don't like them.  Then should I cry and say "you guys should take my
> patch or you are evil"?
> 

So do you consider LFS the upstream for LFS?  I do and as much you
should be open to working with others rather than spewing animosity at
folks you think are lesser than yourselves. Anyone could be wrong,
including yourselves. This is always the result when ever I post here.

[putolin]

> > Also in a lot of places files on the host system are simply
> > over written.  When that happens you have zero idea where the true
> > problem resides as you don't even know what has just occurred. Nor
> > can you reproduce it.
> > 
> > Another example, updating glibc,  the book states that it is not
> > recommended/can't be done,  That is simply not true.  Maybe that is
> > true for a system that is built "in place" as in LFS, but it is
> > simply not true otherwise.  I reinstall and update glibc quite
> > frequently.
> > 
> > The book in my opinion, is only good for a sequence and little more.
> > When I complete my new build sequence the book will not be relevant.
> > 
> > I am also perplexed by the attitude of some here that the ARM
> > platform is simply not needed and not to be addressed. "We only do
> > x86_64"! You folks hereby missed the platform that many are using
> > for learn from. Why discount a platform that is used in many
> > schools to teach computing. Why not embrace it so people can learn
> > and return work back into the industry? What is the REAL goal of
> > LFS?  
> 
> The status quo of alternative platforms, unfortunately, is almost
> totally "your software, your problems".  Mainline kernel just doesn't
> work.  The device vendors maintain their own kernel code and it never
> keeps up with the mainline (often stays at 5.4 or 4.18, I've even
> seen 2.6). If you complains, the vendor will just say "the system is
> running fine and who cares about the kernel version", or "don't
> messing around, use our distro".  What can we do here?
> 
> 1. Keep the vendor kernel and just build a user space.  It's not
> Linux From Scratch, only "some GNU or non-GNU user space from
> scratch".  After all "Linux" means the kernel, originally.
> 2. Pull the kernel source code from some stupid vendor repository,
> which is based on some ancient kernel release.  Then we can't
> maintain a book as new packages may need new kernel features, and we
> may have to configure the kernel exactly same as the vendor.
> 3. Rebase the vendor's kernel changes to latest mainline kernel.  I
> tried (on a very famous ARM board, and a not so famous MIPS board)
> but I just couldn't even make the kernel boot.  Maybe I'm too stupid.
> 4. Don't care the hardware, just test the book with QEMU.  Then
> what's the meaning of this unusable "port"?
> 

Well, well. By the ARM platform I am talking about Raspberry pi.  The
kernel for it is not so special.  In fact the stock kernel is fine, but
the foundations kernel fork is a bit better as it is tuned to the pi.
Guess what it just work and the only thing one needs to due is to
pull the source from their repo. I have built it many times. Although it
isn't the latest. You rant about the latest software but rail against
the latest Berkley db package and use an ancient package when a more up
to date one is available and is fully functional by YOUR standards. 

I can build all of LFS with only a few changes to the "book". I choose
to use special CFLAGS to get the full potential of using that
platform. In other words it just works. drop grub and pull the kernel
source from the foundations git repo and build. Add the part that is
required to make it boot and you now have it working. Yes it is just
that easy. Again you folks at LFS are just like some old farts that
don't want to change. Look at your animosity. You prove my point.  No
where did I state I was talking about any specific package including
the kernel. As for your issue with the ARM platform board, maybe I
could have helped you get it to work, I don't know one way or the
other.  But I will not help you at all now due to your bitterness.
Again it is exactly what I am posting about here.  You folks attitude.
Keep running folks off it is good for your work here.  I know I have
changed to follow Archlinux rather than here. The only thing I use
from here (now) is the system V init.  I need nothing else.  I could
have been an asset to LFS but you folks don't want that and have driven
me away.
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to