date:20111115

Re: /tmp as tmpfs and consequence for imaging software

2011-11-15 Thread Neil Williams

On Tue, 15 Nov 2011 07:41:54 +0100
Andrew Shadura bugzi...@tut.by wrote:

 Hello,
 
 On Mon, 14 Nov 2011 00:14:18 +0100
 Josselin Mouette j...@debian.org wrote:
 
   No it does not work like you said. We know the matrix structure, not
   the kernel. We map and unmap manually. Doing as you said is
   inneficient and trash a lot cache and so on.
 
  This is getting insane. Please learn how to use madvise and
  posix_fadvise and let the kernel deal with paging. The kernel knows
  everything about the underlying hardware; the application does not.
 
 And what about the software being cross-platform? What about other
 systems which don't have such system calls?

Ever heard of #ifdef #else #endif ?

If similar calls exist, use them conditionally. Where they do not
exist, you need to decide if that system can be supported and accept
the limitations of doing so. Where the calls DO exist it is inexcusable
NOT to use the support available.

Do not cripple all platforms with the sins of the weakest.

 Also, the application
 doesn't need to know anything about the hardware except that disk
 memory is usually larger and slower than RAM is.

For a trivial application, that is true. For any application which
makes specific or unusual demands on the hardware / system resources, it
is not. Applications making specific or unusual demands MUST allow for
system differences and that includes adjusting to those which can
handle the requests *better* than your own code as well as providing
code for (or preventing a build / deployment on) those which cannot.

Some kinds of applications just cannot avoid a direct interface with
the kernel (anything using iptables, for example) and any process which
makes unusual demands on the available temporary storage is certainly
sufficiently specialised to require conditionals in the code which make
use of kernel features where those are available.

Cross-platform is not an excuse for one-class-for-all. Cross-platform
means making the most of each platform, not dumbing down to the lowest,
meanest or most inept.

If you want compile-once run anywhere, you could try java and move all
these problems to the VM. (Which has to do this system-specific stuff
anyway.)

If the application needs to be recompiled to be cross-platform then
there is absolutely NO EXCUSE for not including conditional compilation
for specific kernels or environments.

Your build system is unquestionably doing some adjustments from one
platform to another anyway - you simply have to bring those
conditionals into the codebase. There is no excuse - your software is
broken and it must be fixed or removed.

(and, yes, I've explicitly included iptables as an example because I've
got an RC bug outstanding for a tiny app which cannot therefore be used
on BSD and I keep meaning to find the time to fix the build
requirements, so this is directed at me as much as anyone else.)

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpqqs3OEU9lt.pgp
Description: PGP signature

Re: /tmp as tmpfs and consequence for imaging software

2011-11-15 Thread Adam Borowski

On Tue, Nov 15, 2011 at 07:41:54AM +0100, Andrew Shadura wrote:
 On Mon, 14 Nov 2011 00:14:18 +0100
 Josselin Mouette j...@debian.org wrote:
  This is getting insane. Please learn how to use madvise and
  posix_fadvise and let the kernel deal with paging. The kernel knows
  everything about the underlying hardware; the application does not.
 
 And what about the software being cross-platform? What about other
 systems which don't have such system calls? Also, the application
 doesn't need to know anything about the hardware except that disk
 memory is usually larger and slower than RAM is.

madvise():
# _BSD_SOURCE
# CONFORMING TO
#POSIX.1b.

posix_fadvise():
# CONFORMING TO
#POSIX.1-2001.

I'd call functions that are required by a not-so-recent version of POSIX
pretty portable.  What do you want to be cross-platform to then?  win32?
If so, you need a portability layer for anything fancier than Hello world
anyway.

-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Re: Want to become a DM and co-maintainer

2011-11-15 Thread olivier sallou

2011/11/12 Svante Signell svante.sign...@telia.com

 Hi,

 Where/how to apply to become a co-maintainer and a maintainer? The
 packages I'm interested into start with are: gnuradio and octave.
 Additionally, I have not found any package for USRP yet.


At first, you will have to maintain package via a sponsor or a team. After
some time, according to your sponsor, you will be able to ask to be a DM so
that you are able to maintain by yourself the package.
Once ready for being a DM, you can go here:

http://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_Maintainer


 Thanks!


 --
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: http://lists.debian.org/1321127664.6311.24.camel@x60




-- 

gpg key id: 4096R/326D8438  (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: Two groups of users, one distro in the middle

2011-11-15 Thread Charles Plessy

Le Tue, Nov 15, 2011 at 08:48:57AM +0800, Paul Wise a écrit :
 On Tue, Nov 15, 2011 at 8:14 AM, Alex Pennace wrote:
 
  Even without that point, the conclusion remains the same: Both
  projects should endure the rename (unless one concedes), and that
  shouldn't be viewed in terms of look at what those meanies in Debian
  are making us do but instead regarded as a natural outcome of the
  choices each project made at various times.
 
 I personally wonder if we should change our policy instead of forcing
 these two upstream communities into conflict.

I agree.  One possiblity when packages A and B conflict for a program name
would be to rename, but in addition to provide a wrapper that executes the
program from A when only A is installed, from B when only B is installed, and
that gives an error reporting alternative path names when both A and B are
installed.  The wrappers for all names could be provided by a third package.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2015094358.ge27...@merveille.plessy.net

Re: Description-less packages file

2011-11-15 Thread Ansgar Burchardt

Joey Hess jo...@debian.org writes:
 AFAICS, there are no diff files, so this increases the average apt-get update
 download size by 3.6 MB.

 Also, it seems unlikely this will ever allow apt to skip downloading the
 English files, unless translations somehow get to, and stay at 100%

Switching to xz compression would reduce the English translation from
3.7 MB to 3.3 MB.  Maybe we could add support for this to APT and switch
later (so we don't need both bz2 and xz on the mirrors).

Regards,
Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/s2shb25k6fs@bistromathics.mathi.uni-heidelberg.de

Re: /tmp as tmpfs and consequence for imaging software

2011-11-15 Thread Aneurin Price

On 15 November 2011 08:17, Neil Williams codeh...@debian.org wrote:
On Tue, 15 Nov 2011 07:41:54 +0100
Andrew Shadura bugzi...@tut.by wrote:

Hello,

On Mon, 14 Nov 2011 00:14:18 +0100
Josselin Mouette j...@debian.org wrote:

No it does not work like you said. We know the matrix structure, not
the kernel. We map and unmap manually. Doing as you said is
inneficient and trash a lot cache and so on.

This is getting insane. Please learn how to use madvise and
posix_fadvise and let the kernel deal with paging. The kernel knows
everything about the underlying hardware; the application does not.

And what about the software being cross-platform? What about other
systems which don't have such system calls?

Ever heard of #ifdef #else #endif ?

If similar calls exist, use them conditionally. Where they do not
exist, you need to decide if that system can be supported and accept
the limitations of doing so. Where the calls DO exist it is inexcusable
NOT to use the support available.

Do not cripple all platforms with the sins of the weakest.

I think this discussion needs a sanity check.

Please remember, the topic of conversation is whether an application
can reasonably make the assumption that the system defined tmp
directory is a suitable place to store temporary data.

You appear to be saying Of course not; every application should
include a small compatibility layer to call the appropriate syscalls
or other relevant interface for every possible platform to indicate to
the kernel exactly what it wants to do with its data. Yes, that
doesn't answer the question of where temporary data should be stored
in the first place, but I don't care about that as long as nobody has
the audacity to suggest that maybe /tmp might be a reasonable place
for transient temporary data.

Can you see why this might be treated with incredulity? Maybe it's
worth going back to the topic at hand rather ranting about something
irrelevant.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cahb+spbpom8oz5hvespjqtkaglr-+hbh-uk46-ovu79bwd3...@mail.gmail.com

1 2 >

1 - 100 of 120 matches

Mail list logo