Re: Second Ethernet Card
Re: Best e-mail approach for discon. sites
> > This is EXACTLY the environment that UUCP was designed to operate in. > > My apologies then. Now it seems to me this was a dumb question :-) > > I'll start digging in how to configure my Debian boxes and sendmail > to do the trick. But times have changed a lot since the days when the only way (for normal people) to connect machines was a direct modem link. You may want to keep at least one machine somewhere with a full-time internet link so you can accept smtp from the rest of the world (or use someone's service for this). If you have that, you may want your remote machines to dial up a local internet provider and do uucp over tcp to pick up their batched mail instead of making long distance calls directly to the other machines. It is a bit more complicated to set this up but you can also use it for other internet activity. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Help me to build a fileserver!!!
> > I want to build a small network using Linux as the fileserver and > windows 95 computers as the clients. What I have in mind is something > similar to what novell network do, but using Linux in the place of the > novell server. I want to be able to map a linux partition in the server > to work as a directory in the windows 95 computers. I tried to do that > using the tcp/ip protocol but then I got realized that windows 95 do not > have a client for UNIX networks using the tcp/ip protocol so, I have > been unable to map. You just need to start the samba server on the Linux box and set up accounts for the users. Win95 will be able to link to the user's home directories with the appropriate permissions by default and there are configuration options to create shared areas. > I heard that Linux can to use the IPX protocol. I think that maybe I > can to configure Linux to emulate a novell network server and then > configure the windows 95 computers as novell network clients. You can do that too: that's the mars_nwe server but I don't know how they compare. If you want to work over internet routers the tcp based samba would be better. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 2 ethernet cards and loadlin
> > I am trying to get my machine to use 2 3c509 ethernet cards > booting from loadlin. Looking at the loadlin docs I think the > command line should be: > > "loadlin vmlinuz root=/dev/hda1 ether=10,300,eth0 ether=11,310,eth1 ro" > > eth0 is fine but I don't get eth1 at all. There isn't even a reference to it > in /var/log/messages. Where did I go wrong? > The 3c509 card probe is a little strange and only works if you list them in the order of their ethernet MAC addresses. If you just said ether=0,0,eth0 ether=0,0,eth1 it would find them both, but the eth0/eth1 names would refer to the wrong cards. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian quality
> Just replace stable with frozen in dselect and things should work fine. I > upgraded by ftp over a ppp link (~39 MB) and it went as slick as can be > (it took a few hours of course.) > > After struggling with two Red Hat upgrades and getting a system which > worked but could only be upgraded by individually upgrading one package at > a time and struggling with dependencies in the process, I am QUITE > impressed. I had fewer problems than with my original Debian > installation, since there were a few things (like gpm) in stable which > seem broken. Not to say that anything is wrong with Debian, but it is certainly unfair to compare today's Debian with last year's RedHat. You can upgrade from RedHat 4.1 to 4.2 all in one shot over just about any kind of connection you want, including a SMB mount from a Win95 PC if that's where your CD or FTP'd files happen to be. It looks like everyone is making a lot of progress. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: couldn't get a free page
> > Kernel 2.0.30 changed the way it handles memory. It's supposed to be a > > stable kernel (by this I'm saying it's a 2.0.x and not a 2.1.x), but > > problems like this make me think it shouldn't be used in 1.3. Could you > > try downgrading to 2.0.29 and let me (or the whole list) know if it > > works? > > This isn't the same situation, but... > > I've got an spare machine here, where I've been installing and > reinstalling Debian 1.3, using the lastest available disks. Every time I > make the file system, I get a "couldn't get a free page" message. Just > once, when 25% of the partition has been formatted (currently it's a 400 > MB partition). Everything seems to work, and I have no problems after > that, but it's kind of annoying. I didn't think it was something > important, but then again... I got this recently when running in single-user mode doing mke2fs on a 9 gig drive, but I think my swap space wasn't activated. Has the install package activated swap at this point? Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Latex to WinWord 6.0 :-(
> > One interesting (and encouraging) note is that Corel WordPerfect 7 comes > with some utilities to do SGML. Haven't looked into it yet. :) Has anyone used this feature? You have to supply your own dtd. Does the one used by the linuxdoc project work and if so, how do you set it up? Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: can't umount /usr(/dev/hdb3)
> The other asnwers in this list are all very usefull, but sometimes > I find that whatever I do, I cannot unmount for example /usr. > In such cases, it's best to do > > mount -o remount,ro /usr > > i.e. remount it read-only, so that all data is written do the partition, > and you can now safely switch off the computer (execute "halt"). > (assuming all other partions are unmonuted properly). > I've been having trouble with hardware errors on one disk drive causing a filesystem panic that appears to force the filesystem into read-only mode but the processes accessing it are blocked and won't die from signals. I would like to be able to force a reboot remotely when this happens but even 'reboot -f' hangs. Is there some other way besides punching the reset button to make the machine restart? Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Linux 2.1.** kernel support for Intel 82557-based ethernet card?
> Apparently, Linux doesn't have a driver for the Intel 82557-based PCI > twisted-pair ethernet card. It looks as thought this is not the same > as the EtherExpress Pro/10+ because it uses a different chip (the 82557). > Does Linux 2.1.** have such a driver? This is the Pro100B card and there is a driver at: http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html (as usual for ethernet cards). You have to compile it as a module as it stands, or you can find a 2.0.27 kernel with it built-in at ftp.varesearch.com. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: InfoMagic's new LDR
> > provide a consistency check for complete CD's, so that companies like > > InfoMagic can easily check what they press. I have the impression the > > Eric, I suspect you are correct. I do have a tendancy to over-react to > bad situations. What kind of consistency check would we need to > provide? Something to read the Package file and verify that all packages > were there and also read all the directories and verify all packages were > listed in the Package file? Would something like that be enough? Even better would be a tool for the end user with ftp/http capability to compare his CD against the current image over the internet and pick up any updates automatically. How about something that built a symlink tree on the HD with all symlinks initially pointing to the CD copy of each file, then using a directory with timestamps and CRC's update the files that differ? You might also want a brute-force approach that re-read the file's sizes and timestamps at both ends like the perl mirror program so the same thing would work for other CD distributions that didn't have a matching directory file or if you suspect those files are corrupt. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: InfoMagic's new LDR
> > Hmmm, This makes two straight that the infomagic folks have sent out with > > a bad Debian distribution on it. Their December, 1996 LDR with the > > original Debian 1.2.0 was also full of problems. Not to mention they > > still haven't put anything about how to install Debian in the booklet > > they include with the CD's. > > > > I wonder, is it time to request they stop distributing Debian? > > I have also the December 1996 Infomagic cd, it was... a trash. Some > deb binaries were not there, The x-windows does'nt work out of the > box, etc. It is as if they just want you to install redhat or slakware. > Since i was not on the debian list when i installed debian, It was a pain > to install debian for a couple of hours. > > I was even tempted to install redhat just because of ease of installation! > I think there were many people that were turned off to install debian in > this dec. 1996 infomagic cd. Have anybody complained to infomagic? It's hardly Infomagic's fault. I tried several times to install from a mirrored ftp copy directly from the debian site with the same results. Perhaps things are better now. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DIETY: Automagically enhanced.
> I was thinking about maybe an argument for diety so it can be added to > cron.weekly to check for updated packages and *optionally* automatically > download it with an email to root about the update including the > description and dependancies. In addition add the ability to mark > *specific* packages for always auto or always manual download. > > Maybe further complicate it :) with auto-install (a stretch maybe?), maybe > for only specially marked packages that won't cause problems if installed > in the background. Maybe an extension/modification of the perl CPAN module would work for this (it downloads/builds/tests/installs perl modules from the distributed CPAN archives and can tell you what modules have been updated beyond your installed versions). Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dselect/dpkg daydreams
> Finally, Debian could really benefit from a kind person riding up on > a big white 30G drive and giving them a enough space to store > a journal of older .deb files (maybe this already exists somewhere?), > and optimized binary distributions for different intel processors. > (Yes I know there isn't a huge performance difference in some cases > but it would definitely be a selling point to some.) Or heck, > even someone selling CDs with optimized binaries would be great. Better yet, organize things such that you could rebuild everything yourself with a 'make world' command from the existing sources on a read-only medium and a bit of workspace. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM: Minor query re: .deb format
> > > > I'd think the info-zip package would have been a better choice since you > > can extract individual elements without uncomressing the whole mess and > > you wouldn't need two layers of archiving. > > > I use the Midnight Commander for extracting single files from a *.deb > file. I could probably do it as well on the command line using dpkg if > i took the pain reading it's man page, but since MC does the trick and > i'm eternally lazy... ;-) So where is the problem, please? You can hide any amount of cruft behind a pretty front-end but it is still cruft all the same. If you want a file out of the compressed tar component you have to uncompress the whole stream to find it (after the ar pass). Info-zip (unlike gzip) can read it's directory (and comments, I think) without having to uncompress anything, and you can uncompress/extract individual elements without going through the whole stream. I don't think it can maintain unix ownership/attributes like tar does but you shouldn't be doing that directly in an installable package anyway. The install mechanism should set them up as a separate operation. Is it just the not-invented-here syndrome that keeps zip format from being used more under unix? Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM: Minor query re: .deb format
> .deb is a very simple ar archive. You can use ar to display its > contents and to extract data.tar.gz which contains the package, > control.tar.gz contains the pre/post inst/rm scripts. > (filenames from memory, might be called slightly different) > > > Using the universally (well, Unixversally) supported .tar standard has > > The package inside .deb is a simple compressed tar archive. I'd think the info-zip package would have been a better choice since you can extract individual elements without uncomressing the whole mess and you wouldn't need two layers of archiving. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
One more idea to throw in the pot: How about including smbfs in the base kernel and allowing installation from a Win95 or NT share? Almost every office is going to have one of those around where you can share out a CDROM with a couple of mouse clicks. You could even do from with Windows-for-WorkGroups if you mangle the names to fit but that probably isn't worth the trouble. This might help a lot of people get their first Linux system up on machines that don't have their own CDROM drives. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: bi (Please stop it)
> what does it matter if one editor is faster than another? Or if one > is more powerful than any other? Nothing! The particular user has > to be familiar with at least one editor in that way that _he_ can > use it for his purposes. The issue relevant to this group is: what editor should someone expect to find on a system's boot/rescue disk? That someone presumably being a person with enough unix experience to recover from the usual problems that can make your machine fail to boot. The last thing you need at that point (especially if this is a server for many people) is a surprise from the editor or to have to learn a new one. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Will the real vi please stand up?
> > > It is generally agreed that any Unix user should be able to use > > > vi, regardless of which editor he prefers to use regularly. > > > > Apparently the people who generated the debian rescue disk don't agree > > or the recent editor wars wouldn't have happened on this list. > > The main problem was that any of the vi-clone were too big for our > small boot/root disk. That's all of it. This won't be changed I > believe. End. Then how about packaging up a utility to build a 'real' rescue disk and making the install procedure suggest that you run it before you exit? Everyone really should have a floppy around with the filesystem tools, fdisk, tar, and (of course) vi so they can recover from any normal problem. I've done this myself with the 'yard' utility (and needed it too...) but it takes too long for everyone to figure out what to do by themselves. Les Mikesell [EMAIL PROTECTED]
Re: DEITY TEAM -- A suggestion or request
> My needs might be better served if there were an easy way to instruct dpkg > to install the binaries on a different filesystem, like a zip disk. There > is probably a way to do this easily, but I haven't figured it out. Have to > do links by hand? THe config files, and so on, should go in the regulary > places. Maybe more experience with system admin will suggest a way to do > this. > > For example, on my tiny machine, any package of a megabyte would put me in a > pinch, but I might want to use slrn or yorick intermittently. Better yet, make the install always consult a local 'policies' file for all locations instead of insisting that one standard fits all. If a sensible mechanism could be worked out for this, the source packages could eventually be made aware if it and 'configure' could have a simple option to install unmodified packages in either the local or normal destinations, and sharable components could go on the appropriate shared drives. A reasonable first cut at this might drop the files in user-specified places but throw symlinks in the traditional locations to make existing packages work. Also, it would be nice to merge the concepts of installing and configuring packages. How about working out something with the linuxconf guys to use their user interfaces and to be able to automatically start the appropriate configuration run after installing a package that needs it. Linuxconf isn't perfect but it is probably the best attempt so far especially with interfaces that include web browser forms (and they claim to be working on Java). Les Mikesell [EMAIL PROTECTED]
Re: Will the real vi please stand up?
> > I learned vi under SysVr3 and SysVr4 and didn't see much difference > > under Slackware/elvis. Vim does have some annoying differences but > > I can't remember the specifics. Emacs with viper-mode is pretty > > faithful too. > > Emacs emulating vi? The only good thing about emacs is that it's easy > to learn. Emacs emulating vi is: > 1. SLOW... > 2. vi-like interface. > 3. As far as i can remember, you must press ESC twice... Emacs will handle many files that exceed limits in vi (line length, file size, binary content, etc.). I don't care for the finger-stretching emacs commands, though, so I run viper-mode. It has several degrees of 'vi-ness' and level 1 is almost identical. Les Mikesell [EMAIL PROTECTED]
Re: Will the real vi please stand up?
> It is generally agreed that any Unix user should be able to use > vi, regardless of which editor he prefers to use regularly. Apparently the people who generated the debian rescue disk don't agree or the recent editor wars wouldn't have happened on this list. > Which of the vi semi-clones on Debian is most like the original > vi and most likely to work on a broad range of unices? I learned vi under SysVr3 and SysVr4 and didn't see much difference under Slackware/elvis. Vim does have some annoying differences but I can't remember the specifics. Emacs with viper-mode is pretty faithful too. Les Mikesell [EMAIL PROTECTED]
Re: "dselect" replacement project ("deity")y
> > Note that RedHat gets this right, at least on the initial install. They > > prompt for groups of programs that generally would be chosen together > > and hide the ugly details unless you ask to pick individual items. > > It may be nice to individually pick every file on a unix distribution > > but most people have better things to do. These days you probably > > can't buy a disk that is too small to hold a fairly complete > > installation. > > I don't know. I was quite thrilled when I found that debian was giving me > the option to know more or less exactly what was going on my system. You have to compare against RedHat, not slackware. They have a checkbox for 'select individual components'. So you get your choice. > I was of course less thrilled by the problems > mentioned above, especially the confusing way the dependencies are > presented. This is the real issue. If you could select the 'high level' groups and only deal with the components if you want the option it would be fine. But if I select a group I want it to mean 'install what it takes to make this work', not 'tell me about some other things I need to do first in some unknown order'. > Nevertheless I think individual package selectin on install is > something we should keep, at least as a perfectly accesable option. I > would like to see the energy go into that rather than a more general > packaging scheme. I think more new users like it than you think. Watch someone else install both Debian and RedHat, then think about that again. New users want something that works the first time. On the other hand, dselect might be fine once you get past the initial install. Perhaps all it really needs is a special install mode where it knows that you have to take certain things in a certain order. Les Mikesell [EMAIL PROTECTED]
Re: "dselect" replacement project ("deity")
> You have to take the good with the bad. Why? > It would be nice to have a perfect > linux distribution but it will never happen. In that case it seems like the world would be a nicer place if you could mix-n-match things from different distributions easily. Unfortunately it isn't all that easy. I'd like to have a system where everything knows about shadow passwords, the ndbm emulation uses gdbm, and a one-disk nfs installation works the first time. > You can install groups in dselect also. Just select the line that describes > the group and mark it for install or hold. Generally the normal install is > already marked for install. I tried several times (over NFS) and it never completed. That was probably a month ago - perhaps it is fixed now, but I have RedHat loaded. I'll try again on the next machine if shadow support is available by then. What I'd really like is the ability to load .deb's into a redhat or slackware base. Les Mikesell [EMAIL PROTECTED]
Re: "dselect" replacement project ("deity")y
> Yes. Many have raised the issue of conflicts on install. The answer at this > point is to run configure over and over. Each time it will install something > that is needed to settle the conflicts. The problem is that the selected > files aren't in dependant order. Hopefully the new project will address this > problem. Note that RedHat gets this right, at least on the initial install. They prompt for groups of programs that generally would be chosen together and hide the ugly details unless you ask to pick individual items. It may be nice to individually pick every file on a unix distribution but most people have better things to do. These days you probably can't buy a disk that is too small to hold a fairly complete installation. Les Mikesell [EMAIL PROTECTED]
Re: bi
> I'm going to finally ask this question. > > What is it that is so special about vi? Does it decompile programs or write > them all by itself or leap tall buildings with a single bound? It works from any keyboard, you don't need arrows, f-keys or other unlikely stuff. You keep your hands on the keyboard all the time even when doing search commands, etc. With only a couple of exceptions everything takes exactly the same syntax [count] [range] command [escape] so you always type what you mean. For example a typical sequence is /old text (find old text) 2cwreplacement words (change 2 words) n(find next occurance) .(repeat change) Is anything really easier or less keyboard-intensive than that? > Really. I've been on unix boxes for about 7 years and only used vi when I > had no other choice. Is there some hidden, undocumented functionallity to it? It's all documented somewhere. Insert a row of '= ' with 35i =. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = convert columns of 'Last, First' to 'First Last' with :%s/^\(.*\), \(.*\)/\2 \1/ (and if it doesn't work right the first time, just 'u'ndo). Build complicated ex mode commands in the edit buffer itself or read in some you've done before, delete to a register, execute the register and if it doesn't quite work you can undo, yank back the text of the command and fix it. With other editors if your complicated transformations don't work you usually get to make the same typing mistake all over again because they think commands are somehow magically different from the text. Also ex mode is good for scripting things that don't work in sed (like ':$-10d' to delete the 10'th line from the end). Les Mikesell [EMAIL PROTECTED]
Re: RPM
> Debian 1.3 has shadow support built in, last I heard. It's just gone into > testing. I agree you have to install a few packages to make it work in 1.2, > but this is not a big deal. Is there some philosophical problem with incorporating PAM as-is? It's already pretty well tested... I don't see why anyone would want to use non-shadowed passwords at all these days, at least with a machine connected to the internet. In addition to the INN trick, I see people trying the published web server and sendmail games too. > One thing you should consider is how much "systems" work you do on Linux. > For example, if you are building a lot of free software packages you might > consider packaging them for Debian and leveraging your own work into a > contribution that benefits lots of people. It has totaled a lot, updating about 8 machines piecmeal. However by now I think everything involved has been packaged already except the shadow-in-a-box combo which would be better done with PAM. Some things just need to be custom-compiled regardless, like apache with the modules you need locally (php/mod_perl, etc.) I'd have a problem doing packaging that moved locations from the place that 'make install' wants them to live anyway. Les Mikesell [EMAIL PROTECTED]
Re: RPM
> > I think the answers to these questions are serious enough to decide > > whether Debian linux will grow or die. > > Actually, they are serious enough to decide if some number of people will > remove Debian from their systems and replace it with something else before > the Debian maintainers themselves become interested enough in these issues > to change them. Debian has reached the point where its growth does not hinge > upon technical features like the ones above so much as its user and > developer community. I'd say the more immediate problem has to do with ease of initial installation and security issues. I'm still undecided as to which of RedHat or Debian to use on several machines currently running a hand-updated Slackware and I'm holding off because the filesystem layout, ndbm differences, etc. will make it difficult to switch later. There are several things I don't like about RedHat, but the install is a breeze and shadow password support happens with a single command (and most sites running INN had their non-shadowed password files mailed off to an attacker not long ago). So far I haven't gotten dselect to complete an install command over NFS without giving up with too many errors (but perhaps something is wrong with my mirrored copy) and I can't tell what you have to do to get shadow support built into everything that needs it. If I get past these problems and it isn't harder than maintaining Slackware by hand I can probably deal with anything else. Les Mikesell [EMAIL PROTECTED]
Download i386 only?
What would be an appropriate command to the 'mirror' perl script to get the files needed for i386 installations only (including sources)? Les Mikesell [EMAIL PROTECTED]
Re: RPM
> > Great! Will it be aware of the different filesystem locations? Shouldn't > > these really be built into a user-configurable list instead of > > the packages themselves? > > Alien doesn't currently handle that. It's just too much work, and there's > no way I could guarentee it'd be correct all the time. > > Alien just converts from one format to another, and you get all the files, > in all the same locations they were in in the original package. Is anyone keeping track of who is moving what where, and why? The usual reason for wanting to install an alien package would be that it has a bug fix not yet available in a native package so you'll have to seek and destroy all the old components manually. Les Mikesell [EMAIL PROTECTED]
Re: RPM and dpkg merger
> > Please note that having a single packaging standard won't give the > > ability to `cross-install' packages. The distributions differ in the > > filesystem layout, and in the way many services are implemented. > > > The big problem for me is that if the packaging systems converge then so > will the filesystem layout and the way many services are implemented. This > reduces the freedom of two distributions. I don't see this as > strengthening anyone. What we really need is a way for the installer to set up and maintain a policy file that establishes the filesystem layout and where various programs are installed. I don't see how being trapped into forever using the layout philosophy from some distribution is a strength for free software. I do realize that this would be an enormous job for existing packages but it seems like it could be done for new work. Les Mikesell [EMAIL PROTECTED]
Re: RPM
> > Randolph Chung has released a alpha-test version of a utility that > > will convert .deb files to .rpm files. > > > > http://132.236.56.9/pages/rc42/program/martian.html > > > > And Debian's alien package can already install .rpm files. > > Randolph is a close friend of mine (I'm the maintainer of the alien program), > and we're working together on this, and in a week or so, alien will merge in > martian's functionality and be able to convert in both directions. Great! Will it be aware of the different filesystem locations? Shouldn't these really be built into a user-configurable list instead of the packages themselves? Les Mikesell [EMAIL PROTECTED]
Re: Video Cards
> > On Sat, 15 Mar 1997 19:10:08 +0100 (MET) Michael Tempsch wrote: > > > Hi again, forgot something - ask the salesdroid to actually give you > > some real service and dig out the information about what Matrox card it > > is... > > I did do that shortly after I posted the original message. It is > a model specially made for Gateway, "sorta like the Mystique, but not > the same". Sounds like bad news for a Linux user. If they are still shipping the same ones as about a year ago it is a Millineum with a slightly slower RAMDAC and no provision for the daughter cards. Works fine with Xfree 3.2A - supposed to be one of the fastest xfree servers ever. Les Mikesell [EMAIL PROTECTED]
