[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cdrtools cdrecord/cdrecord.c



Geoffrey <esoteric@3times25.net> writes:

> Alexander Noe' wrote:
>> Geoffrey
>>  > Actually Jörg, I tend to agree with Steve, but it could well be
>>  > a cultural issue. You do come across rather blunt.
>> Although this is true, let me tell you some things:
>> * the difficulties to express such notions in a foreign language are
>> unknown to some (actually, too many) english native speakers who have
>> never tried to learn a foreign language seriously (scholar
>> french/german isn't exactly what I mean when saying 'seriously') and
>> thus prefer to feel insulted rather than just assuming a badly chosen
>> expression.
>
> Understood.  I've taken my share of languages, including Spanish, French
> and Latin.  I do understand the issues of "it's lost in the
> translation."  Latin is quite an expressive language, with so many more
> tenses then, say English.

More tenses? It's rather that they express tenses in verb suffixes that
needs to be expressed as compositions with auxiliary verbs in languages
under Germanic influence. Future tenses (Futur I and II in German),
Perfect (Perfekt), Past Perfect (Plusquamperfekt), Passive Voice, and
all that, but modern Romanic languages also have compositions (passé
composé in French "j'ai mangé", Spanish "hé comido" and similar).

> I do agree that changing any software to accomodate an existing flaw in
> another software package (particularily a kernel) is on the verge of
> stupidity.  I'm a firm believer in fixing problems, not patching
> them. Especially patching something that does not have a defect so it
> will work around something broken in another application.

Jörg and I have been debugging the SCSI buffer allocation errors
yesterday and today, and it appears that a Linux extension to
setrlimit() might play a major role with this problem... to me, it
appears as though mlockall(...MCL_FUTURE...) followed by unpriviliged
mmap() causes failures since something in Linux appears to impose a HARD
limit of 32kB on mmap()ed memory since Linux 2.6.9.  If that turns out
true, there'll be little choice than to shuffle code a bit and mmap() as
root.

-- 
Matthias Andree



Reply to: