fetchmail and syslog
Hello all, I'm wondering if someone could help me with how to keep fetchmail from logging to /var/syslog. I read the manpages of both fetchmail and syslog, but still don't understand. When invoked with the --syslog option, fetchmail uses syslog: [...] Messages are logged with an id of fetchmail, the facility LOG_MAIL, and prior- ities LOG_ERR, LOG_ALERT or LOG_INFO. (from "man fetchmail"). And, my /etc/syslog.conf has auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog [...] mail.* -/var/log/mail.log [...] mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err/var/log/mail.err (The full contents will be attached at the end of this message). Non-error messages from fetchmail appear in /var/log/mail.info and mail.log . That I like. But, how can I prevent the same messages from appearing in /var/log/syslog ? I think the "*.*" part for /var/log/syslog is catching the messages from the fetchmail. But, seeing that the messages that appear in auth.log don't appear in syslog and guessing ';' means exclusion, I tried *.*;auth,authpriv.none,mail.* /var/log/syslog and restarted syslogd. This didn't work. Indeed, "man syslog.conf" doesn't say ';' means exclusion. . . . I'm sure I'm missing something. Thank you for your help, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fetchmail and syslog
Wayne Topa <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... [. . .] > In the FM page I did a search on log. Maybe this is what you want. [. . . ] > The -L or --logfile option (keyword: set logfile) > allows you to redirect status messages [. . .] Thank you, Wayne! But, in fact, I recently switched from --logfile to --syslog, because I wanted timestamps. The logs emitted with the --logfile option don't have timestamps. Syslogd seems to add timestamps to the messages before writing them. Also, I wanted to learn how to control desitinations of syslog messages not only for fetchmail but also for other cases. Thanks anyway, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fetchmail and syslog
[EMAIL PROTECTED] (Ryo Furue) wrote in message news:<[EMAIL PROTECTED]>... [...] > When invoked with the --syslog option, fetchmail uses syslog: > >[...] Messages are logged >with an id of fetchmail, the facility LOG_MAIL, and prior- >ities LOG_ERR, LOG_ALERT or LOG_INFO. > > (from "man fetchmail"). And, my /etc/syslog.conf has > >auth,authpriv.* /var/log/auth.log >*.*;auth,authpriv.none -/var/log/syslog >[...] >mail.* -/var/log/mail.log >[...] >mail.info -/var/log/mail.info >mail.warn -/var/log/mail.warn >mail.err/var/log/mail.err > > (The full contents will be attached at the end of this message). > > Non-error messages from fetchmail appear in /var/log/mail.info and > mail.log . That I like. But, how can I prevent the same messages from > appearing in /var/log/syslog ? > > I think the "*.*" part for /var/log/syslog is catching the messages > from the fetchmail. But, seeing that the messages that appear in > auth.log don't appear in syslog and guessing ';' means exclusion, I tried > >*.*;auth,authpriv.none,mail.* /var/log/syslog > > and restarted syslogd. This didn't work. Indeed, "man syslog.conf" > doesn't say ';' means exclusion. . . . I'm sure I'm missing something. Finally I found a solution. What you need is *.*;auth,authpriv.none;mail.none /var/log/syslog That is, "mail.none" is the key. Well, I'm afraid I don't think this grammar is well designed, and also I think the manpage could have been clearer. It took three or four repeated readings of the manpage plus some experimentation until I figured this out. Perhaps, I guess most people don't bother with syslogd and those who do already know enough about it. Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
John L Fjellstad <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > I was wondering if Linux can be considered Unix? This question makes me laugh (no offense to you) because it reminds me (and would remind many people who frequent(ed) comp.unix.admin) of a certain person, who would never fail to be offended, saying "Linux is not Unix" as if it were an mantra, whenever an innocent poster asks a question about Linux in comp.unix.admin. If you are intrested, seach the google groups with "Rev Don McDonald Unix Linux". He was very derisive toward Linux and fierce enough in repeating the mantra to scare novices off and to be quite notorious to the frequenters. Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
"Steven Jones" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Working in a MS, Solaris, Linux, Tru64 shop, I find that for the vast > majority of our servers the usability of Linux is as good as Unix if not > better. While Unix might have high end bits Linux lacks for 95% of the > world's servers that small missing % I suspect is not an issue. This is not a Linux-vs-Unix issue, but I've recently been experiencing a downside of Linux. I think one of the biggest problems for developers of commercial software for Linux is that there's no such thing as "the" Linux OS. There are simply too many combinations of the kernel version, libc version, pthreads version, etc. to support all. The consequence is usually the vendor supports only the RedHat Linux. I'm using the Intel Fortran Compiler (IFC). Its version 7 runs on Debian without any problem whatsoever, although Intel doesn't support Debian. But, last year Intel released a total rewrite of the compiler, version 8, with which my Fortran programs don't work at all (*). Since Debian isn't supported, even if I paid (which I don't), Intel wouldn't fix my problem. (If paying would fix it, I would pay.) This is a big headache. Uniformity is sometimes good. I also heard from a programmer that her company develops software only for Windows because it's so uniform and ubiguitous. Her company, being small, wouldn't be able to support Linux. If a costomer doesn't have a Windows machine, the company makes the costomer buy one. (The sofwares so expensive that the cost of a lowly Windows machine is nothing.) Unfortunately, uniformity and community efforts don't come together. Cheers, Ryo - (*)In case anybody is interested, executables created by the IFC 8 compiler use a pthread library, even when the program isn't parallized (so I don't understand why the thread library is linked). I heard the standard pthread library of Linux has a stacksize limit of 2MB hard-coded in it, so the executable segfaults when the stack limit is reached. The user can do nothing about it. The fix seems to be to update the thread library to nptl, which isn't available for Debian Woody. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What's this mounted temporary drectory? /tmp/autoKVio9R
Hello all, I recently found the following: $ df -k [...] /tmp/autol8wP90 37483560 2742148 32837312 8% /tmp/autoKVio9R $ which I'd never seen before. I'm the sole user and the admin of the machine. Also, $ ls -lF /tmp total 28 drwx--0 root root0 Jul 17 20:21 autoKVio9R/ [...] and there's no /tmp/autol8wP90 . I don't remember what I did diffrently recently, but I certainly didn't create the directory or mount it. I wonder if somebody could guess what it is. Is it something dangerous? like a symptom of being cracked? I use Debian 3.0r2. Thank you, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Paul, Thanks for your comments. | > I'm using the Intel Fortran Compiler (IFC). Its version 7 runs on | > Debian without any problem whatsoever, although Intel doesn't support | > Debian. But, last year Intel released a total rewrite of the | > compiler, version 8, with which my Fortran programs don't work at all | > (*). Since Debian isn't supported, even if I paid (which I don't), | > Intel wouldn't fix my problem. (If paying would fix it, I would pay.) | > This is a big headache. Uniformity is sometimes good. | | However, as explained above, uniformity does not exist. Quick, tell me | which RPM I need, as a Debian user, to easily and cleanly install the | software like the packager intended: Mandrake, Red Hat, Fedora, SuSE... At least, Intel supports RedHat 9.0 (or whatever version Intel mentions. I don't remember correctly.). As long as you use that version of RH, Intel will support you. (If you replace the kernel, libc, or other "critial" part of the OS, your support is void, of course.) And "most" people use RedHat anyway. (In my workplace, all the Linux users except me use RH, it seems.) That's kind of uniformity, isn't it? Not as uniform as Windows XP, though. | > I also heard from a programmer that her company develops software | > only for Windows because it's so uniform and ubiguitous. | | I usually feel sorry for people like that. They miss the fact that unix | is everywhere, has been everywhere for decades, and will probably be | around long after the commercial software fad fades back into relative | obscurity. I suspect you miss my point. Perhaps, I wan't clear enough. Although Unix is everywhere, it's not trivial to write a significant piece of sotware which runs on all the major Unixes out there. The example I gave in my last message about the Intel compilear is a piece of evidence which supports my opinion. | > Unfortunately, uniformity and community efforts don't come together. | | Right. That's why all the open browsers are standards compliant, | and IE is not. Why pretty much every network service out there has | a free, standards compliant implimentation, yet Microsoft still | insists on breaking the uniformity and charging infinitely more for | it. I don't like what MS does, either. But, that doesn't obscure the fact from me that Windows XP is more uniform than Linuxes. The Intel compiler which runs on RedHat doesn't run on Debian, whereas Acrobat reader which runs on a Windows XP machine will run on another. That's not a fair comparison. I know that. My point is orthogonal to standard compliance. IE ignores the standard, but it runs on evey Windows XP, which outnumbers Debian machines. By the way, the Intel compiler doesn't run on Debian because our thread library doesn't comply with the POSIX standard. At least so I heard. Standard compliance on this level is a faraway goal. If there were a single, comprehensible standard of Unix, and every brand of Linux/Unix follows it, source programs of open source software wouldn't need those ugly "#ifdef _SOLARIS_9_" etc. That's why commercial software vendors say something like "Supported OSs: Solaris 9 and 10; Aix such-and-such; . . .". That's understandable. They have to test their program extensively before its release and they have to get ready to receive questions and complaints from the customers. That incurs a LOT of resources (money and manpower), I guess. Some open source software like GNU emacs runs on most Unixes. I bet a LOT of resources went into it. By the way, I know apt is much better than rpm. I'm not saying RH is technically "better" than Debian. I'm not saying Windows XP is better than Linux. I'm trying to explain why commercial vendors are reluctant to develop software to run on all Linuxes, or on all Unixes, for that matter. Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Hi, Since Kent West has kindly clarified what I wanted to say, I'm not going to repeat my main point. Only the following: Erik Steffl <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... [...] >about particular software (nptl thread library) not being available > for woody: why not install it yourself? just because it's not available > as debian package does not mean you cannot install it. I can imagine > that this might not be possible in all cases but in general this > approach solves lot of portability problems (from one linux > distro/version to another linux or even unix distro/version). In fact I looked at the homepage of nptl. That was kind of scary to me :) The page says that you need to use a rather new kernel and libc. So, the installation of nptl would mean: Back up everything, learn how to build kernel since I've never done that before (my machine is dual-processor, and my kernel was built by another guy), learn how large an impact upgrading libc will mean, and so on. If I had a leisure few days, I might try. But, if I had a few days off, I'd rather spend the time away from the computer screen! I've had too much these days in front of my workstation. By the way, Intel compiler is really critical to my work. So, I'm sticking to version 7 of it, which is working. But, one day I will need to switch to version 8, because Intel won't fix bugs of version 7, let alone enhance its features. And, I don't expect the GNU Fortran 95 compiler will be even half as mature as the Intel compiler in a few years. Thank you all for your input, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Paul E Condon <[EMAIL PROTECTED]> wrote in message news: [...] > > I'm using the Intel Fortran Compiler (IFC). Its version 7 runs on Debian > > without any problem whatsoever, although Intel doesn't support Debian. But, > > last year Intel released a total rewrite of the compiler, version 8, with > > which my Fortran programs don't work at all [...] > > If your programs work with version 7, why do you feel a need to > migrate to version 8? Well maybe because version 7 will become > unavailable soon (?). For a couple of reasons. One is that Intel doesn't want to fix bugs in version 7. For example, I discovered a problem in version 7 and reported it to Intel. They aknowledged that it is indeed a problem, but they say they won't fix it because version 8 doesn't have the problem. They strongly urged me to migrate to version 8. I suspect that they wish they hear nothing about version 7 and want to pull out as soon as possible. Another reason is that I'm not sure if you can get a copy of version 7 for free any more. When I installed version 7, I didn't think it will go away so that I didn't store the package. Now, what if my machine crashes and I need to install the compiler again? > Would migrating to the GNU fortran compiler be > more or less work than migrating to intel version 8? I haven't used the GNU Fortran 95, but I'm 98% sure that it's almost unusable at this stage. Since I've had *enough* unpleasantness with new compilers, I'm very reluctant to give the GNU compiler a try at this stage. For example, I had to report a couple of internal compiler errors for the then new Sun Fortran 95 compiler. I again reported a few internal compiler errors for the 2nd version of Sun F95 compiler, and it emitted obviously wrong code in certain cases if you switch on the optimizer. Then the initial releases of the 3rd version of the same compiler gave me a few internal compiler errors. I think the Sun compiler at last reached a mature stage at the later releases of the 3rd version. I had very similar experience with another vendor, too. Also, I heard that the optimizer for the GNU F95 compiler is almost nothing at this stage. I recently found one of the programs I use runs six times faster with -O3 than without on an SGI machine (I'm not using automatic parallization, so the speedup is a genuine improvement due to the optimizer). I mean, the optimizer is really important for the type of computations I'm doing. Speed comparisons by other people between the GNU Fortran 95 and the Intel compiler show similar difference in performance. > (Or migrating to C/C++?) That's out of question! :) For numerical computation, Fortran 95 is "better" than C++. (I have plenty of experience in C++ programming.) Sure I greatly miss C++'s objects and templates and other goodies. But codes for numerical computation can be much more "easily" written in Fortran 95. That's the most important point for a non-proffessional programmer like me. > If you were to migrate to GNU, you would be safe from the need > to ever migrate again. You just have to keep a safe copy of the > source. Yes. I'm waiting for the day when the GNU Fortran 95 becomes as mature as the GNU C compiler. But, then the most commercial compilers will have been supporting Fortran 2003, and I will want to use some of the F2003's features. In this area, open source software lags far behind, sadly. Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Steve Lamb <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Ryo Furue wrote: > > Some open source software like GNU emacs runs on most Unixes. > > I bet a LOT of resources went into it. > > Some? Some!? slrn, apache, mysql, screen, joe, bind, X, vim, kde, > openoffice, perl, python, php, ruby, just to name a few off the top of my > head. Some of those are written and maintained by a single person. Earlier > you wrote... > > > The example I gave in my last message about the Intel compilear is a piece > > of evidence which supports my opinion. > > The above examples refute it. Good! Please tell Intel that it's easy to write a compiler to run on all major brands of Unixes. A single person can do that. Why can't Intel? I can't verify how correct your statement is. I don't know exactly how much effort went into emacs to make it portable, exactly how difficult to write a compiler is, etc. I may be wrong in saying the efforts to make emacs portable were huge. But, if it's so easy to write a portable code, why doesn't Intel do that? I'm not asking Intel to support all Unixes. I'm merely asking to support all Linuxes. Why don't they do that if it's so easy? I thought that it was because each distribution of Linux is a little bit different from each other and this makes writing a portable code non-trivial. But, many people here in this discussion group seem to be in a different opinion. Writing a portable code is easy. Intel doesn't write portable code because . . . ., why? Perhaps because of sheer laziness? I think they will be happy if their compiler runs on Debian, SuSE, etc. I don't think they gain anything by deliberately excluding other brands of Linux than RedHat. I don't think of any other reason why they don't want to support Debian than that that would incur significant cost which they don't want to pay. Anyway, I'll stop generalization. This may be a special case, but it is a special case which is very important to me. The only open source Fortran 95 compiler is very inferior to Intel's, at present. It *will* become as mature as gcc one day and it may become superior to Intel's one day. But, unfortunately, it's not now. Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
"Karsten M. Self" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... [...] I'm not sure whether I understand every point you make (I read your message twice but there are still points I don't understand), but I think I understand your main point: A binary distribution may not work on all Linuxes, but source distribution works because writing a portable code is not hard. That may be so. You said that I was moving the goalpost. I think you said so because I didn't make a clear distinction between a source distribution and a binary one. OK, that was my fault. But, if writing a portable code is not hard, why commercial vendors write a portable code, compile it for all Unixes/Linuxes, and distribute the binaries? Taking my example, why doesn't Intel compile their code not only for RedHat, but also for other distributions? I understand that they don't want to give away their source code, but at least they can distribute binaries for different Linuxes. I *guess* that doing so would incur some cost which the vendor doesn't want to pay. If Debian had as large a share as RedHat, they would see the cost worth. By the way, I'm not much interested in a debate on whether closed-source is a good idea or not. At least, not for this thread. I didn't quote your words because I did't think I can answer you point by point. Please let me know if I missed something important. Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Erik Steffl <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Ryo Furue wrote: [...] > > In fact I looked at the homepage of nptl. That was kind of scary to me :) > > The page says that you need to use a rather new kernel and libc. [...] >I don't think you can expect a really old version of debian to > support new software. If you want to use new software use new software. Excuse me, but I interpret what you say in two ways: 1) The current stable version (which I use) is "old"; 2) You thought I was using an obsolete version (potate or earlier). I don't know which is the correct interpretation, although your reference to "unstable" seems to suggest (1). I'm using the "newest" stable version. :) >I don't see how this is different in windows or redhat or anything > else. But, vendors don't sell Windows software that doesn't work on the current version of Windows XP. Perhaps, in your perception, the unstable version of Debian is "the" current version? :) If that be so, the name "unstable" is misleading, which has scared me off thus far. Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Erik Steffl <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> Ryo Furue wrote:
[...]
> > That's out of question! :) For numerical computation, Fortran 95 is "better"
> > than C++. (I have plenty of experience in C++ programming.) Sure I greatly
> > miss C++'s objects and templates and other goodies. But codes for numerical
> > computation can be much more "easily" written in Fortran 95. That's the most
> > important point for a non-proffessional programmer like me.
>
>I find that hard to believe. is it because of fortran libs that are
> not available for c/c++ or is performance much better or does fortran
> have some features that make it easy to write numerical computation code
> (I forgot most of what I had to learn about fortran but I don't remember
> ANYTHING being easy/readable in fortran).
First of all, thanks for asking this question. Second, let us be clear
about which "Fortran" we are talking about. *Many* people (I don't know
if you are included) have very bad impression on Fortran because all they
know about it is Fortran 77 or 66. A major revision, called Fortran 90,
and its minor revision called Fortran 95, are a very different language.
Fortran 90/95 is a superset of Fortran 77, but the addition over Fortran
77 is a huge improvement. Fortran 90/95 still lacks "modern" features
such as object-oriented programming support, parametric polymorphism,
functional programming support, etc. But it's "usable" to me, whereas
I would call Fortran 77 unusable.
Third, and most important for answering your question, I use Fortran 95
mostly because I can write a certain type of code easily. I think this
example is convincing:
forall (i=1:nx)
where (a(i,:,:) /= b(i))
a(i,:,:) = cos(c(:,:) + e(:,:));
else where
a(i,:,:) = sum(d(:,:,:), dim=3) / count(mask(:,:))
end where
end forall
Fortran 95 has lots of convenient intrinsic capabilities to handle arrays.
And I use arrays a *lot* in numerical codes. The ":" notation means
"all indices". In a simple-minded C++, the above code is roughly equivalent
to
double s[ny][nz];
for (int j=0; j < ny; ++j) {
for (int k=0; k < nz; ++k) {
s[j][k] = 0;
for (int m=0; m < nt; ++m) {
s[j][k] = s[j][k] + d[j][k][m];
}
}
}
int c = 0;
for (int i=0; i < nx; ++i) {
for (int j=0; j < ny; ++j) {
if (mask[i][j]) ++c;
}
}
for (int i=0; i < nx; ++i) {
for (int j=0; j < ny; ++j) {
for (int k=0; k < nk; ++k) {
if (a[i][j][k] != b[i]) {
a[i][j][k] = cos(c[j][k] + e[j][k]);
} else {
a[i][j][k] = s / c;
}
}
}
}
You can see that the Fortran version is easier to write and read. You may
point out that in C++ version, the computation of s and c is outside of the
main loop, so C++ version is more efficient. But, any decent Fortran compiler
will move loop-constants out of the loop. You don't need to worry about it
too much. There's another problem with the above C++ code: If ny and nz
aren't constant, you can't write
double s[ny][nz];
Instead, either you allocate the array in two stages:
double** s = new (double*)[ny];
for (j=0; j < ny; ++j) s[j] = new double[nz];
or you write a multidimensional array class, something like:
template
class ArrayTwoDim {
T* a_; int nx_;
public:
ArrayTwoDim(int nx, int ny) { a_ = new T[nx*ny]; nx_ = nx; }
~ArrayTwoDim() { delete[] a_; }
// operator[]
// operator+, operator-, operator*, operator/,
};
// Also, define sin(), cos(), log(), etc. for a whole array.
The first is cumbersome (Don't forget to deallocate those arrays!) and the
second involves signigicant work. The dynamic allocation of multidimensional
arrays is a piece of cake in Fortran,
real(8):: a(nx,ny) !! nx or ny need not be constant.
!! a is allocated on the stack
or
real(8), allocatable:: a
. . . .
allocate(a(nx,ny)) !! allcated on the heap.
and the deallocation is automatic at the end of the subroutine (or you
can deallocate for yourself if you want an earlier deallocation).
But, you might say, once we've written multidimensional array classes, we
can happily use them. No. Unless the array classes are part of the C++
standard, you'll have problems when you share programs with other people.
And, such classes will be still significantly less powerful than the Fortran
counterpart. For example, sections of array are directly supported by the
core language:
a(:, 3:10, :) = c(1:7, :, :) + sin(d(1:7, :, :))
whereas in C++, either you write
for (int i=0; i < nx; +
Re: Is Linux Unix?
Erik Steffl <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... [. . .] >it's [1]. debian has very slow release cycles, but unstable is much > better quality than you'd expect from name. In general I see unstable > being equal to latest releases of other distros (both features and > stability) while stable is extremely (the kind you need for servers) but > does not have all the latest features. Thanks for the answer. Does that mean that *ordinary* users should use the unstable and that the stable should be used only by those who want extremely stable mission-critical servers? By an "ordianry" user, I mean somebody like this: She can become a root and shut down or restart her Debian work station; she can use apt-cache and apt-get to install packages but is not sure how to configure /etc/apt/source.list; When she wants an application which needs to be build from source, she asks thesysadmin to do that; she's never looked into /var/log; etc. I think an "ordianry" Windows user is like this. Most of the Linux/Unix users around me are like this. (Please don't say they should use Windows if they can't admin their Unixes :-) They seem to be happy with the situaltion and they are certainly productive in their own field.) > >> I don't see how this is different in windows or redhat or anything > >>else. [. . .] > > But, vendors don't sell Windows software that doesn't work on > > the current version of Windows XP. Perhaps, in your perception, > >of course they do, do you remember example of game I bought and > couldn't make it work on win xp pro while it was running fine on win98 > (that was few month ago, win xp was out for quite some time) [the game > is RC Cars published by Whiptail Interactive, developed by Creat Studio, > relese date 12/11/2003] Um, I didn't think of that possibility :-) Weren't we talking about situations where the target OS of the software is too new? The Intel compiler doesn't run correctly on my workstation because the stable Debian is too old. That was the begining of this subthread. I don't think Vendors sell software which runs only on a preview (beta) version of Windows. And I *thought* (but you pointed out that I was wrong) that the unstable Debian roughly corresponded to a beta version of the OS. Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Paul E Condon <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > On Fri, Jul 23, 2004 at 07:54:12PM -0700, Ryo Furue wrote: > > ... I haven't used the GNU Fortran 95, but I'm 98% sure that it's almost > > unusable at this stage. Since I've had *enough* unpleasantness with new > > compilers, I'm very reluctant to give the GNU compiler a try at this stage. > > Is your program concerned with a scientific question? What area of science? Physical oceanography. My colleagues are meteorologists and oceanographers. Some of us numerically solve partial differential equations for fluid motions (That's the same type of computation for numerical whether prediction) and analyze the result. Others analyze observational data. Most of us use Fortran. > Could you share your code with me and let > me see what I can make of it using GNU Fortran? Do you mean that you would test my code with the new GNU Fortran 95 compiler? I'd certainly appreciate it, but I don't know if you really want to bother. > > That's out of question! :) For numerical computation, Fortran 95 is "better" > > than C++. (I have plenty of experience in C++ programming.) Sure I greatly > > miss C++'s objects and templates and other goodies. But codes for numerical > > computation can be much more "easily" written in Fortran 95. That's the most > > important point for a non-proffessional programmer like me. > > I, also, am a non-professional programmer. Some things are surely more > compact in Fortran than in C/C++, but the floating point in both F and > C is surely IEEE standard by now. Or is there some reason for > preferring some other type of floating point that is still available > in IFC? Um, floating points of any modern Fortran compiler are IEEE. Whether you does your calculation in C++ or in Fortran won't matter in terms of floating point arithmetics. The only exception you find these days is Cray. > But I'm interested in investigating in a somewhat serious way, the > actual differences, today. [. . .] I think that the main difference between C++ and Fortran is NOT the speed or accuracy of floating point calculations. You can write as fast code in one language as in the other. The most important thing for me is that you write "easy" Fortran code without thinking much about the speed and compile it, and then the resultant code runs "reasonably" fast. In C++, you can't write "easy" code that uses multidimensional arrays (Please see my other posting which details on the difference). And the resultant C++ code may run slower. Perhaps it will. I don't see any reason why the code in C++ will run faster for the type of code I showed in the other posting of mine, whereas I see a few reasons why the C++ counterpart may run slower. I'm sure you can write as fast code in C++ as in Fortran. The point is how much work you need to achieve that goal. That's why I said I'm not a professional programmer. If you are a professional programmer, you can put more of your energy to make the code fast in any lanugage. Finally, I'm not saying Fortran is better in all type of programming. I'd like C++ better in different problems. But, then, in my situation, I don't have problems better solved in C++ than in Ruby or in Bourne shell. So, if not Fortran 95, I use Ruby or Bourne shell. Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Jeronimo Pellegrini <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > > There's another problem with the above C++ code: If ny and nz > > aren't constant, you can't write > > > > double s[ny][nz]; > > > > Instead, either you allocate the array in two stages: > > > > double** s = new (double*)[ny]; > > for (j=0; j < ny; ++j) s[j] = new double[nz]; > > Actually, the first version works -- and both C and C++ (tested here with > gcc -- not sure it it became a standard or not)) will dynamically allocate > memory for you. Try this: [...] > int size1, size2, i, j; > cin >> size1; > cin >> size2; > double vec[size1][size2]; Wow, that's news to me! The first ANSI C++ standard (1997 or 1998) doesn't allow it. "The number of elements of the array, the array bound, must be a constant expression. . . ." (Stroustrup, _The C++ Programming Language_, 3rd ed., p.89. Although this book isn't the standard document itself, I don't expect that there would be such a big difference as this.) And, certainly, neither size1 or size2 above is a constant expression. I don't know whether the C++ standard has been revised since. If this feature is or become standard or de facto standard, that's a step forward for numerical computations. Thanks for the info, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Roel Schroeven <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Jeronimo Pellegrini wrote: [...] > > Actually, the first version works -- and both C and C++ (tested here with > > gcc -- not sure it it became a standard or not)) will dynamically allocate > > memory for you. Try this: > > > > int size1, size2, i, j; > > cin >> size1; > > cin >> size2; > > double vec[size1][size2]; > > > > And enter something like "1000" and "1000" when asked for the array dimensions. > > It compiles, runs, and does not segfault! :-) > > Are you absolutely sure that code is supposed to work? > > Your program segfaults on cygwin (using gcc 3.3.1) when using 1000 and > 1000. On my sarge installation (gcc 3.3.4) it seems to work when using > 1000 and 1000, but segfaults when using 1000 and 1. Either you were > lucky, or it's a feature that's introduced in more recent versions of gcc. There is a posibility that you run out of stackspace. I guess these dynamically sized arrays are allocated on the stack. You might want to try setting the stacksize to "unlimited". I've found that gcc has implemented this at least for seven years or so. If I remember correctly I found a news article in the google groups dated in 1996 which mentions this feature of gcc. Also, I found that the C99 standard incorporated this feature: http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html It's interesting that some of the new features are (or seem to me to be) mainly for numerical computations, such as the "restrict" keyword and the builtin complex numbers. I suspect they are influenced by Fortran. And it's amusing to see that C99 has *at last* caught up with Fortran 77 (partly with Fortran 90/95) in terms of dynamically sized multidimensional arrays, complex arithmetics, and "restrict"ed pointers, although C99 lags far behind Fortran 90/95 in terms of intrinsic array operations. ;-) Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Roel Schroeven <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... [...] > > It's interesting that some of the new features are (or seem to me to be) > > mainly for numerical computations, such as the "restrict" keyword and > > the builtin complex numbers. > > Possibly, but isn't this feature's usefullness in numerical computations > quite limited if you're restricted to the size of the stack? That's a good question. In fact, most modern Unix/Linux systems allow you to use as large stacksize as you like, roughly speaking. Although the default stakesize limit is often set to a very low value, say, 2MB, each user can raise the limit, unless the system administrator (root) prohibits it. So, no. That feature in question is very useful. Some people believe that the stacksize limit should be kept low (in other words, that you shouldn't use much stack), but, as far as I know, nobody seems to be able to give a convincing argument for that position. I suspect that the posision is just an inertia, a remnant of an old habit. But, I'm ready to be convinced otherwise if somebody has a good argument. Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Erik Steffl <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> Ryo Furue wrote:
[. . .]
> > That's a good question. In fact, most modern Unix/Linux systems allow
> > you to use as large stacksize as you like, roughly speaking. Although
> > the default stakesize limit is often set to a very low value, say, 2MB,
> > each user can raise the limit, unless the system administrator (root)
> > prohibits it. So, no. That feature in question is very useful.
> >
> > Some people believe that the stacksize limit should be kept low
> > (in other words, that you shouldn't use much stack), but, as far as
> > I know, nobody seems to be able to give a convincing argument for that
> > position. I suspect that the posision is just an inertia, a remnant
> > of an old habit. But, I'm ready to be convinced otherwise if somebody
> > has a good argument.
>
>stack is something you do not have control over and you have no
> information about, it's not good to use it for large data - you cannot
> figure out how big it is, how much you're using, there's nothing you can
> do if space cannot be allocated etc. (maybe you can figure some of it
> out but that would be compiler specific, I think)
>
>on the other hand when using malloc/free or new/delete you can do
> _something_ if there's not enough memory.
Right. But, that depends on your design goal. There are many applications
where the heap is the right choise for large data. But, there are others
where the stack is better.
First of all, there are many cases where the heap is the only choise, as
when your function needs to return the pointer to the space allocated
within it. So, the real choise arises in cases like this:
int f() {
//. . .
double workspace0[N]; // stack
double* workspace1 = new double[N]; // heap; Which is better?
//. . .
delete[] workspace1;
}
As you say, if there's _somthing_ to do when there is not enough memory,
the heap is the right choice. That "something" may be, and in many cases,
is, just to print an error message and quit.
If, on the other hand, you don't care if your program crashes in case
of memory shortage, the stack is the better choice. One obvious reason
is that the stack is the faster. Another is that you can forget about
'delete'ing the allocated space; deallocation is automatic for the stack.
Many scientific applications are like this: "If it doesn't run, it doesn't.
That's fine. Use a larger computer."
My point is that it's really is a choice. The fact is that in majority
of cases the heap is the better choise. But, I don't see any inherent
reason why you shouldn't use the stack for large data. I said the
stack-is-not-for-large-data is "inertia", but it may be better called
a myth.
By the way, I don't know how hard to keep track of stack use.
But, the stack is released when the function is finished. Isn't
it, then, harder to keep track of heap use? I've heard a lot about
"memory leak", which refers to forgetting to 'delete' allocated
heap memory. I'm yet to hear "stack leak" :)
Of course, I'm joking. Please don't take this seriously.
Cheers,
Ryo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Erik Steffl <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... [. . .] > > My point is that it's really is a choice. The fact is that in majority > > of cases the heap is the better choise. But, I don't see any inherent > > reason why you shouldn't use the stack for large data. I said the > >what? I just provided you with bunch of reasons. And you provided > another one (you can get around the problem you described by having the > variable declared in highest level function where it's used, in your > example above the workspace would be allocated in whoever calls f and > would be passed as an argument to f). In a particular situation these > might not outweight whatever advantage you get for using stack but that > does not mean there are no reasons. > > > stack-is-not-for-large-data is "inertia", but it may be better called > > a myth. > > > > By the way, I don't know how hard to keep track of stack use. > > But, the stack is released when the function is finished. Isn't > > it, then, harder to keep track of heap use? I've heard a lot about > > "memory leak", which refers to forgetting to 'delete' allocated > > heap memory. I'm yet to hear "stack leak" :) > > Of course, I'm joking. Please don't take this seriously. > >of course there are reasons to use one or another, I am not > advocating heap over stack, you asked for sme reasons why one should be > careful about using stack (you wrote: ...shouldn't use much stack ... > nobody seems to be able to give a convincing argument ...) so I provided > you with some reasons. Obviously, a general rule like that does not > apply in all situations... Then we agree! I may have misunderstood what you said. I agree that "one should be careful about using stack" (your words) but I don't agree that one "shouldn't use much stack" (mine). The reasons you gave are reasons for being careful about stack, not ones that one should't use it in any case. Why am I arguing this? Because I once used a Unix system where the system administrator imposed a low stacklimit. I wanted to use large stack in a situation I described earlier. Before asking the system administrator to raise the limit, I asked knowledgeable people if there's some inherent reasons against using large stack. The answers I got were that you should use heap for large data, without reference to reasons. That was a long time ago. But even today I sometimes see people saying something like: if your program uses more than 2MB of stack, your program is broken. Anyway, thanks for your reply, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Linux Unix?
Erik Steffl <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>.. [. . .] >I forgot to add that Stroustrap says that lot lot of memory > management problems can be avoided by simply using variables on the > stack and not dynamically allocate it using new (so you're not alone:-), > I don't have reference but I guess you'll be able to find it if you want > to... If you use STL (or something similar) you can have the containers > in the stack and let the containers (better debugged than your code) > handle the allocation of the data (that way you get advantage of using > heap for large data plus the advantage of stack - code is > cleaner/shorter, data are automatically freed without you having to take > care of it and you can handle the out of memory error). [. . .] I also remember Stroustrup said something along the lines. Since I read quite a bit of what he wrote and I did it a long time ago, I don't remember exactly where he said that. What I've dug up is: section 2.4 of "The Design and Evolution of C++" (Stroustrup, 1995, Addison Wesley). Here he discusses why he specifically decided to allow allocation of user-defined objects on stack. You find a similar discussion in his "The C++ Programming Language", 3rd ed., where he emphasises the usefulness of "concrete" types, which can be used in the same manner as the intrinsic types. This is an interesting design decision. In "mainstream" object-oriented languages such as Java and Ruby (please notice that I quoted "mainstream" :-), user-defined objects are (almost?) always allocated on the heap. As I like Ruby very much, I also did suffer from the inefficiency of that approach. In passing, yes, I miss the STL. I use only Fortran 95 these days. The other day, I had to hand-craft a linked list in F95. It wasn't a big deal, but I had to use my mental energy not to make mistakes. If there had been a generic container, I would have definetely used it. In short, I wished I had something like the STL in Fortran 95. Someday. . . . Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Q: use remote X fonts?
Hello all, I'm wondering how to use remote fonts. I searched the Google groups for information and browsed "man xfs", but still don't know how to do that. Here is my situation. I log in to a remote machine by "ssh -X" from a local machine on which an X server is running. Let's call the remote machine "rmt" and the local machine "lcl". When I type lcl$ ssh -X rmt.workplace.com [. . . login succesful. . .] rmt$ emacs & an emacs window appears on the screen of lcl. So far so good. But, all Japanese characters appear as blank rectangulars on the screen. English alphabets show perfectly. When I'm at work and directly use the console of rmt.workplace.com, those fonts are displayed flawlessly. Those fonts aren't installed on my home machine, lcl, but I suppose it's possible to use fonts of rmt from lcl. I also guess that xfs has something to do with my problem and I know /usr/bin/X11/xfs-xtt is running on rmt, which is a Debian 3.0r2 system. I don't want to install extra fonts on the home machine, because it varies. I sometimes use Mac OS X, sometimes Cygwin on Windows XP, and sometimes FreeBSD 5.2.1. (I may even buy a PC and install Debian on it in the future. :) Could someone help me? Thanks for your attention, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Console bell (beep) lost
Hi all, After I upgraded the kernel from 2.4.18 SMP to 2.6.7 SMP, I lost the console bell (beep). I don't think I changed anything other than the kernel. Is it possible that the lack of the console bell is due to the kernel? If so, could someone tell me where to look? I tried "xset b 100 400", which didn't work. I searched Google and Google Groups but didn't find how to fix the problem. I've been using first Sun and then Liunx workstations for more than ten years, but I've never thought of the possibility of the lack of the console bell (except when I say "xset b off"). Thank you, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Console bell (beep) lost
Thank you all who responded! The problem was solved. I said: > After I upgraded the kernel from 2.4.18 SMP to 2.6.7 SMP, > I lost the console bell (beep). I don't think I changed > anything other than the kernel. Is it possible that the > lack of the console bell is due to the kernel? If so, > could someone tell me where to look? You guys were all correct. I downloaded and used the "beep" command. No beep. The kernel was most likely to be the cause. I invoked the kernel config menu and searched "PC speaker". It was in Device Drivers -> Input device support -> Misc -> PC speaker support. I turned this switch on, recompiled and installed the kernel, and restarted the workstation. Then I got the beep back! Does the fact that this switch is off by default mean that people in general don't like beeps or that people use other advanced bells? Thank you again, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT: Questions or Doubts?
Kent West <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Hopefully this won't offend anyone; I'm just curious. > > I often see posts on this list with subject lines like: > > Doubt about Debian Installation > > or > > Configuring PS/2 Mouse Doubts > > Is this word "doubt" a non-American-English-speaker's word for > "question"? And if so, in that person's language, is "doubt" equivalent > to "question", or is it just that they don't understand the use of > the word? I'm new to this discussion group/mailing list and I haven't seen such subject lines as you are referring to. But, here's a contribution from a native speaker of Japanese. There is a Japanese word which can indeed be translated either into "doubt" or into "question" depending on the context. Even though this does not preclude other possibilities, those subject lines you cite could be explained as translations from Japanese. Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
firewire (IEEE1394) harddrive: how to use?
Hi all, This may sound a stupid question, but how are we *supposed* to use a firewire harddrive? I'm now using one without problems, so this isn't a usual "howto" question. The other day I asked our tech person for an internal ATA harddrive. He didn't have one at the moment, so he gave me a firewire harddrive instead, saying that it should work with my Debian box because he used it with his RedHat box. He added that I could erase any of his files in the drive. I managed to add necessary modules to my kernel by consulting this website http://www.linux1394.org/start_req.php and I saw that the drive was recognized by the drivers, judging from the messages in /var/log/messages. But, # mount -t vfat /dev/sda1 /mnt didn't work. (The error message was to the effect of wrong filesystem.) I tried "ext2" in place of "vfat" unsuccesfully. Finally, I looked into the disk by fdisk and found that the partitioning didn't make sense to me. The partition boundaries didn't allign with cylinder boundaries; the partition IDs were 53 (Disk Manager 6.0 Aux3), 67 (68 or 69, I forgot which, but it was Novell), and something which wasn't in the ID list (http://www.win.tue.nl/~aeb/partitions/partition_types-1.html). Hmm. Since the tech guy said I could erase anything and since I was in a hurry, I erased all the existing partitions, created a fresh one, and formatted the disk as an ext2 filesystem. That's what I'm now using. It works perfectly fine. But, since I formatted it as an ext2 filesystem, it won't work with Windows any longer. So, I have a feeling that I did something wrong. What was the "right" way? How do you think the tech guy used the drive? The partition ID 53 (Disk Manager), which I don't know what it is, smells something related, but . . . Additional questions are, what should one do to share a firewire drive between Linux and Windows? What about hotplugging? Thank you, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: firewire (IEEE1394) harddrive: how to use?
Kevin Mark <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > On Fri, Aug 27, 2004 at 11:51:58PM -0700, Ryo Furue wrote: [...] > > I managed to add necessary modules to my kernel by consulting this > > website > >http://www.linux1394.org/start req.php > > and I saw that the drive was recognized by the drivers, judging from > > the messages in /var/log/messages. But, > could you post the bits from /var/log/message that relate to the hard > drive. Thanks, Kevin, for your interest. Here's it (date and hostname ellided): 16:52:55 kernel: ieee1394: raw1394: /dev/raw1394 device initialized 16:54:31 kernel: sbp2: $Rev: 1219 $ Ben Collins <[EMAIL PROTECTED]> 16:54:56 kernel: ohci1394: $Rev: 1223 $ Ben Collins <[EMAIL PROTECTED]> 16:54:56 kernel: ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[16] MMIO=[fe1ff000-fe1ff7ff] Max Packet=[2048] 16:54:58 kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices 16:54:59 kernel: ieee1394: sbp2: Logged into SBP-2 device 16:54:59 kernel: Vendor: MaxtorModel: 5000XTRev: 0100 16:54:59 kernel: Type: Direct-Access ANSI SCSI revision: 06 16:54:59 kernel: SCSI device sda: 490232832 512-byte hdwr sectors (250999 MB) 16:54:59 kernel: sda: sda1 16:54:59 kernel: Attached scsi disk sda at scsi0, channel 0, id 1, lun 0 This is the first occurrance of Maxtor 5000XT in /var/log/messages*, so this must be a log before I did anything to this drive. I'm afraid I don't know how to interpret this log. I mean I can't tell how I should use this drive by looking at the log. Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: firewire (IEEE1394) harddrive: how to use?
Nicolas MASSE <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Le samedi 28 Ao t 2004 08:51, Ryo Furue a crit : [...] > > I managed to add necessary modules to my kernel by consulting this > > website > >http://www.linux1394.org/start req.php > > and I saw that the drive was recognized by the drivers, judging from > > the messages in /var/log/messages. But, > > > ># mount -t vfat /dev/sda1 /mnt > > # mount -t vfat /dev/sda /mnt > > It's because windows doesn't create a partition table, > it uses all the disk for the file system. Argh. That sounds plausible. The page I consulted (http://www.linux1394.org/faq.php#sbp2) didn't tell me that! I'll try it next time I use a *fresh* firewire drive. (As I said, I've already *corrupted* my drive by reformatting it. :-) Thanks, Nicolas, for the info. Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: firewire (IEEE1394) harddrive: how to use?
Stefan O'Rear <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > On Sun, Aug 29, 2004 at 03:14:19PM -0700, Ryo Furue wrote: > > Argh. That sounds plausible. The page I consulted > > (http://www.linux1394.org/faq.php#sbp2) didn't tell me that! > > I'll try it next time I use a *fresh* firewire drive. (As I said, > > I've already *corrupted* my drive by reformatting it. :-) > > Corrupted? I've never used a FW drive but you should be able to just: > > mkdosfs -I /dev/sda Right. What I meant was, I "corrupted" the nice, useful DOS filesystem by reformatting it to the lowly Linux filesystem. :-) I didn't mean that I wouldn't be able to restore the drive to the original state, and I didn't mean to exclude such a restore drive from "fresh" drives. But, thanks, anyway. I'll reformat the disk to the DOS filesystem after I'm done with it and will check if the drive works with Windows. Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: firewire (IEEE1394) harddrive: how to use?
John Summerfield <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Ryo Furue wrote: [...] > >But, since I formatted it as an ext2 filesystem, > >it won't work with Windows any longer. > > > >So, I have a feeling that I did something wrong. What was the "right" > >way? How do you think the tech guy used the drive? The partition ID > >53 (Disk Manager), which I don't know what it is, smells something > >related, but . . . Additional questions are, what should one do to > >share a firewire drive between Linux and Windows? What about > >hotplugging? > > > What you've done is pretty much what I'd have done. Disk Manager is > software for DOS-family operating systems so they can use drives not > supported in the BIOS, typically larger than the current BIOS limit. That means that even if I reformat the drive into a DOS filesystem, that won't be the original status of the drive and it won't work as before. Let's hope that our tech guy knows how to fix it. Or let's not. In fact, I borrowed it from him and must return it soon. If he can't fix it, he might give it up and permanently lend it to me. :-) > One thing I would have done is install hotplug. My USB drive pretty much > just works when I plug it into anything. No mucking around with modules. Do you mean the hotplug package? Sounds wonderful. I'll try it. Thanks. Thanks, John, for your help. Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Way OT] Re: GMAIL Invites..!
Patrick Wiseman <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... [...] > (I'm bottom-posting only because this list - uniquely, in my > experience - insists on it. You really should try reading your email > in reverse chronological order. It works.) Top posting may work. But I think bottom posting works better. In fact, I don't understand why people ever want to top-post. I guess the only reason is that many popular mailreaders do that by default. (I still don't understand why those mailreaders do that in the first place.) Let's put email aside for a moment. When you write comments on somebody else's statements, you usually do this: Mr. Blahblah states in the first chapter of his book that Blah blah blah . . . But I don't think his point stands in this context. . . . In the next chapter he re-inforces his argument by asserting Blah blah blah . . . At this point it becomes clear to me that he. . . . I don't see how you can write this kind of comments in the top-posting style. And I don't see why email should be different. You first quote others' words and after that you add your comments or replies. I think this is more readable for majority of people than appending quotes at the end of your writing. Do you really think that appending all the quotations at the end is more readable than the quote-then-comment style? If you do, then we have to agree to differ. By the way, I do think "insisting" on bottom posting is a bit too much. But I would like to kindly ask posters to bottom post because that's more readable to me and I think to majority of the readers, too. (And there are far more readers than writers, right?) Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
avahi-daemon: Received response with invalid source port
Hi Debian users, My /var/log/daemon.log is now being flooded with avahi-daemon: Received response with invalid source port 44038 on interface 'eth1.0' Could someone tell me what's going on? I'm using the testing distribution of Debian. Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
