diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20100926')
18 files changed, 882 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20100926/088d0dda/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100926/088d0dda/attachment-0001.html new file mode 100644 index 000000000..bd3ee7b4d --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/088d0dda/attachment-0001.html @@ -0,0 +1,49 @@ +I Like this idea. An modern way and that envolve community. Maybe it's an successfully.<div><br></div><div>J�nior<br><br><div class="gmail_quote">Em 26 de setembro de 2010 11:27, Andr� Machado <span dir="ltr"><<a href="mailto:afmachado@dcemail.com">afmachado@dcemail.com</a>></span> escreveu:<br> +<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br> +--- <a href="mailto:misc@zarb.org">misc@zarb.org</a> escreveu:<br> +<br> +From: Michael Scherer <<a href="mailto:misc@zarb.org">misc@zarb.org</a>><br> +To: Mageia development mailing-list <<a href="mailto:mageia-dev@mageia.org">mageia-dev@mageia.org</a>><br> +Subject: Re: [Mageia-dev] Will this work for a build system?<br> +Date: Sun, 26 Sep 2010 15:38:19 +0200<br> +<div><div></div><div class="h5"><br> +Le dimanche 26 septembre 2010 � 14:22 +0200, Olivier Blin a �crit :<br> +<br> +> > It would be cool if it could be done that way. �Why pay for data<br> +> > center space, hardware, electricity and big bandwidth when you could<br> +> > have a community-provided "cloud" for free? :o)<br> +><br> +> Because there are some authentication and integrity issues which are not<br> +> simple to solve: we have to be sure that the binary packages really come<br> +> from the unmodified SRPM (so that it does not contains malware).<br> +<br> +We could however use this to host something similar to koji scratch<br> +build ( ie, build that are not pushed to central mirror ).<br> +<br> +<a href="http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Scratch_builds_2" target="_blank">http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Scratch_builds_2</a><br> +<br> +<br> +--<br> +Michael Scherer<br> +<br> +_______________________________________________<br> +Mageia-dev mailing list<br> +<a href="mailto:Mageia-dev@mageia.org">Mageia-dev@mageia.org</a><br> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev" target="_blank">https://www.mageia.org/mailman/listinfo/mageia-dev</a><br> +<br> +</div></div>Tis idea is cool. Can we do something like Nasa' SETI - Search for Extraterrestrial Intelligence -, a community build grid: everyone install dev tools in your machine and runs a piece of software what downloads a SRPM or a part of a SRPM to this machine, compile it and uploads it back. Mageia can be built in minutes (despite some members low connection speed) and would be something completely new and innovative!<br> + +<br> +Reguards,<br> +<font color="#888888"><br> +--<br> +Andre Machado - <a href="http://www.twitter.com/afmachado" target="_blank">www.twitter.com/afmachado</a><br> +Mageia - A Magia continua<br> +<br> +_____________________________________________________________<br> +Washington DC's Largest FREE Email service. ---> <a href="http://www.DCemail.com" target="_blank">http://www.DCemail.com</a> ---> A Washington Online Community Member ---><br> +<a href="http://www.DCpages.com" target="_blank">http://www.DCpages.com</a><br> +</font><div><div></div><div class="h5">_______________________________________________<br> +Mageia-dev mailing list<br> +<a href="mailto:Mageia-dev@mageia.org">Mageia-dev@mageia.org</a><br> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev" target="_blank">https://www.mageia.org/mailman/listinfo/mageia-dev</a></div></div></blockquote></div><br></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/088d0dda/attachment.html b/zarb-ml/mageia-dev/attachments/20100926/088d0dda/attachment.html new file mode 100644 index 000000000..bd3ee7b4d --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/088d0dda/attachment.html @@ -0,0 +1,49 @@ +I Like this idea. An modern way and that envolve community. Maybe it's an successfully.<div><br></div><div>J�nior<br><br><div class="gmail_quote">Em 26 de setembro de 2010 11:27, Andr� Machado <span dir="ltr"><<a href="mailto:afmachado@dcemail.com">afmachado@dcemail.com</a>></span> escreveu:<br> +<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br> +--- <a href="mailto:misc@zarb.org">misc@zarb.org</a> escreveu:<br> +<br> +From: Michael Scherer <<a href="mailto:misc@zarb.org">misc@zarb.org</a>><br> +To: Mageia development mailing-list <<a href="mailto:mageia-dev@mageia.org">mageia-dev@mageia.org</a>><br> +Subject: Re: [Mageia-dev] Will this work for a build system?<br> +Date: Sun, 26 Sep 2010 15:38:19 +0200<br> +<div><div></div><div class="h5"><br> +Le dimanche 26 septembre 2010 � 14:22 +0200, Olivier Blin a �crit :<br> +<br> +> > It would be cool if it could be done that way. �Why pay for data<br> +> > center space, hardware, electricity and big bandwidth when you could<br> +> > have a community-provided "cloud" for free? :o)<br> +><br> +> Because there are some authentication and integrity issues which are not<br> +> simple to solve: we have to be sure that the binary packages really come<br> +> from the unmodified SRPM (so that it does not contains malware).<br> +<br> +We could however use this to host something similar to koji scratch<br> +build ( ie, build that are not pushed to central mirror ).<br> +<br> +<a href="http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Scratch_builds_2" target="_blank">http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Scratch_builds_2</a><br> +<br> +<br> +--<br> +Michael Scherer<br> +<br> +_______________________________________________<br> +Mageia-dev mailing list<br> +<a href="mailto:Mageia-dev@mageia.org">Mageia-dev@mageia.org</a><br> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev" target="_blank">https://www.mageia.org/mailman/listinfo/mageia-dev</a><br> +<br> +</div></div>Tis idea is cool. Can we do something like Nasa' SETI - Search for Extraterrestrial Intelligence -, a community build grid: everyone install dev tools in your machine and runs a piece of software what downloads a SRPM or a part of a SRPM to this machine, compile it and uploads it back. Mageia can be built in minutes (despite some members low connection speed) and would be something completely new and innovative!<br> + +<br> +Reguards,<br> +<font color="#888888"><br> +--<br> +Andre Machado - <a href="http://www.twitter.com/afmachado" target="_blank">www.twitter.com/afmachado</a><br> +Mageia - A Magia continua<br> +<br> +_____________________________________________________________<br> +Washington DC's Largest FREE Email service. ---> <a href="http://www.DCemail.com" target="_blank">http://www.DCemail.com</a> ---> A Washington Online Community Member ---><br> +<a href="http://www.DCpages.com" target="_blank">http://www.DCpages.com</a><br> +</font><div><div></div><div class="h5">_______________________________________________<br> +Mageia-dev mailing list<br> +<a href="mailto:Mageia-dev@mageia.org">Mageia-dev@mageia.org</a><br> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev" target="_blank">https://www.mageia.org/mailman/listinfo/mageia-dev</a></div></div></blockquote></div><br></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/160d6f48/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100926/160d6f48/attachment-0001.html new file mode 100644 index 000000000..093192cba --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/160d6f48/attachment-0001.html @@ -0,0 +1,18 @@ +2010/9/26 Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@iki.fi">tmb@iki.fi</a>></span><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im">Giuseppe Ghib� skrev 26.9.2010 02:09:<br> +><br> +</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +I don't want to deprive the fun of building a router or a firewall from<div class="im"><br> +an old P133/64 with two ethernet cards, or some mediabox, but often you<br> +can't �(and sometimes you pay of energy power in a year much more than<br> +getting some 30-50E linksys ARM linux based router. And when soemone try<br> +such kind of attempts in the real world with your distro, will be very<br> +disappointed of failures. That's why I in some way asked a survey of<br> +oldest hardware based on own experiences.<br> +<br> +</div></blockquote> +<br> +You still miss the point that in Mageia community there are many users that find 30-50e a _lot_ of money, and we dont want to shut them out.<br></blockquote><div><br>I'm not decreasing the value of the money, but rather I was pointing out the false assumption that mageia (or the current inherited mandriva) would work and would work FINE (or at all) on that hardware just because it was using a compatible instruction set. I'm not against this, but if that we wanna support that kind of hardware there is MUCH MORE work to do (I suggested a LEGACY section in the wiki, but seems it wasn't caught) than just keeping the actual flags, because in that way if we don't change then nobody will complain. Even the simple lzma payload of rpm packages requires much more memory than in the past with gzip. I'm not sure with current squashfs for the initial ram disks.<br> +<br>I already cited there are other distro which maybe do a lot better this job. In many countries there isn't even the broadband, dialup, nor the electrical power for them. Right now you are almost assuming that a 10 years old instruction set is still a no go, and that our distro is optimized like the one of the One Laptop Per Child Project. Sadly it isn't. But there is also a 2nd point: on old hardware it is still possible to run old software and old distros: strange but true. Such old software is still doing its dirty job. It's not that you get a trojan as soon as you put the nose out the net. There are still ways of configuring a distro on a LAN and trust in the people using the terminals locally. Many schools still use them. In a 2 hours lesson at school you can't wait half an our just to have your desktop booting..., the same if you plan an antispam server with latest antispam tools on a server of that category (server that was doing it's dirty job with the distro of 2 or 3 generations ago). <br> +<br>I also tried such old hardware, but there are much less bloated distro and less bloated kernels (even non-linux ones) that do the job (or a specific duty) on such hardware a lot better than ours.<br><br>Bye<br>Giuseppe.<br> +<br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/160d6f48/attachment.html b/zarb-ml/mageia-dev/attachments/20100926/160d6f48/attachment.html new file mode 100644 index 000000000..093192cba --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/160d6f48/attachment.html @@ -0,0 +1,18 @@ +2010/9/26 Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@iki.fi">tmb@iki.fi</a>></span><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im">Giuseppe Ghib� skrev 26.9.2010 02:09:<br> +><br> +</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +I don't want to deprive the fun of building a router or a firewall from<div class="im"><br> +an old P133/64 with two ethernet cards, or some mediabox, but often you<br> +can't �(and sometimes you pay of energy power in a year much more than<br> +getting some 30-50E linksys ARM linux based router. And when soemone try<br> +such kind of attempts in the real world with your distro, will be very<br> +disappointed of failures. That's why I in some way asked a survey of<br> +oldest hardware based on own experiences.<br> +<br> +</div></blockquote> +<br> +You still miss the point that in Mageia community there are many users that find 30-50e a _lot_ of money, and we dont want to shut them out.<br></blockquote><div><br>I'm not decreasing the value of the money, but rather I was pointing out the false assumption that mageia (or the current inherited mandriva) would work and would work FINE (or at all) on that hardware just because it was using a compatible instruction set. I'm not against this, but if that we wanna support that kind of hardware there is MUCH MORE work to do (I suggested a LEGACY section in the wiki, but seems it wasn't caught) than just keeping the actual flags, because in that way if we don't change then nobody will complain. Even the simple lzma payload of rpm packages requires much more memory than in the past with gzip. I'm not sure with current squashfs for the initial ram disks.<br> +<br>I already cited there are other distro which maybe do a lot better this job. In many countries there isn't even the broadband, dialup, nor the electrical power for them. Right now you are almost assuming that a 10 years old instruction set is still a no go, and that our distro is optimized like the one of the One Laptop Per Child Project. Sadly it isn't. But there is also a 2nd point: on old hardware it is still possible to run old software and old distros: strange but true. Such old software is still doing its dirty job. It's not that you get a trojan as soon as you put the nose out the net. There are still ways of configuring a distro on a LAN and trust in the people using the terminals locally. Many schools still use them. In a 2 hours lesson at school you can't wait half an our just to have your desktop booting..., the same if you plan an antispam server with latest antispam tools on a server of that category (server that was doing it's dirty job with the distro of 2 or 3 generations ago). <br> +<br>I also tried such old hardware, but there are much less bloated distro and less bloated kernels (even non-linux ones) that do the job (or a specific duty) on such hardware a lot better than ours.<br><br>Bye<br>Giuseppe.<br> +<br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/47ebffc2/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100926/47ebffc2/attachment-0001.html new file mode 100644 index 000000000..89277f0c0 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/47ebffc2/attachment-0001.html @@ -0,0 +1,66 @@ +2010/9/26 Tux99 <span dir="ltr"><<a href="mailto:tux99-mga@uridium.org">tux99-mga@uridium.org</a>></span><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im">On Sun, 26 Sep 2010, Giuseppe Ghib� wrote:<br> +<br> +> Centos4 IS NOT a modern distro. It is a LTS started in 2005 and so it<br> +> maintains 2005's original skeleton of kernel, gcc, glibc and X. That's FIVE<br> +> years old.<br> +<br> +</div>I'm quite sure Centos5/RHEL5 would install and run fine on it too,<br> +Debian would almost certainly too, the point is when you don't<br> +install/use a GUI, Linux still can run fine on very old low end<br> +hardware.<br></blockquote><div><br>kernel 2.6.18 is a lot different than 2.6.31/33. As I said I invite to RUN the installation/installer from scratch (there is the dual-arch installer on a CD) of 2010.1 or cooker in such hardware. And if successful, report the memory usage without any service started apart the login ttys. We are not using the installation tools of CentOS or Debian. NetBSD would have probably even the tiny one since AIM of being still compatible to m68k hardware.<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im"><br> +<br> +> As example MDV 2007.1, which is 3 years old, was still very<br> +> usable and responsive on my P4/ATI (maybe not as much as stable with 3D<br> +> acceleration), but 2010.0 ISN'T.<br> +<br> +</div>Again, you are missing the point, you are talking about desktop/GUI use!<br> +Computers get used for a lot of other purposes, not just desktop/GUI use!<br> +<div class="im"><br></div></blockquote><div><br>�</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"> +<br> +> That's why I in some way asked a survey of oldest hardware based<br> +> on own experiences.<br> +<br> +</div>Well, my oldest hardware that I still have working is a dual cpu<br> +Pentium 233MMX (the original i586) with 384MB RAM (currently has 2008.1<br></blockquote><div><br>in i586 we are not even using MMX. As I said 2008.1 is not 2010.1 but 4 generation distro behind. Since it's not LTS, you might try to upgrade to 2010.1.<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +on it) and a VIA C3 (samuel2 core, i586 since it lacks CMOV) box with<br> +512MB RAM which has mdv 2010.1 installed on it and works fine for it's<br> +purpose too (headless home server running 24/7 and only uses 10Watts).<br></blockquote><div><br>what is the output of "cpuinfo" there?<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> + +<div class="im"><br> +<br> +> Very interesting, but will such "industrial use" will be target for Mageia<br> +> (BTW, certainly socket 775 CPU will support SSE and SSE2...)? If they have<br> +> an ISA slot, I guess is for maintaning the compatibility with some old fancy<br> +> (and maybe custom) card, certainly not for an ISA ethernet card that can be<br> +> easily replaced with a cheap PCI one or the one on board.<br> +<br> +</div>That was just one example, there are many other situations were you<br> +still find ISA hardware, especially in developing countries.<br> +<div class="im"><br> +<br> +> Not exactly. I'm not talking in just using -march=<something> but in also<br> +> pushing -mfpmath=sse -msse (and maybe -msse2) , which should be much more<br> +> than JUST 1-2% (1-2% is usually the benchmark tolerance)...<br> +<br> +</div>AFAIK SSE will only help with media apps (mplayer, etc) and they do<br> +autodedect already anyway so in practice nothing is gained.<br></blockquote><div><br>-mfpmath=sse would replace the x87 with sse. Of course for any CPU not having the SSE would result in a segfault or illegal instruction report rather than a drop of performance as in case of changing the optimization but maintaining the backward compatibility.<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im"><br> +<br> +> being realistic I think it's a lot of work and there aren't the resources,<br> +> so a choice of the default flags should be done.<br> +<br> +</div>Agreed that would be too much work for very little benefit, the default<br> +flags of Mandriva are just fine since they still work on i586.<br></blockquote><div><br>If you are able to break the Page's law you are welcome. :-)<br>[<a href="http://www.appscout.com/2009/05/moores_law_meet_larry_pages_la.php">http://www.appscout.com/2009/05/moores_law_meet_larry_pages_la.php</a>]<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<br> +We could have some selected packages also as i686 (like MIB does and<br> +like the kernel already is), like for example all the media players, but<br> +making the whole distro i686 would break too many uses of it.<br></blockquote><div><br>as I said you are forgetting two of the most important like glibc and kernel. As I said it's not that difficult to provide such packages (even optimized for VIA C3 and C7) but require a little bit more than rebuilding with specifying --target=c3,c7,xxx in rpm building.<br> +<br>I also think that sometimes application due to poor cache (including ATOM) would run faster when compiled with -Os instead of -O2...; we could introduce it for a common .i386.rpm package.<br><br>Bye<br>Giuseppe.<br><br> +In a challenge of better supporting legacy hardware, why not adding Mageia super-Legacy no-desktop section? where we are doing exactly the opposite of supporting newer hardware. E.g.:<br><br>- remove i18n support, only LANG=C<br> +- optimize for tiny cache<br>- reduce the # of fonts installed<br>- no themes<br>- reduce # of things in /etc/profile.d<br>- no extra audio daemon support (pulse, etc) or even no audio support<br><br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/47ebffc2/attachment.html b/zarb-ml/mageia-dev/attachments/20100926/47ebffc2/attachment.html new file mode 100644 index 000000000..89277f0c0 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/47ebffc2/attachment.html @@ -0,0 +1,66 @@ +2010/9/26 Tux99 <span dir="ltr"><<a href="mailto:tux99-mga@uridium.org">tux99-mga@uridium.org</a>></span><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im">On Sun, 26 Sep 2010, Giuseppe Ghib� wrote:<br> +<br> +> Centos4 IS NOT a modern distro. It is a LTS started in 2005 and so it<br> +> maintains 2005's original skeleton of kernel, gcc, glibc and X. That's FIVE<br> +> years old.<br> +<br> +</div>I'm quite sure Centos5/RHEL5 would install and run fine on it too,<br> +Debian would almost certainly too, the point is when you don't<br> +install/use a GUI, Linux still can run fine on very old low end<br> +hardware.<br></blockquote><div><br>kernel 2.6.18 is a lot different than 2.6.31/33. As I said I invite to RUN the installation/installer from scratch (there is the dual-arch installer on a CD) of 2010.1 or cooker in such hardware. And if successful, report the memory usage without any service started apart the login ttys. We are not using the installation tools of CentOS or Debian. NetBSD would have probably even the tiny one since AIM of being still compatible to m68k hardware.<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im"><br> +<br> +> As example MDV 2007.1, which is 3 years old, was still very<br> +> usable and responsive on my P4/ATI (maybe not as much as stable with 3D<br> +> acceleration), but 2010.0 ISN'T.<br> +<br> +</div>Again, you are missing the point, you are talking about desktop/GUI use!<br> +Computers get used for a lot of other purposes, not just desktop/GUI use!<br> +<div class="im"><br></div></blockquote><div><br>�</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"> +<br> +> That's why I in some way asked a survey of oldest hardware based<br> +> on own experiences.<br> +<br> +</div>Well, my oldest hardware that I still have working is a dual cpu<br> +Pentium 233MMX (the original i586) with 384MB RAM (currently has 2008.1<br></blockquote><div><br>in i586 we are not even using MMX. As I said 2008.1 is not 2010.1 but 4 generation distro behind. Since it's not LTS, you might try to upgrade to 2010.1.<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +on it) and a VIA C3 (samuel2 core, i586 since it lacks CMOV) box with<br> +512MB RAM which has mdv 2010.1 installed on it and works fine for it's<br> +purpose too (headless home server running 24/7 and only uses 10Watts).<br></blockquote><div><br>what is the output of "cpuinfo" there?<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> + +<div class="im"><br> +<br> +> Very interesting, but will such "industrial use" will be target for Mageia<br> +> (BTW, certainly socket 775 CPU will support SSE and SSE2...)? If they have<br> +> an ISA slot, I guess is for maintaning the compatibility with some old fancy<br> +> (and maybe custom) card, certainly not for an ISA ethernet card that can be<br> +> easily replaced with a cheap PCI one or the one on board.<br> +<br> +</div>That was just one example, there are many other situations were you<br> +still find ISA hardware, especially in developing countries.<br> +<div class="im"><br> +<br> +> Not exactly. I'm not talking in just using -march=<something> but in also<br> +> pushing -mfpmath=sse -msse (and maybe -msse2) , which should be much more<br> +> than JUST 1-2% (1-2% is usually the benchmark tolerance)...<br> +<br> +</div>AFAIK SSE will only help with media apps (mplayer, etc) and they do<br> +autodedect already anyway so in practice nothing is gained.<br></blockquote><div><br>-mfpmath=sse would replace the x87 with sse. Of course for any CPU not having the SSE would result in a segfault or illegal instruction report rather than a drop of performance as in case of changing the optimization but maintaining the backward compatibility.<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im"><br> +<br> +> being realistic I think it's a lot of work and there aren't the resources,<br> +> so a choice of the default flags should be done.<br> +<br> +</div>Agreed that would be too much work for very little benefit, the default<br> +flags of Mandriva are just fine since they still work on i586.<br></blockquote><div><br>If you are able to break the Page's law you are welcome. :-)<br>[<a href="http://www.appscout.com/2009/05/moores_law_meet_larry_pages_la.php">http://www.appscout.com/2009/05/moores_law_meet_larry_pages_la.php</a>]<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<br> +We could have some selected packages also as i686 (like MIB does and<br> +like the kernel already is), like for example all the media players, but<br> +making the whole distro i686 would break too many uses of it.<br></blockquote><div><br>as I said you are forgetting two of the most important like glibc and kernel. As I said it's not that difficult to provide such packages (even optimized for VIA C3 and C7) but require a little bit more than rebuilding with specifying --target=c3,c7,xxx in rpm building.<br> +<br>I also think that sometimes application due to poor cache (including ATOM) would run faster when compiled with -Os instead of -O2...; we could introduce it for a common .i386.rpm package.<br><br>Bye<br>Giuseppe.<br><br> +In a challenge of better supporting legacy hardware, why not adding Mageia super-Legacy no-desktop section? where we are doing exactly the opposite of supporting newer hardware. E.g.:<br><br>- remove i18n support, only LANG=C<br> +- optimize for tiny cache<br>- reduce the # of fonts installed<br>- no themes<br>- reduce # of things in /etc/profile.d<br>- no extra audio daemon support (pulse, etc) or even no audio support<br><br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/4a8a48d0/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100926/4a8a48d0/attachment-0001.html new file mode 100644 index 000000000..cccaffcf6 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/4a8a48d0/attachment-0001.html @@ -0,0 +1,17 @@ +2010/9/26 Andr� Machado <span dir="ltr"><<a href="mailto:afmachado@dcemail.com">afmachado@dcemail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div style="font-family: Arial,sans-serif; font-size: 10pt;"><div class="im">> Common where? There are schools and universities are dismitting hardware<br></div><div><div class="im"><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div> +> like with P4/2.4Ghz and 512MB RAM for whatever use (either server or<br> +> desktop). And even older hardware no-ROHS, which should be dismantled<br> +> carefully.<br> +<br> +</div>You are seeing everything from a limited european POV, the P4 you say is<br> +being thrown away here is a top-end system in some other countries.<br> +Mageia is supposed to be for the whole world, not just EU/US/BRICs.<br></blockquote></div><div><div class="im"><br>I don't want to deprive the fun of building a router or a firewall from an old P133/64 with two ethernet cards, or some mediabox, but often you can't� (and sometimes you pay of energy power in a year much more than getting some 30-50E linksys ARM linux based router. And when soemone try such kind of attempts in the real world with your distro, will be very disappointed of failures. That's why I in some way asked a survey of oldest hardware based on own experiences.<br> +<br></div>I fully agree, At "first world" countries, Like Europe ones or USA, people can buy the most recet PCS, but at "Thrird world" countries - Like Brazil, what is part of BRIC, or many Africa nations - this is very unacessible by population, even with government programs, like Brazil's "Computador para Todos" (computer for everyone) that sells low-cost PCs with inferior hardware, <span><span title="">often leftover stock lines earlier from the U.S. and Europe. In many department shops here, for example, Core2Duo is </span></span><span><span title="">sold as if it were the last flavor of the moment.</span></span><br> +<br>If, where you are, Pentium I - 4 and 32-bit platform is a museum thing, in most World parts, is not. I know people that, nowadays, uses a Pentium 200 with 64MB RAM as main computer.<br><br>Despite Mageia main target be current computers, we must think in these people; 32-bit will not die anytime soon. Then: Do we need compile 32-bit edition as i586 - and support Pentium and above, i686 - and support Pentium Pro and above, or do a Mageia Lite edition?<br> +<br>[PS: <span><span title="">I did not break the thread this time, broke?</span></span>]<br></div></div><br></div></blockquote><div>�<br>What I'm saying is that in the "real world", an hardware generation is born for a certain software generation. Outside this you can't, if programmers doesn't have paid a particular attention to memory consumption and performance. And currently they haven't.<br> +<br>In mandriva 7.0-7.2 I was able to run vmware on a P133 with not 64 but 48MB of RAM, and there I was running another OS under which I was running a (TWAIN) software for page scanning for a Umax Page Office scanner, and that was the only software available for acquiring data from a parallel port. A bit slow but usable. The same using a modern distro on that old hardware is no longer possible. So the feeling of being compatible with older hardware is just apparent. This is true for even non-graphics applications. Try just with apache, postfix, spamassassin, or even a simple modem-bridge with the only things doing is having a modem connected to a serial port running a getty and pppd for dialup access (that's the smallest application which comes to my mind).<br> +<br>So my point was that we were keeping flags holding the brakes for maintaining a compatibility which is just apparent. Current configuring tools are written in high level languages, like python, with a lot of other libraries, and they consumes a lot more memory than in the past. Even rendering the fonts consumes a lot more. xfs was even removed from standard installation.<br> +<br>Being compatible and usable with legacy system like that is certainly possible, but not in the current way. On the software side is even worst (e.g. some software removed in favour of other newer having the same capability). Maybe there could be created a section called "Legacy" for such kind of things, with much more testing.<br> +<br>Bye<br>Giuseppe.<br><br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/4a8a48d0/attachment.html b/zarb-ml/mageia-dev/attachments/20100926/4a8a48d0/attachment.html new file mode 100644 index 000000000..cccaffcf6 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/4a8a48d0/attachment.html @@ -0,0 +1,17 @@ +2010/9/26 Andr� Machado <span dir="ltr"><<a href="mailto:afmachado@dcemail.com">afmachado@dcemail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div style="font-family: Arial,sans-serif; font-size: 10pt;"><div class="im">> Common where? There are schools and universities are dismitting hardware<br></div><div><div class="im"><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div> +> like with P4/2.4Ghz and 512MB RAM for whatever use (either server or<br> +> desktop). And even older hardware no-ROHS, which should be dismantled<br> +> carefully.<br> +<br> +</div>You are seeing everything from a limited european POV, the P4 you say is<br> +being thrown away here is a top-end system in some other countries.<br> +Mageia is supposed to be for the whole world, not just EU/US/BRICs.<br></blockquote></div><div><div class="im"><br>I don't want to deprive the fun of building a router or a firewall from an old P133/64 with two ethernet cards, or some mediabox, but often you can't� (and sometimes you pay of energy power in a year much more than getting some 30-50E linksys ARM linux based router. And when soemone try such kind of attempts in the real world with your distro, will be very disappointed of failures. That's why I in some way asked a survey of oldest hardware based on own experiences.<br> +<br></div>I fully agree, At "first world" countries, Like Europe ones or USA, people can buy the most recet PCS, but at "Thrird world" countries - Like Brazil, what is part of BRIC, or many Africa nations - this is very unacessible by population, even with government programs, like Brazil's "Computador para Todos" (computer for everyone) that sells low-cost PCs with inferior hardware, <span><span title="">often leftover stock lines earlier from the U.S. and Europe. In many department shops here, for example, Core2Duo is </span></span><span><span title="">sold as if it were the last flavor of the moment.</span></span><br> +<br>If, where you are, Pentium I - 4 and 32-bit platform is a museum thing, in most World parts, is not. I know people that, nowadays, uses a Pentium 200 with 64MB RAM as main computer.<br><br>Despite Mageia main target be current computers, we must think in these people; 32-bit will not die anytime soon. Then: Do we need compile 32-bit edition as i586 - and support Pentium and above, i686 - and support Pentium Pro and above, or do a Mageia Lite edition?<br> +<br>[PS: <span><span title="">I did not break the thread this time, broke?</span></span>]<br></div></div><br></div></blockquote><div>�<br>What I'm saying is that in the "real world", an hardware generation is born for a certain software generation. Outside this you can't, if programmers doesn't have paid a particular attention to memory consumption and performance. And currently they haven't.<br> +<br>In mandriva 7.0-7.2 I was able to run vmware on a P133 with not 64 but 48MB of RAM, and there I was running another OS under which I was running a (TWAIN) software for page scanning for a Umax Page Office scanner, and that was the only software available for acquiring data from a parallel port. A bit slow but usable. The same using a modern distro on that old hardware is no longer possible. So the feeling of being compatible with older hardware is just apparent. This is true for even non-graphics applications. Try just with apache, postfix, spamassassin, or even a simple modem-bridge with the only things doing is having a modem connected to a serial port running a getty and pppd for dialup access (that's the smallest application which comes to my mind).<br> +<br>So my point was that we were keeping flags holding the brakes for maintaining a compatibility which is just apparent. Current configuring tools are written in high level languages, like python, with a lot of other libraries, and they consumes a lot more memory than in the past. Even rendering the fonts consumes a lot more. xfs was even removed from standard installation.<br> +<br>Being compatible and usable with legacy system like that is certainly possible, but not in the current way. On the software side is even worst (e.g. some software removed in favour of other newer having the same capability). Maybe there could be created a section called "Legacy" for such kind of things, with much more testing.<br> +<br>Bye<br>Giuseppe.<br><br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/5b597a0c/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100926/5b597a0c/attachment-0001.html new file mode 100644 index 000000000..83225b576 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/5b597a0c/attachment-0001.html @@ -0,0 +1,76 @@ +2010/9/26 Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@iki.fi">tmb@iki.fi</a>></span><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Giuseppe Ghib� skrev 26.9.2010 02:09:<div class="im"><br> +<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Not exactly. I'm not talking in just using -march=<something> but in<br> +also pushing -mfpmath=sse -msse (and maybe -msse2) , which should be<br> +much more than JUST 1-2% (1-2% is usually the benchmark<br> +tolerance)...<br> +</blockquote> +<br></div> +Well, here is a simple fact.<br> +<br> +Yes, going for i686 + SSE2 would/could give some benefits,<br> +<br> +BUT<br> +<br> +It would close support for all theese:<br> +- Intel i586 (all)<br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +- Intel Pentium Pro<br> +- Intel Pentium II<br> +- Intel Pentium III (Including some Pentium D)<br> +- 32-bit AMD Athlon<br> +- AMD Geode<br> +- VIA C3<br> +- Transmeta Crusoe<br> +<br> +So, thats not an option.<br></blockquote><div><br>As I said I would see someone with such hardware, taking a CD of latest MDV or cooker and try to install to do something and do a report.<br><br>That� reminds me also one suggestion. If someone has old hardware that not in use anymore then could be donated to who is willing to test the latest MDV|Mageia on it. It's not ironic (I think this is a brainstorming), or I'm not kidding, but there could be an wiki hardware section for that. For old hardware schools and institutes or corporations have even to pay for dismantling:� such hardware is usually recycled for:<br> +<br>� a) extracting gold (there are nowadays new chemical processes that found more affordable to extract gold from old PCs than from mines)<br>� b) avoid pollutions with the lead, plastics they contain, if thrown in the dumpster etc. (note there isn't just the CPU, but also CRT monitors, printers, disks, etc.)<br> +<br>IIRC there is a EU law that if you buy a new PC the vendor is obeyed to retire the old one and take care for the dismantling.<br>�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> + +<br> +<br> +Now what about only i686 + SSE then?<br> +It would still close support for all theese:<br> +- Intel i586 (all)<br> +- Some Intel Pentium D<br> +- 32-bit AMD Athlon < XP/MP<br> +- AMD Geode < NX<br> +- VIA C3 (Samuel* and Ezra)<br> +- Transmeta Crusoe<br> +<br> +So, still not an option.<br> +<br> +<br> +Now what about only i686 then?<br> +It would still close support for all theese:<br> +- Intel i586 (all)<br> +- Some Intel Pentium D<br> +- AMD Geode < NX<br> +- VIA C3 (Samuel* and Ezra)<br> +- Transmeta Crusoe<br> +<br> +So, still not an option.<br> +<br> +<br> +And then to point out some other facts:<br> +<br> +Some of the benefits are already accounted for like you noted earlier:<div class="im"><br> +"Of course we shouldn't forget that the MDV had already a system for providing optimized (look at /usr/lib/sse2 for instance) version of libraries according to instruction set supported."<br> +<br></div> +And many applications capable of utilizing sse2 and other instruction sets already have runtime detection support, so no problem there.<br> +<br> +<br> +So, where does that leave us?<br> +<br> +Simple.<br> +For 32bit installs, we will still support i586 as base.<br> +For 64bit installs, it's simple as x86_64 is SSE2 by default.<br> +<br> +<br> +Now, _if_ the Mageia community gets enough developers to think of _and_ support a "light netbook/legacy edition", then maybe we can think of doing a i586/i686 split, but for now we will use i586 as base.<br> +<br> +<br> +And many of the users wanting i686/sse2 already have hardware capable of running x86_64, so that's what they should do, as there is where the future is.<br> +<br></blockquote></div><br>You are forgetting a midrange. Which is the midrange of not the latest hardware but a memory around 2-4GB RAM. In that set a 32bit OS is still consuming 30-50% fewer memory than 64bit.<br>As I said to complete the circle it is needed to provide on a per --target|dialect .rpm package for the kernel as well as for the glibc. We have just to ensure the targets and fix compilation errors (though that wouldn't resolve the problem of bloatware distro).<br> +<br>Bye<br>Giuseppe.<br><br> diff --git a/zarb-ml/mageia-dev/attachments/20100926/5b597a0c/attachment.html b/zarb-ml/mageia-dev/attachments/20100926/5b597a0c/attachment.html new file mode 100644 index 000000000..83225b576 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/5b597a0c/attachment.html @@ -0,0 +1,76 @@ +2010/9/26 Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@iki.fi">tmb@iki.fi</a>></span><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Giuseppe Ghib� skrev 26.9.2010 02:09:<div class="im"><br> +<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Not exactly. I'm not talking in just using -march=<something> but in<br> +also pushing -mfpmath=sse -msse (and maybe -msse2) , which should be<br> +much more than JUST 1-2% (1-2% is usually the benchmark<br> +tolerance)...<br> +</blockquote> +<br></div> +Well, here is a simple fact.<br> +<br> +Yes, going for i686 + SSE2 would/could give some benefits,<br> +<br> +BUT<br> +<br> +It would close support for all theese:<br> +- Intel i586 (all)<br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +- Intel Pentium Pro<br> +- Intel Pentium II<br> +- Intel Pentium III (Including some Pentium D)<br> +- 32-bit AMD Athlon<br> +- AMD Geode<br> +- VIA C3<br> +- Transmeta Crusoe<br> +<br> +So, thats not an option.<br></blockquote><div><br>As I said I would see someone with such hardware, taking a CD of latest MDV or cooker and try to install to do something and do a report.<br><br>That� reminds me also one suggestion. If someone has old hardware that not in use anymore then could be donated to who is willing to test the latest MDV|Mageia on it. It's not ironic (I think this is a brainstorming), or I'm not kidding, but there could be an wiki hardware section for that. For old hardware schools and institutes or corporations have even to pay for dismantling:� such hardware is usually recycled for:<br> +<br>� a) extracting gold (there are nowadays new chemical processes that found more affordable to extract gold from old PCs than from mines)<br>� b) avoid pollutions with the lead, plastics they contain, if thrown in the dumpster etc. (note there isn't just the CPU, but also CRT monitors, printers, disks, etc.)<br> +<br>IIRC there is a EU law that if you buy a new PC the vendor is obeyed to retire the old one and take care for the dismantling.<br>�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> + +<br> +<br> +Now what about only i686 + SSE then?<br> +It would still close support for all theese:<br> +- Intel i586 (all)<br> +- Some Intel Pentium D<br> +- 32-bit AMD Athlon < XP/MP<br> +- AMD Geode < NX<br> +- VIA C3 (Samuel* and Ezra)<br> +- Transmeta Crusoe<br> +<br> +So, still not an option.<br> +<br> +<br> +Now what about only i686 then?<br> +It would still close support for all theese:<br> +- Intel i586 (all)<br> +- Some Intel Pentium D<br> +- AMD Geode < NX<br> +- VIA C3 (Samuel* and Ezra)<br> +- Transmeta Crusoe<br> +<br> +So, still not an option.<br> +<br> +<br> +And then to point out some other facts:<br> +<br> +Some of the benefits are already accounted for like you noted earlier:<div class="im"><br> +"Of course we shouldn't forget that the MDV had already a system for providing optimized (look at /usr/lib/sse2 for instance) version of libraries according to instruction set supported."<br> +<br></div> +And many applications capable of utilizing sse2 and other instruction sets already have runtime detection support, so no problem there.<br> +<br> +<br> +So, where does that leave us?<br> +<br> +Simple.<br> +For 32bit installs, we will still support i586 as base.<br> +For 64bit installs, it's simple as x86_64 is SSE2 by default.<br> +<br> +<br> +Now, _if_ the Mageia community gets enough developers to think of _and_ support a "light netbook/legacy edition", then maybe we can think of doing a i586/i686 split, but for now we will use i586 as base.<br> +<br> +<br> +And many of the users wanting i686/sse2 already have hardware capable of running x86_64, so that's what they should do, as there is where the future is.<br> +<br></blockquote></div><br>You are forgetting a midrange. Which is the midrange of not the latest hardware but a memory around 2-4GB RAM. In that set a 32bit OS is still consuming 30-50% fewer memory than 64bit.<br>As I said to complete the circle it is needed to provide on a per --target|dialect .rpm package for the kernel as well as for the glibc. We have just to ensure the targets and fix compilation errors (though that wouldn't resolve the problem of bloatware distro).<br> +<br>Bye<br>Giuseppe.<br><br> diff --git a/zarb-ml/mageia-dev/attachments/20100926/7a9fabaf/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100926/7a9fabaf/attachment-0001.html new file mode 100644 index 000000000..602f7f1bf --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/7a9fabaf/attachment-0001.html @@ -0,0 +1,35 @@ +2010/9/26 Tux99 <span dir="ltr"><<a href="mailto:tux99-mga@uridium.org">tux99-mga@uridium.org</a>></span><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im"> +> memory only (use 1GB swap?)? Were you able to install the 2010.1?<br> +<br> +</div>Centos 4 installs and runs perfectly fine on a Pentium II 350Mhz with<br> +128MB RAM, I know it because I installed such a box for a friend as home<br> +server running 24/7 (with DNS server, apache and some other stuff).<br> +I didn't try Mandriva since it lacks long term support.<br> +<div class="im"><br></div></blockquote><div><br>Centos4 IS NOT a modern distro. It is a LTS started in 2005 and so it maintains 2005's original skeleton of kernel, gcc, glibc and X. That's FIVE years old. As example MDV 2007.1, which is 3 years old, was still very usable and responsive on my P4/ATI (maybe not as much as stable with 3D acceleration), but 2010.0 ISN'T.<br> +�</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"> +> Common where? There are schools and universities are dismitting hardware<br> +> like with P4/2.4Ghz and 512MB RAM for whatever use (either server or<br> +> desktop). And even older hardware no-ROHS, which should be dismantled<br> +> carefully.<br> +<br> +</div>You are seeing everything from a limited european POV, the P4 you say is<br> +being thrown away here is a top-end system in some other countries.<br> +Mageia is supposed to be for the whole world, not just EU/US/BRICs.<br></blockquote><div><br>I don't want to deprive the fun of building a router or a firewall from an old P133/64 with two ethernet cards, or some mediabox, but often you can't� (and sometimes you pay of energy power in a year much more than getting some 30-50E linksys ARM linux based router. And when soemone try such kind of attempts in the real world with your distro, will be very disappointed of failures. That's why I in some way asked a survey of oldest hardware based on own experiences.<br> +<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<br> +With regards to ISA cards, you can even still buy brand new modern mobos<br> +with ISA slots right here in Europe, they are still common for<br> +industrial uses:<br> +<a href="http://www.spectra.de/produkte/114184/web/spectra/Datenblatt-PMB-601LF.pdf?CFID=92074854-8638-47f6-a589-6517cde18fb1&CFTOKEN=0" target="_blank">http://www.spectra.de/produkte/114184/web/spectra/Datenblatt-PMB-601LF.pdf?CFID=92074854-8638-47f6-a589-6517cde18fb1&CFTOKEN=0</a><br> +</blockquote><div><br>Very interesting, but will such "industrial use" will be target for Mageia (BTW, certainly socket 775 CPU will support SSE and SSE2...)? If they have an ISA slot, I guess is for maintaning the compatibility with some old fancy (and maybe custom) card, certainly not for an ISA ethernet card that can be easily replaced with a cheap PCI one or the one on board.<br> +<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im"><br> +> I'm not speaking about exclusion but about including or optimizing for arch<br> +> and hardware that NOBODY will use anymore, because can't.<br> +<br> +</div>The optimization you are talking about (which will increase<br> +performance by a few percentage points at most, not noticeable at all<br> +in practice) means that the distro will be unusable for others.<br> +<div><div></div><br></div></blockquote><div>�<br>Not exactly. I'm not talking in just using -march=<something> but in also pushing -mfpmath=sse -msse (and maybe -msse2) , which should be much more than JUST 1-2% (1-2% is usually the benchmark tolerance)...Indeed the original idea was of having real .i586, .k6, .k7.rpm, .viac3, .viac7.rpm RPM packages, at least for the core ones: some time ago, when I was fighting with having a non-crashing kernel for the dedibox, I had started adding such "dialects" to the RPM macros (but problems were on the glibc package), but being realistic I think it's a lot of work and there aren't the resources, so a choice of the default flags should be done.<br> +<br>Bye<br>Giuseppe.<br><br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/7a9fabaf/attachment.html b/zarb-ml/mageia-dev/attachments/20100926/7a9fabaf/attachment.html new file mode 100644 index 000000000..602f7f1bf --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/7a9fabaf/attachment.html @@ -0,0 +1,35 @@ +2010/9/26 Tux99 <span dir="ltr"><<a href="mailto:tux99-mga@uridium.org">tux99-mga@uridium.org</a>></span><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im"> +> memory only (use 1GB swap?)? Were you able to install the 2010.1?<br> +<br> +</div>Centos 4 installs and runs perfectly fine on a Pentium II 350Mhz with<br> +128MB RAM, I know it because I installed such a box for a friend as home<br> +server running 24/7 (with DNS server, apache and some other stuff).<br> +I didn't try Mandriva since it lacks long term support.<br> +<div class="im"><br></div></blockquote><div><br>Centos4 IS NOT a modern distro. It is a LTS started in 2005 and so it maintains 2005's original skeleton of kernel, gcc, glibc and X. That's FIVE years old. As example MDV 2007.1, which is 3 years old, was still very usable and responsive on my P4/ATI (maybe not as much as stable with 3D acceleration), but 2010.0 ISN'T.<br> +�</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"> +> Common where? There are schools and universities are dismitting hardware<br> +> like with P4/2.4Ghz and 512MB RAM for whatever use (either server or<br> +> desktop). And even older hardware no-ROHS, which should be dismantled<br> +> carefully.<br> +<br> +</div>You are seeing everything from a limited european POV, the P4 you say is<br> +being thrown away here is a top-end system in some other countries.<br> +Mageia is supposed to be for the whole world, not just EU/US/BRICs.<br></blockquote><div><br>I don't want to deprive the fun of building a router or a firewall from an old P133/64 with two ethernet cards, or some mediabox, but often you can't� (and sometimes you pay of energy power in a year much more than getting some 30-50E linksys ARM linux based router. And when soemone try such kind of attempts in the real world with your distro, will be very disappointed of failures. That's why I in some way asked a survey of oldest hardware based on own experiences.<br> +<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<br> +With regards to ISA cards, you can even still buy brand new modern mobos<br> +with ISA slots right here in Europe, they are still common for<br> +industrial uses:<br> +<a href="http://www.spectra.de/produkte/114184/web/spectra/Datenblatt-PMB-601LF.pdf?CFID=92074854-8638-47f6-a589-6517cde18fb1&CFTOKEN=0" target="_blank">http://www.spectra.de/produkte/114184/web/spectra/Datenblatt-PMB-601LF.pdf?CFID=92074854-8638-47f6-a589-6517cde18fb1&CFTOKEN=0</a><br> +</blockquote><div><br>Very interesting, but will such "industrial use" will be target for Mageia (BTW, certainly socket 775 CPU will support SSE and SSE2...)? If they have an ISA slot, I guess is for maintaning the compatibility with some old fancy (and maybe custom) card, certainly not for an ISA ethernet card that can be easily replaced with a cheap PCI one or the one on board.<br> +<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im"><br> +> I'm not speaking about exclusion but about including or optimizing for arch<br> +> and hardware that NOBODY will use anymore, because can't.<br> +<br> +</div>The optimization you are talking about (which will increase<br> +performance by a few percentage points at most, not noticeable at all<br> +in practice) means that the distro will be unusable for others.<br> +<div><div></div><br></div></blockquote><div>�<br>Not exactly. I'm not talking in just using -march=<something> but in also pushing -mfpmath=sse -msse (and maybe -msse2) , which should be much more than JUST 1-2% (1-2% is usually the benchmark tolerance)...Indeed the original idea was of having real .i586, .k6, .k7.rpm, .viac3, .viac7.rpm RPM packages, at least for the core ones: some time ago, when I was fighting with having a non-crashing kernel for the dedibox, I had started adding such "dialects" to the RPM macros (but problems were on the glibc package), but being realistic I think it's a lot of work and there aren't the resources, so a choice of the default flags should be done.<br> +<br>Bye<br>Giuseppe.<br><br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment-0001.html new file mode 100644 index 000000000..3ebb256b9 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment-0001.html @@ -0,0 +1,16 @@ +<br><br><div class="gmail_quote">2010/9/26 nicolas vigier <span dir="ltr"><<a href="mailto:boklm@mars-attacks.org">boklm@mars-attacks.org</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im">On Sun, 26 Sep 2010, joris dedieu wrote:<br> +<br> +> 2010/9/26 Olivier Blin <<a href="mailto:mageia@blino.org">mageia@blino.org</a>>:<br> +> ><br> +</div><div class="im">> > Because there are some authentication and integrity issues which are not<br> +> > simple to solve: we have to be sure that the binary packages really come<br> +> > from the unmodified SRPM (so that it does not contains malware).<br> +><br> +> This can be avoid by<br> +> - building every package twice (also useful for integrity check)<br> +<br> +</div>Then you can still do it with two hosts adding malware instead of one.<br></blockquote><br>What this means? Two RPMs built at different time will result different, even the executable binaries when built on the same hardware at different time might be different (because of timestamps, etc.).<br> +<br>IMHO the idea of the cloud is not that bad but need to be rethinked. I don't see so much flaws for security. If you inspire to what repsys is right now, the cloud would be like having several svn repositories mirrored around the world each one with a local iurt/repsys building system (it might be even partial, e.g. there could be BIG ones holding the whole svn|git tree, and smaller one holding just the latest release or the latest two releases, etc.). Each building system around the world will sign packages they build with their own signing keys and you know where they come from. And packages won't be resigned by a supposed master. Of course you have to trust their administrators, exactly like you right now have to trust single users submitting sources to the svn and bulding packages.<br> +<br>The most difficult things IMHO would be building from the same syncronized data. In that case you might choose a master server and several mirrors. The master might have multiple internet access points (e.g. from two providers) and will be the only one who might receive svn commits. Or a model without a master, I guess inspiring to a model what UseNET is (was), I think a lot more complicate. But in that case you have two direction of feeding and if two libraries are submitted in different user in nearest time, you need a system to check for coerency and set alarms in some cases.<br> +<br>IMHO one of the building problems was not massive automatic rebuilding but avoid bottenlecks to the users when building goes wrong.<br><br>Bye<br>Giuseppe.<br><br></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment.html b/zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment.html new file mode 100644 index 000000000..3ebb256b9 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/88900d00/attachment.html @@ -0,0 +1,16 @@ +<br><br><div class="gmail_quote">2010/9/26 nicolas vigier <span dir="ltr"><<a href="mailto:boklm@mars-attacks.org">boklm@mars-attacks.org</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<div class="im">On Sun, 26 Sep 2010, joris dedieu wrote:<br> +<br> +> 2010/9/26 Olivier Blin <<a href="mailto:mageia@blino.org">mageia@blino.org</a>>:<br> +> ><br> +</div><div class="im">> > Because there are some authentication and integrity issues which are not<br> +> > simple to solve: we have to be sure that the binary packages really come<br> +> > from the unmodified SRPM (so that it does not contains malware).<br> +><br> +> This can be avoid by<br> +> - building every package twice (also useful for integrity check)<br> +<br> +</div>Then you can still do it with two hosts adding malware instead of one.<br></blockquote><br>What this means? Two RPMs built at different time will result different, even the executable binaries when built on the same hardware at different time might be different (because of timestamps, etc.).<br> +<br>IMHO the idea of the cloud is not that bad but need to be rethinked. I don't see so much flaws for security. If you inspire to what repsys is right now, the cloud would be like having several svn repositories mirrored around the world each one with a local iurt/repsys building system (it might be even partial, e.g. there could be BIG ones holding the whole svn|git tree, and smaller one holding just the latest release or the latest two releases, etc.). Each building system around the world will sign packages they build with their own signing keys and you know where they come from. And packages won't be resigned by a supposed master. Of course you have to trust their administrators, exactly like you right now have to trust single users submitting sources to the svn and bulding packages.<br> +<br>The most difficult things IMHO would be building from the same syncronized data. In that case you might choose a master server and several mirrors. The master might have multiple internet access points (e.g. from two providers) and will be the only one who might receive svn commits. Or a model without a master, I guess inspiring to a model what UseNET is (was), I think a lot more complicate. But in that case you have two direction of feeding and if two libraries are submitted in different user in nearest time, you need a system to check for coerency and set alarms in some cases.<br> +<br>IMHO one of the building problems was not massive automatic rebuilding but avoid bottenlecks to the users when building goes wrong.<br><br>Bye<br>Giuseppe.<br><br></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/a8609cf4/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100926/a8609cf4/attachment-0001.html new file mode 100644 index 000000000..d146304cf --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/a8609cf4/attachment-0001.html @@ -0,0 +1,115 @@ +2010/9/26 andr� <span dir="ltr"><<a href="mailto:andr55@laposte.net">andr55@laposte.net</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Thomas Backlund a �crit :<div><div></div><div class="h5"><br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<br> +Giuseppe Ghib� skrev 26.9.2010 14:59:<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +2010/9/26 Thomas Backlund <<a href="mailto:tmb@iki.fi" target="_blank">tmb@iki.fi</a> <mailto:<a href="mailto:tmb@iki.fi" target="_blank">tmb@iki.fi</a>>><br> +<br> + � �Giuseppe Ghib� skrev 26.9.2010 02:09:<br> +><br> +<br> + � � � �I don't want to deprive the fun of building a router or a<br> + � � � �firewall from<br> +<br> + � � � �an old P133/64 with two ethernet cards, or some mediabox, but<br> + � � � �often you<br> + � � � �can't �(and sometimes you pay of energy power in a year much<br> + � � � �more than<br> + � � � �getting some 30-50E linksys ARM linux based router. And when<br> + � � � �soemone try<br> + � � � �such kind of attempts in the real world with your distro, will<br> + � � � �be very<br> + � � � �disappointed of failures. That's why I in some way asked a survey of<br> + � � � �oldest hardware based on own experiences.<br> +<br> +<br> + � �You still miss the point that in Mageia community there are many<br> + � �users that find 30-50e a _lot_ of money, and we dont want to shut<br> + � �them out.<br> +<br> +<br> +I'm not decreasing the value of the money, but rather I was pointing out<br> +the false assumption that mageia (or the current inherited mandriva)<br> +would work and would work FINE (or at all) on that hardware just because<br> +it was using a compatible instruction set.<br> +</blockquote> +<br> +Well, it depends of what you consider "FINE".<br> +I dont expect people using old hardware to try to get KDE or any 3d stuff to work "FINE".<br> +<br> +But we have lightweight platforms such as lxde and xfce that both works moderate/fast on a 200MHz+ platform with 128MB+ RAM.<br> +<br> +Then if you want it as a server, its even easier... you dont even need a DE/GUI, as it's manageable through console/shell.<br> +<br> +<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +I'm not against this, but if<br> +that we wanna support that kind of hardware there is MUCH MORE work to<br> +do (I suggested a LEGACY section in the wiki, but seems it wasn't<br> +caught) than just keeping the actual flags, because in that way if we<br> +don't change then nobody will complain. Even the simple lzma payload of<br> +rpm packages requires much more memory than in the past with gzip. I'm<br> +not sure with current squashfs for the initial ram disks.<br> +<br> +I already cited there are other distro which maybe do a lot better this<br> +job. In many countries there isn't even the broadband, dialup, nor the<br> +electrical power for them. Right now you are almost assuming that a 10<br> +years old instruction set is still a no go, and that our distro is<br> +optimized like the one of the One Laptop Per Child Project.<br> +</blockquote> +<br> +I know we dont optimize for OLPC.<br> +<br> +Yes, the instruction set is old, but there are many systems that are older. and even if the hw is newer, it still does not enforce full i686 spec, as seen for example with either missing CMOV or another broken register. Even Intel got it wrong with some series of the Pentium D wich didn't work with i686 series builds...<br> + +<br> +<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Sadly it<br> +isn't. But there is also a 2nd point: on old hardware it is still<br> +possible to run old software and old distros: strange but true. Such old<br> +software is still doing its dirty job. It's not that you get a trojan as<br> +soon as you put the nose out the net. There are still ways of<br> +configuring a distro on a LAN and trust in the people using the<br> +terminals locally. Many schools still use them. In a 2 hours lesson at<br> +school you can't wait half an our just to have your desktop booting...,<br> +</blockquote> +<br> +It does not take half an hour if you use xfce/lxde.<br> +<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +the same if you plan an antispam server with latest antispam tools on a<br> +server of that category (server that was doing it's dirty job with the<br> +distro of 2 or 3 generations ago).<br> +<br> +</blockquote> +<br> +Oh, I know several servers out there running on i586 ~200Mhz that has no problem what so ever keeping up with the spam/av filtering.<br> +<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +I also tried such old hardware, but there are much less bloated distro<br> +and less bloated kernels (even non-linux ones) that do the job (or a<br> +specific duty) on such hardware a lot better than ours.<br> +<br> +</blockquote> +<br> +Maybe so, but does that mean we should force them to _not_ use Mageia ?<br> +<br> +-- <br> +Thomas<br> +____<br> +</blockquote></div></div> +To cease support for i586 seems to me to be the height of arrogance.<br></blockquote><div><br>The height of arrogance? C'mon you are seeing politics (like the apology the culture of the waste...or a reverse robin hood which stoles CPU cycles to poor CPU to give to rich ones) where there isn't.<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +If new i586-level hardware can still be bought somewhere in the world, it is still current hardware.<br></blockquote><div><br>Also i386 and i486 hardware can still bought somewhere (including ebay) and maybe one want to run. Why we don't lower to i386 compatatibility set instead of i586? IIRC the i586 origin was to give something more optimized than what was the average distro like RH. But maybe this could be changed.<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +And look at how many 5-year-old, and even 10-year-old, cars are still in use. �Since cars have inherently a much shorter life, computers bought new 5 years ago, or even 10 years ago, should be still be considered current hardware. �It doesn't really matter if most users - </blockquote> +<div><br>There are many places in the world where old cars can't circulate anymore or have restrictions in the zone where they are allowed to circulate (because of laws according to the engine classification they are on). Maybe it's a lobby of car vendors to sell new cars dunno. BTW, I've an old car. But the car analogy is not appropriate because you can still use the car to reach a place at a certain average speed and with certain safety levels (e.g. is compliant against safety belts) not much different than the one of the latest shining EURO5 models� (also due to speed limits). Apart this, cars don't have a shorter life than PCs. While indeed I've seen many motherboard and hard disks dying after a much shorter period of time (and repairing would cost much more than buying a new one). Surviving ones on a such long period of time were just very expensive one (at the time they were new) which had a very good maintenance. In percentage almost all the MSI motherboards died after 5-6 years (maybe after 2 or 3). Gigabyte were similar. ASUS had the lowest percentage of failure. Intel motherboard were too expensive to buy.<br> +<br>Furthermore many new i586 solution are of much more elitism than newer hardware. A newer mini-itx with a VIA CPU doesn't cost less than an entry level CPU of AMD (which arrives at SSE4.1 or more SIMD set) and an all-in-one motherboard. And even hardware with some particular slot support (like ISA) doesn't costs less than one having just a PCI + PCIe slot.<br> +<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">concentrated in the richer countries - have much more powerful hardware. �As has already been pointed out, there is 64-bit support, and a i686 compilation of the kernel to satisfy those with newer hardware that can't (32-bit processor or not enough memory) or prefer not to use the 64-bit compilations.<br> + +Note that the kernel is probably where most of the performance gains are to be made with i686, so dropping i586 in favour of i686 would give little in performance gains.<br> +After all, don't we want almost everyone to be able to use Mageia ?<br></blockquote><div><br>Of course, but it's not a panacea that runs everywhere. My initial post was that we were still keeping a brake on and keeping compatibility for things that NOBODY will use or CAN'T USE for technical reasons. NOBODY means ZERO, NICHT, NADA, NOTHING. If there is at least ONE, then it's not ZERO anymore.<br> +<br>So my post was to keep a BETTER support for old and legacy hardware, not just CLAIM there is where INDEED there ISN'T or there couldn't be (because for instance there isn't enough memory to run the installer) or that NOBODY has TESTED for several reasons.<br> +<br>Bye<br>Giuseppe.<br><br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/a8609cf4/attachment.html b/zarb-ml/mageia-dev/attachments/20100926/a8609cf4/attachment.html new file mode 100644 index 000000000..d146304cf --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/a8609cf4/attachment.html @@ -0,0 +1,115 @@ +2010/9/26 andr� <span dir="ltr"><<a href="mailto:andr55@laposte.net">andr55@laposte.net</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Thomas Backlund a �crit :<div><div></div><div class="h5"><br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<br> +Giuseppe Ghib� skrev 26.9.2010 14:59:<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +2010/9/26 Thomas Backlund <<a href="mailto:tmb@iki.fi" target="_blank">tmb@iki.fi</a> <mailto:<a href="mailto:tmb@iki.fi" target="_blank">tmb@iki.fi</a>>><br> +<br> + � �Giuseppe Ghib� skrev 26.9.2010 02:09:<br> +><br> +<br> + � � � �I don't want to deprive the fun of building a router or a<br> + � � � �firewall from<br> +<br> + � � � �an old P133/64 with two ethernet cards, or some mediabox, but<br> + � � � �often you<br> + � � � �can't �(and sometimes you pay of energy power in a year much<br> + � � � �more than<br> + � � � �getting some 30-50E linksys ARM linux based router. And when<br> + � � � �soemone try<br> + � � � �such kind of attempts in the real world with your distro, will<br> + � � � �be very<br> + � � � �disappointed of failures. That's why I in some way asked a survey of<br> + � � � �oldest hardware based on own experiences.<br> +<br> +<br> + � �You still miss the point that in Mageia community there are many<br> + � �users that find 30-50e a _lot_ of money, and we dont want to shut<br> + � �them out.<br> +<br> +<br> +I'm not decreasing the value of the money, but rather I was pointing out<br> +the false assumption that mageia (or the current inherited mandriva)<br> +would work and would work FINE (or at all) on that hardware just because<br> +it was using a compatible instruction set.<br> +</blockquote> +<br> +Well, it depends of what you consider "FINE".<br> +I dont expect people using old hardware to try to get KDE or any 3d stuff to work "FINE".<br> +<br> +But we have lightweight platforms such as lxde and xfce that both works moderate/fast on a 200MHz+ platform with 128MB+ RAM.<br> +<br> +Then if you want it as a server, its even easier... you dont even need a DE/GUI, as it's manageable through console/shell.<br> +<br> +<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +I'm not against this, but if<br> +that we wanna support that kind of hardware there is MUCH MORE work to<br> +do (I suggested a LEGACY section in the wiki, but seems it wasn't<br> +caught) than just keeping the actual flags, because in that way if we<br> +don't change then nobody will complain. Even the simple lzma payload of<br> +rpm packages requires much more memory than in the past with gzip. I'm<br> +not sure with current squashfs for the initial ram disks.<br> +<br> +I already cited there are other distro which maybe do a lot better this<br> +job. In many countries there isn't even the broadband, dialup, nor the<br> +electrical power for them. Right now you are almost assuming that a 10<br> +years old instruction set is still a no go, and that our distro is<br> +optimized like the one of the One Laptop Per Child Project.<br> +</blockquote> +<br> +I know we dont optimize for OLPC.<br> +<br> +Yes, the instruction set is old, but there are many systems that are older. and even if the hw is newer, it still does not enforce full i686 spec, as seen for example with either missing CMOV or another broken register. Even Intel got it wrong with some series of the Pentium D wich didn't work with i686 series builds...<br> + +<br> +<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Sadly it<br> +isn't. But there is also a 2nd point: on old hardware it is still<br> +possible to run old software and old distros: strange but true. Such old<br> +software is still doing its dirty job. It's not that you get a trojan as<br> +soon as you put the nose out the net. There are still ways of<br> +configuring a distro on a LAN and trust in the people using the<br> +terminals locally. Many schools still use them. In a 2 hours lesson at<br> +school you can't wait half an our just to have your desktop booting...,<br> +</blockquote> +<br> +It does not take half an hour if you use xfce/lxde.<br> +<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +the same if you plan an antispam server with latest antispam tools on a<br> +server of that category (server that was doing it's dirty job with the<br> +distro of 2 or 3 generations ago).<br> +<br> +</blockquote> +<br> +Oh, I know several servers out there running on i586 ~200Mhz that has no problem what so ever keeping up with the spam/av filtering.<br> +<br> +<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +I also tried such old hardware, but there are much less bloated distro<br> +and less bloated kernels (even non-linux ones) that do the job (or a<br> +specific duty) on such hardware a lot better than ours.<br> +<br> +</blockquote> +<br> +Maybe so, but does that mean we should force them to _not_ use Mageia ?<br> +<br> +-- <br> +Thomas<br> +____<br> +</blockquote></div></div> +To cease support for i586 seems to me to be the height of arrogance.<br></blockquote><div><br>The height of arrogance? C'mon you are seeing politics (like the apology the culture of the waste...or a reverse robin hood which stoles CPU cycles to poor CPU to give to rich ones) where there isn't.<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +If new i586-level hardware can still be bought somewhere in the world, it is still current hardware.<br></blockquote><div><br>Also i386 and i486 hardware can still bought somewhere (including ebay) and maybe one want to run. Why we don't lower to i386 compatatibility set instead of i586? IIRC the i586 origin was to give something more optimized than what was the average distro like RH. But maybe this could be changed.<br> +�<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +And look at how many 5-year-old, and even 10-year-old, cars are still in use. �Since cars have inherently a much shorter life, computers bought new 5 years ago, or even 10 years ago, should be still be considered current hardware. �It doesn't really matter if most users - </blockquote> +<div><br>There are many places in the world where old cars can't circulate anymore or have restrictions in the zone where they are allowed to circulate (because of laws according to the engine classification they are on). Maybe it's a lobby of car vendors to sell new cars dunno. BTW, I've an old car. But the car analogy is not appropriate because you can still use the car to reach a place at a certain average speed and with certain safety levels (e.g. is compliant against safety belts) not much different than the one of the latest shining EURO5 models� (also due to speed limits). Apart this, cars don't have a shorter life than PCs. While indeed I've seen many motherboard and hard disks dying after a much shorter period of time (and repairing would cost much more than buying a new one). Surviving ones on a such long period of time were just very expensive one (at the time they were new) which had a very good maintenance. In percentage almost all the MSI motherboards died after 5-6 years (maybe after 2 or 3). Gigabyte were similar. ASUS had the lowest percentage of failure. Intel motherboard were too expensive to buy.<br> +<br>Furthermore many new i586 solution are of much more elitism than newer hardware. A newer mini-itx with a VIA CPU doesn't cost less than an entry level CPU of AMD (which arrives at SSE4.1 or more SIMD set) and an all-in-one motherboard. And even hardware with some particular slot support (like ISA) doesn't costs less than one having just a PCI + PCIe slot.<br> +<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">concentrated in the richer countries - have much more powerful hardware. �As has already been pointed out, there is 64-bit support, and a i686 compilation of the kernel to satisfy those with newer hardware that can't (32-bit processor or not enough memory) or prefer not to use the 64-bit compilations.<br> + +Note that the kernel is probably where most of the performance gains are to be made with i686, so dropping i586 in favour of i686 would give little in performance gains.<br> +After all, don't we want almost everyone to be able to use Mageia ?<br></blockquote><div><br>Of course, but it's not a panacea that runs everywhere. My initial post was that we were still keeping a brake on and keeping compatibility for things that NOBODY will use or CAN'T USE for technical reasons. NOBODY means ZERO, NICHT, NADA, NOTHING. If there is at least ONE, then it's not ZERO anymore.<br> +<br>So my post was to keep a BETTER support for old and legacy hardware, not just CLAIM there is where INDEED there ISN'T or there couldn't be (because for instance there isn't enough memory to run the installer) or that NOBODY has TESTED for several reasons.<br> +<br>Bye<br>Giuseppe.<br><br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20100926/cfffe5e1/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20100926/cfffe5e1/attachment-0001.html new file mode 100644 index 000000000..bbddb279a --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/cfffe5e1/attachment-0001.html @@ -0,0 +1,49 @@ +I would love a server concept too and I have some ideas that could be very interresting for the community using mageia as server.<br><br>If a server team should start, please count me in.<br><br>greetings from Belgium, Sascha<br> +<br><div class="gmail_quote">2010/9/20 Samuel Verschelde <span dir="ltr"><<a href="mailto:samuel.verschelde@pmsipilot.com">samuel.verschelde@pmsipilot.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Le lundi 20 septembre 2010 09:42:12, Bersuit Vera a �crit :<br> +> �Hi<br> +><br> +> I'm also very interested in Server packages. �Did anyone speak with Oden?<br> +> Mandr�va server packages has always been very stable. In my opinion mageia<br> +> should mantain and boost this line.<br> +> Mageia must be a great server distro<br> +> For server packager/tester/bug reporting team, count me in!<br> +> Bersuit.<br> +><br> +><br> +> 2010/9/20 Gergely L�nyai <<a href="mailto:gergely@lonyai.com">gergely@lonyai.com</a>><br> +><br> +> > Hi,<br> +> ><br> +> > Have we got a conception to server packages? I have some server and my<br> +> > work required me to package/recompile some server related package<br> +> > I torn between Mageia and Mandriva:<br> +> > �- I don't know what does the mandriva (the official new is in France<br> +> > lang), but they want to do strong the server side, and most friend came<br> +> > here.<br> +> > �- If the Mageia fork the server side (without Oden) with a right<br> +> > conception then I connect this community.<br> +> > If the quality don't guaranteed then I need stand to Mandriva (or<br> +> > CentOS).<br> +> ><br> +> ><br> +> > Let's go:<br> +> > Aleph<br> +> ><br> +> > _______________________________________________<br> +> > Mageia-dev mailing list<br> +> > <a href="mailto:Mageia-dev@mageia.org">Mageia-dev@mageia.org</a><br> +> > <a href="https://www.mageia.org/mailman/listinfo/mageia-dev" target="_blank">https://www.mageia.org/mailman/listinfo/mageia-dev</a><br> +> ><br> +><br> +<br> +Server packages are also important for me, I really hope there will be a team of contributors around this.<br> +<br> +Regards<br> +<br> +Samuel<br> +_______________________________________________<br> +Mageia-dev mailing list<br> +<a href="mailto:Mageia-dev@mageia.org">Mageia-dev@mageia.org</a><br> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev" target="_blank">https://www.mageia.org/mailman/listinfo/mageia-dev</a><br> +</blockquote></div><br> diff --git a/zarb-ml/mageia-dev/attachments/20100926/cfffe5e1/attachment.html b/zarb-ml/mageia-dev/attachments/20100926/cfffe5e1/attachment.html new file mode 100644 index 000000000..bbddb279a --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20100926/cfffe5e1/attachment.html @@ -0,0 +1,49 @@ +I would love a server concept too and I have some ideas that could be very interresting for the community using mageia as server.<br><br>If a server team should start, please count me in.<br><br>greetings from Belgium, Sascha<br> +<br><div class="gmail_quote">2010/9/20 Samuel Verschelde <span dir="ltr"><<a href="mailto:samuel.verschelde@pmsipilot.com">samuel.verschelde@pmsipilot.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Le lundi 20 septembre 2010 09:42:12, Bersuit Vera a �crit :<br> +> �Hi<br> +><br> +> I'm also very interested in Server packages. �Did anyone speak with Oden?<br> +> Mandr�va server packages has always been very stable. In my opinion mageia<br> +> should mantain and boost this line.<br> +> Mageia must be a great server distro<br> +> For server packager/tester/bug reporting team, count me in!<br> +> Bersuit.<br> +><br> +><br> +> 2010/9/20 Gergely L�nyai <<a href="mailto:gergely@lonyai.com">gergely@lonyai.com</a>><br> +><br> +> > Hi,<br> +> ><br> +> > Have we got a conception to server packages? I have some server and my<br> +> > work required me to package/recompile some server related package<br> +> > I torn between Mageia and Mandriva:<br> +> > �- I don't know what does the mandriva (the official new is in France<br> +> > lang), but they want to do strong the server side, and most friend came<br> +> > here.<br> +> > �- If the Mageia fork the server side (without Oden) with a right<br> +> > conception then I connect this community.<br> +> > If the quality don't guaranteed then I need stand to Mandriva (or<br> +> > CentOS).<br> +> ><br> +> ><br> +> > Let's go:<br> +> > Aleph<br> +> ><br> +> > _______________________________________________<br> +> > Mageia-dev mailing list<br> +> > <a href="mailto:Mageia-dev@mageia.org">Mageia-dev@mageia.org</a><br> +> > <a href="https://www.mageia.org/mailman/listinfo/mageia-dev" target="_blank">https://www.mageia.org/mailman/listinfo/mageia-dev</a><br> +> ><br> +><br> +<br> +Server packages are also important for me, I really hope there will be a team of contributors around this.<br> +<br> +Regards<br> +<br> +Samuel<br> +_______________________________________________<br> +Mageia-dev mailing list<br> +<a href="mailto:Mageia-dev@mageia.org">Mageia-dev@mageia.org</a><br> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev" target="_blank">https://www.mageia.org/mailman/listinfo/mageia-dev</a><br> +</blockquote></div><br> |