[Dclug] Still Lost in the Linux Labyrinth of Distros
alan at his.com
Mon Jul 16 07:56:41 EDT 2012
On Sun, Jul 15, 2012 at 03:29:28PM -0400, Peter Larsen wrote:
> Yup - 18 months ago. The context of Linus was that the latest dot
> version of 2.6 and 3.0 weren't that far appart. Now from 2.6 back then
> to 3.4 now, that's a different ballgame all together. So I don't feel I
> contravened at all ;)
> I got the distinct notion from reading your posts, that things were
> simply a matter of inserting compiled code and in essence everything
> else didn't really matter.
Oh no. I've had some very bad experiences, grabbing
tarballs, putting them into a subdirectory of /root,
unpacking(so far OK) and then running ./configure. There
is usually something found to be missing, and either
I've already got it<sob>, or what's missing is impossible
to find. Even if that works, the later 'make' usually
dies . . .
> > Generic whine: I have never understood libraries. I pick, quite at
> > random, the file /lib/libmemusage.so out of my /lib directory. What
> > is it, what does it do, who wrote it, what SW needs it?? does
> > anyone know any good information about libraries and library
> > documentation?
I've received several posts with interesting information about
how to discern dependencies among the various libraries, and
I can envision how these methods might help an expert. But
I'm far from being an expert<sob>. I've done some googling
and I think what I need is something like the Stevens-Rago
book "Advanced Programming in the Unix Environment". But
this book is expensive, and since I'm no longer in the
business, shell, or Perl, or Ruby, or LISP will do for
any slight needs I might have.
> $ nm --defined-only -D /lib64/libmemusage.so
> 00000000002040a4 A __bss_start
> 0000000000002990 R __invoke_dynamic_linker__
> 00000000002040a4 A _edata
> 000000000038c338 A _end
> 00000000000025bc T _fini
> 0000000000000d70 T _init
> 0000000000001e40 T calloc
> 0000000000001f70 T free
> 0000000000001ac0 T malloc
> 0000000000002020 T mmap
> 00000000000021b0 T mmap64
> 0000000000002340 T mremap
> 0000000000002520 T munmap
> 0000000000001bf0 T realloc
You are working to converg me to yum! I can tell. But all
them nasty 000000000es? ! ? !
> The question "what software needs it" requires a developer to answer and
> the right kind of developer. The functions listed here is what allocates
> memory dynamically for code. If you only code in interpreted languages
> like Ruby or Perl, this makes no sense to you - but any assembler/C
> programmer out there will instantly know how central and important this
> library is.
Random remark. I retired over a decade ago; back then
processors, altho getting faster, were still amblers; and
storage was at a premium. We wrestled with compression
algorithms and worried about having to swap out . . . many
people here will recall those times.
Half, maybe 3/4 of the stuff I wrote in C I would now write
in Perl or Ruby. We spit on interpreters in those days<g>.
Now things are fast enough, and interpreters have improved
enough, so that lots of work can be done using them.
> No - there's a big different how you implement software from a system
> perspective if you're on a multi-user or single user thing like an
> embedded device. Security too. Even if we can agree to a common file
> structure, we may not agree to the compiler directives to use, features
> to include/exclude, options on how to share/interact with the rest of
> the OS and libraries - and how we want things running secured.
You are absolutely right. And I'm thankful that I am spared
such worries. I am happy to have apt etc manage things for
me, even though various things irritate me at times.
> Take a look at all the "non firefox" things firefox depends on:
> $ rpm -q --requires firefox
(gobs deleted . . . )
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> xulrunner(x86-32) >= 13.0.1-1
> rpmlib(PayloadIsXz) <= 5.2-1
> Each of the above features come with their own set of choices, own
> setups etc. Distributions make life simple for those of us who simply
> want to do out emails, write some text files etc. - all the complexities
> of putting things together, making the balancing act of getting all the
> parts to work together, is left to those with skills that I admire. It's
> too big of a puzzle for me to even try to venture into today.
<G> For me too. I think that you and I agree on everything;
except we view things from slightly different perspectives.
> Exactly. It's why saying "I know Linux" makes no sense to me. It's
Philosophical remark: one could say the same thing about
just about anything, no? Feynman somewhere makes fun of
philosophers who say "Take a brick" or "Take a chair" and
points out that already a brick or a chair is immensely
complicated, each losing or gaining millions of atoms
each second. I think you are making the same point
> different experiences, implementations - even if you're a command line
> monkey like me. Over the last 25 years or so with Linux/Unix I've had to
> learn and get used to about 5 different shells.
Why? I used ?? with Irix, which is how I first got started
with Unix, back in 1990, But by 1994 I was a Linuxer, using
bash, and I never looked back.
> worse when it comes to choices and complexity. There are some who says
> it's the disadvantage of Linux - that there is no one set way to do
> things. To me, it's the opposite. It's the strong side of Linux and the
I agree totally. Now if we could only persuade Mr Kiss of
> Ahh - my world with yum/rpm is a bit more detailed than that. But then,
> I'm not just an ordinary user. Most people I meet have a hard time with
> just "yum search". Luckily there's a gui side to things, that makes life
> easier for the non-techie.
I think you mean, easier for those that can't type. My typing
ain't great, but I still often resent the times I have to
take my right hand from the keyboard and grab the mouse . . .
> partly what makes testing of our code complex today - does it work with
> pam, without pam, with/without selinux, with/without this library etc.
> It's no wonder, testing is automation today ....
Again, I agree. I did lots of 'testing' way back when; but I
only had to test on the system I was working on. I never had
to find users from XXXX using system YYYY and ask them: does
this stuff run OK on your machine?
> the same - you wouldn't know the difference ;) Electronically we can do
> things a lot more secure than in the physical world. I sure prefer doing
> my "shopping" online than physical.
I think you're wrong here. I want physical stores I can walk
into, not just pictures on my screen, vast warehoused everywhere,
and the streets cluttered with UPS and FedEx trucks. But
this is getting into a quite different subject.
> If we had a Fry's here on the east coast I would probably visit brick
> and mortar stores more. Pretty much all my custom build boxes were built
> by parts I ordered online.
I used to pull the covers off machines and stick boards in.
Now I go to MicroCenter and say: I want such-and-such
motherboard, power supply, etc. Atavistically, I still
want a 3.5in floppy slot!
> > Let's agree -- and I hope all dclugers will join us --
> > that if our TeXs or our mutts or even(especially!) our
> > ls-es or our bashes work differently on our different
> > distributions, that we raise our voices in high protest.
> Ohhh - a real distro fight! <sarsasm> Now that would be fun ...
I really hope not. I believe, 'cause I got faith, that my
bash works the same as yours, my TeX works the same as yours,
etc. When that is no longer true, we A L L will have to
back up and take a deep breath; for then anarchy will have been
loosed upon the world.
> Wise words of the day:
> We come to bury DOS, not to praise it.
> -- Paul Vojta, vojta at math.berkeley.edu
Vojta is really scary. Mathematicians will know how
great he is; and yet he writes software too. Awesome.
Please note Alan McConnell's new E-address: alan at his.com .
"The great safeguard of society and domestic life was, that opinions
were not acted upon. Sane people did what their neighbors did."
More information about the Dclug