Mopac - public domain
Before I put any effort into this, is anyone familiar with this law? Is it the same as NASA's NQS that became Cray NQS (commercial), Cern NQS (free?), GNQS (GPL), ... ? Mopac is one of the few free computational chemistry packages, and already has an rpm. PROGRAM MOPAC C C Notice of Public Domain nature of MOPAC C C 'This computer program is a work of the United States C Government and as such is not subject to protection by C copyright (17 U.S.C. # 105.) Any person who fraudulently C places a copyright notice or does any other act contrary C to the provisions of 17 U.S. Code 506(c) shall be subject C to the penalties provided therein. This notice shall not C be altered or removed from this software and is to be on C all reproductions.' -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Perl LWP method for dselect
I'm working on an LWP method for dselect. Current code is available at http://biocomp.anu.edu.au/~dld/debian/dpkg-http_0.1_all.deb The method can use any URL supported by LWP. Proxies can be set using ftp_proxy=http://wwwcache and http_proxy=... Multiple sites can be specified during Access setup (main archive, non-US archive, local archives, bo-updates, ...). The Packages files are downloaded using mirror(), so if the remote site hasn't changed, the Update function should return quickly. For the moment, I'm using the standard MIME-Base64 and libwww-perl perl modules (/usr/local/site_perl/...). I'm expecting the Debian modules to be functional soon (libwww-perl is a bit behind, and mime-base64 is m68k only). Yes, I know deity will be out soon, but we're paying $0.19/megabyte here, and caching helps. -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Perl LWP method for dselect
On Tue, 6 Jan 1998, Jason Gunthorpe wrote: > I would be very interested in hearing your experiances with using HTTP for > downloading .debs and the Packages file. I was hoping to use it as the > prefered method with deity. > Not much experience yet, as the code is less than a day old and there are no HTTP accessible mirrors yet (prod prod). I just downloaded some files from nonus.debian.org through the cache at high speed, so they do cache locally, even when the source is ftp. HTTP should cache more reliably (using If-Modified-Since GETs) rather than the heuristics of an ftp cache. HTTP/1.0 doesn't support partial retrieves (unlike ftp which can continue an interrupted download), but HTTP/1.1 does. I suspect we'll get better cache hit rates if everyone in Australia [the world?] uses the same sites (ftp.debian.org.au and nonus.debian.org), rather than everyone picking a nearby site. This way the caches will be more likely to hold a local copy. Most universities here are in the same cache heirachy - so using common remote URL's will be cheaper than using dispersed interstate URLs. I don't think the smaller ISP's are as organized (judging by their volume limits), but the larger ones may be. More sophisticated hashing (HTTP/1.1?) in the caches might make this all irrelevant. -Drake -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: package ordering in dpkg methods (was Re: Distribution ordering)
On 3 Apr 1998, Adam P. Harris wrote: > While you're thinking about ordering, have you thought about > integration Manoj's pkg-order into dpkg-http in order to provide more > reasonable unpack/config/remove ordering to dpkg-http? Would this be > extremely difficult to do? Do you need volunteers? I thought about it, but with the code freeze coming up I didn't have time to implement it, so I went back to plain-dselect style (dis)ordering. I'd have had to implement a lot more in dpkg-http, and even if I succeeded in time, it wouldn't have had any testing. The effort is probably better spent enhancing and testing apt. dpkg-http was a stopgap effort on my part to make use of our local webcache, and be able to access both US and non-US archives at the same time. > > Another question, somewhat related. How suitable is dpkg-http for use > either installing a fresh system (only base packages from the floppies > installed) or upgrading bo to hamm? I wonder, since it uses > libwwwperl. More code would have to be placed on the install floppies, but not all of libwwwperl. Someone would have to figure out which additional files from the perl, libnet-perl, and libwww-perl packages are required. libmd5-perl is in the dependency chain, but no files from it are actually used. These files would then have to be transfered to the perl-base package (I think). If you want to do this, you should probably check with the install floppy team and see if they'll add it. Upgrading from bo to hamm probably won't work, but is slightly safer than dpkg-ftp. It [should] warn of a predependency and abort, suggesting you install that package by hand (dpkg -i). If no predependencies exist, the selected .debs are downloaded, and dpkg -iGROEB is run on the download directory. -Drake -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another Linux distribution! :-)
On 1 May 1998, Jim Pick wrote: > I'd like to see more people announce that they want to develop their > own "subset" Linux distributions based on Debian. I'd be willing to > collaborate on tools to make this easier. Interesting. I'm starting up an ISP with a Debian focus, and planning to produce configuration-packages which will be added into the local Debian mirror, producing a (barely) derivative Linux distribution. I suspect many consultants and ISPs will begin doing this. I worry about name collisions in real derivatives though. We may need some new policies with respect to derivatives, so we avoid clashes. Off the top of my head: 1) Derivatives are allocated a subdirectory in /opt by Debian. 2) Derivatives should place files only in /opt. Links into the main /usr/bin directories may be made via alternatives and diversions, or perhaps we'll need a third method to manage the merge (adding directories to the default environment seems second-class, and will complicate things for the derivative-users). 3) Derivative package names should start with "[derivative]-". We'll promise not to produce any packages that start with registered derivative names. Package sources that are easy to redirect to /opt would also be useful for producing .debs for non-Debian systems. It would be great to have /opt/debian on Irix (I'm always slipping behind keeping the free software up-to-date on it). Of coure, derivatives would be free to ignore any guidelines. They just wouldn't get much sympathy when things broke. :) > The Debian distribution "proper" may never have more market share than > the commercial distributions such as Red Hat, Caldera, and SuSe. > However, it is entirely possible that derivative subset distributions > of Debian could dominate the Linux marketplace (especially given the > technical superiority of Debian). Maybe. I suspect they'll be niche markets mostly, as the mainstream Debian is such a moving target, and will likely be ahead of a derivative in most applications. It just wouldn't have the focus. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another Linux distribution! :-)
On 2 May 1998, Jim Pick wrote: > As far as people developing local packages to add on to Debian (which > is not really what I am planning) - I don't think additional policy is > needed for that, because they are "local" packages, so it is a matter > of "local" policy. Yep, but it'd be nice if there were guidelines on how to keep local packages out of the way of upstream debian packages. I recently had a collision between amber (a huge proprietary molecular modelling package I packaged a year ago) and an update of debianutils. Both had which.1.gz manpages, and with force-overwrite off debianutils wouldn't install. The solution was to recompile the amber package of course (since it was the trespasser), but it was a major chore. I should have compiled the amber package to place everything in /opt/drake/ or something, but there's little support for adding directories to the binary, manpage, and library search paths. If anyone creates a (completely different) package named amber I'll have to rename this one so it doesn't get squashed. -Drake -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-http and proxy cache
On Tue, May 05, 1998 at 08:25:44PM +0200, [EMAIL PROTECTED] wrote: > > i have squid cache > i have dpkg-http > > there was a time, when it worked. i could do [U]pdate in dselect, and he > used the version of Packages.gz in the Cache. > i can check that he uses the cache, because if i stop the cache, he fails. > i can check, that the cache caches the file with Netscape. > > but i do not know, why dpkg-http doesn't take the cached version ! It's probably a result of: dpkg-http (0.13) unstable; urgency=low * Added Cache-Control headers to make Packages.gz very current (max_age=0) and *.deb very cachable (max_stale=1 year) Starting with 0.13, dpkg-http requests the upstream site to compare the age of the Packages.gz file, and download a new one only if necessary. ftp doesn't handle dates very gracefully, and squid may be downloading a new copy even when unnecessary. Some possible fixes: 1) configure squid to hold onto stale objects longer. (wrong) 2) point your squid at your ISP's web cache, and let them do the download every time. (somebody else's problem) 3) modify dpkg-http to set different Cache-Control values. (wrong) 4) modify squid/ftpget to support timestamps on ftp sites. (right. Hard.) 5) Modify LWP (used by dpkg-http) to handle If-Modified-Since gets from an ftp site. Stop using squid with dpkg-http. (right. hard.) 6) Use an http: mirror and avoid the problem. On the other hand, Packages.gz does change frequently, and new versions should be downloaded when available. There's no cure if this is the problem. Take a look at /var/log/squid/access.log to see exactly what squid did about each request. -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Non-interactive install proposal
I was reading an rpm vs. dpkg, interactive vs non-interactive thread on debian-private (?) when I had the following idea. What happens to a typical postinst script if you kill it when it tries to read from stdin? apt, dselect, or dpkg could have a non-interactive mode. When attempting to install non-interactively, all postinst scripts are run with either /dev/null or a pipe on stdin. If the postinst attempts to read from stdin, the install utility kills it. This would leave the package in an unconfigured state for later interactive configuration. Out of 433 packages installed on my local system, only 45 have "read" in the postinst script. None of the examples I looked at appeared to need any changes to support kill-on-read, the package would just be left unconfigured. Many of the reads are optional, and not issued on upgrade. It should be much simpler to add one feature to dpkg than to learn, write, test, and debug 45-2000 new linuxconf install scripts. install-mime and config-file handling would probably also need some changes. -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-interactive install proposal
On Tue, Jun 02, 1998 at 09:48:46PM -0500, Manoj Srivastava wrote: > > What is the benefit of keeping packages in an unconfigured > state? It's a reminder to me that I need to configure this package still. > This shall certainly play havoc with large scale upgrades, > when latter packages require earlier packages to be configured. No worse than the current situation. There aren't that many Predepends at the moment. For instance, I unpack mesa dpkg --unpack -B mesag2_2.6-4.deb Preparing to replace mesag2 2.6-3 (using mesag2_2.6-4.deb) ... Unpacking replacement mesag2 ... dpkg --audit mesag2 A 3-D graphics library which uses the OpenGL API [libc6]. dpkg --status xlockmore-gl Status: install ok installed Depends: libc6, mesag2 (>= 2.6), xlib6g (>= 3.3-5), xpm4g (>= 3.4j-0) xlockmore-gl didn't deconfigure. It still works. Now perhaps xlockmore-gl *should* be marked as unconfigured, but it currently isn't. If mesag2 asked a question (it doesn't) and were killed, it could still meet other package's dependency requirements (the library is present to link against). mesag2 just can't meet a Predependency. > Why is the prospect of asking the questions a priori or an > interactive configuraion supposedly so vastly inferior? It's mostly a question of when they get asked. At the moment, all packages are configured at once. During a major upgrade, 90% of packages configure without human intervention. The remaining 10% are scattered among them, resulting in about 90% wasted time waiting for prompts. Emacs and TeX in particular take a considerable amount of time to configure, but don't usually ask questions. Under apt, the interactive stage will be even longer, as you have the unpacking and possibly download times mixed in with the configure time. It will be an even longer wait between questions. An alternative is to configure the 90% of packages that don't ask questions immediately, and configure the remaining 10% at your convenience. And file wishlist items against the informational pauses.. > Has anyone actually tried upgrading severl hundred packages at > a time? Yes, last night. I'd have gone home an hour earlier if I could have left the questioning packages in an unconfigured state. > run, and a study of what happens to the install when packages are > left unconfigured. This happens to me frequently under dselect. I'll start a machine upgrading and leave for a while, get busy, and not check the window for a day. Most times the user (or me) doesn't even know their system is halfway through an upgrade with 90 packages left unconfigured, because they've all unpacked and the first one is asking a question. I'd like the option of ignoring that question until later and having the rest configure themselves. For a compute farm, I'd definitely prefer to eliminate as many questions as possible, but when a question does arise, I'm probably doing a non-interactive install anyway (in an iconified window or something), and would rather it continue with easier packages and ask me again later. -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternate versions of the same shared library?
On Wed, Sep 22, 1999 at 12:36:17AM -0400, Camm Maguire wrote: > Greetings! Is there any way to maintain alternate versions of the > same shared library on a Debian system? (i.e. same soname) One can > have two packages which conflict with each other, but I was thinking > about some run-time switching functionality, like in the > 'alternatives' system, so that one could choose between an > experimental but fast shared lib, and the trusted but slower one, at > runtime. I've tried several things, but lintian disallows most of them. One way to do this is to include a wrapper script with your alternate-library version and place the libs in a package-specific directory. I use the following script under Irix to replace the GLX-dependent libraries with bare-X11 Mesa equivalents when running tools to non-GLX platforms: mesa #!/bin/sh export _RLD_LIST _RLD64_LIST _RLDN32_LIST _RLD_LIST=/usr/lib/libm.so:/usr/local/Mesa/lib/libGL.so:DEFAULT _RLD64_LIST=/usr/lib64/libm.so:/usr/local/Mesa/lib64/libGL.so:DEFAULT _RLDN32_LIST=/usr/lib32/libm.so:/usr/local/Mesa/lib32/libGL.so:DEFAULT exec $* From man ld.so the Linux equivalents would be LD_LIBRARY_PATH and LD_AOUT_LIBRARY_PATH. LD_PRELOAD could also be used to replace just a few routines. The /usr/lib/lib*.so.N could then be placed under alternatives control if the maintainers all cooperated, with the alternatives available in the wrapped environments. This is for libblas?
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 04:31:05AM -0500, Francois Gurin wrote:
>
> Minimun hassle/inconvenience is mutually exclusive of minimum harm.
> Looking at the example set forth by some of the other distributions
> (and more than a few operating systems), the reduced hassle of
> installation and administration is traded for security (which I
> hope most people will agree is harmful).
>
One way to minimize the harm of unintentionally installed or
misconfigured daemons would be to add a default ipchain/ipfwadm policy
rejecting all TCP SYN (incoming initialization) and non-DNS UDP packets
except those from localhost. Daemon maintainers could then add commented
out or localhost-only examples in their init.d scripts, which could be
modified by the sysadmin to their local policies. The brave could answer no
in netbase's postinst to a default deny policy. The DNS rule begs to be
tightened up. Non-IP daemons (netatalk) are outside the scope of an IP
firewall, but maybe netfilter will have a cure for that.
I'd prefer to just remove the Conflicts: and allow the daemons to race for
the service number. It can be very useful to run different daemons on
different aliases, ports, or interfaces. Alternatively some daemons could
default to unique numbers (eg. squid/junkbuster), requiring sysadmin
intervention to reconfigure if a well-known port was prefered.
/etc/init.d/daemon
--
case "$1" in
start)
# start http daemon here
# if [ -e /proc/net/ip_fwchains ]; then
# ipchains -I input 1 -j ACCEPT -p tcp -d 0/0 http
# elif [ -e /proc/net/ip_input ]; then
# ipfwadm -I -i accept -P tcp -D 0/0 http
# fi
# ;;
stop)
# if [ -e /proc/net/ip_fwchains ]; then
# ipchains -D input -j ACCEPT -p tcp -d 0/0 http
# elif [ -e /proc/net/ip_input ]; then
# ipfwadm -D -i accept -P tcp -D 0/0 http
# fi
# stop http daemon here
;;
esac
/etc/init.d/network
---
# comment these out if you don't want to self firewall
if [ -e /proc/net/ip_fwchains ]; then
ipchains -A input -j ACCEPT -s localhost
ipchains -A input -j ACCEPT -s ${IPADDR}
ipchains -A input -j ACCEPT -p icmp
ipchains -A input -j ACCEPT -p tcp -d ${IPADDR} \! -y
ipchains -A input -j ACCEPT -p udp -d ${IPADDR} -s 0.0.0.0/0 domain -l
ipchains -A input -j DENY -l
elif [ -e /proc/net/ip_input ]; then
ipfwadm -I -a accept -S localhost
ipfwadm -I -a accept -S ${IPADDR}
ipfwadm -I -a accept -P icmp
ipfwadm -I -a accept -P tcp -D ${IPADDR} -k
ipfwadm -I -a accept -P udp -D ${IPADDR} domain -o
ipfwadm -I -a deny -o
fi
/etc/ppp/ /etc/pcmcia/ ip-(up|down).d/...
# need similar rules here too with new IP numbers
Package giveaway, will sponsor if necessary.
I'm just looking to create some free time to put into other projects. If no one wants these I'll just keep going, but updates will be seldom. I'll sponsor new maintainers of these until they get their upload privs. rtf2latex - simple C program. New upstream waiting at CTAN. Excellent first package. empire-ptkei - Surely there must be another empire fanatic out there? I've never actually played with this client, nor do I know python. Newer upstream available. gtkglareamm - C++ wrapper library around the GtkGLArea widget. Not used by any binaries at present, so it would be a good first lib package. gtkglarea - I'm still using this, but if someone wants to lighten my load it could go with gtkglareamm. -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet
Re: Danger Will Robinson! Danger!
On Sun, Mar 12, 2000 at 06:27:41PM +0100, Marcus Brinkmann wrote: > > Nothing wrong about that, if we don't go a long way to make additional > changes in the various admin packages (isdn, pcmcia comes to mind). > > I was always a supporter of the latest and greatest kernel as a binary > package in extra. > If we look at why the latest kernel should go in, it's most likely for the new hardware support, not the other new features. New hardware support seems to be a reasonable justification for allowing new versions into stable/frozen if there is also an older version there for the rest of us to fall back on in case it's a lemon.
Re: Potato now stable
On Mon, Aug 14, 2000 at 10:55:59PM -0600, Jason Gunthorpe wrote: > > Clearly the desired effect of all meta-packages is to provide the user > with a single node to manipulate and view a group of packages. They should > have special properties in any UI, you should be able to view and > manipulate their grouped packages. Idillicly the grouping would have > priorities of packages (ie -python doesn't need to install every freaking > package, but some are definately critical) and the ability to track and > optionally install new packages added to the group, remove the whole > group, etc. > Under the Irix packaging system (quite nice UI except that it has to handle Irix packages..) packages exist in a hierarchy, with lowest level packages quite fine grained. For example: I fw_bzip2 02/28/2000 bzip2-0.9.0c Compress/decompress files I fw_bzip2.man 02/28/2000 bzip2-0.9.0c man pages I fw_bzip2.man.bzip2 02/28/2000 bzip2-0.9.0c man pages I fw_bzip2.man.info02/28/2000 bzip2-0.9.0c info pages I fw_bzip2.man.relnotes 02/28/2000 bzip2-0.9.0c Release Notes I fw_bzip2.sw 02/28/2000 bzip2-0.9.0c execution only env I fw_bzip2.sw.bzip202/28/2000 bzip2-0.9.0c execution only env I fw_bzip2.sw.hdr 02/28/2000 bzip2-0.9.0c header files I fw_bzip2.sw.lib 02/28/2000 bzip2-0.9.0c shared libraries I fw_bzip2.sw6402/28/2000 bzip2-0.9.0c 64-bit execution only env I fw_bzip2.sw64.lib02/28/2000 bzip2-0.9.0c 64-bit shared libs Some of these are marked for default installation if the top level (fw_bzip2) is selected. Others are non-default. Still others (the sw64's) are only installed by default if the hardware they're being installed on is capable of running them. You can unfold the selection and mark components (full fledged packages themselves) for install if you really want to, but most times the defaults are fine. You can use wildcards for instance to delete all info page packages without going beyond the package system. We could probably use something similar to handle localization and multiple architectures. Many of our packages are already hierarchical ( x-dev, x-doc, libx, ...), but not in a formal way that the user interface can use to shorten the list a user sees. -Drake
Re: Potato now stable
On Mon, Aug 14, 2000 at 11:08:59PM -0700, Joey Hess wrote:
>
> Perhaps these sub-packages would be additional files in the ar file.
> Perhaps those files themselves should be in .deb format? Then we have
> sub package nesting and meta-data too
>
> > Of course this is all just off hand... :>
>
> Same.
Irix does that with it's packages: multiple micropackages in one file.
Actually, you can also get jumbo packages, just tarballs ("tardist") with
lots of packages inside them, each package with lots of micropackages.
Beyond the modifications to the .deb format we'd also need to modify the
way dpkg stores package information. ls /var/lib/dpkg/info just took 30
seconds on my machine. Each package has several files in there. At 4K
and 1 inode apiece, the dpkg overhead is even higher than the overhead for
microdebs all in separate files.
Tasks wouldn't be well served by jumbo packages - there'd still have to
be some support for a hierarchy beyond the .deb layer, so the hierarchy
support should probably not be related to the actual file handling at all.
Maybe .debs could simply contain other, simpler .debs. That should be
fairly easy to unpack with existing dpkg functions (whatever extracts
streams from the ar format), and would allow an infinitely deep and
arbitrarily broken-into-separate-files division. Signed .debs are probably
an issue.
-Drake
Re: package pool and big Packages.gz file
On Sun, Jan 07, 2001 at 11:43:39AM +1100, Sam Couter wrote: > > A deb plugin would be better. :) One problem with a deb plugin is that .debs are signed in compressed form. gzip isn't guaranteed to produce the same compressed file from identical uncompressed files on different architectures and releases. Varying the compression flags can also change the compressed file. -Drake
Re: Including Mysql in the Main Distrubation
> Meskes, Michael <[EMAIL PROTECTED]> wrote: > > Please tell me what exactly you like more about mysql in comparison to > > PostgreSQL which really is DFSG free. > On Sat, Jun 13, 1998 at 07:55:46PM -0500, Erv Walter wrote: > 1) Speed > 2) While neither completely implements SQL92 and newer standards, the > portion that mysql implements is more useful for my application than > the portion that PostgreSQL implements. > > Erv Walter In some tests I ran, I found that postgres was only capable of 4 transactions per second in the default configuration. The speed could be increased to 80 transactions/sec if you were willing to turn off the automatic disk syncing. It is not clear from the mysql documentation whether it syncs the disk after each transaction, so mysql may only be comparable to the unsync'd postgres speed. With an fsync after each transaction, Postgres is limited by disk seek times. You might be able to speed it up by putting each file in the database on separate (fast) disks. /etc/postgresql/postmaster.init --- PGFSYNC=no -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Including Mysql in the Main Distrubation
On Tue, Jun 16, 1998 at 11:03:22AM +0200, Michael Meskes wrote: > No DBMS syncy after each transaction. Most systems do it every 30 seconds. > Support for that will be added to Postgres later on. And with 80 TPS I think /usr/doc/postgresql-doc/FAQ.gz -- 2.11) How do I tune the database engine for better performance? There are several things that can be done. You can disable fsync() by starting the postmaster with a '-o -F' option. This will prevent fsync()'s from flushing to disk after every transaction. I haven't examined the code, but postgres was seeking all over the disk with fsync() on (the default), and only getting 4 transactions/sec inserting a row into a table (no indices or anything). Performance rose a factor of 20 after turning fsync()s off. msql and mysql don't appear to have full transaction support, so I didn't consider them "real" databases. They would be sufficient for the task I was performing (moving squid log entries into a database), but since postgres could be sped up I didn't see a need to learn another DB. There has been a lot of criticism of Postgres' speed. Perhaps the fsync() warning should be made more prominent (in README.Debian, or even the package description). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to upload (package) Empire-lafe and empire-hub
I intend to upload shortly an empire (rec.games.empire) client and multiplexer I wrote a few years ago. They are being licensed under the GPL. Time permitting I may upload documentation from the server, which is being relicensed under the GPL, and pei (another empire client I had a hand in). -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet
Re: Bug Report?
d) Try using NFS. This slows down the i/o bound resource hog enough to leave the machine usable for interactive tasks. Yes it's ugly, but scheduling in 2.0 is suboptimal, and nice doesn't have much effect on i/o, only CPU. An extra disk dedicated to the i/o hog would probably be better than an SMP for this problem. -Drake
Re: Which PGP?
On Thu, Oct 15, 1998 at 03:34:54PM -0700, Joseph Carter wrote: > On Thu, Oct 15, 1998 at 03:08:46PM +0100, Dave Swegen wrote: > > Out of curiosity, which version of PGP is the debian de facto standard. > > I'm currently using v5, but I've seen a number of people use 2.6... > > The Debian standard is RSA/IDEA (2.6.x compatible) keys, though Debian is > slowly adjusting to include gpg (5.x compatible plus more and it's free, > with the ability to add RSA and IDEA as modules if you don't mind that > they're non-free due to patent BS) In case anyone was expecting me to upload these modules, the IDEA module is strongly discouraged by the gpg author (patented in at least Japan, US, and Europe until 2011), and I've decided for immigration reasons not to get involved in crypto packages. The RSA module could be packaged separately for compatibility with the existing PGP keyring, IDEA isn't necessary. The modules are easy to compile yourself, see the /usr/doc/gnupg for ftp site.
Need Povray 3.1 Maintainer
Povray 3.1 (a raytracer) has been released, and I've had a request to package it. Unfortunately, 3.1 deleted experimental features in 3.0 (halos), and does not have the patches I applied to the 3.0 codebase (PVM, isosurfaces). Some of the new 3.1 features are already in the patched Debian 3.0 package (macros). What I think we should do is create new Povray 3.1 packages, but keep the 3.0 packages as well. The announcement on povray.org suggests this (keeping the 3.0 binaries around for legacy scenes). update-alternatives entries already exist for the povray binaries, as there are 2 different povray 3.0 binaries (a bare one and a feature-laden one). I don't need any of the new features in 3.1, so I won't be using that version for some time (until isosurfaces and PVM support in 3.1 exist). We need another maintainer for 3.1. Anyone want this popular non-DFSG (source available) package? I plan to keep the 3.0 package. -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet
Re: PROPOSAL: preparation for freezes, release coordination
In linux.debian.devel, you wrote: > >I hope to fix this in the long run by having more frequent releases, >so that maintainers are less anxious to get their packages in the >upcoming release. In the short term... let's just hope :-) > How about creating woody at the freeze announcement instead of at the actual freeze? Then you could rail at new-package uploaders and they'd have no excuses, plus we could compete to be the first uploader.. It would also give the archive maintainers a chance to spread out their workload: freeze would be independent of creating the new distribution area. -Drake
