Re: Safety of Upgrading Unstable
>>>>> "nate" == nate <[EMAIL PROTECTED]> writes: nate> sounds like your new to debian.. if this is a new installation I nate> would reccomend upgrading now. The more experience you have nate> dealing with a broken system the better. And if you break your nate> current system in it's new state you risk losing less. Chances are nate> good that you'll break your system to _some_ extent sooner or nate> later, that's just the way it is when running the unstable(or even nate> testing) stuff. Just be reminded that an apt upgrade is about to start, and aptitude is currently uninstallable in sid. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rm -rf .* alternatives
>>>>> "Karsten" == Karsten M Self <[EMAIL PROTECTED]> writes: Karsten> on Fri, Oct 24, 2003 at 03:28:36PM +0100, Colin Watson Karsten> ([EMAIL PROTECTED]) wrote: >> On Fri, Oct 24, 2003 at 11:36:25PM +0930, David Purton wrote: >> > Sadly no, I neglected to say that I could not get things to work >> even > using a test account and doing an rm -rf .* in $HOME. >> >> Just in case other people try this, 'rm -rf .*' is VERY >> DANGEROUS. '.*' expands to include '.' and '..', and if you happen to >> have privileges to write to the parent directory then you'll end up >> removing all directories *next* to your current directory as well! Karsten> So what do folks do? Karsten> rm -rf .?* # will expand to include .. Karsten> rm -rf .[^.]* # seems right. mkdir temp # Add * to the following if one would like to nuke everything mv .* temp # Check to see whether temp contain anything wrong \rm -rf temp Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNOME == bloatware?
>>>>> "Nathan" == Nathan E Norman <[EMAIL PROTECTED]> writes: Nathan> This is why I went back to windowmaker. I thought gnome looked Nathan> really cool, but between fixing the breakage caused by fast Nathan> moving development, bugs, interesting packaging (by debian Nathan> maintainer and/or Ximian), dependency hell, and the performance, Nathan> it's just not for me. For me, the problem is that Gnome = leakware. The sawfish I've just restarted eats up 26M of virtual memory, and at the same time the gnome-panel I just killed eats up another 30M. After being killed that now sit at 8M and 13M respectively. Of course some of the apps simply shouldn't need that amount of memory, like gnome-terminal. I don't use it, and stay with rxvt, though. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Content-Length header (Was: Some myths regarding apt pinning)
>>>>> "Adrian" == Adrian Bunk <[EMAIL PROTECTED]> writes:
Adrian> From a security point of view woody + libc6 from unstable is
Adrian> worse than any other possibility. Consider there's another
Adrian> security bug in libc6. The fixed version for stable has a lower
Adrian> version number than the version on your system and you won't get
Adrian> the update. This is worse than the situation when you are
Adrian> running one of stable/unstable/testing:
When the above mail arrives my mailbox, the "From " becomes ">From ". This
is de-facto standard (for V7 Mailboxes), I know, and is added by procmail.
Unluckily, this happens to MIME contents as well as normal mail contents.
Of course, that won't appear in base64 contents, but quoted-printable has
that.
I know that procmail will avoid escaping "From " with ">" if a
"Content-Length" header appears in the mail. Unluckily, the mail server
feeding me mails eat all "Content-Length" header. Anyone know whether there
is a convenient "filter" that can be put in procmail to add a correct
Content-Length header into the mail even if that has not been there before?
("filter" put in quote because I know they can't be "real" filter, but must
instead store the whole message somewhere in order to count the number of
bytes there before going back and rewrite the Content-Length header.)
Regards,
Isaac.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Memory usage on debian
>>>>> "Colin" == Colin Watson <[EMAIL PROTECTED]> writes: > quaternion:~$ free >total used free sharedbuffers cached > Mem:256104 251680 4424 0 67536 66640 > -/+ buffers/cache: 117504 138600 > Swap:0 0 0 > quaternion:~$ ./src/crap > zsh: killed ./src/crap > quaternion:~$ free >total used free sharedbuffers cached > Mem:256104 59900 196204 0 6828 13932 > -/+ buffers/cache: 39140 216964 > Swap:0 0 0 Colin> The usual cause of this one is as follows: to start with, you Colin> have a fairly quiet system with lots of data in the kernel's Colin> cache - see the 'buffers' and 'cached' entries - held there Colin> against the possibility that it will be needed in the Colin> future. Hm... then why the numbers after "-/+ buffers/cache" can decrease (by nearly 80M) after running such crap? There is no swap, so nothing can migrate there. Perhaps some clean mmapped pages are simply removed from memory? (Does Linux do that?) I simply can't tell for sure. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Content-Length header (Was: Some myths regarding apt pinning)
>>>>> "Bob" == Bob Proulx <[EMAIL PROTECTED]> writes: Bob> And added by any delivery agent delivering mail to an old style Bob> mail file. It is not just procmail. It is required. I know. But then, there is no "standard" anyway, so that can't be said to be "required". For me as long as my tools happily read them it's okay. Bob> IIRC in the www.mutt.org docs there are references to that. Also Bob> more references as to why you should not do that. Thanks, although I can't find it. Bob> Here is one classic treatise on the subject. Read this before Bob> trying what you suggest. Bob> http://www.jwz.org/doc/content-length.html I know the problem it describes, even when I first read the man page of procmail. I know perfectly that content-length will have problem of jamming up the mail box. But that's not my problem. I use it only as a temporary mail storage. Emacs which we read my inbox and split it up to many groups. Each mail is stored in its own file (I use nnml), so all the critics don't make sense to me. It just feels stupid that at the end each mail is stored in a single file, but still the "From " headers are escaped because it "transits" in a V7 format mail box. And the damage is permanent: you never know whether a ">From " line is due to a "From " line or due to a real ">From " line. (Why they didn't use a less brain-dead escape format?! If you just turn all leading "F" to "FF" it will be perfectly reversible...) And the problem is there even for Quoted printable files. E.g., shell scripts, postscript files, etc., are affected. Yes, very low probability, but I just want to know whether there is a way to avoid it. Bob> Your better option would be to convert to Maildir format mailbox. Bob> Those do not need to escape From markers. Here is a useful Bob> reference for this. Bob> http://www.nb.net/~lbudney/linux/software/safecat.html The only real problem is that the mail will actually be stored *first* in a V7 mailbox by procmail or sendmail or exim or whatever, when the damage is done. Later when you try to split it into many files, you can't undo the damage. Anyway, thanks very much for your response. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Content-Length header (Was: Some myths regarding apt pinning)
>>>>> "Bob" == Bob Proulx <[EMAIL PROTECTED]> writes: >> I know. But then, there is no "standard" anyway, so that can't be >> said to be "required". For me as long as my tools happily read them >> it's okay. Bob> Perhaps no standard. But if you don't escape them somehow then the Bob> message is broken up into two messages at the non-escaped From Bob> line. The second message won't have proper headers as it is just Bob> the body of the first message. Ouch. I mean, Content-Length can be added to avoid having to escape the "From " line, and I won't be unhappy about it. Bob> IIRC in the www.mutt.org docs there are references to that. Also Bob> more references as to why you should not do that. >> Thanks, although I can't find it. Bob> Negative. Why do you insist that mail will be stored first in a Bob> berkeley mbox file and then split? Don't do that. Basically, because I'm so ignorant about the capability of procmail to generate maildir files, and about the capability of Emacs to process them. I will go for that route. Thanks! Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maildir vs. mbox vs. mh ???
>>>>> "Cameron" == Cameron Matheson <[EMAIL PROTECTED]> writes: Cameron> What do you mean by the "From "-thing? Send a mail to yourselves, having a line starting with "From ", and see what is the result. What you will get is this: --- example --- >From time to time you get a line starting with the word From. --- end example --- If you use an mbox-style mail box, you will see a ">" character there at the beginning. This is not seen by anyone using maildir, and I didn't type that in my message. Cameron> I have always just used mbox because that is what fetchmail Cameron> puts my mail into but this thread has aroused my interest in Cameron> maildir... Can i use maildir w/ fetchmail/exim? If not, how Cameron> does one get maildir, For exim: yes. For fetchmail: dunno (perhaps not). But you can always ask fetchmail to put the mail forward to another processor like a local exam, or procmail, which does support maildir. Cameron> and what are the technical advantages? If you don't like the idea that you have mails with "From " lines modified to "suit" the mailbox, or the idea that mails pile up into huge files so that it takes forever to delete or move one message, or the idea that to know how many mails you are having you must read and parse the whole mailbox file (which might well be counted in megabytes), or the idea that when you are reading the mailbox the E-mail delivery program must not write into your mailbox at the same time or the mailbox gets corrupted; while at the same time you don't afraid that your filesystem suddenly have ten thousand files because each mail ends up into a file, maildir is for you. For me, each mail has two copies. I regularly read one of them, the "regular" copy, which is stored as maildir. I use spamassissin to scan for junk, let Gnus throw mails away without too much care, etc., so that I can control the number of files for storing mails (currently around 2000). To minimize the wastage on filesystem space, I use reiserfs on my mail partition, although an ext3 partition with tail files enabled should have similar effect. The other "unprocessed" copy are kept in mbox format for months or even years, just in case when I accidentally delete a mail that I want, when I can rush to it, tail it and hope to extract the needed message. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Laptop with new X server
Dear all, I have a IBM Thinkpad X21, and installed Debian unstable in it. In the previous versions of X servers (including the 3.3.2 version currently in unstable using xserver-mach64), I can switch between using CRT and LCD monitor by pressing the Fn-F7 sequence, but somehow I failed to do so in the current X server (using the ati driver with the xserver-xfree86 package). If I start X with no CRT connected to it, the panel will be used, and after that even if I connect a CRT and press Fn-F7 there is no response at all (rather than switching to CRT and then both CRT+LCD). Does anybody have the same experience, and know how to deal with the problem? Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BS changed to give ^? instead of ^H?
>>>>> "Paul" == Paul Smith <[EMAIL PROTECTED]> writes: Paul> If I use bash and C-q BS, or emacs -q -nw to start it within the Paul> terminal and use C-q BS, it shows that they key typed is ^? and Paul> not ^H as it should be. Who say it "should be" ^H? Even the default text console will give you ^? rather than ^H when you press backspace. In Emacs, ^H is a prefix character for "help" rather than binding to "delete-backward-char". If the ^H binding is made to X terminal programs, Emacs users will find that pressing backspace leave them a prompt asking for a key to specify what help he want, rather than deleting one character on the left of the cursor. If any environment by default sends ^H rather than DEL (i.e., ^?) when you press BackSpace, then you have to file bug against that environment. The only one that this won't work is the one that you have no capability to file a bug against (i.e., MS-Windows...). BTW, the Del key sends the delete sequence in most terminal emulator, i.e., [ 3 ~ (if you use an ANSI compatible terminal-type). Paul> Looking at xmodmap -pke shows that keycode 22 emits backspace, and Paul> xev shows that the BS key is sending the backspace keysym. The BackSpace keysym is a keysym, not a keycode. If you look down, you'll find that the keycode is said to be '"'. Of course, this is not really the case. It actually want to say the keycode is ^?, and enclose it between double quotes. But the ^? actually deletes the leading double quote. Paul> Where should I look for the cause of this? I need BS to give ^H, Paul> like it always used to do. It "always" used to send DEL, unless your configuration is wrong. The "always" means something that is back as far as around the "bo" (i.e., Debian 1.3) days. Now it is probably time to fix your stty so that it accepts ^? rather than ^H. (Just "stty sane" will actually do the trick if you are confronted in such a misconfigured environment.) There is an exception. Until recently, the gnome-terminal incorrectly sends ^H rather than DEL on receiving BackSpace. If you want to get back the broken environment, you can go to the Profile menu, go to compatibility menu, and say you want BS instead of DEL when BackSpace is pressed, and "enjoy" the brokenness of Emacs now. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BS changed to give ^? instead of ^H?
>>>>> "Paul" == Paul Smith <[EMAIL PROTECTED]> writes: it> If you look down, you'll find that the keycode is said to be '"'. it> Of course, this is not really the case. It actually want to say the it> keycode is ^?, and enclose it between double quotes. But the ^? it> actually deletes the leading double quote. Paul> I don't understand this at all... the keycode for backspace is 22, Paul> not ^?, and xmodmap -pke doesn't generate output in quotes. Paul> Where should I look for the cause of this? I need BS to give ^H, Paul> like it always used to do. Oops, sorry, I mean XLookUpString returns you "^?". Paul> I've never used gnome-terminal. I use rxvt almost exclusively. Paul> Maybe a few xterms by accident. Paul> So, something changed in the rxvt/xterm builds? I checked all the Paul> app-defaults and couldn't find anything. Do I have to recompile Paul> them locally? Look for the /etc/X11/Xmodmap files if you REALLY want BackSpace to give you ^H rather than DEL. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XMMS goes silent when moving windows
>>>>> "Michael" == Michael D Crawford <[EMAIL PROTECTED]> writes: Michael> The theory given when I asked about it on the linux-kernel Michael> mailing list was that the X server was not freeing the PCI bus, Michael> and that moving a window would generate activity in the server Michael> that caused it to become free. Michael> This got fixed, but maybe it is broken again. That's another problem. Xmms has never been able to work when the X window manager stop responding to it. I think that just means the XMMS audio thread somehow needs to synchronize to (i.e., wait for) the GUI (or something locked by it) rather than the other way round. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext2 vs ext3 vs xfs vs reiserfs
>>>>> "Matthias" == Matthias Hentges <[EMAIL PROTECTED]> writes: Matthias> Ext3 is rock-stable since it is based on ext2 which is in use Matthias> for many years and is well tested. You probably cannot infer the stability of ext3 from that of ext2. The layout has been made mostly compatible, but the code has been changed for much more than what you can trust without trying it. Matthias> Many people have reported problems (including data-loss) with Matthias> ReiserFS, but for most people ReiserFS works great. I think that is experience during the time when Reiserfs is still stabilizing. I don't know anyone still unhappy with Reiserfs with its stability. The real problem of Reiserfs is that it is not compatible with ext2 at all, and your only hope to create a Reiser filesystem is to create it from scratch. This trouble has to be weighed against the performance benefit that is brought by the transition, which is basically none unless you have a directory containing thousands of files (then Reiser will be much better for looking up files in that directory). That is for Reiser3. Reiser4 is about to come out, and with luck it will get into Linux kernel 2.6/3.0. They say performance doubles with this FS (they achieve this by delayed allocation of blocks to minimize fragmentation), and perhaps that will be a better time to switch FS. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext2 vs ext3 vs xfs vs reiserfs
>>>>> "Vincent" == Vincent Lefevre <[EMAIL PROTECTED]> writes: Vincent> Then, why is fsck necessary with ext3? In a perfect world where there is no filesystem code bug, it is not needed. Now come to the real world again. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] C++ question re. dyn. mem.
>>>>> "MJM" == MJM <[EMAIL PROTECTED]> writes:
MJM> They do. My app would be broken from the start if I could not rely
MJM> on this capability. This style of type conversion is covered in
MJM> elementary C++ books by Bjarne. It's not unusual. You must be
MJM> aware of what you are doing when you do a type conversion.
MJM> Portability is a concern. I am limiting my app to Intel 32 bit
MJM> Linux. Screw everything else.
That you do not treasure portability across CPUs and compilers do not mean
others don't.
MJM> By whom? Your example is nowhere to be found in my C++ books by
MJM> Bjarne. So you are saying that Bjarne promotes bad style in his
MJM> books? Why not tell him:
MJM> http://www.research.att.com/~bs/homepage.html
You must be reading pre-standard C++ books. Bjarne's "The C++ Programming
Language, 3rd Edition" clearly stated that the () "C-style" casting syntax
should be avoided:
This C-style cast is far more dangerous than the named conversion
operators because the notation is harder to spot in a large program and
the kind of conversion intended by the programmer is not
explicit. [Section 6.2.7.]
In his "The Design and Evolution of C++", Bjarne explained that he even
wanted to strike the C-style cast out of the C++ standard except that all C
programs would become not compilable.
MJM> Besides, reinterpret_cast is probably a template function doing
MJM> this:
MJM> return ((T) x); // type conversion using cast
Definitely not. The objection of (T)x is not just its syntax, but also its
unclear behaviour. Consider the following:
#include
using namespace std;
class B {
public:
virtual ~B() {}
};
class B1 {
public:
virtual ~B1() {}
};
class B2 {
public:
virtual ~B2() {}
};
class D: public B1, public B2 {};
int main() {
D d;
B *pb;
B2 *pb1;
pb1 = (B2 *)&d;
cout << pb1 << endl;
pb1 = reinterpret_cast(&d);
cout << pb1 << endl;
pb1 = static_cast(&d);
cout << pb1 << endl;
pb = (B *)&d;
cout << pb << endl;
}
When executed from my computer (Debian sid, gcc 3.3), it gives:
0xbb04 # C-style cast to B2*
0xbb00 # reinterpret_cast to B2*
0xbb04 # static_cast to B2*
0xbb00 # C-style cast to B*
In other words, the behaviour of a C-style cast depends on whether the
casting of the pointer is an "up-cast"/"down-cast" or not; if it is (in this
case up from D to B2) then the cast will be a static cast, doing pointer
adjustment (so that the sub-object of type B2 is found within the object of
type D); and if it is not then the cast will be a reinterpret cast, doing no
pointer adjustment. It is generally agreed that such "compiler
intelligence" is in general no good, since the programmer probably only
expect one of the two possibility will happen, and the result is sometimes
what the programmer expects and sometimes not. If the programmer expects a
static cast he should write static_cast(&d) so that the compiler will
emit an error if the classes are actually of two different hierarchy. If
the programmer expects a dynamic cast he should write dynamic_cast(&d)
so that you understand you are doing something that the compiler has no
control of, and dereferencing the result will probably be a programming
error.
Regards,
Isaac.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] C++ question re. dyn. mem.
>>>>> "Al" == Al Davis <[EMAIL PROTECTED]> writes: Al> Since you didn't say what uint64_t is, let me make a diabolical Al> definition of it. uint64_t is a type defined in C99, which is always a 64-bit unsigned integer. Whether it is already in your C++ compiler depends pretty much on platform, but it can be expected that before too long it will. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error when setting path
>>>>> "Wayne" == Wayne Gemmell <[EMAIL PROTECTED]> writes: Wayne> Any ideas?? These are just two of my many attempts, the second Wayne> being as root. As you can see the directory does exist but from Wayne> what I can tell that doesn't matter much. Remember that the shell language is strange enough that variables declaration syntax and usage syntax are different. As variable name to be assigned, *don't* put the $. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rms on debian
>>>>> "Diego" == Diego Calleja García <[EMAIL PROTECTED]> writes: >> programs, and their ftp server distributes them. That's why we don't >> have links to their site on www.gnu.org. Diego> *ahem*ahem* Diego> I was going to saywell. Better I'll shut up. Some people just Diego> can't learn. Learn what? Or is it that you can't learn? Different people have different opinions, and the fact that www.gnu.org decided not to have a link to Debian means that the crews in www.gnu.org agreed to RMS about not having Debian listed is a good idea, even though GNU is the one who started Debian. And www.gnu.org does not represent RMS alone, but instead a group of followers who are pushing the ideals of GNU. FSF is not about getting something usable as soon as possible. If that is the case, we don't need GNU, since Unix had always been available (although probably with a fee and unsatisfying license). It's a political movement, and being such it wants the largest number of people know about the political ends. Having the most people using Linux or even GNU software is *not* the motivation of GNU. So if some existing distribution doesn't suggest the use of proprietary software *at all*, it is simply natural for GNU to promote that, than to promote something that *does* suggest the use of those proprietary software (people would say, "proprietary software are good and necessary---even the software distribution promoted by primary proponents like FSF suggests the use of them). Frankly, I don't find anything wrong or sad about it, and I don't find it difficult to continue to use Debian as a result of that. Of course, moving non-free software out of Debian is better, but it's so hard to get there. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rms on debian
>>>>> "Paul" == Paul E Condon <[EMAIL PROTECTED]> writes: Paul> On Mon, Aug 18, 2003 at 10:12:13AM +0800, Isaac To wrote: >> ... Different people have different opinions, and the fact that >> www.gnu.org decided not to have a link to Debian means that the crews >> in www.gnu.org Paul> >> agreed to RMS about not having Debian listed is a good idea, even >> though GNU is the one who started Debian. And www.gnu.org does not >> represent RMS alone, but instead a group of followers who are pushing >> the ideals of GNU. >> Paul> I just looked at www.gnu.org. Found lots of idealistic stuff that Paul> lots of people have never read. The only distribution that I found Paul> mentioned under "Links to Other Free Software Sites" was "Debian Paul> GNU/Linux". Not Redhat, SuSe, Mandrake, etc, And not Paul> "GNU/LinEx". Maybe my search skills are not great. Someone else Paul> should repeat my work and report. Paul> If my result is correct, what are the implications? Paul> I like Debian. I like GNU. I like Linux. I like Free Software. But Paul> what is RMS really intending? Did he really say what is being Paul> attributed to him? Who is in charge at www.gnu.org? Perhaps I really should not buy the interview so much as not to check www.gnu.org before posting. =) Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.6
>>>>> "Sridhar" == Sridhar M A <[EMAIL PROTECTED]> writes: Sridhar> On Mon, Sep 01, 2003 at 11:33:51AM +0900, Nick Hastings wrote: >> echo "8139too" >> /etc/modules >> Sridhar> That is the solution similar to what I have for my cd-writer Sridhar> (ide-scsi). But I am curious to know why it fails under 2.6 Sridhar> and works under 2.4.x. Should eth0 be `defined' anywhere for Sridhar> the kernel to know about it? The kernel don't know about it. It will simply modprobe eth0 when you use it. So if you have "alias eth0 8139too" in your /etc/modules.conf (or /etc/modprobe.conf for new kernels), it will load it automatically. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xmms conflics with esd?
>>>>> "Dai" == Dai Yuwen <[EMAIL PROTECTED]> writes: Dai> Hi, Dear All I find xmms conflics with esd. Unless I kill esd can Dai> xmms play MP3s. I use woody and gnome1.4. Any advise? Go to the output plugins preference of xmms and choose esd. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XMMS and the new MP3 patent terms
>>>>> "W" == W Paul Mills <[EMAIL PROTECTED]> writes: W> Are you saying even remove from non-free? Some of us have good reason W> to use MP3 files from 3rd parties. For example: W> http://www.banjonews.com/ If you look at the license of non-free software in the Debian archive and read the copyright file of each of them, you can find that they allow the binary code to be distributed in a Debian CD-ROM to be sold. They become non-free because of things like source code not provided, commercial *use* (rather than distribution) restrictions, disallowing changes to the code, etc. This is not the case for MP3 code. And in fact, I do think that patent encumbered things should be off from Debian once the patent holder starts to do something "real" with the patent, given that patents is the biggest threat to free software. You will be able to use MP3 players. Given that the format is so popular, somebody is going to setup a site so that you can add a source line to your /etc/apt/sources.list to download MP3 players, even if Debian finally decided to stop distributing them. It just makes life of CD producers easier, by not forcing them to either pay Thomson or render their distribution less competitive by pruning those software. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XMMS and the new MP3 patent terms
>>>>> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes: Joey> Restrictions on commercial sale violate point 1 of the DFSG, and Joey> such a violation alone is enough to put software into non-free. So Joey> be very careful before selling CD's of debian's non-free archive. Hm... then we can make everybody "happy" (sort-of) by moving xmms mpg123 module, mpg123 package and mpg321 package into non-free? Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XMMS and the new MP3 patent terms
>>>>> "Colin" == Colin Watson <[EMAIL PROTECTED]> writes: Colin> On Sun, Sep 01, 2002 at 01:25:39PM +0800, Isaac To wrote: >> Hm... then we can make everybody "happy" (sort-of) by moving xmms >> mpg123 module, mpg123 package and mpg321 package into non-free? Colin> Not necessarily. If it is not legal to distribute the package at Colin> all without paying a fee (and I'm not making any claims about Colin> whether that's true or not in this case), then we cannot Colin> distribute it even in non-free. Ah... just forgot that the mpg321 package, etc., must be relicensed because GPL states that in case of patent problem any distribution must be ceased. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SOLVED: XMMS and the new MP3 patent terms
>>>>> "Paul" == Paul Johnson <[EMAIL PROTECTED]> writes: Paul> OK, I *know* it's been mentioned in the thread already, but in Paul> case people somehow missed it, the patent holders clarified thier Paul> position on August 29th, and I'm really getting tired of this Paul> thread. In short, nothing changed for software. If it wasn't GPL Paul> compatible before, it never was. This dies here. So what? The xmms and mpg321 packages still cannot continue to stay where it is now, and Redhat is 100% right in removing the xmms mpg123 module and the mpg321 out of its archive. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XMMS and the new MP3 patent terms
>>>>> "David" == David Wright <[EMAIL PROTECTED]> writes: David> But Debian does encourgage people to sell CD-ROMs of whatever is David> not in non-free. If someone were to include an MP3 player on a David> Debian CD-ROM and sell it, that person would be violating the MP3 David> licensing terms. As a courtesy to those who sell Debian CD's, and David> to avoid any possibility of being charged as an accessory to David> patent infringement, Debian should put MP3 players into non-free David> and remind people not to sell CD-ROMs of that archive. Except that GPL'ed programs must not have such problematic patents problem. The general discussion of GPL says this: Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. and in the terms and condition, it says: 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. So basically, because of the clarification of Thomson, the authors of mpg321 (or any other GPL mp3 players) or any distributors (Debian included) can no longer grant you a license saying "you are free to use, copy, modify and distribute your programs with or without a charge as long as the result remains GPL", it is the obligation of the authors and distributors to "refrain entirely from distribution of the Program". Well, perhaps Thomson didn't have made the "allegation" yet, but that's the idea. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XMMS and the new MP3 patent terms
>>>>> "John" == John Hasler <[EMAIL PROTECTED]> writes: John> No conditions have been imposed on Debian. Until a registered John> letter from Thomson's lawyers arrives GPLd mp3 stuff can go in John> non-free. The program does not satisfy DFSG (it cannot be sold at a fee), so there is no place in main for it, *now*. The only thing that is up to interpretation is whether it can stay in non-free. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XMMS and the new MP3 patent terms
>>>>> "Isaac" == Isaac To <[EMAIL PROTECTED]> writes: John> No conditions have been imposed on Debian. Until a registered John> letter from Thomson's lawyers arrives GPLd mp3 stuff can go in John> non-free. Isaac> The program does not satisfy DFSG (it cannot be sold at a fee), Isaac> so there is no place in main for it, *now*. The only thing that Isaac> is up to interpretation is whether it can stay in non-free. Reading it again, I find that this is exactly what John really means. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is it reiserfs?
>>>>> "Romuald" == Romuald DELAVERGNE <[EMAIL PROTECTED]> writes: Romuald> By default ext3 don't journalised data. The default mode is Romuald> 'ordered'. Even in that case, similar problem can occur. In general, a Unix journaling filesystem cannot completely prevent halfly written files. The problem is due to Unix concurrency semantics (things written are immediately visible by all other processes, so if in the middle the processes all dies there is no safe point to get back to). If you use a filesystem that looks like that of Ameoba or Sprite, that's another matter (but, let's get back to reality). So in general, a journaling filesystem is good in that you won't trash your filesystem. But that's all it can guarantee to you. Perhaps the average amount of failure can be reduced, but it is not guaranteed. You can still need your backup copy of available, or a UPS. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mozilla too many process
>>>>> "Derrick" == Derrick 'dman' Hudson <[EMAIL PROTECTED]> writes: Derrick> On Tue, Sep 17, 2002 at 06:53:11PM -0400, Seiichiro Tanizaki Derrick> wrote: | When I lunch mozilla, it takes about 80M of memory Derrick> | with seven processes running. Derrick> This last statement isn't true. It's one process with 7 Derrick> "kernel" threads. The linux kernel maps threads onto Derrick> lightweight processes. Your output from 'ps' or 'top' will Derrick> make it appear that there are many processes running, but it is Derrick> an illusion. Linux does not distinguish between "kernel threads" and "lightweight processes". It doesn't make any distinction between "process" and "threads" either. In fact, it doesn't use the word "process" within the kernel. Instead it use the word "task". So this statement is also wrong. Instead, what happens is that all the mozilla tasks are sharing the same memory, so although it might seems that each of them is taking 54M of swap and 36M of physical memory, it does not add up. All of them are sharing the same memory, so in total, "only" 54M of swap (actually, "Virtual memory") and 36M of physical memory is used. BTW, I don't know how the original poster comes up with the magic number "80". Even if I adds up 54 and 36 (which is wrong: physical memory is part of virtual memory), I can only get 90. And multiplying anything with 7 gets a number way too large. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext2 ext3 ?
>>>>> "Gerard" == Gerard Robin <[EMAIL PROTECTED]> writes: Gerard> tune2fs -j /dev/hdb3 worked fine for me (I use Gerard> kernel-2.4.18...deb) but after that, I stopped badly my machine Gerard> and when I rebooted, the time to clean /dev/hdb3 is about the Gerard> same as before. Thanks to all who responded to me. Most likely your kernel does not have ext3 compiled to it. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gnome and Sound
>>>>> "Jerome" == Jerome BENOIT <[EMAIL PROTECTED]> writes: Jerome> Bonjour, I have just configured Gnome on Woody: whereas I can Jerome> listen to my favorite CD with the cdplayer, I can not ear the Jerome> sound events from Gnome (despite the fact that there are allowed Jerome> via the Gnome control center). I guess I have missed something. Jerome> Any idea ? Try to disable it once and then re-enable it and see whether it works then. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Investigation Report after Server Compromises
>>>>> "Paul" == Paul Morgan <[EMAIL PROTECTED]> writes: Paul> With regard to your question 3, a buffer overflow exploit is Paul> always a stack exploit and is designed to execute arbitrary code Paul> with the called program's privilege. But this time it is an "integer overflow", not a "buffer overflow". The idea is that when brk() is called, the kernel forgot to check whether this will result into the memory map pasting the end of address space used for the processes. The problem is that after pasting the end of the address space, it starts to be the kernel space, mapping all the physical memory of the computer directly. I.e., it includes all the memory of the kernel and also all the memory of all other processes. Once you get to this point, it just requires a little bit more imagination before you can write to all the memory of the computer directly, skipping all the protection mechanism of the kernel. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Investigation Report after Server Compromises
>>>>> "Isaac" == Isaac To <[EMAIL PROTECTED]> writes: >>>>> "Paul" == Paul Morgan <[EMAIL PROTECTED]> writes: Paul> With regard to your question 3, a buffer overflow exploit is Paul> always a stack exploit and is designed to execute arbitrary code Paul> with the called program's privilege. Isaac> But this time it is an "integer overflow", not a "buffer Isaac> overflow". The idea is that when brk() is called, the kernel Isaac> forgot to check whether this will result into the memory map Isaac> pasting the end of address space used for the processes. The Isaac> problem is that after pasting the end of the address space, it Isaac> starts to be the kernel space, mapping all the physical memory of Isaac> the computer directly. I.e., it includes all the memory of the Isaac> kernel and also all the memory of all other processes. Once you Isaac> get to this point, it just requires a little bit more imagination Isaac> before you can write to all the memory of the computer directly, Isaac> skipping all the protection mechanism of the kernel. All the "pasting" should really be "passing"... stupid me non-native English speaker... Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Server Compromise -- A Fire Drill ??
>>>>> "Dave" == Dave <[EMAIL PROTECTED]> writes: Dave> Seems like the critical link to be fixed is the vulnerability of Dave> daemons that run with root privilege and receive input from users. No. The kernel itself has bug. The "user" (attacker) is running *perfectly legitimate* system calls (brk(), the call that will be made when you malloc()) from a rather strange but allowed executable file (that have the code segment moved to the end of address space). And then, due to the kernel bug, the user can write into arbitrary location in the kernel, do whatever he wants. So here the problem is the kernel---the ultimate source of permission that you have on the computer. If the kernel is buggy, there is really little that you can do to be protected from being harmed---except of course to have a network of mutually distrusting servers with completely different passwords, keys, etc. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Server Compromise -- A Fire Drill ??
>>>>> "Dave" == Dave <[EMAIL PROTECTED]> writes: Dave> So how many daemons and kernel routines need both root access and Dave> input from a user process? Remember that *all* kernel routines are running in kernel-mode of the processor, i.e., having even higher permission than a normal root process. And most of the inputs taken by system calls are tainted with user inputs. Even worse, the kernel is performance critical. Adding all of these, you'll understand why it is so hard to make sure everything is correct. That's why some people advocate micro-kernels, to reduce the "source of power" to a very small code base that can be monitored in an easier way. But we are not at that point yet, so the race between white-hat and black-hat hackers *will* continue. In any case, even if we are in a micro-kernel like Hurd, a bug in the core servers (e.g., the authentication server, the filesystem server or the Unix API server) can easily give out arbitrary power to the user, so it is important to make sure core servers are bug-free in any case. The only question is "how many code are in the core servers". Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make-kpkg
>>>>> "Paul" == Paul Johnson <[EMAIL PROTECTED]> writes: >> I use Grub as a bootloader. After making a kernel .deb using >> make-kpkg, I'm running dpkg -i Near the end you are asked to if >> you want to make a boot block. What is this? Is it just an entry in >> Grub or LILO? What I'm most concerned about is being able to boot to >> my old kernel if I screwed this one up. If the old kernel is not yet deleted, you can edit the Grub entry at boot to replace the kernel file by the old kernel, and boot. The old kernel will be booted allowing you to correct the problem. Paul> Since LILO is so much better documented, easy to configure, far Paul> more widely used, is generally the "assumed" bootloader, and just Paul> works, why not just use LILO? Because Grub provides a lot of functionalities that is not provided by LILO. E.g., in Grub you can boot a test kernel once without running "grub-install" (in LILO you must run "lilo" after rewriting lilo.conf). Even filename completion will work, so you can still find your kernel or initrd even if you forget their exact names. You can change any boot parameters before that, so you don't need nearly as many "emergency" boot entries as in LILO. Grub understand the filesystem, so you don't need to worry about any utility moving the actual location of the kernel on the disk---you can safely cp your kernel to somewhere else and mv it back (or run your defragmentor), and there is no need to rerun "grub-install" as in LILO (rerun "lilo"). Grub also allow some entries to be protected by a password, so you can have your Windows boot entry without worrying about somebody boot to Windows and trash your Linux partition (because only you, knowing the password, can boot to Windows), and at the same time allow anybody to boot the Linux partition and login there. And I don't consider Grub to be much less documented than LILO. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux is not for consumers!
>>>>> "Terry" == Terry Hancock <[EMAIL PROTECTED]> writes: Terry> Saying that the source code *is* the documentation is not unlike Terry> saying the Human Genome is an Anatomy & Physiology textbook. :-P But very often the source code is very good part of the documentation, especially when the source code is written by competent programmers. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux is not for consumers!
>>>>> "H" == H S <[EMAIL PROTECTED]> writes: Isaac.> But very often the source code is very good part of the Isaac.> documentation, especially when the source code is written by Isaac.> competent programmers. H> uh huh, where are we going? I for a moment, while reading your above H> message, thought you meant that Human Genome is *not* written by a H> competent programmer! No, that can't be. I must have been mistaken. Right, Human Genome is not written by programmers. Genes are evolved, not designed. In contrast, a good programmer write code that will make sense when it is being read, because they are the ones who need to read them the most, and when they need to change them it is usually at a time when they forget much of the program. They will write it in a structure that reflect the specification of the project, layered in a way that reflects how the users will perceive the software, etc. In other words, they should be self-documenting. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failure to start gnome settings daemon
>>>>> "William" == William Ballard <[EMAIL PROTECTED]> writes: William> what's wierd is that when I did an aptitude upgrade today, William> dlocate -S gnome-set reported capplets contained William> /usr/bin/gnome-settings-daemon, and I had capplets installed, William> but the file /usr/bin/gnome-settings-daemon wasn't present. Don't forget that dlocate works like locate: it report the data that is collected during the last update of the database, which happens once a day in a cron job. So the info you get from dlocate is old: the gnome settings daemon is really gone, to /usr/lib/control-center. William> I undid all of todays changes and will just wait a week or two. William> There's a lot of gnome brokenness now in unstable, apparently. I'm still wondering whether it actually is something to do with the fact that some of the packages in unstable are still at 2.4. E.g., gnome-games-data, gnome-applets, gnome-applets-data, gnome-common, gnome-games, gnome-media, gnome-mime-data, gnome-system-monitor, gnome-utils, etc., all have the version with "2.4" as part of it. Anyone can confirm? Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC
>>>>> "Dave" == Dave Carrigan <[EMAIL PROTECTED]> writes: Dave> Actually, gcc 2.95 does support quite a bit of the standard. It Dave> definitely supports namespaces, and a majority of the Dave> STL. You're probably thinking of the previous version (2.2?). The Dave> timeline was Dave> gcc 2.2 -> egcs -> gcc 2.95 -> gcc 3 Dave> egcs was what drove gcc into C++ standards compliance; I can Dave> remember switching from gcc to egcs when doing a project that Dave> needed good STL. This was in the fall of '98 if I recall, and gcc Dave> at that time was not good enough, but it was not 2.95. g++ in GCC 2.95 deviates so much from standard C++ that I decline to say it approximates the standard. Things as simple as the hex or fixed manipulators are not implemented. Trying to define any rdbuf for its iostream and you'll see it is a nightmare. So sad that the acm.uva.es judge (which is one of the primary reason that I write C++) is still using that particular version. :( Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: use udev
>>>>> "John" == John L Fjellstad <[EMAIL PROTECTED]> writes: >> Is sysfs going to replace procfs or something? John> Not a replacement, an extension. Procfs was originally intended John> to be just for the processor-related info, I think, Process related, not processor related. John> and slowly it got added more features (like disk info, system info John> etc). With sysfs, anything that doesn't belong to procfs will go John> there. So far it seems only the device information has moved over. Things like the sysconf interface, net directory, sysvipc information, and files in the root directory of the /proc fs, are still only found in /proc. Anyone has any idea about whether they will eventually be moved as well? Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC
>>>>> "Dave" == Dave Carrigan <[EMAIL PROTECTED]> writes: Dave> And 5 years from now, they will probably be telling you to avoid Dave> the export keyword because it's not well supported (yet!). Perhaps I'm too optimistic, but I think 5 years from now they will probably tell you not to use export at all because it is non-standard. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stable vs. Testing Vs. Unstable
>>>>> "Loren" == Loren M Lang <[EMAIL PROTECTED]> writes: Loren> I'm curious about how many people are actually using Debian Loren> Unstable or Testing to Stable for normal desktop use or even a Loren> production server. I've being using Gentoo lately, and I love Loren> how nice the newer software is like KDE 3.2.1 or Gnome 2.4 and I Loren> don't want to go back to Gnome 1.x just because I want a "stable" Loren> debian system, where gentoo seems to run fine with the latest. I use testing for my home server, and stable for a computer that I don't care much anyway. For desktop (and laptop) I use unstable, ever since the first time I have the gust to try---and find that it is not *that* unstable, after all. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fat32 write access for user
>>>>> "Adam" == Adam Aube <[EMAIL PROTECTED]> writes: Adam> Jacob Bresciani wrote: >> or umask=000 for 777 permissions on all files/folders Adam> World-writable directories are generally discouraged unless you Adam> really know what you're doing - that's why I suggested 004 Adam> instead. Then you'd want 007 or 002, not 004. Regards, Isaac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Setting up gdm output display in stretch
Hi all, I've recently acquired a new Dell desktop, featuring a display card with both VGA and HDMI output. The monitor can also take both as input. As HDMI has better quality I naturally want to get the output there. The problem is, X consider the two as separated displays, and gdm3 would always output the login screen to both inputs, where VGA is the primary, HDMI is the secondary, in extended mode. This means I can only login if I can see the VGA output. After login I can change the display settings to mirror, so that I can see the output in HDMI. But that doesn't change the login screen. I've searched the web for a while, and there are essentially two solutions. One is to put an xrandr command in /etc/gdm3/Init/Default. I've experiment it for a while, until I conclude that in my Debian stretch installation, the file is not run at all: putting something like "echo hello > /tmp/hello" into that file will not create the /tmp/hello file after X gets started. The other solution is to copy my ~/.config/monitors.xml to ~Debian-gdm/monitors.xml. Again, nothing happen, the file simply gets ignored. I've also tried to add something to /etc/init.d/gdm3, thinking about whether I can run xrandr after I detected gdm is running. But I noticed that it won't work, as Debian is now using systemd, and the later part of the script won't run. Anything I've missed? Regards, Isaac
