Menu
▾
▴
devil-linux-develop
|
From: Heiko Z. <hz...@pr...> - 2003-06-17 19:43:45
|
On 06/17/2003 03:25:50 PM Bruce Smith wrote: >In menuconfig, submenu: "Build System Configuration", there is an opti= on >that allows you to select your CPU. I've been building all of my beta= s >as i686 because my home firewall is a celeron. > >It _appears_ the CPU option only effects the kernel compile, and it >would seem like all heavily used packages would benefit from this. *beep* wrong ! ;-) Take a look at scripts/prepare and search for "uname" ( without the quo= tes *lol*). The complete DL System is build for the specific CPU. >FWIW, The following Redhat packages come with optional i686 RPM's: >kernel, glibc and openssl. > >It would seem like the DL CPU option should apply to at least all thre= e >of those packages. (and it appears not to effect any of them, as far = as >I can tell) At least.... ;-) >Is this something we should change? Nope ;-) cya Heiko = |
|
From: Heiko Z. <hz...@pr...> - 2003-06-17 20:44:10
|
On 06/17/2003 03:58:11 PM Bruce Smith wrote: >> >In menuconfig, submenu: "Build System Configuration", there is an >option >> >that allows you to select your CPU. I've been building all of my >betas >> >as i686 because my home firewall is a celeron. >> > >> >It _appears_ the CPU option only effects the kernel compile... >> >> *beep* wrong ! ;-) > >Not the first time, or the last! :-) Look who you're talking to. (Hope it's right, I learned this one yesterday) >> Take a look at scripts/prepare and search for "uname" ( without the >quotes >> *lol*). The complete DL System is build for the specific CPU. > >Are you sure it's working? I was watching openssl & glibc both compil= e >on my screen, and I never say anything that looked like: -march i686 >or any gcc parameter containing "686" (except for the kernel). Hmmm.....checking...checking.....checking....executing: ./scripts/build= .sh build opt=3Dopenssh Ok, the host-type and build-system-type in the configure part is correc= t, but I don't see any -march=3D686 either. Question: doesn't gcc use the architecture it was compiled for, when yo= u don't specify anything? I'm getting a bit confused now.... >Not to mention the comment near "uname", only says "kernel". :-) That most be Friedrichs fault, I never do any mistakes. It's just a typ= e anyway.... ;-) cya Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-06-17 20:56:19
|
> >> Take a look at scripts/prepare and search for "uname" ( without the > >quotes > >> *lol*). The complete DL System is build for the specific CPU. > > > >Are you sure it's working? I was watching openssl & glibc both compile > >on my screen, and I never say anything that looked like: -march i686 > >or any gcc parameter containing "686" (except for the kernel). > > Hmmm.....checking...checking.....checking....executing: ./scripts/build.sh > build opt=openssh > Ok, the host-type and build-system-type in the configure part is correct, > but I don't see any -march=686 either. > Question: doesn't gcc use the architecture it was compiled for, when you > don't specify anything? I don't know. I'm far from being a gcc expert. > I'm getting a bit confused now.... Welcome to the club! :-) I've been reading the gcc man page, looking at gcc.gnu.org docs, and searching the newsgroups. The most useful thing I found so far is "gcc -v" tells what "spec" file it uses for default options. I looked at that file, but all the fancy substitution stuff is over my head. It may be using i686 optimization (in my case), but I don't know how to confirm or deny it. - BS |
|
From: Heiko Z. <he...@zu...> - 2003-06-17 22:20:20
|
Bruce Smith wrote: >>>>Take a look at scripts/prepare and search for "uname" ( without the >>> >>>quotes >>> >>>>*lol*). The complete DL System is build for the specific CPU. >>> >>>Are you sure it's working? I was watching openssl & glibc both compile >>>on my screen, and I never say anything that looked like: -march i686 >>>or any gcc parameter containing "686" (except for the kernel). >> >>Hmmm.....checking...checking.....checking....executing: ./scripts/build.sh >>build opt=openssh >>Ok, the host-type and build-system-type in the configure part is correct, >>but I don't see any -march=686 either. >>Question: doesn't gcc use the architecture it was compiled for, when you >>don't specify anything? > > > I don't know. I'm far from being a gcc expert. same here >>I'm getting a bit confused now.... > > > Welcome to the club! :-) > > I've been reading the gcc man page, looking at gcc.gnu.org docs, and > searching the newsgroups. > > The most useful thing I found so far is "gcc -v" tells what "spec" file > it uses for default options. I looked at that file, but all the fancy > substitution stuff is over my head. > > It may be using i686 optimization (in my case), but I don't know how to > confirm or deny it. Let's hope somebody on this list has the answer to this. cya Heiko |
|
From: John v. V. <joh...@ya...> - 2003-06-17 22:33:31
|
Well... I am not sure if this will help, but I am going to try to start developing inside the BOCHS emulator using DL and then moving onto a uClibc version that I will call SOY. I am not sure if I will have success, but you guys have VMWare (jealous) John --- Heiko Zuerker <he...@zu...> wrote: > Bruce Smith wrote: > >>>>Take a look at scripts/prepare and search for "uname" ( without the > >>> > >>>quotes > >>> > >>>>*lol*). The complete DL System is build for the specific CPU. > >>> > >>>Are you sure it's working? I was watching openssl & glibc both compile > >>>on my screen, and I never say anything that looked like: -march i686 > >>>or any gcc parameter containing "686" (except for the kernel). > >> > >>Hmmm.....checking...checking.....checking....executing: ./scripts/build.sh > >>build opt=openssh > >>Ok, the host-type and build-system-type in the configure part is correct, > >>but I don't see any -march=686 either. > >>Question: doesn't gcc use the architecture it was compiled for, when you > >>don't specify anything? > > > > > > I don't know. I'm far from being a gcc expert. > > same here > > >>I'm getting a bit confused now.... > > > > > > Welcome to the club! :-) > > > > I've been reading the gcc man page, looking at gcc.gnu.org docs, and > > searching the newsgroups. > > > > The most useful thing I found so far is "gcc -v" tells what "spec" file > > it uses for default options. I looked at that file, but all the fancy > > substitution stuff is over my head. > > > > It may be using i686 optimization (in my case), but I don't know how to > > confirm or deny it. > > Let's hope somebody on this list has the answer to this. > > cya > Heiko > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > > ===== CXN, Inc. Contact: jo...@th... President, The Linux Society http://groups.yahoo.com/group/linux-society linux society distro -> http://www.thinman.com/eLSD/readme ThinMan is a registered trademark of CXN, Inc __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: John K. <jk...@sa...> - 2003-06-22 17:12:54
|
Hey John, I've already started on a uClibc verson of Devil Linux. And when I mean started, it just means I've worked out the best way to start this adventure and keeping it compatible with the big daddy distro of Devil Linux. I've scheduled this to start July 15th. I was also planning to call this uDL or Micro Devil Linux. It will target not only PC's but embedded targets and cross compilation for other micro processors as well, eg. ARM. Media types will include ISO, CompactFlash, SmartMedia and JFFS2. Steps Involved 1) Create a branch off of the main Devil Linux. Of course after approval from the head DL developers 2) Create a new LFS system, build around uClibc and not glibc * Also would be configured for cross compilation 3) Add the uClibc package into the source tree. 4) Compile Packages against uClibc and make any changes to build and source. **** This is the hardest part. I'll be putting together a project proposal to share with everyone on the mailing list. One question that may be asked is why, why start with Devil Linux? The answer is simple, the people/developers resonsible for putting together the /build system have done an excellent job. It's simple, easy to configure and change without huge structual changes. The other reason, last but not least, is the documentation on the website, that in my opinion is what really makes DL progress. Cheers John On Tue, 2003-06-17 at 18:33, John van V. wrote: > Well... I am not sure if this will help, but I am going to try to start > developing inside the BOCHS emulator using DL and then moving onto a uClibc > version that I will call SOY. I am not sure if I will have success, but you > guys have VMWare (jealous) > > John > > > --- Heiko Zuerker <he...@zu...> wrote: > > Bruce Smith wrote: > > >>>>Take a look at scripts/prepare and search for "uname" ( without the > > >>> > > >>>quotes > > >>> > > >>>>*lol*). The complete DL System is build for the specific CPU. > > >>> > > >>>Are you sure it's working? I was watching openssl & glibc both compile > > >>>on my screen, and I never say anything that looked like: -march i686 > > >>>or any gcc parameter containing "686" (except for the kernel). > > >> > > >>Hmmm.....checking...checking.....checking....executing: ./scripts/build.sh > > >>build opt=openssh > > >>Ok, the host-type and build-system-type in the configure part is correct, > > >>but I don't see any -march=686 either. > > >>Question: doesn't gcc use the architecture it was compiled for, when you > > >>don't specify anything? > > > > > > > > > I don't know. I'm far from being a gcc expert. > > > > same here > > > > >>I'm getting a bit confused now.... > > > > > > > > > Welcome to the club! :-) > > > > > > I've been reading the gcc man page, looking at gcc.gnu.org docs, and > > > searching the newsgroups. > > > > > > The most useful thing I found so far is "gcc -v" tells what "spec" file > > > it uses for default options. I looked at that file, but all the fancy > > > substitution stuff is over my head. > > > > > > It may be using i686 optimization (in my case), but I don't know how to > > > confirm or deny it. > > > > Let's hope somebody on this list has the answer to this. > > > > cya > > Heiko > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: INetU > > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > > _______________________________________________ > > Devil-linux-develop mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > > > > > > > ===== > CXN, Inc. Contact: jo...@th... > President, The Linux Society > http://groups.yahoo.com/group/linux-society > linux society distro -> http://www.thinman.com/eLSD/readme > ThinMan is a registered trademark of CXN, Inc > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop -- John Kiss <jk...@sa...> |
|
From: Heiko Z. <he...@zu...> - 2003-06-22 18:25:18
|
John Kiss wrote: > Hey John, > > I've already started on a uClibc verson of Devil Linux. And when I mean > started, it just means I've worked out the best way to start this > adventure and keeping it compatible with the big daddy distro of Devil > Linux. I've scheduled this to start July 15th. I was also planning to > call this uDL or Micro Devil Linux. It will target not only PC's but > embedded targets and cross compilation for other micro processors as > well, eg. ARM. Media types will include ISO, CompactFlash, SmartMedia > and JFFS2. > > Steps Involved > > 1) Create a branch off of the main Devil Linux. > Of course after approval from the head DL developers > 2) Create a new LFS system, build around uClibc and not glibc > * Also would be configured for cross compilation > 3) Add the uClibc package into the source tree. > 4) Compile Packages against uClibc and make any changes to > build and source. > **** This is the hardest part. > > I'll be putting together a project proposal to share with everyone on > the mailing list. > > One question that may be asked is why, why start with Devil Linux? > The answer is simple, the people/developers resonsible for putting > together the /build system have done an excellent job. It's simple, easy > to configure and change without huge structual changes. The other > reason, last but not least, is the documentation on the website, that in > my opinion is what really makes DL progress. I think it would make a lot of sense to incorporate those changes into the main build system, you just select glibc or uclibc via "make menuconfig". I'm pretty confident that it should be easy to incorporate all those changes into our build system. I also don't think it is necessary to create a new LFS System, all the important parts (gcc, glibc, binutils) are compiled by us anyway. Probably we just have to add a few more programs. The thing you would have problems with is the cross-compile. Currently (only theoratical) the only way to compile for a different plattform is to work on that plattform. OK, in that cause you'll need a new LFS system. By incorporating those changes into the main build system, we all benefit from eachothers developments and progress much faster then others. We could define those changes as a goal for v2.0, I'm sure it'll take a while until you get everything running. cya Heiko P.S. Devil-Linux on a Linksys or Netgear Router.... sounds cool! |
|
From: John K. <jk...@sa...> - 2003-06-22 19:09:52
|
On Sun, 2003-06-22 at 14:22, Heiko Zuerker wrote: > John Kiss wrote: > > Hey John, > > > > I've already started on a uClibc verson of Devil Linux. And when I mean > > started, it just means I've worked out the best way to start this > > adventure and keeping it compatible with the big daddy distro of Devil > > Linux. I've scheduled this to start July 15th. I was also planning to > > call this uDL or Micro Devil Linux. It will target not only PC's but > > embedded targets and cross compilation for other micro processors as > > well, eg. ARM. Media types will include ISO, CompactFlash, SmartMedia > > and JFFS2. > > > > Steps Involved > > > > 1) Create a branch off of the main Devil Linux. > > Of course after approval from the head DL developers > > 2) Create a new LFS system, build around uClibc and not glibc > > * Also would be configured for cross compilation > > 3) Add the uClibc package into the source tree. > > 4) Compile Packages against uClibc and make any changes to > > build and source. > > **** This is the hardest part. > > > > I'll be putting together a project proposal to share with everyone on > > the mailing list. > > > > One question that may be asked is why, why start with Devil Linux? > > The answer is simple, the people/developers resonsible for putting > > together the /build system have done an excellent job. It's simple, easy > > to configure and change without huge structual changes. The other > > reason, last but not least, is the documentation on the website, that in > > my opinion is what really makes DL progress. > > I think it would make a lot of sense to incorporate those changes into > the main build system, you just select glibc or uclibc via "make > menuconfig". I'm pretty confident that it should be easy to incorporate > all those changes into our build system. Ohh for sure, why maintain two main branchs?? The only reason why I suggested a branch is for development purposes. Once it's at a stage that can compile both ISO and other media targets then it can be merged into the mainline. This way Devil-Linux V1.x versions can continue to be built with out uClibc or V2.0 developers breaking the builds. > I also don't think it is necessary to create a new LFS System, all the > important parts (gcc, glibc, binutils) are compiled by us anyway. > Probably we just have to add a few more programs. > The thing you would have problems with is the cross-compile. Currently > (only theoratical) the only way to compile for a different plattform is > to work on that plattform. OK, in that cause you'll need a new LFS system. > Bingo ;-) > By incorporating those changes into the main build system, we all > benefit from eachothers developments and progress much faster then others. > > We could define those changes as a goal for v2.0, I'm sure it'll take a > while until you get everything running. > Not really, Devil-Linux is already running on an embedded platform running an ELAN processor, a firewalled gateway. The only problem is that a make iso doesn't work for this target and I have to do a manual conversion and put it on a disk space diet. I just want to make life easier by adding an entry into the menuconfig that selects the target media, ISO, CF or JFFS2. This option would change certain build variables, eg. PACKAGEDIR. Also certain variable names may need to be changed or others added since CDDIR and ISODIR are very specific. There are lots of other items that need to be considered for embedded targets such as: not all will need to build individual packages or installing only required files to save disk space.. I can go on and on but we can save this for a more specific discussion when we're ready. Also at some point in the future I'll be requesting a CVS account (for R/W access) so I can check in. > cya > Heiko > > P.S. Devil-Linux on a Linksys or Netgear Router.... sounds cool! Or even better, on a QuickBane Kincora Secured Gateway =).... Cheers John > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop -- John Kiss <jk...@sa...> |
|
From: Friedrich L. <fl...@fl...> - 2003-06-22 19:53:29
|
Hello John! John Kiss wrote: > Not really, Devil-Linux is already running on an embedded platform > running an ELAN processor, a firewalled gateway. Sounds superb. > The only problem is > that a make iso doesn't work for this target and I have to do a manual > conversion and put it on a disk space diet. I just want to make life > easier by adding an entry into the menuconfig that selects the target > media, ISO, CF or JFFS2. This option would change certain build > variables, eg. PACKAGEDIR. Also certain variable names may need to be > changed or others added since CDDIR and ISODIR are very specific. If you could convert your manual conversion into a script and finally into a patch or just a tar.gz if it's a new addition this would be very much appreciated. > There are lots of other items that need to be considered for embedded > targets such as: not all will need to build individual packages or > installing only required files to save disk space.. I can go on and on > but we can save this for a more specific discussion when we're ready. May you could at first add a menu option target with the options "normal" and "embedded" with the suboptions "CD" (only if normal), "compact flash", "...." and then keep working on your stuff. > Also at some point in the future I'll be requesting a CVS account (for > R/W access) so I can check in. Of course, but first it would be good if you showed us your competence and professionality via contribution of patches and your contribution on the mailinglist. As of now I would very much consider you as one of our next additions to our team ;-) -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2003-06-22 20:30:22
|
I have nothing to add here, I fully agree with Friedrich. Oh guys, I see such a bright future...... cya Heiko Friedrich Lobenstock wrote: > Hello John! > > John Kiss wrote: > >> Not really, Devil-Linux is already running on an embedded platform >> running an ELAN processor, a firewalled gateway. > > > Sounds superb. > > >> The only problem is >> that a make iso doesn't work for this target and I have to do a manual >> conversion and put it on a disk space diet. I just want to make life >> easier by adding an entry into the menuconfig that selects the target >> media, ISO, CF or JFFS2. This option would change certain build >> variables, eg. PACKAGEDIR. Also certain variable names may need to be >> changed or others added since CDDIR and ISODIR are very specific. > > > If you could convert your manual conversion into a script and finally > into a patch or just a tar.gz if it's a new addition this would be > very much appreciated. > > >> There are lots of other items that need to be considered for embedded >> targets such as: not all will need to build individual packages or >> installing only required files to save disk space.. I can go on and on >> but we can save this for a more specific discussion when we're ready. > > > May you could at first add a menu option target with the options > "normal" and > "embedded" with the suboptions "CD" (only if normal), "compact flash", > "...." > and then keep working on your stuff. > > >> Also at some point in the future I'll be requesting a CVS account >> (for >> R/W access) so I can check in. > > > Of course, but first it would be good if you showed us your > competence and professionality via contribution of patches and your > contribution on the mailinglist. > > As of now I would very much consider you as one of our next > additions to our team ;-) > |
|
From: John K. <jk...@sa...> - 2003-06-22 21:55:01
|
On Sun, 2003-06-22 at 16:25, Heiko Zuerker wrote: > I have nothing to add here, I fully agree with Friedrich. > > Oh guys, I see such a bright future...... > > cya > Heiko > > > Friedrich Lobenstock wrote: > > Hello John! > > > > John Kiss wrote: > > > >> Not really, Devil-Linux is already running on an embedded platform > >> running an ELAN processor, a firewalled gateway. > > > > > > Sounds superb. > > > > > >> The only problem is > >> that a make iso doesn't work for this target and I have to do a manual > >> conversion and put it on a disk space diet. I just want to make life > >> easier by adding an entry into the menuconfig that selects the target > >> media, ISO, CF or JFFS2. This option would change certain build > >> variables, eg. PACKAGEDIR. Also certain variable names may need to be > >> changed or others added since CDDIR and ISODIR are very specific. > > > > > > If you could convert your manual conversion into a script and finally > > into a patch or just a tar.gz if it's a new addition this would be > > very much appreciated. > > > > > >> There are lots of other items that need to be considered for embedded > >> targets such as: not all will need to build individual packages or > >> installing only required files to save disk space.. I can go on and on > >> but we can save this for a more specific discussion when we're ready. > > > > > > May you could at first add a menu option target with the options > > "normal" and > > "embedded" with the suboptions "CD" (only if normal), "compact flash", > > "...." > > and then keep working on your stuff. > > > > > >> Also at some point in the future I'll be requesting a CVS account > >> (for > >> R/W access) so I can check in. > > > > > > Of course, but first it would be good if you showed us your > > competence and professionality via contribution of patches and your > > contribution on the mailinglist. > > Not even a challenge to prove myself... I've been watching this mailing list for about a month now and just like you'll be watching me, I've already been watching you ;-).. No I'm not a coding pervert, I'm just careful where I spend my time. The only patches I can think of to add right away are: *BOA - embedded web server *SHOREWALL - IPTABLES Firewall * And of course eventually a script that would convert the ISO directory to a Compact Flash media. A few other things I'll be working on in the weeks to come. * APACHE * PHP 4.3.x When these are added I wanted to start work on a generic GPL'ed Web UI for Devil Linux, with lots of input of course, unless someone is already working on one? One other thing I have that you guys are probably not interested in but I'll mention it anyways is a modified HostAP which supports PrismII USB dongles. It's based on the May 2002 release of HostAP and not the lastest, last I checked was November 2002. Jouni, maintainer of HostAP, has been given the patches, but has not released it yet. The biggest disadvantage of using this, that I can think of, is disable ESSID broadcasts... Doesn't effect what I'm doing now but it will soon. Test usb dongles are ZCOM and the old LinkSys 2.5, not the 2.6. Anyways just let me know what you guys want, and a brief discription of how to contribute patches to the group. > > As of now I would very much consider you as one of our next > > additions to our team ;-) > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop -- John Kiss <jk...@sa...> |
|
From: Friedrich L. <fl...@fl...> - 2003-06-22 22:13:40
|
Hi! John Kiss wrote: > One other thing I have that you guys are probably not interested in but > I'll mention it anyways is a modified HostAP which supports PrismII USB > dongles. I'd know one who'd be longing for such a thing. Thomas wouldn't you? > The biggest disadvantage of using this, that I can think of, is > disable ESSID broadcasts... I would not call a security feature a disadvantage. > Anyways just let me know what you guys want, and a brief discription of > how to contribute patches to the group. As said before if you change something then create a patch relative to the build directoy, eg. when you are at /data/build in the LFS chroot via "cvs diff -u [optinal single filename]". New additions (scripts and sources) are better distributed as tar.gz/bz2 as a patch is useless in this case. Also relative to the aformentioned path. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: John K. <jk...@sa...> - 2003-06-22 22:20:21
|
On Sun, 2003-06-22 at 18:13, Friedrich Lobenstock wrote: > Hi! > > John Kiss wrote: > > One other thing I have that you guys are probably not interested in but > > I'll mention it anyways is a modified HostAP which supports PrismII USB > > dongles. > > I'd know one who'd be longing for such a thing. Thomas wouldn't you? > > > > The biggest disadvantage of using this, that I can think of, is > > disable ESSID broadcasts... > > I would not call a security feature a disadvantage. Whoooops.. Should have said.. Disable Broadcast ESSID is not included.. But your right it not a disadvantage.. It's a hazard =)... > > > > Anyways just let me know what you guys want, and a brief discription of > > how to contribute patches to the group. > > As said before if you change something then create a patch relative > to the build directoy, eg. when you are at /data/build in the LFS > chroot via "cvs diff -u [optinal single filename]". > > New additions (scripts and sources) are better distributed as tar.gz/bz2 > as a patch is useless in this case. Also relative to the aformentioned > path. -- John Kiss <jk...@sa...> |
|
From: Thomas E. <tho...@bu...> - 2003-06-24 20:38:48
|
Friedrich Lobenstock schrieb:
>> One other thing I have that you guys are probably not interested
>> in but
>> I'll mention it anyways is a modified HostAP which supports PrismII USB
>> dongles.
>
>
> I'd know one who'd be longing for such a thing. Thomas wouldn't you?
:-))
--
Regards
thomas
|
|
From: Bruce S. <bw...@ar...> - 2003-06-23 12:55:48
|
> A few other things I'll be working on in the weeks to come. > > * APACHE > * PHP 4.3.x > > When these are added I wanted to start work on a generic GPL'ed Web UI > for Devil Linux, with lots of input of course, unless someone is already > working on one? I had mentioned writing one before, but haven't started on the _web_ interface yet. Instead I'm writing a ncurses setup utility, because for the web interface, you need a network card up and running first. A web interface would be a nice addition, and a logical next step. I've VERY GLAD to see "PHP" listed above. Personally, I wouldn't use anything else to write the web interface. Perhaps we could work together on the web interface? - BS |
|
From: John K. <jk...@sa...> - 2003-06-23 19:13:06
|
On Mon, 2003-06-23 at 08:55, Bruce Smith wrote: > > A few other things I'll be working on in the weeks to come. > > > > * APACHE > > * PHP 4.3.x > > > > When these are added I wanted to start work on a generic GPL'ed Web UI > > for Devil Linux, with lots of input of course, unless someone is already > > working on one? > > I had mentioned writing one before, but haven't started on the _web_ > interface yet. > > Instead I'm writing a ncurses setup utility, because for the web > interface, you need a network card up and running first. > > A web interface would be a nice addition, and a logical next step. > > I've VERY GLAD to see "PHP" listed above. Personally, I wouldn't > use anything else to write the web interface. Niether would I... > > Perhaps we could work together on the web interface? > I would like that.... I'll send out some ideas that I have to get one up quickly and also be usefull... > - BS > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop -- John Kiss <jk...@sa...> |
|
From: Bruce S. <bw...@ar...> - 2003-06-23 19:26:43
|
> > Instead I'm writing a ncurses setup utility, because for the web > > interface, you need a network card up and running first. > > > > A web interface would be a nice addition, and a logical next step. > > > > I've VERY GLAD to see "PHP" listed above. Personally, I wouldn't > > use anything else to write the web interface. > Niether would I... Good. I was afraid a Perl monger would want to write it. :-) (I don't care for Perl) I'm also not sure that Apache is necessary. It would be nice to get by with a smaller web server that supports PHP. I don't think the web interface needs many of the advanced features offered by Apache. But, I could be wrong. I've only have experience with Apache ... > > Perhaps we could work together on the web interface? > > > I would like that.... I'll send out some ideas that I have to get one > up quickly and also be usefull... Yes. I think a first step would be to decide what should go into the web interface, what should stay in the ncurses setup, and what should go in both places. As an example, I think setting up the basic functions, like network cards, language, keyboard, etc. (stuff you normally only do once) should stay in the ncurses setup. I think setting up more advanced services (dhcpd, iptables, CIPE, ...) should go in the web interface. - BS |
|
From: Friedrich L. <fl...@fl...> - 2003-06-23 21:03:41
|
Bruce Smith wrote: > I'm also not sure that Apache is necessary. It would be nice to get by > with a smaller web server that supports PHP. I don't think the web > interface needs many of the advanced features offered by Apache. > But, I could be wrong. I've only have experience with Apache ... FWIW Axis, known for their webcams running Linux, uses the boa web and PHP3 on their webcams see http://developer.axis.com/software/apps/index.html (boa) http://www.axis.com/techsup/faq/index.cgi?id=21155 (php3) So that must have really small memory footprint then. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2003-06-23 21:23:32
|
> > I'm also not sure that Apache is necessary. It would be nice to get by > > with a smaller web server that supports PHP. I don't think the web > > interface needs many of the advanced features offered by Apache. > > But, I could be wrong. I've only have experience with Apache ... > > FWIW Axis, known for their webcams running Linux, uses the boa web > and PHP3 on their webcams > see http://developer.axis.com/software/apps/index.html (boa) > http://www.axis.com/techsup/faq/index.cgi?id=21155 (php3) > > So that must have really small memory footprint then. And according to boa.org, thttpd is "very similar to Boa", and I see we already have thttpd in DL... PHP can be compiled as a standalone CGI program, so it should work with any web server that supports CGI. - BS |
|
From: Friedrich L. <fl...@fl...> - 2003-06-23 21:33:20
|
Bruce Smith wrote: > And according to boa.org, thttpd is "very similar to Boa", and I see we > already have thttpd in DL... So a step closer, except if John really needs the real apache. > PHP can be compiled as a standalone CGI program, so it should work with > any web server that supports CGI. I guess Axis did choose PHP3 because of the lower memory footprint than PHP4. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2003-06-22 20:30:22
|
John Kiss wrote: > Not really, Devil-Linux is already running on an embedded platform > running an ELAN processor, a firewalled gateway. The only problem is > that a make iso doesn't work for this target and I have to do a manual > conversion and put it on a disk space diet. I just want to make life > easier by adding an entry into the menuconfig that selects the target > media, ISO, CF or JFFS2. This option would change certain build > variables, eg. PACKAGEDIR. Also certain variable names may need to be > changed or others added since CDDIR and ISODIR are very specific. It probably would be a good idea to change those variable names in general, e.g. CDDIR = MEDIADIR cya Heiko |
|
From: Bruce S. <bw...@ar...> - 2003-06-23 21:39:59
|
> > And according to boa.org, thttpd is "very similar to Boa", and I see we > > already have thttpd in DL... > > So a step closer, Why was thttpd originally added to DL? > except if John really needs the real apache. I hope not. Apache is HUGE compared to boa & thttpd: http://www.acme.com/software/thttpd/benchmarks.html One other advantage of thttpd over boa is thttpd supports "basic auth", and boa doesn't. > > PHP can be compiled as a standalone CGI program, so it should work with > > any web server that supports CGI. > > I guess Axis did choose PHP3 because of the lower memory footprint > than PHP4. Could be. We should probably go with PHP4 so we are sure to have the latest security updates. - BS |
|
From: Friedrich L. <fl...@fl...> - 2003-06-23 23:18:00
|
Bruce Smith wrote: > > Why was thttpd originally added to DL? Hmmm....can't find this thread in the mailinglist archive. Did SF lose some messages? So from my local mailinglist archive (just an excerpt): -------- Original Message -------- Subject: [Devil-linux-develop] thttpd Date: Sun, 21 Apr 2002 02:48:52 +0200 From: Friedrich Lobenstock <fl...@fl...> Maybe thttpd+stunnel would be interesting for a DL online config tool. http://www.acme.com/ -------- Original Message -------- Subject: Re: [Devil-linux-develop] thttpd Date: Sun, 21 Apr 2002 18:11:25 +0200 From: Friedrich Lobenstock <fl...@fl...> Heiko Zuerker wrote: [...removed some noice...] > I think it would be much easier, when we use Webmin. Otherwise we would > have to write something from scratch. Hmmmm...don't know if that's not a little bit of an overkill. I think that if we have a webserver on DL, various people can install their prefered script to manage portions of the system. Somehow an open framework. But if we can trim webmin it might also be a solution. Any ideas? -------- Original Message -------- Subject: Re: [Devil-linux-develop] thttpd Date: Mon, 22 Apr 2002 11:00:30 -0400 From: Heiko Zuerker <he...@zu...> John van V. wrote: > Hi > > The www.acme.com site also includes a cli interface, something similar to > webmin. Maybe the author could be encouraged to complete the project. > > More on webservers: > One commonly needed use for a webserver is to run it as an httpd virtual host > re-director as part of a firewall/router for single ip address sites with > multiple webservers on the internal net. > > I think this is the page: > http://httpd.apache.org/docs/mod/core.html#namevirtualhost > > Apache 2 may have even more capabilities. Apache will be included in the future, but before we do that, we need to have a "User-Build-System", otherwise DL is getting too big and too feature rich. > > The acme site seems to have a form of webmin, an "experimental" web cli, > http://www.acme.com/cmd/ > > Maybe the author could be encouraged to finish this and package it with thttpd. > The thttpd memory footprint seems almost too good to believe. It's not really a Web-Config tool. ------------------------------------------------------------------------ I have to admit that I really forgot about thttpd because I played with an axis camserver lately and that's why I had the boa server in mind. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: John K. <jk...@sa...> - 2003-06-24 00:26:23
|
On Mon, 2003-06-23 at 17:39, Bruce Smith wrote: > > > And according to boa.org, thttpd is "very similar to Boa", and I see we > > > already have thttpd in DL... > > > > So a step closer, > > Why was thttpd originally added to DL? > > > except if John really needs the real apache. Not necessary for DL, I would like to add apache for my own use so I can add microCode. Which is a PHP source encrypt/decrypter. I'll need this for another project to protect the PHP source from being copied from the CD. > > I hope not. Apache is HUGE compared to boa & thttpd: > > http://www.acme.com/software/thttpd/benchmarks.html > > One other advantage of thttpd over boa is thttpd supports "basic auth", > and boa doesn't. As of now, boa or thttpd are both excellent choices.. I suggest since thttpd is already in, lets use it instead. > > > > PHP can be compiled as a standalone CGI program, so it should work with > > > any web server that supports CGI. A standard compile turns the PHP CLI file size to be about 3Megs. I don't know if that is stripped or not. But there are plenty of features and functions that can be disabled. I've figured that I can get the file size down to be about 1 to 1.5 Megs in size. > > > > I guess Axis did choose PHP3 because of the lower memory footprint > > than PHP4. > > Could be. We should probably go with PHP4 so we are sure to have the > latest security updates. This is what I was aiming for. Plus I don't think PHP3 has support for the standalone CGI interface (PHP CLI, I believe that was introduced in PHP4) > > - BS > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop -- John Kiss <jk...@sa...> |
|
From: John v. V. <joh...@ya...> - 2003-06-25 21:49:54
|
Hi all, Heiko's email about the mistakes in security pointed out problems in PHP. I have been fooling around with AmphetaDesk, a RSS news tool which is in perl and has a tiny perl http server. Webmin, also written in perl, is in wide commercial use, has significant secturity and has a perl httpd server. Python is nice but I never used it because it uses white spaces as part of it OO implementation, which is scary when debugging under pressure. As I mentioned to Bruce it is high time for a new admin scripting language though I am on advocating DL... I am in Utah right now, at a big party in the mountains.. big 20,000 people :) John http://www.itworld.com/AppDev/4072/020301phpflaws/ PHP security flaws affect 1 million Web sites ITworld.com 3/1/02 About 1 million Web sites are vulnerable to attack through recently discovered flaws in the popular PHP (Personal Home Page) scripting language, Web server information firm Netcraft Ltd. said Friday. Advertisement On this topic Data Management Strategies. Sign up Now! New Strategies to Effective Business Continuity An Architecture for Next-Generation Business Intelligence Hole in PHP could give attacker server control Server-side HTML hell Open source Web application development tools and languages One million may seem a high number, but it is much lower than the numbers suggested in security warnings that have been sent out this week, Netcraft Director Mike Prettejohn said. "A system is only vulnerable when PHP is actually used on a Web site, not when it is installed on the server. Current advisories have not made that especially clear," he said. About 8.4 million Web sites support a vulnerable version of PHP, but only about 1 million of those actually use the scripting language on Web pages, which is what makes them vulnerable, according to Prettejohn. --- Bruce Smith <bw...@ar...> wrote: > > > And according to boa.org, thttpd is "very similar to Boa", and I see we > > > already have thttpd in DL... > > > > So a step closer, > > Why was thttpd originally added to DL? > > > except if John really needs the real apache. > > I hope not. Apache is HUGE compared to boa & thttpd: > > http://www.acme.com/software/thttpd/benchmarks.html > > One other advantage of thttpd over boa is thttpd supports "basic auth", > and boa doesn't. > > > > PHP can be compiled as a standalone CGI program, so it should work with > > > any web server that supports CGI. > > > > I guess Axis did choose PHP3 because of the lower memory footprint > > than PHP4. > > Could be. We should probably go with PHP4 so we are sure to have the > latest security updates. > > - BS > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > > ===== CXN, Inc. Contact: jo...@th... President, The Linux Society http://groups.yahoo.com/group/linux-society linux society distro -> http://www.thinman.com/eLSD/readme ThinMan is a registered trademark of CXN, Inc __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
