Re: [Leaf-devel] Poll: Ladybug Architecture
One vote for IBMHelpingLinuxWebsite..G On Tue, Mar 13, 2001 at 12:41:00AM -0800, Mike Sensney scribbled: At 07:26 PM 03/12/2001 -0500, George Metz wrote: Hopefully, the way Linus is going about things for 2.4.x, the kernel will be a lot stabler a lot sooner. I can honestly say that I haven't seen any issues running as a workstation. I agree that servers are a bit touchy ground, but it seems to be coming along better than 2.2.x did. I saw Rick Lindsley of the IBM Linux Technology Center (LTC) at a lecture last December. He had been working for Sequent for 9 years when IBM bought Sequent, formed the Linux Technology Center with the formerly Sequent programmers as the core and has turned them loose on Linux kernel development. The LTC has rewritten the scheduler in the 2.4 kernel and improved performance by 25% on a 4 processor computer to where it is 2.5 times the speed of a single processor computer. They are confident that they should be able to achieve 3.99 times the speed of a single processor. They have already done this on Sequent's own OS. Their plans for the future include support for 16 processor computers. All of this without having an effect on single processor performance (one of Linus' personal requirements). The first step was to do a major rewrite of the scheduler and then prove to Linus that they were still using the same algorithm, just cleaner code. Then they started doing multiprocessor improvements. Alan Cox has signed on to do peer review of their work. Also they want to do other work on hardening the kernel and file system redundancy. It is IBM's view that if Linux is to reach common use in big iron, it must be much more dependable than it is currently. That is IBM's goal. Rick said that currently the LTC has around 40 programmers. They plan on expanding to around 80 to 90 programmers, not including support staff. The facility is located in Beaverton, Oregon, though many of the LTC personnel are located around the world. IBM believes that the importance of Linux is only going to grow. As such it is better to get involved now than to have to play catch up later. They are willing to play the game by the OSS rules. -- rick -- A mind is like a parachute... it only works when it's open. ICQ# 1590117 [EMAIL PROTECTED] (home) Help with LRP: http://lrp.c0wz.com Home page: http://www.c0wz.com ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Poll: Ladybug Architecture
I saw Rick Lindsley of the IBM Linux Technology Center (LTC) at a lecture last December. He had been working for Sequent for 9 years when IBM bought Sequent, formed the Linux Technology Center with the formerly Sequent programmers as the core and has turned them loose on Linux kernel development. The LTC has rewritten the scheduler in the 2.4 kernel and improved performance by 25% on a 4 processor computer to where it is 2.5 times the speed of a single processor computer. They are confident that they should be able to achieve 3.99 times the speed of a single processor. They have already done this on Sequent's own OS. Their plans for the future include support for 16 processor computers. All of this without having an effect on single processor performance (one of Linus' personal requirements). The first step was to do a major rewrite of the scheduler and then prove to Linus that they were still using the same algorithm, just cleaner code. Then they started doing multiprocessor improvements. Alan Cox has signed on to do peer review of their work. Also they want to do other work on hardening the kernel and file system redundancy. It is IBM's view that if Linux is to reach common use in big iron, it must be much more dependable than it is currently. That is IBM's goal. Rick said that currently the LTC has around 40 programmers. They plan on expanding to around 80 to 90 programmers, not including support staff. The facility is located in Beaverton, Oregon, though many of the LTC personnel are located around the world. IBM believes that the importance of Linux is only going to grow. As such it is better to get involved now than to have to play catch up later. They are willing to play the game by the OSS rules. /x-flowed
Re: [Leaf-devel] Poll: Ladybug Architecture
George Metz wrote: On Mon, 12 Mar 2001, David Douthitt wrote: Snip! * Tried to remove EVERYTHING and ANYTHING located in root.lrp that required backups: thus, root.lrp should be completely static for almost all purposes. (if it isn't, I'm not done :) As a note, on the lazy side of things - since I am, first and foremost, a lazy SOB g - this means that any update to Oxygen's root.lrp can be simply plugged in to any Oxygen-derived images and BANG, Derivative updated. That's awfully appealing to me. =) Every good programmer is :) I'm thinking like this: grab your config.lrp, add it to a new Oxygen disk, and bang! Instant update! * Using a new glibc means you are no longer able to use a floppy (probably). Why? A stripped glibc 2.1.x setup only takes about a hundred to two hundred kbytes more of disk space; if the only things on the disk are the root and etc LRPs, then there should be tons of space for it. Yes and no. 100k - 200k is HUGE! However, the only things required to boot Oxygen is the syslinux overhead and root.lrp; the rest can be loaded over the network. Also, I've been leery of "stripped glibc" ever since I banged my head on ncurses from the get go. First thing I did was replace Dave's stripped ncurses (in LRP) with a full ncurses 4 library. All of a sudden everything worked :) * using a more up-to-date glibc - this is something to seriously consider, methinks. Aye. I've been wondering if newlib or something would implement everything but with basic functions - to provide full support for new libraries and functions, yet in a small package. 100k to 200k is too much for me - I don't have that much free space on disk! ... ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Poll: Ladybug Architecture
- Original Message - From: "David Douthitt" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 13, 2001 2:43 PM Subject: Re: [Leaf-devel] Poll: Ladybug Architecture George Metz wrote: On Mon, 12 Mar 2001, David Douthitt wrote: Snip! * Tried to remove EVERYTHING and ANYTHING located in root.lrp that required backups: thus, root.lrp should be completely static for almost all purposes. (if it isn't, I'm not done :) As a note, on the lazy side of things - since I am, first and foremost, a lazy SOB g - this means that any update to Oxygen's root.lrp can be simply plugged in to any Oxygen-derived images and BANG, Derivative updated. That's awfully appealing to me. =) Every good programmer is :) I'm thinking like this: grab your config.lrp, add it to a new Oxygen disk, and bang! Instant update! That's what I was dreaming for some weeks ago when I started the thread about making a config.lrp keep the pressure, David ;-) Etienne * Using a new glibc means you are no longer able to use a floppy (probably). Why? A stripped glibc 2.1.x setup only takes about a hundred to two hundred kbytes more of disk space; if the only things on the disk are the root and etc LRPs, then there should be tons of space for it. Yes and no. 100k - 200k is HUGE! However, the only things required to boot Oxygen is the syslinux overhead and root.lrp; the rest can be loaded over the network. Also, I've been leery of "stripped glibc" ever since I banged my head on ncurses from the get go. First thing I did was replace Dave's stripped ncurses (in LRP) with a full ncurses 4 library. All of a sudden everything worked :) * using a more up-to-date glibc - this is something to seriously consider, methinks. Aye. I've been wondering if newlib or something would implement everything but with basic functions - to provide full support for new libraries and functions, yet in a small package. 100k to 200k is too much for me - I don't have that much free space on disk! ... ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Poll: Ladybug Architecture
George Metz wrote: On Tue, 13 Mar 2001, David Douthitt wrote: I'm thinking like this: grab your config.lrp, add it to a new Oxygen disk, and bang! Instant update! That's definitely appealing. I'm expecting to release a new version of Oxygen in a few days (or hours :) and it should have this capability fully implemented. Also, I've been leery of "stripped glibc" ever since I banged my head on ncurses from the get go. First thing I did was replace Dave's stripped ncurses (in LRP) with a full ncurses 4 library. All of a sudden everything worked :) I might be mistaken, but I THOUGHT that 2.0.7 in LRP was also stripped and compiled with tight optimizations. I'm not sure if it was, but Oxygen has been using the glibc that Debian released as a security fix for Debian 2.1. Correct me if I'm wrong, but aren't you using the ncurses binary a lot more heavily than base LRP ever did? That would probably be why, since Dave C probably compiled in only what he wanted to use. Well, it happened first with the editor - elvis-tiny didn't work - neither did nano or zile - and then there is all the other utilities... I guess I am using them more :) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Poll: Ladybug Architecture
On Mon, 12 Mar 2001, Jack Coates wrote: Background, for those who haven't downloaded it yet: Didn't know it was that far along. Will see about taking a peek. Snip! b) "the minimum" of system configuration files. In my dreams, that's two files: linuxrc and ladybug.conf. c) any package related configuration is going to go here, so the disk needs to have as much spare room as possible. Snip! b) a CD-ROM with all the support goodies and server packages needs to be available, or else you're looking at 30 floppies :-) Snip! 3) Security should be as good as possible. a) only serial and ssh access are supported. b) out of the box bastion - it comes up safe. c) only local media supported for package load. d) packages updated and kernel patched. Snip! 1-b) This is somewhat hard to do, given the progression from Debian through a few versions of LRP to Oxygen. However, the work is 90% done in the files that are up on my page. My question is, am I violating The Unix Way(TM) by going this direction? Would tons of little config files tied together with lrcfg menu be better? Regardless of the Unix Way, which I can definitively say I am NOT an expert on, I'd say having EVERYTHING in a ladybug.conf file is a bad way to go about it. Your IPChains rules - I know, it's not a firewall and a router, but you still want chains to lock down the box totally, and it works as an example - shouldn't be in the same file as you're specifying your network settings and kernel modules. If I'm misinterpreting, let me know. 2-b) If I'm assuming a CD-ROM and a box with lots of RAM, why not get away from the glibc issue and use a newer Linux as my base? Pros and cons? Pro: REALLY easy development, probably more secure, definitely more obtainable. Cons: May conflict with 1c. In fact, it probably will conflict. It's possible that the stripped versions of 2.1.x are workable, since they aren't THAT much larger. But with root.lrp needing to be on the boot image - in my case, a floppy - that might get a little hefty. I know that my 1.68M router image, with packages removed, has gobs and gobs of space, once you pull the packages, and that's using 2.2.18-kernel LRP 2.9.8. 3-d) Easier said than done. Kernel's easier done than said - at least, I think so - but the packages, well... I will say that this is another place where going to 2.1.x glibc will help. -- George Metz Commercial Routing Engineer [EMAIL PROTECTED] "We know what deterrence was with 'mutually assured destruction' during the Cold War. But what is deterrence in information warfare?" -- Brigadier General Douglas Richardson, USAF, Commander - Space Warfare Center ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Poll: Ladybug Architecture
Jack Coates wrote: Ladybug is based loosely on Oxygen, [...] The newer version should be nicer for you, for two reasons: * More programs removed from root.lrp into their own packages, meaning root.lrp is smaller and the overall boot disk is more configurable * Tried to remove EVERYTHING and ANYTHING located in root.lrp that required backups: thus, root.lrp should be completely static for almost all purposes. (if it isn't, I'm not done :) 1) The "idiot image" main system should be dirt simple. b) "the minimum" of system configuration files. In my dreams, that's two files: linuxrc and ladybug.conf. c) a local harddisk is assumed, which the /var directory will be written to. c1) persistence of /var means lrpkg/ needs to move elsewhere. Why? 3) Security should be as good as possible. d) packages updated and kernel patched. 1-b) This is somewhat hard to do, given the progression from Debian through a few versions of LRP to Oxygen. However, the work is 90% done in the files that are up on my page. My question is, am I violating The Unix Way(TM) by going this direction? Would tons of little config files tied together with lrcfg menu be better? I think you are, but I'm biased :-) Part of what I like doing with Oxygen is making it behave like any other UNIX out there. So if one looks for /etc/rc* there they are 2-b) If I'm assuming a CD-ROM and a box with lots of RAM, why not get away from the glibc issue and use a newer Linux as my base? Pros and cons? I've been thinking about the same for my CDROM off and on. Here are some of my ramblings: * Using a new glibc means you are no longer able to use a floppy (probably). * Linux 2.4 is not really yet fully solid and stable; wait for 2.4.9 :) * Many patches are not yet available for 2.4 - patches I've been watching include: linux progress patch, proconfig, linuxrc-always, initrd, VPN+Masq, and openwall many of these are not yet available for 2.4. Yet the availability may be much more scarce for 2.2.19... There really is two issues here (and my opinions with them): * using a more up-to-date glibc - this is something to seriously consider, methinks. * using Linux 2.4 - this may be worth avoiding for production systems right now... but keep watching. 3-d) Easier said than done. Not that hard, I thought. Once you've upgraded that which is necessary, things don't change much. I updated everything in sight for Oxygen originally. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Poll: Ladybug Architecture
Thus spoke David Douthitt: * Using a new glibc means you are no longer able to use a floppy (probably). Especially if combined with a 2.4 kernel. * Linux 2.4 is not really yet fully solid and stable; wait for 2.4.9 :) For the class of hw generally used under LRP, I don't think that the stability issue is that great a concern (it's been very stable for me running on 4 different boxes ranging from a 486/50 to a K6-II/350). * Many patches are not yet available for 2.4 - patches I've been watching include: linux progress patch, proconfig, linuxrc-always, initrd, VPN+Masq, and openwall many of these are not yet available for 2.4. This is a very definite problem. I'm currently running an LRP box just so I can masquerade my PPTP clients. All of my other traffic is through a 2.4.2/Shorewall system. The latter's disk footprint is huge by LRP standards however: [root@firewall /root]# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda1 387022155070211970 43% / /dev/hda515856 2385 12641 16% /boot [root@firewall /root]# There really is two issues here (and my opinions with them): * using a more up-to-date glibc - this is something to seriously consider, methinks. Nod -- the current situation makes LRP package creation much more cumbersome that it should be. * using Linux 2.4 - this may be worth avoiding for production systems right now... but keep watching. As I've mentioned, I think that the lack of patches is the critical factor there. On the other hand, once you become comfortable with iptables, you'll not want to go back to ipchains. My $.02 -Tom -- Tom Eastep \ Alt Email: [EMAIL PROTECTED] ICQ #60745924 \ Websites: http://seawall.sourceforge.net [EMAIL PROTECTED] \ http://seattlefirewall.dyndns.org Shoreline, Washington USA \___ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Poll: Ladybug Architecture
c) a local harddisk is assumed, which the /var directory will be written to. c1) persistence of /var means lrpkg/ needs to move elsewhere. Why? No real good reason - just trying to keep system and data separate. If /var is reserved for log and spool and pid files, it just seems cleaner to me. 3) Security should be as good as possible. d) packages updated and kernel patched. 1-b) This is somewhat hard to do, given the progression from Debian through a few versions of LRP to Oxygen. However, the work is 90% done in the files that are up on my page. My question is, am I violating The Unix Way(TM) by going this direction? Would tons of little config files tied together with lrcfg menu be better? I think you are, but I'm biased :-) Part of what I like doing with Oxygen is making it behave like any other UNIX out there. So if one looks for /etc/rc* there they are 2-b) If I'm assuming a CD-ROM and a box with lots of RAM, why not get away from the glibc issue and use a newer Linux as my base? Pros and cons? I've been thinking about the same for my CDROM off and on. Here are some of my ramblings: * Using a new glibc means you are no longer able to use a floppy (probably). Or it means that root.lrp is on a CD-ROM and all you're getting from the floppy is /etc * Linux 2.4 is not really yet fully solid and stable; wait for 2.4.9 :) * Many patches are not yet available for 2.4 - patches I've been watching include: linux progress patch, proconfig, linuxrc-always, initrd, VPN+Masq, and openwall many of these are not yet available for 2.4. Yet the availability may be much more scarce for 2.2.19... I'm definitely sticking with 2.2.18 for now -- gotta draw a line in the sand somewhere, and I don't see a point in going to 2.4 unless going whole hog (devfs and USB support and a bunch of other stuff I don't care to deal with at this time). There really is two issues here (and my opinions with them): * using a more up-to-date glibc - this is something to seriously consider, methinks. * using Linux 2.4 - this may be worth avoiding for production systems right now... but keep watching. 3-d) Easier said than done. Not that hard, I thought. Once you've upgraded that which is necessary, things don't change much. I updated everything in sight for Oxygen originally. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Poll: Ladybug Architecture
On Mon, 12 Mar 2001, George Metz wrote: On Mon, 12 Mar 2001, Jack Coates wrote: Background, for those who haven't downloaded it yet: Didn't know it was that far along. Will see about taking a peek. I wouldn't say far along, but thanks for the peek :-) Snip! 1-b) This is somewhat hard to do, given the progression from Debian through a few versions of LRP to Oxygen. However, the work is 90% done in the files that are up on my page. My question is, am I violating The Unix Way(TM) by going this direction? Would tons of little config files tied together with lrcfg menu be better? Regardless of the Unix Way, which I can definitively say I am NOT an expert on, I'd say having EVERYTHING in a ladybug.conf file is a bad way to go about it. Your IPChains rules - I know, it's not a firewall and a router, but you still want chains to lock down the box totally, and it works as an example - shouldn't be in the same file as you're specifying your network settings and kernel modules. If I'm misinterpreting, let me know. No ipchains. You need two interfaces and ip forwarding enabled, and since this is for a single-nic server I'm relying on minimal network access and portsentry. 2-b) If I'm assuming a CD-ROM and a box with lots of RAM, why not get away from the glibc issue and use a newer Linux as my base? Pros and cons? Pro: REALLY easy development, probably more secure, definitely more obtainable. Yup. I especially like the idea of compiling software on Mandrake instead of VMWare :-) snip ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
