Re: Hijacking apt-cacher (Jonathan Oxer MIA?)
Hi Eduard and Martin, On Wed, 2005-05-11 at 10:45 +0100, Martin Michlmayr wrote: > * Eduard Bloch <[EMAIL PROTECTED]> [2005-05-11 10:55]: > > I do not get any answers from the maintainer of apt-cacher (Jonathan > > Oxer <[EMAIL PROTECTED]>) without any obvious reason, he has been > > responding few weeks ago. > ... > > If anyone has contact with Jonathan, please tell him to contact me. > > Jon became the president of Linux Australia a while ago and is working > on a book so he's probably just busy and will appreciate your work. > I'd give him a chance to say "go ahead" though. Just to make it official: "go ahead" ;-) Eduard, I'm really sorry I haven't responded recently but I've been following your work on apt-cacher and I certainly appreciate your efforts. In recent times I've been even more of a pathetic excuse for a DD than usual, so I apologise for that. There is a whole litany of excuses including those already mentioned by Martin: I'm now President of Linux Australia (a position involving much more work than it may appear), I'm working on 3 more books, spent the last few months organising Debian Miniconf4, have a newish baby son, am on 5 (IIRC) management or advisory boards, am part of upstream for a bunch of projects, and am trying to run a business that's so frantically busy I can't hire people fast enough. So since you've shown so much interest and initiative, you're welcome to either adopt or co-maintain Apt-cacher as you prefer. It still has personal interest for me but obviously you're in a better position to give it the attention it deserves right now. Cheers :-) Jonathan Oxer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: RFS: eaccelerator - PHP script cacher]
On Thu, 2005-05-12 at 12:07 -0400, Roberto C. Sanchez wrote: > Quoting Florian Weimer <[EMAIL PROTECTED]>: > > > * Roberto C. Sanchez: > > > >> I forwarding this to d-d since after a couple of days I > >> still have no response from anyone on d-m willing to sponsor > >> this package. > > > > Please have a look at the following discussions: > > > > <http://lists.debian.org/debian-legal/2004/11/msg00078.html> > > <http://lists.debian.org/debian-legal/2005/01/msg00130.html> > > Thanks. I was not aware. Is there a problem with me providing the > eAccelerator > packages? Yes, it's a problem. This has been a long ongoing debate originally among Turck-mmcache users (I'm the turck-mmcache maintainer) and now among eAccelerator users / developers (I've also created eAccelerator packages, but I haven't submitted them to the archive because the legal situation needs to be resolved first). In fact there are now two problems with eAccelerator. The first problem which was carried over from Turck-mmcache was the GPL/PHP licence linking problem, and now there is also possibly a copyright problem because when the project was forked the new developers simply removed all the Turcksoft copyrights and added their own. > I am not distributing PHP at all, and I also have the eAccelerator > source available with the binary. Unfortunately that doesn't solve the problem because it would mean distributing binaries that have been linked against PHP, which has a GPL-incompatible licence. One of the suggestions a long time ago was to replace the Turck-mmcache package with a 'loader' package that grabbed the source tarball and built it on the target machine, but I resisted that idea because it would require the target machine to have all sorts of things installed including a compiler, the C dev libs, the PHP source, and a bunch of other things that wouldn't typically exist on a deployment server. It would also be a rather jarring experience for the admin, with a package install taking quite a few minutes and chewing up all the CPU time rather than the fractions of a second required to install a binary package. It would technically work and it would be legal, but it would be a very ugly kludge. > I really hope that this is worked out. So do I. I've had a brief informal chat to Jeremy Malcolm of iLaw (who also happens to be Linux Australia's legal counsel) about the situation and I'll probably follow this up with him in a more formal way when I get a chance. I'm happy to pay the $$$ to get formal legal advice on this issue if it helps resolve things. The primary issue to resolve is the ownership of the codebase so that it can be re-licenced. At present the copyright of Turck-mmache resides with Turcksoft, a Russian company that now seems to be out of business. As a result there's no-one to re-licence the code to LGPL or similar, which would then make binaries built against PHP legal to distribute. Cheers :-) Jonathan Oxer -- The Debian Universe: Installing, managing and using Debian GNU/Linux http://www.debianuniverse.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: RFS: eaccelerator - PHP script cacher]
[CCd to relevant parties including the eAccelerator developers] Hi Roberto, Just a quick update on distributability of Turck-MMCache / eAccelerator: I've now contacted Jeremy Malcolm of iLaw (who also happens to be a DD!) and provided him with a brief history of the two projects, and asked him to provide legal advice on how to proceed. I'm happy to pay for his time to help sort it out, especially if it results in Debian being able to distribute eAccelerator. After an informal chat with him I'm hopeful that given the demise of TurckSoft it will be possible to relicense the Turck-MMCache code in eAccelerator to allow it to be linked against PHP, but I'll let you know the outcome in any case. Cheers :-) Jonathan Oxer -- The Debian Universe: Installing, managing and using Debian GNU/Linux http://www.debianuniverse.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes a debconf?
On Sat, 2003-05-24 at 15:27, Brian May wrote: > On Fri, May 23, 2003 at 05:25:29PM -0400, Joe Drew wrote: > > Do we need some method of deciding what constitutes 'the' Debconf? > > No, as everyone knows that the only true "Debconf" are the ones in > Australia, with LCA. Hehe, preach it brother ;-) Maybe a reasonable compromise would be to have 2 'official' debconfs / year, as 'Debconf North' and 'Debconf South' (as in Northern and Southern hemisphere). With the last Mini-Conf in Australia attracting more people than any Debconf so far, it's probably not unreasonable for the annual Debian Mini-Conf at LCA to be promoted as Debconf South. That would provide an official Debconf in each hemisphere for people that need to convince their bosses to send them to one, making it more attainable (ie: cheaper) but without leaching too much from each other. Cheers Jonathan signature.asc Description: This is a digitally signed message part
Re: [OT?] Re: Managing package sources with subversion?
> On Thu, May 29, 2003 at 10:12:28AM -0700, Brian Nelson wrote: > > I use subversion for some things, but I haven't moved my Debian > > package repositories over yet because I've just had too many problems > > with subversion. It's just not stable enough yet, IMO. FWIW I've started managing the apt-cacher package using Subversion, and in my business we use it in production for development of web apps. It's had some flakiness prior to the BDB4.1 transition, but since then has been rock solid for me. I've noticed a few SVN commit messages from X-strike-force on the list too, so I assume Branden et al are using it for Xfree86? If it's up to the task for Xfree86, I'd say it'd be good enough for most Debian packages. Cheers Jonathan
Re: Celebrating Debian's 10th birthday?
On Mon, 2003-06-02 at 12:14, Kenshi Muto wrote: > At Mon, 2 Jun 2003 03:24:39 +0200, > Alexander Neumann wrote: > > Are there any parties planned already? ;) > > Debian JP Project, consists of Debian developers/users in Japan, are > planning 'Debian 10th anniversary party' at Tokyo on Aug 15 midnight. There has also been talk of a get-together in Melbourne, Australia on the Debian-melb list. Looks like Martin will be back just in time for it :-) Stewart Smith (VP of Linux Australia, the org that runs LCA) suggested synchronising events in multiple venues, which could have the effect of attracting some media attention to it. A global multi-venue party sounds pretty cool to me :-) Cheers Jonathan
Re: A success story with apt and rsync
On Sun, 2003-07-06 at 09:27, Goswin Brederlow wrote: > 4. (and this is the knockout) rsync support for apt-get is NO > WANTED. rsync uses too much resources (cpu and more relevant IO) on > the server side and a widespread use of rsync for apt-get would choke > the rsync mirrors and do more harm than good. One way to alleviate this would be to only generate the deltas once on server-side when first requested, then cache them on disk to be served out like any other static file for reconstruction of the new package on the client-side using rsync. I've been thinking for a while about trying to build this into Apt-cacher. Jonathan
Re: Debian 10th birthday gear
On Tue, 2003-07-08 at 20:00, Christian Marillat wrote: > > > > I would recommend to exchange these last two lines. More installations > > than users? Debian seems to be strong as a server-oriented OS: seems quite logical to me that there are many more installations than users. I personally run more than 10 Debian boxes, so me as 1 user counts as more than 10 installations. Cheers Jonathan
Re: Debian 10th birthday gear
On Wed, 2003-07-09 at 11:02, Matt Zimmerman wrote: > These servers do not have any users besides you? I run a number of Debian > servers, but of course, these servers have other users (that is who they > serve). When you look at it that way, yes, you're right. I suppose I was thinking of "user" as "someone who runs a computer" rather than "some random internet user who happens to pull a page off my server". If the definition of user is broadened that much, the ratio changes *dramatically*. The middle ground definition would be "people with an account (shell, mail, whatever) on a machine", which would of course still mean more users than machines and proves your point. Either way, one figure I'd really like to know is how many unique individuals use Debian directly (managing a server, on the desktop, whatever) on a regular basis. Not much chance of getting a number on that though! Cheers :-) Jonathan
Re: The size of debian packages
On Wed, 2003-09-24 at 07:34, Andrew Lyon wrote: > Since installing Debian in May the amount of disk space required for my OS > has risen from 1.5GB to 3GB and has reached the limit of the partition. > I don't really want to allocate any more space to the OS as I'm sure there > must be stuff there that I do not need or use (I admit to running dselect > a little to liberally in the past!). How can I find out the sizes of the > packages and try to establish what I can remove without disaster. I tried Consider also not just what packages are installed but other things that could be using space: logs, caches etc. Not too many machines would have 3GB of actual packages installed unless you'd been *really* liberal with dselect ;-) Do an 'apt-get clean' (or 'apt-get autoclean'), then check disk usage again. And maybe try 'ls -lhS | head' and 'du -h --max-depth=1' in a few places like /var/log, and get rid of big/old/rotated logfiles. I suspect you'll find there are plenty of places you can recover space that way. Cheers :-) Jonathan
Bug#212988: ITP: turck-mmcache -- Precompiler and cache to improve performance of PHP scripts
Package: wnpp Version: unavailable; reported 2003-09-27 Severity: wishlist * Package name: turck-mmcache Version : 2.4.0 Upstream Author : TurckSoft <[EMAIL PROTECTED]> * URL : http://turck-mmcache.sourceforge.net/ * License : GPL Description : Precompiler and cache to improve performance of PHP scripts Turck MMCache is a PHP Accelerator, Optimizer, Encoder and Dynamic Content Cache. It increases performance of PHP scripts by caching them in a compiled state, so that the overhead of compiling is almost completely eliminated. It also uses some optimizations for speedup of PHP script execution. Turck MMCache typically reduces server load and increases the speed of PHP code by 1-10 times. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux firewall2 2.4.22 #4 SMP Wed Sep 24 21:20:57 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C
App-specific libraries (was: Re: Bug#218868: ITP: gphpedit -- PHP/HTML/CSS editor with syntax checking)
Hi Joe, > "Gnome2" should be changed to one of: Good point, changed now locally. I hope to upload the initial package soon, but I've been held up with library issues - gPHPEdit requires a patched version of GtkScintilla2, and the fixes aren't being incorporated into the main tree for some reason. So to upload gPHPEdit I somehow need to get a patched version of GtkScintilla2 uploaded as well. Question is, would it be reasonable to create a library package just for gPHPEdit, perhaps something like 'libgtkscintilla-gphpedit', if upstream for the main GtkScintilla2 don't incorporate the fixes? I'd rather not add a whole new package just for this if I can avoid it, but it may be the only way to make gPHPEdit work. Cheers :-) Jonathan signature.asc Description: This is a digitally signed message part
Re: App-specific libraries (was: Re: Bug#218868: ITP: gphpedit -- PHP/HTML/CSS editor with syntax checking)
On Thu, 2003-11-06 at 10:29, Matthew Palmer wrote: > If the patches would be of general use, I'd try and get them incorporated > into the Debian package for scintilla, even if upstream won't take them Good point, I'll look at this. > (I'd > try and work out amongst those involved *why* it's not being accepted > upstream). AFAIK the gPHPEdit developer has been trying to get it included for a while (IIRC there are bugs in upstream GtkScintilla WRT mouse scroll events) and isn't getting anywhere. I doubt my intervention in the situation will help, although it's worth a try. > otherwise breaks normal function), then it's time to consider static > linking. I don't know if the patched version of scintilla is included with > upstream's sources for gPHPEdit, but if it is, you're home free. If not, > you'll have to fudge it into the source package somehow - by giant diff or > rebuilding the source package, whichever you think will be better. The patched GtkScintilla is distributed "with" gPHPEdit, but as a separate tarball. The instructions for gPHPEdit say to build and install the patched GtkScintilla first. From a purely packaging POV it would be much cleaner to make 2 packages rather than have to merge the GtkScintilla build into each version of the gPHPEdit package, but... > Before all the shared object people kill me, if it's only going to be of > practical use to this one application, archive space will be saved by *not* > making a separate library package. Scream "slippery slope" all you like. I absolutely agree. That's why I've been pondering the best approach, I really don't want to add a whole extra package just for this since it'd be unlikely to be used by anything else. Thanks for the suggestions Matt. Cheers :-) Jonathan
Re: binary patch
On Thu, 2003-11-06 at 10:50, Martin Pitt wrote: > But isn't rsync supposed to do this? I don't know exactly how > efficiently it detects and compresses binary differences, but it > definitely does it and not too bad. With rsync, you get both the easy > management of complete debs and the bandwidth-saving of binary diffs. > The only problem is that apt does not support rsync IIRC, but this > could be solved by separately download the new debs into apt's cache > with a script using rsync. Actually IIRC there was some work to make Apt support rsync. Goswin Brederlow was talking about adding it in Jan 2001. And a lot of mirrors actually are set up to support rsync. The problem is that most mirrors are loaded up pretty hard already, and if everyone started using rsync they'd probably melt. So it's a tradeoff, bandwidth vs CPU. At the moment CPU seems to be the factor for mirror admins. Cheers :-) Jonathan Oxer
Bug#219507: ITP: gtkscintilla2 -- Gtk-2 wrappers for the Scintilla source editing components
Package: wnpp Severity: wishlist * Package name: gtkscintilla2 Version : 0.0.8-aj Upstream Author : Andy Jeffriess <[EMAIL PROTECTED]>, Dennis J Houy <[EMAIL PROTECTED]> * URL : http://www.gphpedit.org/, http://http://sourceforge.net/projects/moleskine * License : GPL Description : Gtk-2 wrappers for the Scintilla source editing components GtkScintilla2 provides a Gtk-2 wrapper for the Scintilla source code editing component and adds some features to it. Scintilla is only available as a static library and has an unusual API, so GtkScintilla2 provides access to Scintilla features through a shared library as a true GtkWidget subclass with a GTK2+ API. Note1: This release is based on the '-aj' (Andy Jefriess <[EMAIL PROTECTED]>) patched source tree required by gPHPEdit. This does not prevent it being used by packages other than gPHPEdit, as it adds functionality without otherwise affecting the API. Current upstream Dennis J Houy <[EMAIL PROTECTED]> has indicated the -aj patches should ultimately be merged into the official tree, at which time the -aj tree will become redundant and this package will be switched to build from the official tree instead. This situation has been carefully discussed with all parties involved. Note2: I am aware of bug #107496, originally an ITP and now an RFP for libgtkscintilla and others. I'm not closing that bug with this package because it refers to a version of GtkScintilla for Gtk-1, and I am not packaging the other items listed in that RFP. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux svn.ivt.com.au 2.4.18 #11 SMP Thu Jun 26 14:57:43 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: longer Debian confession
Hi Martin, > A company has asked me whether they [sc]hould write a longer > confession about their use of Debian, why they chose it, and how > their impressions are. I asked them to submit a short text to > www.d.o/users, but they would prefer to write an official statement, > two pages or so. I've been thinking for a while that if I could convince some of the organisations involved to provide more detail I'd like to really exand the Linux Rollouts page at http://jon.oxer.com.au/linuxrollouts/ with detailed case studies. If they do finish writing it up please let me know. There's also the possibility it could be used as the basis of a magazine article, which I'd be very happy to collaborate on. Cheers :-) Jonathan Oxer
Re: an idea for next generation APT archive caching
On Thu, 2004-10-21 at 13:04 +1000, Brian May wrote: > * No thought put into the file deletion algorithm. IMHO, deleting > files based on age is wrong (consider how long stable files > last). Deleting files based on number of different copies is also > wrong (consider if you have some systems setup with stable and another > is unstable). IMHO, the only correct way is to scan the most recently > downloaded Packages and Source index files and delete files that > aren't mentioned anymore. That's how apt-cacher does it. Early versions of apt-cacher did no cache cleaning and it was the #1 requested feature for a while, but once I sat down to actually start implementing it I discovered something that's not obvious until you actually try to do it yourself: Writing Cache Expiry Algorithms Is Bloody Hard(TM). In the end I settled on a combination: Packages and Release files are expired based on age, and .debs are purged based on reference within a Packages file. However, that's not a 100% solution either because what happens if several days go by without any clients doing an 'apt-get update'? The Packages file is purged by the cache cleaning script because it's too old, but then all the .debs are purged too because there's no matching Packages file! Doh. So it's necessary to keep fetching the Packages files within their expiry time or the cache gets nuked. > If you want a reliable caching service, I think some thought needs to > be put into some of the issues above. Some issues might be easy to > fix, others might be harder (e.g. minimizing latency so the client > doesn't time out and to minimize download time but choosing the best > server at the same time). I haven't looked at it them for this purpose in detail but I still think p2p systems are a natural for this. Layering .deb package retrieval onto the Torrent or similar would rock. I'm sure others know much more about the issues though. > You mean via HTTP? This would be possible to add, I think. I guess it > hasn't been considered a priority. Not necessarily, it depends on the cache architecture. Trying to do this with apt-cacher, for example, would suck mightily because it uses a flat cache structure. What's really needed to make is trivially browseable is a cache that stores objects in a structure that mimics the original mirror structure. My understanding is that apt-proxy v2 was written with this in mind, but as usual I'm probably wrong. Cheers :-) Jonathan Oxer -- The Debian Universe: Installing, managing and using Debian GNU/Linux http://www.debianuniverse.com/
Re: an idea for next generation APT archive caching
On Fri, 2004-10-22 at 03:36 +0200, Tobias Hertkorn wrote: > a request for http://yourserver/testing//apachedeb will not create a > hit if requested as http://yourserver/sid//apache...deb . Furthermore > requests to similar mirrors will not create cache hits. So everybody has to > use the same sources list, down to the same requests by symlinks. Yep, that's annoying and it's one of the reasons for the flat cache design in apt-cacher: if clients fetch the same package from different mirrors it will cause a cache hit since the package names are the same. However, something that was raised at Debian Miniconf2 (IIRC) was that this allows cache poisoning: by creating a compromised package and sticking it on any random web server, a cracker can then fetch the package themselves through the cache and any user who subsequently fetches it (even using a genuine mirror in the sources.list) will get the poisoned package. Good argument for package signatures. Cheers :-) Jonathan Oxer -- The Debian Universe: Installing, managing and using Debian GNU/Linux http://www.debianuniverse.com/
Re: an idea for next generation APT archive caching
On Thu, 2004-10-21 at 13:13 +0200, martin f krafft wrote: > also sprach Jonathan Oxer <[EMAIL PROTECTED]> [2004.10.21.0617 +0200]: > > So it's necessary to keep fetching the Packages files within their > > expiry time or the cache gets nuked. > > Why delete them at all? Because then they are never re-fetched, and they'll be out of date. Cheers :-) Jonathan Oxer
Re: an idea for next generation APT archive caching
On Fri, 2004-10-22 at 13:43 +1000, Paul Hampson wrote:
> Is there anything such a system would want to fetch from a Debian
> mirror that doesn't show up in Packages.gz or Sources.gz?
Yes, lots of things as I found out the hard way when I implemented
object type checking in apt-cacher - even plain old .tar.gz if you want
people to be able to fetch sources. Not good from a "don't use this as a
general purpose relay" standpoint! The current checks in apt-cacher look
like this:
if ($filename =~ /(\.deb|\.rpm|\.dsc|\.tar\.gz|\.diff\.gz|\.udeb)$/) {
...
} elsif ($filename =~ /(Packages.gz|Release|Sources.gz)$/) {
...
} else {
etc.
(It's trapping the Packages.gz etc files separately because you can't
just cache them directly: you'd have namespace collisions all over the
shop. They have to be stored separately in the cache based on the
requested host, distro etc and then the names mapped back again when
another request comes in).
Cheers :-)
Jonathan
Re: mirroring question
> apt-move and demish are really mirror programs that rely on apt for > downloading of packages, while apt-proxy is 'just' a cache (you could > also try squid instead of apt-proxy). Or you could try Apt-cacher: http://www.apt-cacher.com/ Jonathan Oxer Ph +61 3 9723 9399 / Fx +61 3 9723 4899 GPG key: http://www.ivt.com.au/gpg/jon.oxer.gpg
Re: mirroring question
Oops! > > Or you could try Apt-cacher: > http://www.apt-cacher.com/ > http://www.apt-cacher.org/
Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, 2002-11-22 at 06:36, Alexander Neumann wrote: > John Goerzen wrote: > > GRUNT is a tool to let you execute commands remotely, offline. > > It will also let you copy files to a remote machine. > > How did you solve the problem of re-sending such mails? Say, Joe Evil > Cracker is able to catch a command mail containing "halt". Will he be > able to shutdown my machine every time he want? I can't speak for GRUNT (having no first-hand knowledge of it) but a couple of ways to do this spring to mind. For example, timestamp every message internally (so the timestamp is inside the GPG payload, not just in the header) and keep a record at the recipient end of timestamps of all executed commands. Ignore duplicates. Alternatively a random character string could be used, but timestamps might give other benefits (for eg, ignore messages older than 5 minutes). Jonathan Oxer Ph +61 3 9723 9399 / Fx +61 3 9723 4899 GPG key: http://www.ivt.com.au/gpg/jon.oxer.gpg signature.asc Description: This is a digitally signed message part
Re: automatic selection which kernel image to install
On Thu, 2002-11-28 at 19:00, Stephen Zander wrote: > >>>>> "sean" == sean finney <[EMAIL PROTECTED]> writes: > sean> i would guess not... > > /proc/cpuinfo. > > Of course if the user doesn't start out using an smp kernel, they > clearly don't need one. Not necessarily. One obvious application for this would be in an installer, which would presumably boot a lowest-common-denominator kernel for maximum compatibility. One possible workaround is trying to detect the mobo type and match that to a list of SMP mobos, but that strikes me as a dodgy solution. After typing the above I had a squiz in /var/log/dmesg on a handy non-SMP machine, and what did I find? This: "SMP motherboard not detected." Then on a SMP machine, and found this: "Intel MultiProcessor Specification v1.1" Hm. Jonathan Oxer Ph +61 3 9723 9399 / Fx +61 3 9723 4899 GPG key: http://www.ivt.com.au/gpg/jon.oxer.gpg signature.asc Description: This is a digitally signed message part
Re: Fwd: Please confirm your message
On Tue, 2002-12-03 at 09:53, Brian May wrote: > On Tue, Dec 03, 2002 at 10:22:32AM +1300, Corrin Lakeland wrote: > > Personally I think bayesian based spam filters are a godsend. They're a > > bit > > naive in places such as being unigram or bigram based, but that'll probably > > get fixed in version two. And already they are still amazingly good. > > Are these packaged for Debian? > > Where can I find more information? apt-get install bogofilter http://www.tuxedo.org/~esr/bogofilter/ http://www.paulgraham.com/spam.html Works like a ripper, I've primed it with a 2000 message spam corpus and 10,000 message non-spam, and it gets called by procmail. Very high accuracy, very few (approaching 0) false positives and negatives. Jonathan Oxer Ph +61 3 9723 9399 / Fx +61 3 9723 4899 GPG key: http://www.ivt.com.au/gpg/jon.oxer.gpg signature.asc Description: This is a digitally signed message part
Bug#188516: ITP: mrtg-ping-probe -- Ping module for Multi Router Traffic Grapher (MRTG)
Package: wnpp Version: unavailable; reported 2003-04-11 Severity: wishlist * Package name: mrtg-ping-probe Version : 2.1.0 Upstream Author : Peter W. Osel <[EMAIL PROTECTED]> * URL : http://pwo.de/projects/mrtg/ * License : GPL version 2 Description : Ping module for Multi Router Traffic Grapher mrtg-ping-probe is a ping probe for MRTG 2.x. It is used to monitor the round trip time and packet loss to networked devices. MRTG uses its output to generate graphs visualizing minimum and maximum round trip times or packet loss. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux jon.ivt.com.au 2.4.18 #8 SMP Fri Oct 11 10:41:39 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C
Re: Topics for Debian conferences?
On Tue, 2003-04-15 at 01:44, Martin Schulze wrote: > With two Debian conferences ([1] [2]) taking place this year, I wonder > which topics other developers would like to see covered by the talks > and/or workshops held within. Although it hasn't yet been announced, there's also the Debian Mini-Conf at LCA2004 next January, for which I'll be organising some speakers. That makes me very interested in responses to this question, so please... > (These events in particular should be discussed on the > debian-events-eu list and not on debian-devel.) ...also CC me on any responses that don't go to debian-devel. Cheers Jonathan signature.asc Description: This is a digitally signed message part
Re: i386 compatibility & libstdc++
On Mon, 2003-04-28 at 08:45, José Luis Tallón wrote: > At 12:52 27/04/2003 -0400, you wrote: > >Please explain how I can get a similar system, running on a similar > >amount of power, and with no moving parts (i.e., no fans) using, even a > >P-II. > > Hey! Where did you get that from? > I'd love to have one of those ( specially if they came in a 19" 1U form > factor or similar !!! ) Rack mount? These sorts of things are usually about the size of a pack of playing cards, and aren't intended for use as a stand-alone machine or server: they're often used as embedded systems for industrial monitoring and control, etc. However, even at this level use of the i386 arch is diminishing rapidly, and most of the PC104 etc cards you see around the place are at least 486 or better. My company set up some industrial monitoring units a couple of years ago for a client and we used AMD chips running a very minimal Debian, because the 386 options were just way too underpowered. So speaking as someone with a vested interest in maintaining Debian support for small scale embedded systems, even I wouldn't care if i386 was dropped (at least officially - as someone else noted, running unofficial i386 sources wouldn't be too hard if anyone cared enough to do it). At this point i486 seems to be the minimal ix86 arch worth maintaining, IMHO. Cheers Jonathan
Debian Miniconf3 @ LCA2004: be there!
The dates for LCA2004 in Adelaide (South Australia) have now been finalised, and the Amazing Touring Debian Miniconf Orchestra And Review is about to get underway all over again. There's much more to follow, but preliminary info is online at www.debconf.org/miniconf3/ As with previous events, the Debian Miniconf is being run as a prelude to Linux Conf Australia (lca2004.linux.org.au). Anyone who registers for LCA is welcome to come along and spend a couple of extra days hanging out with fellow Debianites. The last Miniconf was great fun and showed how strongly Debian is represented among very technical Linux users, with fully a third of the attendees at LCA also turning up for the Debian Miniconf! A survey at LCA showed Debian was by far the dominant distro, with RedHat a distant second much to Alan Cox's dismay. So if you can possibly make it to Adelaide next January, do it. You won't regret it. Also, while I've already got a couple of speakers lined up I'm going to need quite a few more, so if you've got an idea for a presentation just pop along to www.debconf.org/miniconf3/cfp/ and submit a paper proposal. See you there! Jonathan
