headers
William Pitcock | 1 Jun 01:09
Picon

Bug#483899: ITP: sockstat -- clone of freebsd's sockstat(1) utility

Package: wnpp
Severity: wishlist
Owner: William Pitcock <nenolod <at> sacredspiral.co.uk>

* Package name    : sockstat
  Version         : 0.1
  Upstream Author : William Pitcock <nenolod <at> sacredspiral.co.uk>
* URL             : http://www.nenolod.net/sockstat
* License         : BSD
  Programming Lang: C
  Description     : clone of freebsd's sockstat(1) utility
 This package is a clone of freebsd's sockstat(1) utility. It includes
 features like the ability to search for open sockets by user,
 program-specific socket usage information, searching for listening
 sockets, connected sockets, and much more.

-- System Information:
Debian Release: lenny/sid
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Permalink | Reply | 0 comments |
headers
Joe Smith | 1 Jun 05:58
Picon

Re: Large data packages in the archive


"Joerg Jaspert" <joerg <at> ganneff.de> wrote:
> [snip]
>c.) We can host an own archive for it under control of ftpmaster.
> [snip]
>So the way to go for us seems to be c.), hosting the archive ourself
>(somewhere below data.debian.org probably).
> [snip]

A data.d.o would presumably be running on a debian project machine. Do we 
really have the bandwidth and reasources to be hosting large files that 
could be downloaded by a great many people?
Or do we intend to get a mirror network and point users to some form of 
round-robin DNS entry?

Because of the size of the packages involved, I would expect this to create 
a much bigger strain on our infrastructure than volatile.d.o. (Which is the 
only similar system I can think of off the top of my head).
Permalink | Reply | 0 comments |
headers
Lennart Sorensen | 1 Jun 17:20
Picon
Picon
Favicon

Re: 37.5% boot time reduction in Lenny is possible (recipe)

On Sat, May 31, 2008 at 12:22:36PM +0200, Goswin von Brederlow wrote:
> Benefits may greatly varry.
> 
> For this slowest 2+GHz 8 core server of the world make that 5 minutes
> 48 seconds to 5 minutes 30 seconds here or 5% speed increase. And yes,
> this slowest 2+GHz 8 core server of the world does take that long to
> boot, mainly bios ram test and scsi probing. Never seen a server count
> its ram so slow.
> 
> And you get that once or twice a year. Not sure if the risk of
> breaking things is worth that optimization.

Parallel startup actually made a system I work with take longer to start
up so I certainly turned that off again.

Ignoring the time spent by the bios (can't change that after all), it
went from 29 to 33 seconds with parallel startup scripts.

--

-- 
Len Sorensen
Permalink | Reply | 9 comments |
headers
Manoj Srivastava | 1 Jun 17:37
X-Face
Face
Picon
Favicon

Re: the quality of Debian's diff.gz

On Sun, 01 Jun 2008 15:14:49 +0200, Ove Kaaven <ovek <at> arcticnet.no> said: 

> George Danchev skrev:
>> Very good, but please make these easily visible/readable to the rest
>> via diff.gz

> Oh no, not again... This was already flam^H^H^H^Hdebated on
> debian-devel. I believe debian-mentors is where new maintainers learn
> current best practices, not where *new* practices are developed; for
> that, you'd go to debian-devel. Feel free to join the efforts there.

        Point. I should say that Debian should be a good free software
 citizen, not just a glorified packager of software.  I like the clause
 in the GPL that says that the sources should be distributed in the form
 best suited for modification (usually defined as the form used by the
 authors). It does not really matter if the authors use haskel or
 smalltalk or Ocaml, despite the fact that not many people know these
 languages. 

        Given that, if the package is developed using, say, git, then we
 should distribute it using the native development mechanisms -- in
 order to let the downstream users fully cooperate in development. Since
 we do not deprecate people developing in python or C or c++ or perl,
 despite each  language having limited users, instead of PHP, which I am
 told is the most popular, we should not dictate what work-flow people
 use.

        We also should not try to hide these preferred forms of
 modifications from our users. And in this day and age of Web 2.0,
 requiring an intrnet connection is not an anathema; and neither is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Petter Reinholdtsen | 1 Jun 17:40
Gravatar

Re: 37.5% boot time reduction in Lenny is possible (recipe)

[Lennart Sorensen]
> Parallel startup actually made a system I work with take longer to
> start up so I certainly turned that off again.

Right.  Are you talking about CONCURRENCY=startpar or something else?
Never seen that myself, so I am curious how you get it.  Could it be
wrong init.d script dependencies in some of the packages you have
installed?  Please provide 'ls /etc/rc*.d/' for the machine in
question, to give me a chance to reproduce this.  What kind of
hardware was this?  Can you provide the bootchart graphs for the
parallel and non-parallel boot?

Happy hacking,
--

-- 
Petter Reinholdtsen
Permalink | Reply | 6 comments |
headers
Gustavo Iñiguez Goya | 2 Jun 01:40
Favicon

Bug#484029: ITP: gnome-inm-forecast -- Spanish weather forecast applet for the GNOME desktop

Package: wnpp
Severity: wishlist
Owner: "Gustavo Iñiguez Goya" <ga <at> kutxa.homeunix.org>

* Package name    : gnome-inm-forecast
  Version         : 0.6.1
  Upstream Author : Gustavo Iñiguez Goya <ga <at> kutxa.homeunix.org>
* URL             : http://kutxa.homeunix.org/trac/gnome-inm-forecast
* License         : GPL
  Programming Lang: C
  Description     : Spanish weather forecast applet for the GNOME desktop

 It displays the Spanish weather forecast on the GNOME panel, getting
 the information from the Spanish Meteorological Agency (http://www.aemet.es).
 Features:
	Up to 7 days of meteorological information, including maximum and
	minimum temperatures, rainfall probability, wind direction, snow
	level and general weather state.
	Snowfalls reports for the Pyrenees.
	Intuitive city search just by typing the firsts characters.
	Weather reports for the following days.
	Maximum and minimum temperatures maps for the following day.
	Spanish weather forecast image.
	Satellite radar images of the weather evolution.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Powell | 2 Jun 04:36
Picon
Favicon

Re: Mouse configuration during installation needs improvement

Well shut my mouth!  I did some testing this past
weekend, as I said I would, and results are better
than expected.  First, leaving things the way I had
them configured (X pointing to /dev/gpmdata and gpm
pointing to /dev/psaux, I unplugged the PS/2 mouse
from the mouse port.  The mouse became dead in both X
and gpm (duh!).  I then plugged it back in again.  It
worked again, both in X and in gpm!  Then I configured
X and gpm both to use /dev/input/mice and turned off
gpm's repeater function.  After restarting both
daemons and verifying that both X and gpm could use
the mouse, I again unplugged the mouse.  Again it was
dead in both X and gpm (duh!).  And again I plugged it
back in and it started working again, both in X and in
gpm, with no action on my part.  I didn't have to
restart the gpm daemon, I didn't have to restart X, I
didn't have to unload and reload a kernel module, etc.
 This is better than I expected.

Of course, this is on a different machine (a Dell
Dimension 4400) than I last tried this on (an IBM
Thinkpad 600).  But I'm impressed.  Theoretically, one
is not supposed to be able to hot swap a PS/2 mouse. 
But it works.  Kudos to the kernel folks.

The repeater function of gpm now appears to be
obsolete, as you say.  I would still like to see gpm
installed by the Debian installer whenever a mouse is
detected on the system in order to allow copy and
paste in a virtual console.  But I'm not going to flog
(Continue reading)

Permalink | Reply | 501 comments |
headers
Yves-Alexis Perez | 2 Jun 08:21
Picon
Favicon

Re: Bug#483899: ITP: sockstat -- clone of freebsd's sockstat(1) utility

On sam, 2008-05-31 at 18:09 -0500, William Pitcock wrote:
>   Description     : clone of freebsd's sockstat(1) utility

Not sure it's a really good short description, especially if $user
doesn't know what sockstat do.

Cheers,
--

-- 
Yves-Alexis
Permalink | Reply | 0 comments |
headers
Goswin von Brederlow | 2 Jun 08:48
Picon

Re: Mouse configuration during installation needs improvement

Stephen Powell <zlinuxman <at> yahoo.com> writes:

> Thinkpad 600).  But I'm impressed.  Theoretically, one
> is not supposed to be able to hot swap a PS/2 mouse. 
> But it works.  Kudos to the kernel folks.

The problem has never been that the mouse didn't work after a hot
swap.

The problem is that with PS/2 the power surge on the port, as little
as it is, may well fry your mainboard. Obviously in the last 10 or so
years mainboards have become a bit more resilient to this because
people to tend to accidentally pull a mouse cable every now and then
and plug it back in.

MfG
        Goswin
Permalink | Reply | 501 comments |
headers
Goswin von Brederlow | 2 Jun 08:51
Picon

Re: 37.5% boot time reduction in Lenny is possible (recipe)

lsorense <at> csclub.uwaterloo.ca (Lennart Sorensen) writes:

> On Sat, May 31, 2008 at 12:22:36PM +0200, Goswin von Brederlow wrote:
>> Benefits may greatly varry.
>> 
>> For this slowest 2+GHz 8 core server of the world make that 5 minutes
>> 48 seconds to 5 minutes 30 seconds here or 5% speed increase. And yes,
>> this slowest 2+GHz 8 core server of the world does take that long to
>> boot, mainly bios ram test and scsi probing. Never seen a server count
>> its ram so slow.
>> 
>> And you get that once or twice a year. Not sure if the risk of
>> breaking things is worth that optimization.
>
> Parallel startup actually made a system I work with take longer to start
> up so I certainly turned that off again.

Single core? Slow disks? Unless you have idle times the multiple
threads won't help. Works best with things like portmapper that does
sleep 1.

> Ignoring the time spent by the bios (can't change that after all), it
> went from 29 to 33 seconds with parallel startup scripts.

Who says you can't change it? There is OpenBios. :)

MfG
        Goswin
(Continue reading)

Permalink | Reply | 1 comment |

Gmane