Anand Kumria <[EMAIL PROTECTED]> writes:
> A simple assurance that your package will be rejected from the NEW queue
> if no ftp-master approves it within 2 weeks would actually be a benefit.
Why?
It seems like, if that's the way that you want the world to work, you
could already just pretend tha
On Dec 18, Darren Salt <[EMAIL PROTECTED]> wrote:
> An alternative appears to be to process events in series... or maybe delaying
This was the precedent approach, and it's much slower (also, it cannot
be implemented anymore with just udevd).
--
ciao,
Marco
signature.asc
Description: Digital si
On Saturday 17 December 2005 09.30, Marco d'Itri wrote:
> On Dec 17, Christian Perrier <[EMAIL PROTECTED]> wrote:
> > It is currently very likely that systems with two network interfaces
> > will end up with both switched on the installed system after the
> > reboot. This is of course a blocker.
>
On Dec 17, 2005 at 18:48, Simo Kauppi praised the llamas by saying:
> On Sat, Dec 17, 2005 at 03:21:41PM +0100, Lionel Elie Mamane wrote:
> > No, you have to _remove_ the offending code. Not only "disable it at
> > build-time", but not ship it at all, also not in the
> > source. Distributing infrin
On Dec 18, Graham Wilson <[EMAIL PROTECTED]> wrote:
> > I do not remember a consensus about this.
> Changes in Debian are generally decided by package maintainers, not by
> consensus.
Good to know. So I'm happy that nobody will complain when I will make
udev mandatory.
--
ciao,
Marco
signature
On Sun, Dec 18, 2005 at 04:34:54PM +1100, Anand Kumria wrote:
> On Wed, Dec 14, 2005 at 09:30:15AM +, David Pashley wrote:
> > On Dec 14, 2005 at 00:25, Anand Kumria praised the llamas by saying:
> > > I'd like to congratulate our ftp-master team on their ability to timely
> > > process package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Benjamin Mesing wrote:
>>"Please (re)check, if the package can be built by g++ > 3.4
>> on [hppa/arm/m68k]"?
>>
>>Do I simply remove the explicit build dependency on g++,
>>upload the package and wait if it succeeds (and probably
>>create another packa
[Marco d'Itri]
>> > I do not remember a consensus about this.
>> Changes in Debian are generally decided by package maintainers, not by
>> consensus.
> Good to know. So I'm happy that nobody will complain when I will make
> udev mandatory.
You seem to have mixed up lack of complaints with decision
On Sun, Dec 18, 2005 at 10:39:53AM +0100, Marco d'Itri wrote:
>> Changes in Debian are generally decided by package maintainers, not by
>> consensus.
> Good to know. So I'm happy that nobody will complain when I will make
> udev mandatory.
I won't complain, I'll just send a friendly assassin to yo
This message is to confirm the addition of your
email address: debian-devel@lists.debian.org to the
Alharamain Sermon(english)
Subscribe Me mailing list.
If you feel you have received this notice in error,
please visit the Alharamain Sermon(english)
Subscribe Me mailing list
at our website:
htt
Hi
I've run some scripts to find out the size of binary pakcages in debian
and how theycould be made smaller, here's the results:
http://www.linuks.mine.nu/sizematters/
Comments are welcome...
Yours,
Gürkan
On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:
> I've run some scripts to find out the size of binary pakcages in debian
> and how theycould be made smaller, here's the results:
My comments are about the same as on IRC:
- Disk space is cheap, bandwidth is cheap.
- CPU doesn't
Gürkan Sengün <[EMAIL PROTECTED]> wrote:
> I've run some scripts to find out the size of binary pakcages in debian
> and how theycould be made smaller, here's the results:
> http://www.linuks.mine.nu/sizematters/
Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. -
Have you perhaps
On Sat, Dec 17, 2005 at 10:23:54PM -0800, Eduardo Silva wrote:
> As a lurker to debian-devel, I would like to point to
> all a deficiency in the current KDE way of naming
> menus, and hope that if Debian menu goes this way, it
> should improve on it.
>
> The current way KDE names programs is:
> Ty
2005/12/18, Andreas Metzler <[EMAIL PROTECTED]>:
> Gürkan Sengün <[EMAIL PROTECTED]> wrote:
> > I've run some scripts to find out the size of binary pakcages in debian
> > and how theycould be made smaller, here's the results:
>
> > http://www.linuks.mine.nu/sizematters/
>
> Afaict from the webpage
Marco d'Itri wrote:
> I do not remember a consensus about this.
Perhaps the last hold-outs can be convinced this time? :)
Bernd Eckenfels wrote:
> and if it is placed in a tmpfs (which is really the best thing
anyway)
> it doesnt matter under which mountpoint it is located.
It does matter,
(OK, this time reformatted to make my webmail composer happy.)
Marco d'Itri wrote:
> I do not remember a consensus about this.
Perhaps the last hold-outs can be convinced this time? :)
Bernd Eckenfels wrote:
> and if it is placed in a tmpfs (which is really the best thing
> anyway) it doesnt
This message is to verify that you wish to have your
email address: debian-devel@lists.debian.org removed from the
Alharamain Sermon(english)
Subscribe Me mailing list.
You MUST click on the link below to have your address removed
from our list. This is to ensure that someone doesn't remove your
On Sun, Dec 18, 2005 at 01:28:18 +0100 (+0100), Elimar Riesebieter wrote:
> On Sun, 18 Dec 2005 the mental interface of
> Matthew Palmer told:
>
> > On Sat, Dec 17, 2005 at 08:37:28PM +0100, Elimar Riesebieter wrote:
> > > does one know why xmcd isn't upgraded since 31 of May in 2003? The
> > > pa
On Dec 18, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I have yet to hear any strong reason why we should _not_ implement
> /run.
> I do not count "It's ugly!" as a strong reason.
It's not needed (since we have /dev/shm/), so it's harmful.
--
ciao,
Marco
signature.asc
Description: Digita
Steinar H. Gunderson wrote:
On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:
I've run some scripts to find out the size of binary pakcages in debian
and how theycould be made smaller, here's the results:
My comments are about the same as on IRC:
- Disk space is cheap, bandwi
This message is to confirm the removal of your
email address: debian-devel@lists.debian.org from the
Alharamain Sermon(english)
Subscribe Me mailing list.
We're sorry to see you go!
If you feel you have received this notice in error,
please visit the Alharamain Sermon(english)
Subscribe Me maili
On 12/18/05, Roberto Sanchez <[EMAIL PROTECTED]> wrote:
> I think that the biggest problem is really updates. Packages like
> XFree86 (no X.org) and Openoffice.org are *huge*. A simple security
> update to one of those packages causes all subordinate binary packages
> to get a version bump. That
On 12/18/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:
> > I've run some scripts to find out the size of binary pakcages in debian
> > and how theycould be made smaller, here's the results:
>
> My comments are about the same as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 18, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>> I have yet to hear any strong reason why we should _not_ implement
>> /run.
>> I do not count "It's ugly!" as a strong reason.
> It's not needed
On Sun, Dec 18, 2005 at 08:41:03AM -0500, Roberto Sanchez wrote:
>> - CPU doesn't grow nearly as fast as those three.
> In 1995 I had a Pentium 166 and a 56 kbps modem. Now, today the fastest
> CPU you can get from Intel is 3.6 GHz. However, the fastest dial modem
> you can get today is still
Hi,
I realize TeX is tough program to maintain. Thanks to Frank.
One quick and easy way to avoid TeX related build issues are to avoid
using TeX related tools during build time. So the results will be
Debian only ships documentations in plain text and HTML. (No PS and no
PDF). But is it what w
On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote:
> Why would this be huge?
> Why is it that hard to plugin another codec?
You'd have to rewrite about every single tool in the world handling .debs,
make up a transition plan and upgrade from that. Not to mention that you'd
have to
On Sun, Dec 18, 2005 at 02:37:28PM +0100, Marco d'Itri wrote:
> On Dec 18, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> > I have yet to hear any strong reason why we should _not_ implement
> > /run.
> > I do not count "It's ugly!" as a strong reason.
> It's not needed (since we have /dev/shm/)
In article <[EMAIL PROTECTED]> you wrote:
> However there a big differences: /var/run is much smaller than /run, and if
sorry i meant to say: /var/run is much smaller (bytewise) as /usr/lib.
Gruss
Bernd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Con
On Sun, 18 Dec 2005 the mental interface of
adrian told:
> On Sun, Dec 18, 2005 at 01:28:18 +0100 (+0100), Elimar Riesebieter wrote:
> > On Sun, 18 Dec 2005 the mental interface of
> > Matthew Palmer told:
> >
> > > On Sat, Dec 17, 2005 at 08:37:28PM +0100, Elimar Riesebieter wrote:
> > > > does
In article <[EMAIL PROTECTED]> you wrote:
> Bernd Eckenfels wrote:
>> and if it is placed in a tmpfs (which is really the best thing
>> anyway) it doesnt matter under which mountpoint it is located.
>
> It does matter, because /run needs to be usable before other
> filesystems are mounted, and a f
In article <[EMAIL PROTECTED]> you wrote:
> I hope this will be solved soon!
use nameif.
Gruss
Bernd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sun, Dec 18, 2005, Andreas Metzler wrote:
> Have you perhaps run some benchmarks?
Thanks to Kingsley Morse Jr.: http://adn.diwi.org/debian/p7zip/7za.jpg
Even more precise at http://www.linuxjournal.com/article/8051
--
adn
Mohammed Adnène Trojette
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
On Sunday 18 December 2005 15:34, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > I hope this will be solved soon!
>
> use nameif.
This has been suggested before but AIUI nameif has problems/limitations
renaming eth0.
The correct solution seems to be to use udev rewriting
Package: wnpp
Severity: wishlist
Owner: Jonas Genannt <[EMAIL PROTECTED]>
* Package name: libpod-tests-perl
Version : 0.18
Upstream Author : Adam Kennedy <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~adamk/
* License : GPL
Description : Perl extensi
Russ Allbery <[EMAIL PROTECTED]> writes:
> Anand Kumria <[EMAIL PROTECTED]> writes:
>
>> A simple assurance that your package will be rejected from the NEW queue
>> if no ftp-master approves it within 2 weeks would actually be a benefit.
>
> Why?
>
> It seems like, if that's the way that you want
Are we seriously expecting to ship etch with 2.4
kernels? Is anyone still doing active security support for it?
This point isn't too bad yet. As you've seen 2.4 had a security update a
few days ago. Sure, it's from August, but 2.6 isn't doing better anyway.
Some Debian kernel team people (suc
On Sun, Dec 18, 2005 at 01:26:45PM +0100, [EMAIL PROTECTED] wrote:
> It does matter, because /run needs to be usable before other
> filesystems
I realise your heart's set on /run, but is there any possibility
of putting it under /lib/run or /boot/early-writable-fs instead of
introducing a new dir
On Dec 18, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > It's not needed (since we have /dev/shm/), so it's harmful.
> Does not follow. Cars aren't needed either (you can always take the
> train, or go by bus), but that doesn't make them harmful.
Cars and trains are different thigs, but a tmpfs i
On Dec 18, Roger Leigh <[EMAIL PROTECTED]> wrote:
> How strongly can I put this? /dev/shm is for *shared memory*, not for
> random junk. /dev/shm is for POSIX shared memory and semaphores
/dev/shm is a tmpfs which happens to be used by POSIX SHM. I have not
seen yet a good reason why it should n
Package: ftp.debian.org
Severity: wishlist
I am asking for the immediate removal of the following source packages and
all their binaries:
usermin
usermin-contrib
webmin
webmin-cluster
webmin-contrib
webmin-exim
webmin-extra
webmin-optional
webmin-snort
webmin-virtual-server
It should be blindin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 18, Roger Leigh <[EMAIL PROTECTED]> wrote:
>
>> How strongly can I put this? /dev/shm is for *shared memory*, not for
>> random junk. /dev/shm is for POSIX shared memory and semaphores
> /dev/shm is
"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
I won't complain, I'll just send a friendly assassin to your house :-)
A friendly assasin? Is that the type that comes in, talks with you for a
while, and eventually offers you a poisioned beer?
--
To UNSUBS
"Marco d'Itri" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Furthermore, /dev/shm is a mount point with a _very_ specific function.
It's a bad idea to start using it for something else.
Reality check: packages have been using it for a long time and the world
has not fallen yet
On Sun, 2005-12-18 at 15:02 +0100, Steinar H. Gunderson wrote:
> On Sun, Dec 18, 2005 at 08:41:03AM -0500, Roberto Sanchez wrote:
> >> - CPU doesn't grow nearly as fast as those three.
> > In 1995 I had a Pentium 166 and a 56 kbps modem. Now, today the fastest
> > CPU you can get from Intel is 3
On Sun, 2005-12-18 at 12:59 +0100, Steinar H. Gunderson wrote:
> On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:
> > I've run some scripts to find out the size of binary pakcages in debian
> > and how theycould be made smaller, here's the results:
>
> My comments are about the same
As you can see below and in the BTS, vim's maintainer has managed to
create a vim-tiny package that is vim without some of the extras such as
syntax highlighting. It's now only marginally larger than nvi, which is
the standard vi included in the base system (amazingly, it's smaller
than nano, the o
On Sun, Dec 18, 2005 at 01:38:57PM -0500, Joey Hess wrote:
> There are obviously users who will prefer nvi to vim (and others who
> prefer some other vi), but I get the impression there are rather more who
> prefer vim, it's probably the most commonly used vi in linux these days.
Count me as an nvi
Anthony Towns wrote:
> is there any possibility
> of putting it under /lib/run or /boot/early-writable-fs instead of
> introducing a new directory on / that's of very limited use?
That is certainly possible, but I don't see anything wrong with putting
it at the top level either.
FWIW I asked Chr
su, 2005-12-18 kello 13:38 -0500, Joey Hess kirjoitti:
> One argument I can think of for keeping nvi in base is that it is the
> closest to bug-compatible with the original vi. However, I don't think
> that will prevent hardcore vi users from easily using vim-tiny if
> it's in base.
I'm one of the
* Lars Wirzenius wrote:
> In fact, given that it's good for base to be small, I'd like to
> suggest that we don't have more than one editor there.
We already have two editors in the base system, nvi and nano.
Norbert
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe"
On Dec 18, "Andrew M.A. Cater" <[EMAIL PROTECTED]> wrote:
> Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX
Sure, I often use vim over serial consoles.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Dec 18, Joe Smith <[EMAIL PROTECTED]> wrote:
> 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm,
> or that if it does exist, that it can be be read as a block device, or that
> if it can, it has a file system on it.
> 2. Neither does FHS.
> 3. The Linux 2.6 device li
On Dec 18, Thomas Hood <[EMAIL PROTECTED]> wrote:
> FWIW I asked Chris Yeoh for his opinion on the name and he said that
> /run sounded preferable to both /etc/run and /lib/run.
Competition with /root in tab-completion, for a start.
--
ciao,
Marco
signature.asc
Description: Digital signature
On 12/18/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote:
> > Why would this be huge?
> > Why is it that hard to plugin another codec?
>
> You'd have to rewrite about every single tool in the world handling .debs,
> make up a t
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>> Anand Kumria <[EMAIL PROTECTED]> writes:
>>> A simple assurance that your package will be rejected from the NEW queue
>>> if no ftp-master approves it within 2 weeks would actually be a benefit.
>> Why?
* Steinar H. Gunderson:
> My comments are about the same as on IRC:
>
> - Disk space is cheap, bandwidth is cheap.
Depends. Decent IP service costs a few EUR per gigabyte in most parts
of the world.
> Thus, anything sacrificing lots of human power and CPU power to save on disk
> or bandwidth
On Sun, Dec 18, 2005 at 01:03:37PM -0500, Joe Smith wrote:
> 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm,
> or that if it does exist, that it can be be read as a block device, or that
> if it can, it has a file system on it.
> 2. Neither does FHS.
> 3. The Linux 2.6
su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti:
> * Lars Wirzenius wrote:
> > In fact, given that it's good for base to be small, I'd like to
> > suggest that we don't have more than one editor there.
>
> We already have two editors in the base system, nvi and nano.
Yes, that bein
On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:
> Hi
>
> I've run some scripts to find out the size of binary pakcages in debian
> and how theycould be made smaller, here's the results:
>
> http://www.linuks.mine.nu/sizematters/
FWIW :
https://wiki.ubuntu.com/Dpkg7Zip
Actual mai
* Andreas Metzler:
> Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. -
> Have you perhaps run some benchmarks?
Memory use during decompression would be interesting, too.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROT
su, 2005-12-18 kello 20:18 +0100, Marco d'Itri kirjoitti:
> > Sounds it sounds to me like it is a bad idea to use it.
> Only because you have no clue of what you are talking about.
Marco, would please keep the discussion technical, and not attack the
people taking part, even if you think they're
Anthony Towns wrote:
> On Fri, Dec 16, 2005 at 11:24:39AM +0100, Frank Küster wrote:
>> > No, that would be "unsuitable for release". Which is a problem that
>> > should either be fixed quickly, or means you're trying to make a big
>> > enough change that you should be working out how to get it d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 18, Joe Smith <[EMAIL PROTECTED]> wrote:
>
>> 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm,
>> or that if it does exist, that it can be be read as a block device, or that
On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote:
> On 12/18/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
> > On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote:
> > > Why would this be huge?
> > > Why is it that hard to plugin another codec?
> >
> > You'd hav
On Sun, Dec 18, 2005 at 08:34:04PM +0100, Frank Küster wrote:
> >
> > Six months is a lot of time; and experimental should provide you with
> > the space and machine power to handle the rebuilding.
>
> I don't know of any autobuilders that build packages from sid against
> build-dependencies in e
On Sun, Dec 18, 2005 at 06:54:42PM +, Andrew M.A. Cater wrote:
> On Sun, Dec 18, 2005 at 01:38:57PM -0500, Joey Hess wrote:
> > There are obviously users who will prefer nvi to vim (and others who
> > prefer some other vi), but I get the impression there are rather more who
> > prefer vim, it's
Lars Wirzenius wrote:
> I'm one of the people who prefers nvi over vim. I do so quite strongly,
> because I find that nvi obeys my fingers and vim does not. The
> differences are minute, of course, but they are really irritating.
> Unfortunately, I can't enlist them properly, since my fingers don't
Andrew M.A. Cater wrote:
> Will it work fine over a serial console?
Yes, vim works fine over a serial console. You might want to turn off
part of the status line if using it at less than 9600 baud.
> Is it fine for ex-Solaris/HP-UX
> /AIX admins who may have got used to nvi?
I imagine they might
Oh, another possible advantage to having vim-tiny in base is that it
includes the vimtutor command, which is a fairly good way to learn how
to use vim (or any vi; it avoids most vim-isms). The tutor is how I
finally learned (to love) vi after years of badly using and loathing it
as the base editor
On Sun, 18 Dec 2005 15:02:55 +0100
"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote:
> Not to mention that a DVD-R can fit about three million times as much
> data as a floppy disk, which was the dominant way of distributing
> software at the time. We can continue keep playing these number
> games
su, 2005-12-18 kello 14:57 -0500, Joey Hess kirjoitti:
> Yeah, I understand the feeling (coming at it from the exact opposite
> side). It would be helpful if there were an analysis of the major differences
> somewhere; the ones I am most aware of incude:
I'm not personally very interested in this.
Lars Wirzenius wrote:
> In the name of reducing base's size, I would support a policy change
> here, excempting vi clones, but I suspect I'd be shouted down.
> Personally, I think "standard" would be the appropriate priority for for
> the vi clone.
In which case it wouldn't really reduce base's si
On Sun, Dec 18, 2005 at 09:08:21PM +0100, Luca Brivio wrote:
>> Not to mention that a DVD-R can fit about three million times as much
>> data as a floppy disk, which was the dominant way of distributing
>> software at the time. We can continue keep playing these number
>> games, but I don't really
On Sun, Dec 18, 2005 at 15:40:46 +0100 (+0100), Elimar Riesebieter wrote:
> On Sun, 18 Dec 2005 the mental interface of
> adrian told:
[snip]
> > Hi, sorry for not responding earlier, I've less and less time for
> > Debian stuff as time goes by (busy). There are substantial changes
> > upstream i
On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote:
> Why would that stop working if you switch compression schemes?
> I guess tar is coded to use gzip with -z and bzip2 with -j, but why is
> there no generic way to add coders/decoders (codecs) to tar (and other
> applications that w
On Sat, Dec 17, 2005 at 06:09:05PM -0600, Peter Samuelson wrote:
> Given the need, and now the reality, of /run, is there any need for a
> separate /var/run? I vote we migrate to /var/run -> /run, at least in
> the default install.
If /run is tmpfs, it means everything stored there eats virtual
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 18, Thomas Hood <[EMAIL PROTECTED]> wrote:
>
>> FWIW I asked Chris Yeoh for his opinion on the name and he said that
>> /run sounded preferable to both /etc/run and /lib/run.
> Competition with /root in tab-completion, for a start.
Under what circ
Graham Wilson <[EMAIL PROTECTED]> writes:
> On Sun, Dec 18, 2005 at 06:54:42PM +, Andrew M.A. Cater wrote:
>> Count me as an nvi person. Vim is great - but not as the default in
>> the most basic system, no matter how stripped down.
> Why is nvi better if the size of nvi and vim-tiny are comp
On 12/18/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote:
> > Why would that stop working if you switch compression schemes?
> > I guess tar is coded to use gzip with -z and bzip2 with -j, but why is
> > there no generic way to
On Sun, Dec 18, 2005 at 04:50:33AM +, Matthew Garrett wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote:
> >> Under Linux, can't all of this be done with mount --move anyway? I'm not
> >> convinced that we actually need a /run
Steinar H Gunderson <[EMAIL PROTECTED]> writes:
> On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote:
>> Why would that stop working if you switch compression schemes? I guess
>> tar is coded to use gzip with -z and bzip2 with -j, but why is there no
>> generic way to add coders/de
On Sun, Dec 18, 2005 at 10:15:31PM +0100, Olaf van der Spek wrote:
> I guess what I'm asking is, why are tar and other applications using
> gzip instead of a generic library that handles all
> compression/decompression and can be easily extended.
General complexity, I'd guess. If you want “easily
On Sun, Dec 18, 2005 at 02:57:17PM -0500, Joey Hess wrote:
> Lars Wirzenius wrote:
> > I'm one of the people who prefers nvi over vim. I do so quite strongly,
> > because I find that nvi obeys my fingers and vim does not. The
> > differences are minute, of course, but they are really irritating.
>
On Sun, Dec 18, 2005 at 05:24:40PM +0100, Marco d'Itri wrote:
> Reality check: packages have been using it for a long time and the world
> has not fallen yet.
Emphasis on "yet". /dev/shm was created to be used uniquely by shm_open(),
and violating this _will_ cause some problems after a certain l
On Sun, Dec 18, 2005 at 01:03:37PM -0500, Joe Smith wrote:
> 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm,
> or that if it does exist, that it can be be read as a block device, or that
> if it can, it has a file system on it.
AFAIK /dev/shm is just an internal deta
Glenn Maynard wrote:
> ":set compatible" will switch Vim's behavior for all of these, except for:
Nope, I was running vim in compatible mode (the default without a
~/.vimrc) for all of them.
> In "compatible", arrow keys don't work at all in insert mode, like vi
> ("set esckeys" to revert).
They
On Sun, Dec 18, 2005 at 06:54:42PM +, Andrew M.A. Cater wrote:
> Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX
> /AIX admins who may have got used to nvi?
As an ex-Solaris/AIX admin I can say that I used vim there too (except
when the filesystem containing vim did n
[Anthony Towns]
> I realise your heart's set on /run, but is there any possibility
> of putting it under /lib/run or /boot/early-writable-fs instead of
> introducing a new directory on / that's of very limited use?
/lib is no more appropriate than /sbin. That it is already overloaded
in the FHS
On Sun, Dec 18, 2005 at 04:44:13PM -0500, Joey Hess wrote:
> Glenn Maynard wrote:
> > ":set compatible" will switch Vim's behavior for all of these, except for:
>
> Nope, I was running vim in compatible mode (the default without a
> ~/.vimrc) for all of them.
/etc/vim/vimrc sets "nocompatible", a
On Sun, Dec 18, 2005 at 03:05:40PM -0500, Joey Hess wrote:
> Oh, another possible advantage to having vim-tiny in base is that it
> includes the vimtutor command, which is a fairly good way to learn how
The vimtutor content is not available if vim-runtime is not installed,
and it wont be in the ba
On Sun, Dec 18, 2005 at 01:11:32PM -0800, Russ Allbery wrote:
> Among other things, because it doesn't do the obnoxious auto-indent thing
> that you have to work around with :set paste. I have no objections to vim
Well, this is a matter of configuration, not really a matter of editor.
Debian's vi
On 12/18/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 10:15:31PM +0100, Olaf van der Spek wrote:
> > I guess what I'm asking is, why are tar and other applications using
> > gzip instead of a generic library that handles all
> > compression/decompression and can be
Russ Allbery <[EMAIL PROTECTED]> writes:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>>> Anand Kumria <[EMAIL PROTECTED]> writes:
>
A simple assurance that your package will be rejected from the NEW queue
if no ftp-master approves it with
Package: wnpp
Severity: wishlist
Owner: Kari Pahula <[EMAIL PROTECTED]>
* Package name: gecode
Version : 1.0.0
Upstream Author : Christian Schulte <[EMAIL PROTECTED]> and others
* URL : http://www.gecode.org/
* License : BSD
Description : generic constrai
On Sun, 18 Dec 2005 the mental interface of
adrian told:
> On Sun, Dec 18, 2005 at 15:40:46 +0100 (+0100), Elimar Riesebieter wrote:
> > On Sun, 18 Dec 2005 the mental interface of
> > adrian told:
> [snip]
> > > Hi, sorry for not responding earlier, I've less and less time for
> > > Debian stuff
This one time, at band camp, Marco d'Itri said:
> On Dec 18, Thomas Hood <[EMAIL PROTECTED]> wrote:
>
> > FWIW I asked Chris Yeoh for his opinion on the name and he said that
> > /run sounded preferable to both /etc/run and /lib/run.
> Competition with /root in tab-completion, for a start.
Well,
In article <[EMAIL PROTECTED]> you wrote:
> If /run is tmpfs, it means everything stored there eats virtual memory.
> So a musch metter strategy would be to move everything from /run to
> /var/run at the end of the boot process.
tmpfs stores run ressources in vm more efficiently (since they are ot
On Sun, Dec 18, 2005 at 09:52:42AM +0100, Marco d'Itri wrote:
> On Dec 18, Darren Salt <[EMAIL PROTECTED]> wrote:
>
> > An alternative appears to be to process events in series... or maybe
> > delaying
> This was the precedent approach, and it's much slower (also, it cannot
> be implemented anymo
1 - 100 of 107 matches
Mail list logo
