Re: [Haifux] No! No! Don't compile your kernel!

2011-01-24 Thread Shlomi Fish
On Sunday 23 Jan 2011 23:06:40 Nadav Har'El wrote:
 On Sun, Jan 23, 2011, Eli Billauer wrote about [Haifux] No! No! Don't 
compile your kernel!:
  Yet another sign that Linux is turning into a don't-touch-me kind of
  system. How many times did they tell me I don't really want to compile
  my kernel?
  http://wiki.centos.org/HowTos/Custom_Kernel
 
 When was the last time you compiled gcc on your own? 

I compiled it shortly after I read this article - 
http://lwn.net/Articles/387122/ in May 2010, and wanted to see how the new 
flags affect the speed of Freecell Solver, and it indeed benefited from them. 
The process was not hard and here's my script for it:

[code]
#!/bin/bash
~/Download/unpack/prog/gcc/gcc-4.5.0/configure \
--prefix=$HOME/apps/prog/gcc-4.5.0 \
--enable-languages=c,c++
[/code]

(You need to build it in a different directory than the source.).

Previously, in April 2009, I built gcc-2.95.3 (which is very old) to see how 
much faster it *compiles*, and how much slower the resultant executables are:

http://tech.groups.yahoo.com/group/fc-solve-discuss/message/940

 When was the last time
 you compiled the X Window System? 

It's been a while since I compiled the entire X Window System since it became 
modular, but I've built the x11-server on occasions for Mandriva. Though I 
used the .src.rpm.

 For me, the answers to both questions is
 1995. If you answered similarly (or even, never), why should the kernel
 be any different - i.e., why do you need to compile a kernel unless you're
 a kernel developer (and 99.9% of Linux users aren't)?

Well, I've also built some kernels for ocassions. The vanilla 2.6.37 kernel I 
built seemed snappier than the shipped-in Mandriva kernel, and it Freecell 
Solver executed there at 72.7685720920563s instead of 73.6936609745026s (the 
fractions are what was reported by my script and copy pasted here - they are 
not very accurate.).

 
 Before Linux had modules, you often needed to recompile the kernel to add
 new hardware. With the advent of kernel modules (in Linux 1.2 in 1995...),
 this is no longer the case. So really, why *would* you want to recompile
 the kernel, unless you are a kernel developer, i.e., modifying the kernel?

Possibly to gain some speed or responsiveness or reduce memory consumption. 
Also, there are source-based distributions (e.g: Gentoo) which compile the 
source on each upgrade.

Regards,

Shlomi Fish

-- 
-
Shlomi Fish   http://www.shlomifish.org/
Why I Love Perl - http://shlom.in/joy-of-perl

Chuck Norris can make the statement This statement is false a true one.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


Re: [Haifux] No! No! Don't compile your kernel!

2011-01-24 Thread Nadav Har'El
On Mon, Jan 24, 2011, Shlomi Fish wrote about Re: No! No! Don't compile your 
kernel!:
 built seemed snappier than the shipped-in Mandriva kernel, and it Freecell 
 Solver executed there at 72.7685720920563s instead of 73.6936609745026s (the 

I hope that you agree with me that 99.9218485921% of the users wouldn't bother
themselves with recompilation (or any other manual step for that matter)
to make their games run 1.27127529900685765% faster ;-)

-- 
Nadav Har'El|  Monday, Jan 24 2011, 19 Shevat 5771
n...@math.technion.ac.il |-
Phone +972-523-790466, ICQ 13349191 |My password is my dog's name. His name is
http://nadav.harel.org.il   |a#j!4@h, but I change it every month.
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


Re: [Haifux] No! No! Don't compile your kernel!

2011-01-24 Thread Shachar Shemesh

Just a couple of nitpicks, in the hope they will prove useful.

On 24/01/11 09:02, Shachar Raindel wrote:

dpkg-buildpackage -rfakeroot
   
At least on debian, -rfakeroot is assumed unless you want something 
else (sudo, plugfakeroot-ng/plug or whatever).

And if I skip the tinker stage, build is 100% sure to succeed.

   
Let's agree on higher than 98%, so that we do not introduce 
unnecessary and unjustified hubris.


Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


Re: [Haifux] No! No! Don't compile your kernel!

2011-01-24 Thread Shlomi Fish
On Monday 24 Jan 2011 12:55:04 Nadav Har'El wrote:
 On Mon, Jan 24, 2011, Shlomi Fish wrote about Re: No! No! Don't compile 
your kernel!:

  built seemed snappier than the shipped-in Mandriva kernel, and it
  Freecell  Solver executed there at 72.7685720920563s instead of
  73.6936609745026s (the
 
 I hope that you agree with me that 99.9218485921% of the users wouldn't
 bother themselves with recompilation (or any other manual step for that
 matter) to make their games run 1.27127529900685765% faster ;-)

shlomif[fcs]:~$ perl -E 'say 
((73.6936609745026-72.7685720920563)/72.7685720920563*100)'
1.27127529900685

Kudos for the exact calculation. And yes, I agree that most people won't 
bother with this, but still the system running the vanilla kernel otherwise 
felt faster and snappier, and some people may wish to go to the extra trouble 
for that. (Without caring too much about the 1.27% speed increase in Freecell 
Solver's speed.). I don't know how much, and I'm possibly quite above the 
average computer user, but this option should still be relevant.

I agree with you that most people should not bother with this and just use the 
packages that their distribution provides.

All that put aside, as a software developer, I don't find 1% speed increases 
negligible, because when put together, they add up to significant savings. See 
what I wrote about it here:

http://en.wikibooks.org/wiki/Optimizing_Code_for_Speed

(Search for «Small» (with the double-quotes, but without the angle quotes).

Regards,

Shlomi Fish

 
 -- 
 Nadav Har'El|  Monday, Jan 24 2011, 19 Shevat
 5771
 n...@math.technion.ac.il |-
  Phone +972-523-790466, ICQ 13349191 |My password is my dog's name. His
 name is http://nadav.harel.org.il   |a#j!4@h, but I change it
 every month. 

I think this joke would be funnier if it said and I change it every month. 
instead of but I change it every month..

Regards,

Shlomi Fish

-- 
-
Shlomi Fish   http://www.shlomifish.org/
Best Introductory Programming Language - http://shlom.in/intro-lang

Chuck Norris can make the statement This statement is false a true one.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


Re: [Haifux] No! No! Don't compile your kernel!

2011-01-24 Thread Eli Billauer

Hi,


To put it short: I never was much into the ideals of freedom. My 
preference of free software always was because I could alter it to meet 
my own needs. It was easy enough to do for real. And I had this feeling 
that the system was meant to be hacked. It belonged to me. And that's 
fading away, most likely because nobody really seems to care about this. 
Linux is becoming a piece of opaque spaghetti, but it's OK as long as 
yum this or apt-get that trades one bug for another. Spaghetti is not 
free software. Not in any sense.



Shachar Raindel wrote:



And for both issues, if you were a company and not a home user, the
risks of replacing a major software component with a version that
haven't been tested and properly integrated with the rest of the
system would have been far worse than the risks of root on NFS
through initrd and small part of my hardware isn't supported by an
extremely outdated system.
  
Ah, that's my point. I clearly remember playing around with my kernel, 
upgrading it with a gap of several years with a vanilla kernel, and 
guess what? I just booted and all was OK. Would you believe that? When 
did it become so scary make changes in the kernel? And even worse: Why 
do we accept this? What's the practical difference between Window's 
kernel and Linux' if you can't compile one, but don't dare to compile 
the other?


There are many kind of companies. My experience with companies, in 
particular large ones, is that they put stability before anything. If 
you have 1000 running stations out there, the last thing to do is to 
just upgrade everything in one go. The worst nightmare is some rare bug 
which suddenly knocks your entire infrastructure down (Cellcom, 
anyone?). Justified or not, large companies tend to stick to what they 
got for as long as possible. I mean, a lot of end-user terminals still 
emulate DOS-like screens in a window (Israeli railways? Banks?), because 
they stick to the interface they had 20 years ago.


When small glitches mean big money, the top priorities are stability and 
control. Stability means to patch only what you need changed. Control 
means that you know what you're doing, to the smallest detail. yum 
upgrade and its apt parallel is losing control completely.


Have you tried Ubuntu recently? If I have package X, and I want to
tinker with its source files, all I have to do is:
(...)
  
Redhat has a similar system. I'm aware of it. It's yet another 
expression of the don't-touch-me paradigm. If you have to make a change 
in the sources, we'll hold your hands while you're doing it. The build 
process can be a piece of spaghetti, you won't understand it, it will 
work only on this specific distribution. And of course, if something 
fails, you're cooked.


But why would it fail? Software never fails. It always lives up to these 
don't-worry promises that everything will be smooth, and you'll never 
need to understand how things work behind the scenes, and therefore it 
can be as messy as ever.

How do you find information on the web? Who makes your Shampoo? Who is
providing your Internet connectivity? We are dependent on big
corporations for our everyday life whether you like it or not.

  

You mean, like Microsoft?

It looks like I'm the only one who want to throw away all those bells 
and whistles and go back to the good old days when you could do violent 
things to your OS and it would still run as if nothing happened. Or put 
simply: When GNU/Linux was stable as a rock.


  Eli

--
Web: http://www.billauer.co.il

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


Re: [Haifux] No! No! Don't compile your kernel!

2011-01-24 Thread Oron Peled
On Monday, 24 בJanuary 2011 22:11:49 Eli Billauer wrote:
 ... It was easy enough to do for real. And I had this feeling 
 that the system was meant to be hacked. It belonged to me. And that's 
 fading away, most likely because nobody really seems to care about this. 
 Linux is becoming a piece of opaque spaghetti, but it's OK as long as 
 yum this or apt-get that trades one bug for another. Spaghetti is not 
 free software. Not in any sense.

1. You should not be too worried about the lost art of kernel
compilation from sources.
Yes, only a tiny  fraction of Linux users today compile their
kernel (gcc, whatever)., but comparing fractions is a mistake.
The *number* of people doing these compiles today in comparison
with, say, 15 years ago is many-fold.
It's simply that we now have many more people who are *only users*
and should take their needs in account *as well* -- It doesn't mean
we have less *developers* or that very few can do this the old way

2. The system in general *is* more complex today than 15 years ago.
But attributing this purely to developers surrendering fashion is
ignoring the real changes that affected Linux during this time:
a lot more architectures, more cpus (numa), dynamic peripherals
(scsi, usb, hot-plug pci, etc), hot-plugable cpus and ram (balloning)
 virtualization, embedded systems.
 And please note I only mentioned hardware related changes, ignoring
 functional changes (e.g: desktop integration)

So not only you can compile your own stuff today, many of us do this
pretty routinely (you cannot evade it completely in embdeded space yet).
However, if you want to compile key parts of a modern *desktop* you'll
simply have to work harder.

BTW: the apt-get/yum mentioned before in this thread would also help you
 compile on your own because they can both bring you the build
 dependencies (and document them for you) and also contain the
 steps required for the build (which you can compare with your
 manual process if you have problems).

Don't worry ;-)

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron
If you have an apple and I have an apple and we exchange apples then
you and I will still each have one apple.  But if you have an idea and I
have an idea and we exchange these ideas, then each of us will have two
ideas. -- George Bernard Shaw
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


Re: [Haifux] No! No! Don't compile your kernel!

2011-01-24 Thread choo

(top-posting. yey!)

just as an example - we are using CentOS at work. We needed to
touch something in the kernel - so we changed the code and
compiled it. we Stumbled into bugs in various
networking-related packages - so we took the srpms, read the
source and fixed some bugs. we had a kernel crash bug - and we
had a dump that allowed us to find the cause of the bug - and
sending a report to the relevant mailing list - someone made a
fix, and we could back-port it into our (centos) kernel and
solve the issue.

we had varius problems with python, so we could delve into
python's source code and understand what is causing them. we
also read parts of the code of glibc to understand why some
APIs don't work as we expect them to work.

so, linux is still open source, when you're on the side of the
developers. it takes more then in the past to do things,
because the system is more complicated and contains much more
packages and much more lines of code.

--guy

 Original message 
Date:   Mon, 24 Jan 2011 23:12:48 +0200
From:   Oron Peled o...@actcom.co.il  
Subject:   Re: [Haifux] No! No! Don't compile your kernel!  
To:   haifux@haifux.org
Cc:   Shachar Raindel shach...@gmail.com

   On Monday, 24 בJanuary 2011 22:11:49 Eli Billauer
   wrote:

... It was easy enough to do for real. And I had
   this feeling

that the system was meant to be hacked. It
   belonged to me. And that's

fading away, most likely because nobody really
   seems to care about this.

Linux is becoming a piece of opaque spaghetti, but
   it's OK as long as

yum this or apt-get that trades one bug for
   another. Spaghetti is not

free software. Not in any sense.

   1. You should not be too worried about the lost
   art of kernel

   compilation from sources.

   Yes, only a tiny fraction of Linux users today
   compile their

   kernel (gcc, whatever)., but comparing fractions is
   a mistake.

   The *number* of people doing these compiles today in
   comparison

   with, say, 15 years ago is many-fold.

   It's simply that we now have many more people who
   are *only users*

   and should take their needs in account *as well* --
   It doesn't mean

   we have less *developers* or that very few can do
   this the old way

   2. The system in general *is* more complex today
   than 15 years ago.

   But attributing this purely to developers
   surrendering fashion is

   ignoring the real changes that affected Linux during
   this time:

   a lot more architectures, more cpus (numa), dynamic
   peripherals

   (scsi, usb, hot-plug pci, etc), hot-plugable cpus
   and ram (balloning)

   virtualization, embedded systems.

   And please note I only mentioned hardware related
   changes, ignoring

   functional changes (e.g: desktop integration)

   So not only you can compile your own stuff today,
   many of us do this

   pretty routinely (you cannot evade it completely in
   embdeded space yet).

   However, if you want to compile key parts of a
   modern *desktop* you'll

   simply have to work harder.

   BTW: the apt-get/yum mentioned before in this thread
   would also help you

   compile on your own because they can both bring you
   the build

   dependencies (and document them for you) and also
   contain the

   steps required for the build (which you can compare
   with your

   manual process if you have problems).

   Don't worry ;-)

   --

   Oron Peled Voice: +972-4-8228492

   o...@actcom.co.il http://users.actcom.co.il/~oron

   If you have an apple and I have an apple and we
   exchange apples then

   you and I will still each have one apple. But if you
   have an idea and I

   have an idea and we exchange these ideas, then each
   of us will have two

   ideas. -- George Bernard Shaw

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


[Haifux] No! No! Don't compile your kernel!

2011-01-23 Thread Eli Billauer
Yet another sign that Linux is turning into a don't-touch-me kind of 
system. How many times did they tell me I don't really want to compile 
my kernel?



http://wiki.centos.org/HowTos/Custom_Kernel

--
Web: http://www.billauer.co.il

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


Re: [Haifux] No! No! Don't compile your kernel!

2011-01-23 Thread Etzion Bar-Noy
Not because you can't.
Because for the enterprise market, where Centos is aimed at, *supportability
* is more important than 1.2% additional performance, or a certain new
experimental feature.

For your own home/development box, do whatever you want. For Enterprise?
Hell, no.

Ez

On Sun, Jan 23, 2011 at 4:57 PM, Eli Billauer e...@billauer.co.il wrote:

 Yet another sign that Linux is turning into a don't-touch-me kind of
 system. How many times did they tell me I don't really want to compile my
 kernel?


 http://wiki.centos.org/HowTos/Custom_Kernel

 --
 Web: http://www.billauer.co.il

 ___
 Haifux mailing list
 Haifux@haifux.org
 http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


Re: [Haifux] No! No! Don't compile your kernel!

2011-01-23 Thread Nadav Har'El
On Sun, Jan 23, 2011, Eli Billauer wrote about [Haifux] No! No! Don't compile 
your kernel!:
 Yet another sign that Linux is turning into a don't-touch-me kind of 
 system. How many times did they tell me I don't really want to compile 
 my kernel?
 http://wiki.centos.org/HowTos/Custom_Kernel

When was the last time you compiled gcc on your own? When was the last time
you compiled the X Window System? For me, the answers to both questions is
1995. If you answered similarly (or even, never), why should the kernel be
any different - i.e., why do you need to compile a kernel unless you're a
kernel developer (and 99.9% of Linux users aren't)?

Before Linux had modules, you often needed to recompile the kernel to add
new hardware. With the advent of kernel modules (in Linux 1.2 in 1995...),
this is no longer the case. So really, why *would* you want to recompile the
kernel, unless you are a kernel developer, i.e., modifying the kernel?

-- 
Nadav Har'El|  Sunday, Jan 23 2011, 19 Shevat 5771
n...@math.technion.ac.il |-
Phone +972-523-790466, ICQ 13349191 |Cats are smarter than dogs. You can't get
http://nadav.harel.org.il   |eight cats to pull a sled through snow.
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


Re: [Haifux] No! No! Don't compile your kernel!

2011-01-23 Thread Eli Billauer

Nadav Har'El wrote:


When was the last time you compiled gcc on your own? When was the last time
you compiled the X Window System? For me, the answers to both questions is
1995. If you answered similarly (or even, never), why should the kernel be
any different - i.e., why do you need to compile a kernel unless you're a
kernel developer (and 99.9% of Linux users aren't)?

  
In my case, I've had two reasons lately: One was because I wanted new 
hardware to be supported on an outdated distribution, and the second was 
because I wanted the kernel to support root on NFS without an initrd.


I agree, that both issues have workarounds. In particular, most people 
upgrade the whole system when hardware isn't supported. As for the root 
on NFS, I could alter the initrd to do the job necessary, and go on with 
that. I had my reasons not to take that path.


Anyhow, the issue here is that compiling from sources is getting less 
and less common, which in turn makes the sources more and more difficult 
to compile. In the past, I maintained my system with compiling tarballs, 
and it was quick and easy. Today, I pray when going ./configure, even on 
an up-to-date system.


And to take this issue to a broader scope: If the source becomes 
difficult to compile, we slowly drift towards losing the edge of free 
software. When only large corporates will have the knowledge and 
patience to compile from source, it won't matter so much whether you can 
obtain it or not. If nobody except corporates dig into the gory details, 
we will all end up depending on them. And they will, at best, allow us 
use of the software they distribute free, as in beer.


  Eli

--
Web: http://www.billauer.co.il

___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux


Re: [Haifux] No! No! Don't compile your kernel!

2011-01-23 Thread Shachar Raindel
On Mon, Jan 24, 2011 at 12:54 AM, Eli Billauer e...@billauer.co.il wrote:
 In my case, I've had two reasons lately: One was because I wanted new
 hardware to be supported on an outdated distribution, and the second was
 because I wanted the kernel to support root on NFS without an initrd.

 I agree, that both issues have workarounds. In particular, most people
 upgrade the whole system when hardware isn't supported. As for the root on
 NFS, I could alter the initrd to do the job necessary, and go on with that.
 I had my reasons not to take that path.

And for both issues, if you were a company and not a home user, the
risks of replacing a major software component with a version that
haven't been tested and properly integrated with the rest of the
system would have been far worse than the risks of root on NFS
through initrd and small part of my hardware isn't supported by an
extremely outdated system.

 Anyhow, the issue here is that compiling from sources is getting less and
 less common, which in turn makes the sources more and more difficult to
 compile. In the past, I maintained my system with compiling tarballs, and it
 was quick and easy. Today, I pray when going ./configure, even on an
 up-to-date system.

Have you tried Ubuntu recently? If I have package X, and I want to
tinker with its source files, all I have to do is:
sudo apt-get build-dep X
apt-get source X
cd X
tinker with source files
dpkg-buildpackage -rfakeroot

And if I skip the tinker stage, build is 100% sure to succeed.


 And to take this issue to a broader scope: If the source becomes difficult
 to compile, we slowly drift towards losing the edge of free software. When
 only large corporates will have the knowledge and patience to compile from
 source, it won't matter so much whether you can obtain it or not. If nobody
 except corporates dig into the gory details, we will all end up depending on
 them. And they will, at best, allow us use of the software they distribute
 free, as in beer.

How do you find information on the web? Who makes your Shampoo? Who is
providing your Internet connectivity? We are dependent on big
corporations for our everyday life whether you like it or not.
Therefore, it shouldn't come to you as a surprise that it is a little
bit like this with software as well. However, having the source code
available means that even random people like us can compile it and
tinker with it (note how easy it is to do that in many distros, such
as Ubuntu and Gentoo). Much better than your situation with
web-search, or with Shampoo.

--Shachar
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux