Re: 'typo' in policy

[Julian Gilbey]

On Thu, Jun 28, 2001 at 10:20:39PM +0200, Frank Loeffler wrote:
> Hi,
> 
> it is not really a typo, under 6.6 it reads:
> 
> When we configure a package (this happens with dpkg --install and dpkg
> --configure), we first update any conffiles and then call:
>   ^
> 
> The marked 's' (in conffiles) is not in the  and therefore
> appearing in normal font.

Correct; "conffile" is a technical term (it means something which
appears in debian/conffiles) and appears in ..., the 's' is a
plural ending added on.  I'm not sure if this is correct usage or not;
if there is any concensus, I'm not at all bothered about changing
every conffiles to conffiles.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: 'typo' in policy

[Richard Braakman]

On Fri, Jun 29, 2001 at 12:41:58AM +0100, Julian Gilbey wrote:
> Correct; "conffile" is a technical term (it means something which
> appears in debian/conffiles) and appears in ..., the 's' is a
> plural ending added on.  I'm not sure if this is correct usage or not;
> if there is any concensus, I'm not at all bothered about changing
> every conffiles to conffiles.

I think the current usage is more correct.  Not necessarily in
typographical terms, but then typographical tradition would have
us tell people that in vi lines are deleted with "dd."
I prefer semantical correctness :)

-- 
Richard Braakman
Will write free software for money.
See http://www.xs4all.nl/~dark/resume.html

Re: Policy proposal: Cpu extension code, update-ldsoconf

[Adam C Powell IV]

Camm Maguire wrote:


2) This library should be placed in a designated subdir of /usr/lib
  specialized for code requiring the cpu extension in question.  All
  such directories should be agreed on and sanctioned by the policy
  committee.  As a suggestion, the directory might be named after
  the cpu capability (as reported in /proc/cpuinfo) required to run
  the code, e.g. /usr/lib/xmm, /usr/lib/3dnowext, etc.)

I think ldso already has this capability.  While they were around, the 
glibc-i686 etc. packages took advantage of this.



looks like a good idea, but I'd like to add something to this paragraph:

Libraries placed in these directories are exempted from the obligation
to use the -fPIC compilation flag. The rationale is that this code has
been separated only as an easy way to comply with 1), not because we
actually expect to share this code with any other executables. Because
this code is time-critical, it makes more sense to avoid the runtime
cost associated with -fPIC here.

The problem is that this breaks on those architectures, e.g. ARM, which 
can't link shared libs at all without -fPIC.  You'd have to be very 
careful to include -fPIC with subarches on some arches and leave it out 
on others.  It would be tricky to build such packages.


The real lesson here is not that -fPIC is bad, but that 
register-starved architectures like i386 and derivatives are inherently 
flawed, IIRC due to legacy compatibility issues.  Maybe the -fPIC 
exception should only apply to such broken architectures?



Wonderful.  So how should we proceed from here?


Wishlist bug report against debian-policy.

Zeen,
--

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe! 

Re: Colo Servers, Telco-Grade Configuration, Embedded/Turnkey Systems

[James R. Van Zandt]

[EMAIL PROTECTED] writes:
> I'd like to see Debian GNU/Linux come to completely dominate the 
> colocated and telco-grade remote/isolated server markets.  These 
> sorts of unattended systems (sometimes called "embedded" or "turnkey"
> systems) are a huge marketshare among full-time professional system
> administrators.  

Sounds great!

Some possibly related capabilities:

 Monitoring: Hardware (e.g. CPU core temperature), resource
 utilization (CPU load, swap space, free disk space, network
 bandwidth...), security incidents (failed login attempts,
 rejected packets, SATAN scans...) all reported remotely.

 RAID

 mass installs

 backups

 load sharing/parallel processing


By the way, some of the steps you mention sound useful to blind users
who want to run their systems via a serial link to another computer.
One of the frustrations of that setup is that it's hard to get to the
boot-time messages.

- Jim Van Zandt