> www.toms.net seems to be down > My evil ISP does transparent port 80 proxying - so it could just be that > they that are broken, but it has been inacessible from here for ~24hrs.
I've used it throughout today, so it must be on your end. > > > failings in tomsrtbt to 'try to make it behave like a normal system'. > > Heh heh - I never thought it would be interpreted that way. > Well, most normal systems have sysvipc etc. - normal to me means the > functionality of a more 'normal' unix system> Normal means, "The included components behave like they normally do". I'll consider changing the wording in the FAQ. A "normal Unix system" is probably by definition something before the SYSV/BSD split. Since those systems had no sound, no AF_PACKET, no SYSV_IPC, and no lightweight threads, I think I'm safe on that definition. Certainly a loaded RedHat 9.9.9 system with a sound card does NOT come to mind. Unix is historically a *server* operating system- they don't *have* sound cards... > > It is intended to have tools necessary for fixing broken systems. > > Nmap, sound, etc, all fail the test. > But the potential to allow it to expand to this? Heh, it is open source, all the components are vanilla, the "potential" exists to turn it into a control system for a Merry-Go-Round that reads paper tape rolls of Jelly Roll Morton and plays them with compressed air over lead pipes. And I don't care if it is cloned or forked or if various package-management formats are created. But, none of those are in my plan for what is distributed or supported. Even the add-ons are not core. What is core is 1 (1) "1" ONE floppy image, the thing that is different about tomsrtbt from all the others, and that was different from the outset, is that it tries to be the "best compromise single 1" floppy image. It is by definition " 1 floppy ". Anything outside of the floppy, including the add-ons, and even the ElTorito image, is extra. > Uhm, but a web-browser like "Links" requires threading... Web browsing is not supported. Or desired. Web browsing should be done on a real system, even if "real system" means Dragon Linux or Dos Linux or Mu Linux or Peanut Linux or Coyote Linux. Tomsrtbt is a rescue and recovery system, Links is off-topic. I like Links a lot, it beats the heck out of Lynx, but, it will never be supported or distributed with tomsrtbt by me. That is what MuLinux is for. I'm not kidding when I say you should just design "jarvistLinux" and base it on tomsrtbt and have a comment in your FAQ that says you got it from tomsrtbt at the www.toms.net by Tom Oehser, [EMAIL PROTECTED] As long as you give credit to where you got it, you are welcome to turn it into something else. It is something that is not a new idea, I have thought for years about all the ways it could be extended, expanded, made into multiple packages, multiple floppies, etc. > ack, mpg123 just needs libm :) That is easy, just link libm static. Delete the .so and link it, it will find the .a. (I'm sure there is a compiler option, too). > There is a thin distinction between 'applications' and system recovery > 'tools', it is up to the user to decide what to integrate into their > system. Yes, an asm-httpd is included on the floppy, but there are Ah- there we differ. With Mandrake or Redhat or Suse or Slackware or Debian, you do an "install" and it is "up to the user what to integrate into their system". With tomsrtbt, you are 99% of the time booting *THE* image, already installed, no choices, no install, no packages, no options. Sure, cases are made that this or that should be there, and I try to balance the options- but a web server is NEVER required for rescue and recovery. Neither is AF_PACKET, or sound. Or threading, probably. > situations where a fully fledged server can be required. Like what? Use nc (netcat). There is an NT and Linux netcat, you can put that on the other end and pipe anything. A web server makes things *EASIER*, it doesn't make more things possible. > > > What is the priority list? > > Fixing the man pages, freeing up space, looking at some kind of > > Reiser support, and support for more scsi cards and raid solutions, > > some kludge to make gnu tar incremental backups restorable, working on > > using library minimalizers to try to get libc 6 working and fitting, > library minimalizers?! The only way I can imagine getting libc 6 squeezed > is to silently delete functionality in the hope that no applications > require them... Actually, there are things that *automatically* collect all the symbols on a set of executables, that is, it would go through *every binary on tomsrtbt*, collect the symbols, and then allow re-linking libc. > For what is libc 6 needed? Most things will compile under libc 5, or is it Several reasons. Some are things like large file support, libc5 goes only up to 2 gigabytes. The dd-lfs I include is a kludge, it can only work because it uses direct syscalls from nasm and doesn't use libc. > just to allow a person to immediate include his favourite tools from his > 'big' linux? That is a HUGE reason, the average user is constantly trying to copy "mc" or "bash" or "emacs" onto tomsrtbt, and not figuring out how to recompile with libc5. And, it may be able to be just as small, properly whacked. > >rewriting things in lua or nasm to be smaller, > rather labour intensive, wouldn't it be easier to intergrate within > busybox?> small thing, a better "more", > Maybe even less :) > Sometimes very irritating not having a page-up :-| The current "more" actually DOES have a page up, when viewing a file, you can use the 'b' key. I think it has help, too. But it can't do it from standard input. And cursor keys would be nice. Sure, it is labour intensive, but, if I'm going to fit libc6 and reiser and 5 or 10 more scsi drivers and maybe put pcmcia scsi back in, I have to make a lot more space. Busybox is not a panacea, most of it fails my "like a normal system" test. The busybox "more" is worse than the one I have, I want something more like "less". And if I do it myself in nasm, I can make it much better in a much smaller size. Busybox suffers from too many differing goals among the parties using it, and too few actual programmers, willing to accept far too many compromises, and it also tends to be buggy. I just spent hours debugging and fixing the busybox 'init', because things broke when I replaced the sysvinit with it. It breaks too, just a few days ago ' echo xxx | ./busybox gzip | ./buzybox gzip -d '. Really, my ultimate goal is to have 6 approaches for binaries, and to pick on a case-by-case basis: -Real GNU normal, -Busybox, -Asmutils, -Lua by me, -Nasm by me, -C by me. Of course, mixtures are also possible. I go based on whether the functionality is broken enough to bug me. For example, 'find' and 'sort' are the real thing, busybox just has too many compromises on them, and I don't want to write them. 'find' will probably always be that way, but 'sort' I might be able to hack a smaller one out. Note, "easier" is NOT one of the design goals- if I wanted easier, I wouldn't have rewritten the kernel boot loader to use bzip2, or many other things. > I appreciate the size of the task, but just a few tiny changes to the base > system and the possibilities would increase so tremendously :) As long as those changes make it SMALLER. You have to understand, in the course of tomsrtbt, I have spent plenty of time working to free up one single sector. The goal is to be counting bytes, the fact that I'm at 50 sectors free is a temporary luxury. Besides, the possibilities do NOT increase, just the EASE of implementing them. You can already replace the kernel, the binaries, the structures, the libraries, the scripts, and um, whatever else you want... > Of course, if you're sure, I'll just try & work around things... It is entirely possible that I would add sysv_ipc, or even af_packet. I may also end up getting the sound modules built, there is no reason not too. > > > Would you mind me creating pages for my little projects on your > > > wikki? Or would you like that to remain a strictly vanilla-tomsrtbt > > > area? > > Go for it. The wiki is free for all. I may re-arrange things, > > but this kind of thing is exactly what the wiki is for. > Just checking you wouldn't mind a possible confusion between vanilla & > 'side-shooted' tomsrtbt... :) Rename it. It shouldn't be called tomsrtbt. Note that things like NucLinux and Seth are derived from tomsrtbt, even MuLinux takes some components right from it. There won't be any confusion, becuase the mirrors and the static web pages will remain as they are, it will be a seperate project. > > Um, a > > caveat- the wiki is fine for web-page and discussion use, don't > > use it for file storage or distributions. It doesn't have the > > bandwidth to be used for anything but small chunks of static html. > he heh, UU-Encoded Wikki ;) It (TWiki) supports binary attachments, so it isn't so far fetched. > > I doubt ext3 adds that much. Compare my config, check the current one: > Ack, my bo-bo, somehow mangled your config file... > > Just compiling the modules, kernel itself was 20kb larger with sysvipc :-! > > If AF_PACKET.o works OK with the stock kernel, would you like a copy for > the modules folder? I'll do it, I need to just turn all modules on. > Jarvist -Tom
