Re: Quote: Debian and Democracy at Advocato.org

[Vince Mulhollon]

Daniel Ruoso <[EMAIL PROTECTED]> writes:

> I think this should be clearly discussed.
> Original link at:
> http://www.advogato.org/article/716.html
>
> 
> Debian and Democracy
> Posted 7 Oct 2003 by exa (Master)
>
> me "you need to get 5 sponsors blah blah" I found 4, but they scared out
> every 5th one! I was at a later time told that it was a way of rejecting

I will admit I was one of the four sponsors, based on my theory that
the best way to make someone be nice, is to be nice to them, as what
goes around comes around.  Golden rule and all that.

In retrospect, perhaps that technique has not been entirely successful.

Anyway, I'd like to publically say no one ever tried to "scare me out" 
or any B.S. like that.  I find that claim Very Very Hard to believe.

Re: [RFD] optimized versions of openssl

[Vince Mulhollon]

On 09/04/2002 08:51:02 AM [EMAIL PROTECTED] (Dagfinn Ilmari Mannsåker)
wrote:

>> division and multiplication. Recompiling libssl with SPARCv8
>> optimizations speeds up logging in with ssh on an Ultra1 (SPARCv9) by
>> a factor of 6, IIRC. See the debian-sparc archives for details.

This is quite possibly the first time during the eternal debate of
processor specific optimizations on debian-devel, that someone has ever
posted real measured numbers, showing greater than single digit percentage
improvements for optimization.  That changes the debate.

In this individual case, I'd agree with you, it would be a great idea for
someone to create a libssl-*-sparc8 package.

Re: [RFD] optimized versions of openssl

[Vince Mulhollon]

On 09/04/2002 08:26:19 AM "Vince Mulhollon" wrote:

>> I think I can safely speak for everyone on debian-devel as per this:
>>
>> 1) The difference in overall speed is small, and rarely publically
>> reported.
>> The 1% gain is individually considered either vital must-have, or
>> worthless.
>> 2) The archive disk space required expands.
>> This is individually considered either intolerably huge or not worth
>> mentioning.
>> 3) In a question of "good taste" like this, one developer can't force
>> another developer to either do this or not do this.
>> If you want to do this, no one can stop you.

I apologize for following up to my own response but I forgot one important
one:

4) It makes troubleshooting "more exciting".
Does user A's SSL not work while user B's works OK?
What if user A is using -i386 while user B is using -tsc586 and the package
maintainer is using -k6?
Some individuals don't consider this a problem, some consider this a
crisis.

Re: [RFD] optimized versions of openssl

[Vince Mulhollon]

On 09/04/2002 08:12:50 AM Christoph Martin wrote:
>> etc. This has the benefit that it works on every i386 compatible
>> processor but it is slow on processors where there could be a lot of
>> optimisation.

Oh not this thread again!
Processor specific optimizations for i386 is debated approx every 2 months
on debian-devel, plus or minus other distributions PR campaigns.

>> Do we have a general opinion or policy on optimized library versions?

I think I can safely speak for everyone on debian-devel as per this:

1) The difference in overall speed is small, and rarely publically
reported.
The 1% gain is individually considered either vital must-have, or
worthless.
2) The archive disk space required expands.
This is individually considered either intolerably huge or not worth
mentioning.
3) In a question of "good taste" like this, one developer can't force
another developer to either do this or not do this.
If you want to do this, no one can stop you.

>> Do we have modells for this?

The kernel-image packages.

>> What do you think?

This eternal flamewar is located somewhere in:
http://lists.debian.org archives

Re: Should we customize apps for a common "debian-look"?

[Vince Mulhollon]

On 08/30/2002 10:34:18 AM Mateusz Papiernik wrote:
>> > If I like the look of ratpoison, and someone themes it to look like
W95,
>> > I'm not going to like it when I'm "surprised" with Debian's themed
version.
>> so maybe debconf should ask (when installing windowmanager) which theme
>> do you like - original from wm, or this debian theme ?

That is an excellent idea.
However, a new can of worms opens.

If you thought vi vs emacs was a good flame-fest, how will we come up with
an "artistic standard" that all will agree to?
Redhat has it easy, boss says "either you like the theme I pick or you find
new job"

I predict this will get just about as far as requiring emacs to start up in
VI emulation mode, "to make it more consistent for the users".

For example:
I can't stand KDE's "redmond" theme, and I'm quite a fan of the B-II window
decorations and the QT-SGI style.
Then again, I'm weird enough to keep my panel on the right side of the
screen (next to my konsole scrollbars) which has the annoying side effect
of making all the "ticks" on the K menu point the wrong direction when I
open the K menu.  And I like running xplanet -sun in the root.

Re: Should we customize apps for a common "debian-look"?

[Vince Mulhollon]

On 08/30/2002 08:43:32 AM Erich Schubert wrote:
>> It's one of the things Apple proved: desktop and apps that look smooth
>> do make their users feel comfortable with them ;)

No, they proved if you do not give users a choice of "nothing" or "Apple's
theme" the users prefer to use their theme rather than an abacus or count
on their fingers.

The problem is, I experiment with and chose window managers by going to the
website and look at the pretty screenshots.
If I like the screenshot, then it's a quick apt-get install somethingwm.  I
expect to get what I saw on upstream's screenshots.
If I like the look of ratpoison, and someone themes it to look like W95,
I'm not going to like it when I'm "surprised" with Debian's themed version.

This is different from integrating the Debian menu system into the WM,
because that is a utility thing that does not damage the artistic-ness of
the WM.
For example, modifying a work of art so the frame can hang up using "Coca
Cola" brand picture hanging nails or sticking a little plaque on the frame
saying "this painting donated to the museum by Coca Cola"  is perfectly
acceptable because it (more or less) doesn't damage the artistic impact the
artist tried to make.
However, if Coke painted over the "Mona Lisa" so she was drinking a coke,
before they donated it to the museum, that would be totally hideous from an
artistic integrity standpoint, immoral even if it is perfectly legal.

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Vince Mulhollon]

On 08/30/2002 06:42:48 AM Richard Atterer wrote:
>> As usual Heise got it right:
>>  (German).

Or, for you English speakers,
http://www.heise.de/english/newsticker/data/jk-28.08.02-008/

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Vince Mulhollon]

On 08/29/2002 02:45:01 PM Michael Cardenas wrote:
>> can you please post the "company statement" that is refferred here?

Per this web page, http://www.mp3licensing.com/royalty/software.html,  it
will cost Debian $50K per program or $0.75 per apt-get (?)
There is no exception under any circumstances.

Oddly enough, regarding streaming, per
http://www.mp3licensing.com/royalty/emd.html
Note: No license is needed for private, non-commercial activities (e.g.,
home-entertainment, receiving broadcasts and creating a personal music
library), not generating revenue or other consideration of any kind or for
entities with an annual gross revenue less than US$ 100 000.00.
So, it costs money to make the SW to encode or decode mp3, but in certain
circumstances it doesn't cost $3K per year to stream mp3.
A streamer would still be in non-free because the license discriminates
against various user activities, such as commercial activities.

So, per one PR flack whom updates their web page, there is no exception.
Per another PR flack, there is "no change".
What is the true license?  Whom knows.

If I can't figure it out, I'm not going to flame slashdot for not figuring
it out either.

Re: Kindly Get Back To Me Please

[Vince Mulhollon]

Why hello, republic of Angola.  I got your email address off your website
http://www.angola.org/

Here's a deal for you, your military can track down this rebel and kill
them, then we'll split the money.

Is that a good deal or what?  I'll even give you your share paid in
valuable "Enron" stock.

- Forwarded by Vince Mulhollon/Brookfield/Norlight on 04/12/2002 08:01
AM -

   
  "Sandra Savimbi"  
   
  <[EMAIL PROTECTED]To:   
debian-devel@lists.debian.org 
  .com>    cc:   (bcc: Vince 
Mulhollon/Brookfield/Norlight)
   Fax to:  
   
  04/12/2002 07:48 Subject:  Kindly Get Back To Me 
Please  
  AM
   
  Please respond to 
   
  nnengi_sam
   

   

   




ATTN:

This letter may come to you as a surprise due to the fact that we have not
yet met. The message could be strange but reel if you pay some attention to
it. I could have notified you about it at least for the sake of your
integrity. Please accept my sincere apologies. In bringing this message of
goodwill to you, I have to say that I have no intentions of causing you any
pains.

I am Ms. Nnengi savimbi, daughter of the late rebel leader Jonas savimbi of
Angola who was killed on the 22nd of febuary 2002 . I managed to get your
contact details through "The World Business Journal", a journal of the
Johannesburg Chamber of Commerce in South Africa in the time I was
desperately looking for a trustworthy person to assist me in this
confidential business.

my late father, Jonas savimbi  was able to deposit a large sum of money in
differnt banks in europe My father is presently death and the movement  of
his family members (including me) is restricted. We are forbidden to either
travel abroad or out of our localities. Presently, the US$8,500,000.00
EIGHT, MILLION, FIVE HUNDRED DOLLARS my father transfered  to Netherlands
is safe and is in a security firm. Before you can get access to it i have
to give you the password  I am  therefore soliciting your help to have this
money  transfered into your account.  before my government get wind of this
fund .You know my father was a rebel leader in Angola before his death  My
reason for  doing this is because it will be difficult for the  Angolan
government to trace my father's money to an individual's account,
especially when such an individual has no relationship ,I decided to keep
that money for my family use. At present the money is
kept in a Security Company in nertherland.

I am currently and temporarily living in Angola with my husband my brother
has a refugee status'in The Netherlands. Moreover the political climate in
Angola at the moment being so sensitive and unstable.With this password and
information I will send to you, and power of attorney to the security firm,
When you are ready i will give you the information needed before you can
get access to the fund you will then proceed to Netherlands where the
US$8,500,000.00 EIGHT, MILLION, FIVE HUNDRED DOLLARS will be given to you
as payment. Alternatively, you can have the fund  transferred into any
account that suits you.

Yours sincerely,

Nnengi Savimbi.


See Dave Matthews Band live or win a signed guitar
http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/splash.asp



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: About sponsoring non-free packages

[Vince Mulhollon]

On 01/14/2002 10:05:52 AM af_mara wrote:

>> Adrian Bunk <[EMAIL PROTECTED]> writes:
>> > It's clear that free software is better than non-free software but
please
>> > don't forget that you agreed that "We will support our users who
develop
>> > and run non-free software on Debian".
>>
>>   I'd like to remind that Debian does not support non-free software but
>>   _tolerates_ them.

I disagree with Jérôme Marant, with evidence supporting that disagreement
below:

http://www.debian.org/social_contract

1.   We will support our users who develop and run non-free software on
Debian, but we will never make the system depend on an item of non-free
software

Adrian could have made it clearer he was quoting the social contract as
opposed to stating his personal opinion.

Re: Student Looking for A Final Year Project

[Vince Mulhollon]

On 09/07/2001 09:21:27 PM Glenn McGrath wrote:
>> The command line arguments CVS use are truely original, which is a
really
>> really bad thing !
>>
>> :pserver:, :ext: mixed with environment variables crazy... what were
>> they thinking when they came up with that stuff, not simplicity thats
for
>> sure.

Agreed.  That was the entire point of the suggested project for that
student, encapsulate all the uglyness of CVS into either APT or DPKG or a
separate program.

Right now I can type something that vaguely resembles line noise into my
terminal to do what I'm proposing.  The goal of the student's project would
be to replace that uglyness with a nice smooth interface thats well
integrated with the rest of the Debian system, all well working
cooperatively with other developers.

Re: Student Looking for A Final Year Project

[Vince Mulhollon]

On 09/07/2001 11:20:42 AM Andrew Suffield wrote:

>> On Fri, Sep 07, 2001 at 10:13:50AM -0500, Vince Mulhollon wrote:
>> > Integrating CVS into Debian (as a core component, not just a package)
would
>> > be a long, complex, and rewarding project.
>>
>> But futile and misguided. CVS has whole swathes of fundamental flaws,
>> largely historical. Better to integrate with something similar to CVS

References?  Just curious what the huge problems are.  It fundamentally
seems to work, or at least I've not yet run into any road blocks.

I know CVS doesn't do binaries or compressed files very well, but for plain
text based config files or lists of installed packages, that's OK.

I would imagine the tool would store the state of installed packages in a
way very similar yet different from dpkg --get-selections | sort >  file
and then CVS commit the file.  I've been playing with that method in an
extremely manual way, but a smoothly integrated command or script would be
much less painful to use, and could have cool features added.  I haven't
run into any inherent CVS related issues while experimenting with this
method, and I'm curious if you've had bad experiences trying something
similar, etc.

Considering that the student wanted a good project, I'd think that
integrating this into the greater overall Debian system would be more
useful "real world project" with all kinds of legacy issues and social
interaction w/ other package developers, than the typical individualistic
small system end of year project.

I follow up to debian-devel, as several developers use CVS, and if there's
some big unpublicized fundamental weakness and flaws in CVS, I'm sure
others need to know, so please inform us.

Thanks!

Re: Student Looking for A Final Year Project

[Vince Mulhollon]

On 09/07/2001 09:45:35 AM "T.Pospisek's MailLists" wrote:

>> Add versioning to debian packet management. Something like:
>>
>> # apt-get install package
>> # # damn it broke my server again!!
>> # apt-get rewind package

I'd prefer something "like CVS" so I could roll back to milestones or back
to a specific date

"apt-get make my Debian system exactly like it was when it passed my
benchmark test, several upgrades ago"

"apt-get make my Debian system exactly like it was on May 13 2001"

"apt-get roll my system back to the CVS tag "potato""

Also, integrate all files tagged as conf-files into CVS
optionally/automatically.

"apt-get roll my httpd.conf back to last working version" etc.

Add comments / CVS tags / CVS userid so you can tell the difference between
a change a package upgrade tried to automatically make (and probably
screwed up) or a change a sysadmin manually made.  And add an easy to use
shortcut command to rollback any changes a package tried to make in it's
config, like "apt-get rewind conf package".

Don't forget the obligatory GUI interface (??)

Oh, and use the features of CVS so I can remotely secure CVS into a
machine, change stuff, and it'll automatically act based solely on the CVS
commit I make, without having to log in.  So, via remote CVS I could force
an "apt-get install" of any arbitrary package.

Integrating CVS into Debian (as a core component, not just a package) would
be a long, complex, and rewarding project.

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Vince Mulhollon]

On 09/04/2001 10:52:58 AM Gustavo Noronha Silva wrote:

>> Em Tue, 4 Sep 2001 10:08:15 -0500
>> "Vince Mulhollon" <[EMAIL PROTECTED]> escreveu:
>> > they mistakenly call it "automated", as if it's a computer generated
>> > translation like from babelfish...

>> the translator did nothing... it's a feature of the ddts...

I think of it like the bug reports from the "bug" package.  (I'm thinking
bug uses email submission, or maybe I'm thinking of a similar package)
True, in both cases a "program" sends the message.  However, in both cases
the email is generated by a person "filling in the blank", either bug
description or package description.

There was a person involved in each individual email, thus to me, it's not
automated.  To me, automated would be writing a Perl script to run the
entire Packages file thru a computer auto-translator like babelfish and
then submitting without any human editing...  That could be annoying.

>> > Someone whom speaks "BR" (Brazilian?) wrote translations for your
Debian
>> Brazillian Portuguese

>> > I've gotten similar emails from "IT"s (Italians? Information
>> > Technologists?) ...
>> italians =)

The emails should have a full language name instead of abbreviation.
It's hard enough for developers to figure out if the translation is "fair",
without having to guess if "ES" means Eastonian or Espanol.

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Vince Mulhollon]

On 09/04/2001 09:44:11 AM Adam Heath wrote:

>> On Tue, 4 Sep 2001 [EMAIL PROTECTED] wrote:
>>
>> > Hello
>> >
>> > This is only an automated notification mail from the ddts (Debian
Description
>> > Translation Server).
>>
>> As an automated mail, to which I have not request, I consider this spam.
>>
>> Please remove me, and all ways of contacting me, from your automated
lists.  I
>> do not take kindly to unwarranted spam mails.

Read the contents of the email.  It's a bug on their side.  It's not
automated at all, or at least no more than any mailling list software is
"automated".  It was generated by a person who knows a language that you
don't.  The translator presumably doesn't know English as well as us, thus
they mistakenly call it "automated", as if it's a computer generated
translation like from babelfish...

Someone whom speaks "BR" (Brazilian?) wrote translations for your Debian
package, so rather that send you a message in BR language (which you
probably can't read) you get the English form letter.  Overall, better to
get a form letter in a language you can read, than a personally written
email in a language you can't read.

I've gotten similar emails from "IT"s (Italians? Information
Technologists?) ...

They are nice guys, being nice to you and your Debian packages.  Please be
nice in return.  Treat it like a NMU, smile and say "thanks" and carry on
with life.

It's a new system so it's understandable that everyone doesn't know about
it.

Re: Giram: Request for removal

[Vince Mulhollon]

On 05/07/2001 02:03:33 PM Egon Willighagen wrote:

>> What about a Debian policy to remove packages for which alternatives are
>> available with same or similar functionality *and* for which development
has
>> stopped or almost stopped completely?

All you'll get is endless flamewars about "same or similar" and "stopped".

Personally, for my "Vince Special" Debian CDRoms, I'd like to toast about
seven of the eight vi clones, xemacs, all the "optimized" kernel-images,
original awk, and all the gnome stuff in favor of KDE, but I don't
realistically think my personal biases will have any effect, and I don't
think my personal biases should have any effect on the overall project...

If someone out there likes "Q" but I think it's not a good idea, all I can
do if try to talk them out of it, and thats the way it should be.

Need to clearly define who makes that decision, because obviously the
developers directly involved in the fight (and it will be a fight each
time) will be biased.

Also, that would be a major policy shift away from "if you care enough to
maintain it, we'll let it in if it's legal" to "we'll only let it in if the
cabal likes it".

Of course there is no cabal.

Re: Proposing task-debian

[Vince Mulhollon]

On 05/01/2001 12:40:24 PM roland wrote:

>> Vince Mulhollon wrote:
>> > From my poor memory, the "generally agreed best idea" is to setup two
>> > packages, vaguely like this:
>> >
>> > Package name: task-abc
>> > Conflicts: task-abc-remove
>> > Depends: abc, bcd, cde, def
>> >
>> > Package name: task-abc-remove
>> > Conflicts: task-abc, abc, bcd, cde, def
>>
>> Please, NO! This is a pretty ugly hack and there are better ways to do
>> this, e.g. the debfoster aproach. I don't agree at all with you that
>> this is the "generally agreed best idea". Rather the opposite.

Oh, I don't know if it's an ugly hack.  Think about it, theres one program
or system that handles conflicts and dependencies.  Why not rely on it?
Making multiple programs to do the same function (installing and removing
packages) is probably not the prettiest method.

As far as "generally agreed best idea" goes, I put it in quotes for a
reason.  As with all things Debian there is no way to make everyone happy.

Re: Proposing task-debian

[Vince Mulhollon]

On 05/01/2001 03:09:16 AM Sam Powers wrote:

>> While we're discussing what's wrong with task packages, I'd like to pick
on
>> them a little more:
>> Task packages make things like task-gnome-desktop very easy to install,
but
>> removing the packages which are installed can sometimes be really tough,
if
>> you just wanted to try out gnome, for example.
>> Perhaps task packages should be required to flag their dependencies for
>> removal in their prerm to ease removal of the entire package group.
(probably
>> a better name for this type of package..)
>> Any better ideas?

Been there, done that, noone cares enough.  Would take a policy change I
suppose, to enforce it.

>From my poor memory, the "generally agreed best idea" is to setup two
packages, vaguely like this:

Package name: task-abc
Conflicts: task-abc-remove
Depends: abc, bcd, cde, def

Package name: task-abc-remove
Conflicts: task-abc, abc, bcd, cde, def

>From that description you can probably figure out whats going on.

If someone cared enough to do that for all task packages, that would make
removal of tasks "simple".  I don't think this will happen soon, because I
get the feeling the the "powerusers" who would have to create the -remove
packages don't use task packages to begin with.  Making a sweeping
generalization, most people who have root don't install task packages, if
they want KDE they apt-get install koffice konquerer and let apt figure out
all the dependancies.  In other words they already know the names of the
tools they need, so they don't need a task package crutch.  Then I could
complain that the newbies that could benefit by the installation of
everything to do task-abc will probably not be able to figure out what's
installed by the task package or what in general is installed on their
system..

Ideally task-abc-remove would even remove itself once it's done.  That
would be hard, but it might be possible via a nasty combination of at,
cron, and who knows what else.

Other theories included enforcing the addition of a file in /usr/sbin, for
example:

# filename /usr/sbin/task-abc-remove
# This shell script cleans out task-abc
dpkg --remove abc
# you get the idea
dpkg --remove def
dpkg --remove task-abc
rm /usr/sbin/task-abc-remove

This is also somewhat tricky, as youd have to create
/usr/sbin/task-abc-remove as part of the postinst of task-abc.

Re: kernel-{image,headers} package bloat

[Vince Mulhollon]

On 04/30/2001 03:21:55 PM "Christopher C. Chimelis" wrote:

>> Basically, I can understand everyone's desires for a kernel that covers
>> their cases (SMP, UP, 686, 386, etc), but the bloat issue that initially

I can't understand that desire for such a small gain, but whatever.

>> this thread gets more and more Intel/AMD-centric, I'm beginning to
wonder
>> what the larger implications may be...

I would think an even scarier larger implication is that on my desktop
machines, it's not unusual to have less than 10% kernel utilization.  Thus
even in the wildest dreams, no level of "optimization" can have more than a
2% effect on overall CPU speed.  But what happens when people provide /
request / demand optimized versions of Gnome, KDE, and Apache for every
possible combination of optimization?  I'm sure an optimized libc would
have more impact that an optimized kernel.  I'm sure my webserver would
benefit far more from "optimized" Apache and Perl than it would from an
"optimized" kernel, based on crude observations of the "top" command.

The problem is not providing "optimized" versions of one "little" package,
the problem is opening the floodgates to recompiles of every package in
Debian with every possible combination of optimization.

In an example that is fairly silly, if I recompile the kernel for a machine
with a CPU that costs $300 (my processors are usually cheaper) and it gets
a 20% kernel performance boost (totally unrealistic daydream) and it
typically spends 10% of it's time in kernel space (probably less), that's
the equivalent of saving me $6 over the cost of just buying the next faster
processor.  Now compare $6 to the cost of the electricity to run the box,
or my salary to properly install and test the "optimized" kernel and I just
don't see the payoff.  Then there are the non-monetary costs, someone
spending time making 20 different compilations of the same package is not
spending time fixing bugs or playing Quake or drinking beer.

Or on my firewall and kiosk machines using $50 special computers, the
processor is probably worth $5 so I'd figure the optimizations save me 10
cents over the cost of upgrading the CPU to a faster one.

Re: Referring what kernel-images to build to the technical committee?

[Vince Mulhollon]

On 04/26/2001 09:59:13 AM Russell Coker wrote:

>> On Thursday 26 April 2001 16:38, Ilya Martynov wrote:
>> > RC> There is no need for a MTTR specific kernel.  MTTR is not really
>> > RC> needed as there is no software written which is unable to run
>> > RC> without it.  Our goal here should be compatibility with software.
>> > RC> MTTR can increase speed significantly in certain situations, but
>> > RC> there's lots of other ways of doing that for less effort which we
>> > RC> aren't supporting.  MTTR can allow you to work around broken
>> > RC> hardware.  But we can't provide enough kernels to support all
>> > RC> combinations of broken hardware (I am sure that I could find a
>> > RC> list of a dozen boolean options which are all needed to be in one
>> > RC> state or another for various broken hardware - we can't provide
>> > RC> 2^12 kernels).
>> >
>> > I think you are wrong about 'MTTR is not really needed'. One good
>> > example is aviplay (player for avi files). It perfomance is seriously
>> > affected by MTTR option. This fact is mentioned in its docs and I've
>> > seen myself *significant* difference in its perfomance when I've
>> > compiled kernel with MTTR option. Probably perfomance of simular
>> > programs will be affected too.
>>
>> I've played many AVI files without MTRR support.  It will still work,
just a
>> bit slower.  If programs won't run at all (as in the case of MMX and
3DNow!)
>> then we should compile different kernels.  If they just don't run as
fast
>> then we can let the users compile their own kernels.
>>
>> If you want maximum video speed you want to compile your own kernel with
AGP
>> and DRI support etc...

Naw, lets just quadruple the number of kernels we have so we can have:

1) kernel without AGP or DRI
2) kernel with AGP and no DRI
3) kernel without AGP with DRI
4) kernel with AGP and with DRI

For each of the 30 or so processor revisions that can be compiled for.

After all, if half a dozen kernels for the i386 "port" of debian is OK
instead of 1, what's wrong with quadrupling it again?  The same arguements
apply to that case.

Eventually there will be so many kernels that newbies will find it quicker
and easier to navigate "make xconfig" that to navigate dselect.

And optimizations aren't just limited to playing AVIs.

I recall a few years ago a special version of mpg123 that was optimized for
a 486.  A 486-33 that could barely play a mono 22.1 K mpeg easily played
stereo 44.2 K mpegs with the optimizations, if I recall correctly.  We
desparately need to include that of course.  I'm sure similar optimizations
could be added to mpg123 that would reduce processor load on a P4-1ghz by
0.001 % so we need to include that of course.

If we are going to recompile everything to get 1% better performance, we
should have the guts to split the i386 port into all the little processor
families instead of this halfway stuff.

Re: kernel-{image,headers} package bloat

[Vince Mulhollon]

On 04/22/2001 05:40:30 PM zhaoway wrote:

>> Hey, hey, it's for you! Do you guys really expect all Debian users ==
>> Debian develoepers? What about k12 users? What about, say Donald
>> E. Knuth? Do you really think that trivial cubersome kernel compiling
>> ability is necessary for all to enjoy? They may just have no time,
>> they may have no interests! Please don't even try to educate(??) them
>> on this, OK?

I think the problem is a lack of cultural understanding.

Compare this situation to American cars.  You've got the hot-rod-ers and
"performance enthusiasts" who will gladly rebuild their engines and chrome
plate their exhausts to get that extra one percent of performance.  Then
again there are the stereotypical little old ladies and soccer moms who
care more about the color of the vehicle, or maybe how many cup holders the
vehicle has.

Now, following that same situation, you've got the hot-rod-ers screaming
that the car manufacturers need to chrome plate the exhaust headers,
because after all the little old ladies have a busy shuffleboard schedule
and they don't really know how to safely handle cyanide based plating
solutions, and we don't have time to teach them..

The cultural mismatch, is that the little old ladies and soccer moms
couldn't care less if the exhaust is chrome plated or the intake ports are
polished.  All they care about is that they reliably get to the
shuffleboard tournament and the soccer field.

Meanwhile all the other gearheads won't appreciate the factory mods anyway,
because they'll say the chrome isn't polished enough or the factory didn't
set the valve lashup properly.  Besides, the whole point of being a
gearhead is to brag to your friends that you have so much spare time and
extra money and "skill" that you can spend thousands of dollars and
hundreds of hours to tune up an old Pinto (even though you could have used
the same time and money to buy a Ferarri instead of a tuned up Pinto).

So the point is, that the K12 users won't care that you did all that work
to make netscape start up in 5.45 seconds instead of the default 5.50
seconds.  Time is not money to the K12ers anyway.  Besides, when all the
work is done to create 1000 kernel packages tuned to each manufacturer's
possible combination of CPU, MB, HD controller, and sound card, and all the
money is paid, netscape is still going to take about 5 seconds to start up
anyway, and everyone that can compile their kernel is going to continue
doing so anyway.  One of your phrases "they may have no interests!" pretty
much summarizes the attitude of your average K12er.

Bringing us back to my thesis, using a super optimized and patched kernel
is a status symbol for debian developers and computer using "gearheads".
However, the K12ers and office secretaries couldn't care less.

So wouldn't the investement in time and money be better spent elsewhere?

Re: Kernel Sends 7E ?

[Vince Mulhollon]

Yes, this would be the wrong list.

I suppose you need to research the following:

0) Your email refers to a client server system, and mentions embedded dos,
a linux server, and a linux client.  So a client/server architecture has
two parts, and your system has three parts, an embedded DOS thing, a linux
server, and a linux daemon.  There's a problem right there.

1) What is the server program?  Who wrote it?  What happened when they ran
a debugger on it?  Why are you positive your daemon is not sending the 7E?
Did you run a complete strace on the thing and look at the log?

2) What is the embedded dos and who manufactured it?  What version?  What
do they think about all this?  Why can't it recover from a errors?

3) What communication hardware are you using?  RS-232?  Ethernet?  SCSI?

4) What communication protocols are your using? none?  TCP/IP?  SNA?

5) How exactly did you determine "a" 7E was appended (or do you mean 8
bytes of 7E?)  Do you mean appended at the physical layer, or the network
protocol layer?

6) Then of course you need to try some spare hardware.  Ideally you'd have
two completely separate systems (nothing connected between them) and both
failling the same way.  That would partially prove the hardware OK.

7) Then you'd need to try different manufacturers hardware to make sure its
not a bug in that model and manufacturer of network card or the serial
port.

8) Finally, there have been about one thousand versions of "the kernel"
since 1991.  So which version are you using and how (if at all) has it been
patched, and did you try to recompile a recent kernel and reproduce the
problem.

9) Then how did you isolate it to "Debian"?  Are you using a debian package
of some daemon?  Does your project even use Debian?

By the time you finish all that I'm sure you'll have found the problem.





"Derrick

(Thrawn01)"  To: debian-devel@lists.debian.org  
        
    <[EMAIL PROTECTED]cc: (bcc: Vince 
Mulhollon/Brookfield/Norlight) 
ike.com> Fax to:

 Subject: Kernel Sends 7E ? 

01/09/2001  

10:14 AM









I'm not sure if this would be the correct List to post a question such was
this. but.

we use Linux as the server on a Embedded DOS client-server environment.
the devices running embedded Initiate a communication with the Linux
server. Our Daemon on the Linux box responds with
a single packet containing the Transaction information. directly after that
packet the Linux box sends a packet containing , 8 bytes,
( in hex ) " 7E".

The Embed DOS interprets this as a response from our daemon, resulting in a
miscommunication.
We are positive that our daemon is not sending the "7E" 's We believe that
it's originating from the Kernel.

Anyone encountered this before ?
Any Direction or Thoughts would be greatly Appreciated.
---
This has been a Communiqué from
his Imperial Majesty Admiral Thrawn.
---
[EMAIL PROTECTED]

Re: Developer Behavior

[Vince Mulhollon]

1)
It's a totally informal and unofficial first draft.  Maybe a better way of
expressing my thoughts would be:

"A Debian Developer will never knowingly allow a mission critical server to
run unstable unless all the affected users and managers understand the
danger."

or, perhaps more acceptable:

"A Debian Developer will completely accept, understand, and expect the
problems that result from running unstable without reacting in anger and
flaming."

What I'm getting at is the prevention of emails like:

"I upgraded my machine to unstable because I wanted to run the latest GTK
solitaire game, but then libc broke and now the embedded system is locked
up so the primary cooling pumps shut down, and the reactor core is
overheating, what do I do now, please respond before the reactor
Chernobyls!" or similar dramatic responses.  I'm not trying to make fun of
people getting fired because their webhosting or dnshosting goes down, but
there's some tragic humor in seeing people destroy their critical business
tools over and over by running unstable without knowing the consequences.
Then again, you could say they destroy their critical business tools every
time they get out the Microsoft installation CDRom (humor).  Once one
person learns the hard way what not to do, there's always someone else
ready to do the same dumb thing.

I really didn't expect as many complaints as I got... I know that if I ran
unstable on a mission critical machine at work, I'd get fired when it
crashed, because of poor judgement (and rightly so!).  It seems unwise to
run experimental development kernels or development packages on something
that should not be screwed around with.  And if it is OK to screw around
with it, then either it's really not mission critical after all, so its OK
to screw around with it because it doesn't really matter, or the management
is totally screwed up.  It would be unprofessional for my doctor to give me
experimental drugs that might cure me or might kill me, and I think it's
equally unprofessional for a sysadmin to install experimental software that
might kill the machine.

Thus ironically bringing us full circle to the start of the thread where
howling occurred because a bunch of users lost access when a working
(presumably mission critical) machine was upgraded, resulting in a flamewar
about how dare the developer not care that the endusers were screwed when X
broke (because the upgrader was not familiar with the changes), etc.

If I felt like stirring the pot, I'd propose we stop calling it "unstable"
and start calling it "full-of-bugs".  People like developers won't be
scared of the bugs, but the people doing "important end user things" will
be scared away (except for the stupid people, but there's nothing that can
be done to help them, other than euthanasia).  We could rename "stable" to
"no-release-critical-bugs".

Another idea would be to change the /etc/issue for unstable and stable such
that they print the approximate number of release critical bugs in stable,
testing, and unstable.  It might even motivate developers to work bugs so
they don't have to see a huge number every time they log in.  Even a change
from "Unstable" to "Unstable with approx 9000 release critical bugs as of
x/y/2001" might be interesting.

Enough subject drift.

2)
The ham radio connection.  There's no direct connection, other than
inspiration.

Both the ARRL and Debian are nongovernmental  agencies composed of
volunteers, and a tiny fraction of people whom are paid to work on the
project, to make their "product" as good as it can be, primarily for the
benefit of the members, but society at large also benefits.  The front of
the ARRL handbook has had the "amateur code" in it for as long as I can
remember, to encourage radio operators to behave.  A listen to certain
parts of the 80 meter band shows that isn't totally effective, but at least
the ARRL tries, and all a volunteer organization can do is try to encourage
good behavior, can't really force it.  I see some similarity in Debian.
The ARRL also has a "considerate operator's bandplan" which most people
seem to follow, which also is good inspiration.

A statement of shared values that we should at least try to be civil to
each other and all play together nicely according to our rules certainly
can't do any harm (?)

- Forwarded by Vince Mulhollon/Brookfield/Norlight on 01/08/2001 02:44
PM -


John O      
    
Sullivan To: debian-devel@l

Re: Developer Behavior

[Vince Mulhollon]

Yes, it took me about a year's wait also.

The point I'm making is that complaining to volunteers is ineffective
unless you give a solution.

Now that you and Eray have publically complained about the team's slowness,
that means that after you complete the NM process, you both be joining the
NM team to help your fellow developers get processed quicker, right?

I'm not being sarcastic, my initial account manager who did the interviews
and stuff had just completed the process a few months ago, so I assume
you'll be joining the new maintainer team just like he did.





Aaron Lehmann   

<[EMAIL PROTECTED]    To: Vince Mulhollon <[EMAIL 
PROTECTED]> 
us.com>  cc: debian-devel@lists.debian.org, 
(bcc: Vince 
 Mulhollon/Brookfield/Norlight) 

01/08/2001   Fax to:

10:25 AM Subject: Re: Developer Behavior









On Mon, Jan 08, 2001 at 10:17:42AM -0600, Vince Mulhollon wrote:
> "waiting for DAM approval, whenever that is supposed to happen"
(emphasis
> on the "supposed to happen")

No offense to the DAM, but I share Eray's pedicament and feel that I
could definately contribute more effectively if I had the ability to
make uploads. Currently I go through a sponsor, which works but is
less efficent than being able to contribute directly.
(See attached file: attpucp9.dat)



attpucp9.dat
Description: Binary data

Developer Behavior

[Vince Mulhollon]

Some Eray quotes, one paragraph of advice for Eray, and a possibly useful
idea at the end for everyone.

"Non-regulation is a false claim"

"His actions are simply not tolerable"

"I'd be greatly surprised if anybody told me that developers have the right
to swear publicly in an outburst of adolescent frenzy."

"waiting for DAM approval, whenever that is supposed to happen"  (emphasis
on the "supposed to happen")


Your problem (our advantage?) is your lack of power to enforce your
demands.  Yes, someone publicly used naughty words against you, you think
their actions are not tolerable, you think our communication styles are
regulated (or should be), you think we don't have the right of free speech.
That's all very nice of you to let us know what you think, thank you (?).
But you have no power over us.  You can't fire the Xwindows maintainer,
because you don't send him a paycheck.  You can't censor the mailling list
because you aren't the moderator (there isn't one).  You attempt to
objectively state what happened, then in the same thought, shift to extreme
purely personal subjective opinions and wishes.   You've decided in a
fascist manner for us, what actions are intolerable, what speech is
acceptable, what policies are false, and how you're "above the law" and
able to quote private emails freely although everyone else isn't "above the
law".  You can't boss people around and tell them how to think if they are
volunteers in a freedom oriented group.  I would advise you not to push for
some kind of formal code of conduct, because with your luck, the new code
would be modified into something like "Debian will tar and feather anyone
who annoys more than x% of the developers", and it would seem in a few
short days you've managed to offend everyone from the Account Manager team
to the X maintainer.  Luckily for you, there are plenty of other people,
already in Debian, with poor social skills, so at least you can reasonably
request to be "grandfathered" in...  My own experience in these manners is
I've posted some stupid emails, sometimes because I've got the unique
ability to "invent" a good idea long after someone else implemented it, or
else I've just been plain ole stupid and in a hurry.  Regarding that, I
would say that true intelligence is learning from mistakes, which I'm
trying to do, and I suggest you do the same.


One possibly useful idea that could come out of this flamewar is an
"informal" code of conduct.  The model I'm thinking of is the ARRL amateur
radio operator's code.  It has about five sections, basically giving advice
on how not to be annoying as a ham radio operator.  It's informal in that
if you ignore it, they can't kick you out of anything, yet if you're a jerk
and publically ignore it, noone will have anything to do with you.

Something like this might (I stress might) be useful for Debian.  You could
even test people on their knowledge of the code in the new applicant
process.

Here's my start as an example of what I'm thinking of.

"Debian Developer Code of Conduct" by Vince

The goal of the Debian Code of Conduct is to improve the social skills of
Developers through a process of suggestion so that more effort can be
placed on working on code and less effort can be placed on flamewars.  In
short, the code will try to tell you how to be a help, not an annoyance.
The code is not a demand, but a really strong suggestion of what actions
helps the project and what actions hurt the project.

1) A Debian Developer is a freedom oriented volunteer, yet will try to act
and communicate in the most formal and professional manner they can, as if
they represented a conservative bank, not as if they represented a bunch of
drunks fighting at the bar.

2) A Debian Developer will RTFM, isolate the problem as much as possible,
and include as much evidence as possible, before filing a bug

3) A Debian Developer will acknowledge the diversity of skill levels of his
fellow developers and will try to help other developers learn, rather than
flaming them for their ignorance.

4) A Debian Developer will understand that computer languages have priority
over traditional languages, flaming someone for poor english (or German or
whatever) is in even more annoying and non-productive than flaming someone
over poor code.

5) A Debian Developer will never knowingly run a production server on
"unstable" and will never encourage a non-developer to run "unstable".

6) ....

I have this feeling in about 1 hour someone's going to post a followup that
this idea was implemented way back in '92 and why don't I RTFM, but what
the heck, my excuse can always be

Re: Bug#81396: root shell fscked after upgrade to woody

[Vince Mulhollon]

The reason for installing ssh in this case was for troubleshooting,
although higher security would be a positive side effect.

He reports trouble from an unknown source, and telnetd is "involved".
Installing ssh would allow comparisons of the failure modes with different
network login clients.

If it failed with telnetd and worked with ssh, well then that would isolate
the problem to something related to telnetd.

If it failed with telnetd and failed with ssh, then the problem is probably
not the the telnetd package (although there are possibilites)

rsh could be used in a similar troubleshooting manner, although a side
effect of installing rsh would probably be lower security rather than
higher...


Some people ask why and/or complain Debian has more than 1 package that can
provide "Q" where Q is webserving or DHCPing, or BIND versions, or
whatever.  I think the ability to troubleshoot problems by trying alternate
programs is an excellent reason to have "multiple packages doing the same
thing".





Craig Sanders   

<[EMAIL PROTECTED]To: "Eray Ozkural (exa)" 
<[EMAIL PROTECTED]>,
au>  [EMAIL PROTECTED]  

         cc: (bcc: Vince 
Mulhollon/Brookfield/Norlight) 
01/06/2001   Fax to:

11:36 PM Subject: Bug#81396: root shell 
fscked after upgrade to woody   
Please  

respond to  

Craig   

Sanders;

Please  

respond to  

81396   









On Sun, Jan 07, 2001 at 04:38:10AM +0200, Eray Ozkural (exa) wrote:

> We use telnet here because this is a diverse university network; we
> can't force people to run ssh and any moron could go root on this
> machine if he really wanted to.

why not?

the most you'd have to do is put up a single web page with links to
local copies of ssh clients for various platforms...and optionally
replace telnetd with a script (or tcp-wrapper's "twist" capability)
which printed a message displaying the URL and advising the user to
install an ssh client. telnet problem solved with a minimum of user
support calls.

there's really no excuse for running (non-ssl) telnetd any more. good
free ssh clients are available for just about every operating system.


craig

--
craig sanders


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]

Re: What to do about /etc/debian_version

[Vince Mulhollon]

How about creating a directory called "/etc/organizations" including the
following files:

/etc/organizations/debian-unstable
Contains the text "Debian Unstable http://www.debian.org";
Found in perhaps the unstable version of base files package.

/etc/organizations/helixgnome
Contains the text "Helix Gnome version X.Y http://whatever";
found in helix's gnome-base package

/etc/organizations/TYDC-KDE
Contains the text "TYDC KDE http://whatever";
found in the kdebase package.

/etc/organizations/corel
contains the text "Corel (tm) ver X.Y http://www.corel.com";
found in corel's base-files

Then to see what you've got installed at boot up and at on the login
screen,

echo This Debian based system contains components from the following
organizations:
cat /etc/organizations/*
echo Please contact the appropriate organization with trouble reports.





The Doctor  

What To: debian-devel@lists.debian.org  

    <[EMAIL PROTECTED]cc: (bcc: Vince 
Mulhollon/Brookfield/Norlight) 
.org>Fax to:

 Subject: Re: What to do about 
/etc/debian_version  
01/05/2001  

09:14 AM









* Bart Schuller ([EMAIL PROTECTED]) [010105 07:48]:
> I've seen third-party software install scripts use the file to determine
> which Linux distribution it's running on.

Yes, I think it's important to have one central file that can show
(roughly) which version of the OS is running.  Being human and
machine parsable.

3rd party software uses it, users like to know it, etc.

However, it's going to be much more confusing as you get the ability
to pull in peices from different places (via apt, package pools,
etc.).

Is a system that pulls in woody plus helix *still* a woody system?
Or is something else?

Maybe apt/dpkg are the only things that can acurrately tell us what
the system is.

I suspect this is a policy desicion more than anything, though.

Ciao!

--
"No one will ever win the battle of the sexes; there's too much
fraternizing with the enemy.."
   -- Henry Kissinger

The Doctor What: "What, Doctor What" http://docwhat.gerf.org/
[EMAIL PROTECTED]   KF6VNC


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]

Re: package pool and big Packages.gz file

[Vince Mulhollon]

The only other possibility not yet proposed (?) would be to split the
packages file by section.

base-packages
games-packages
x11-packages
net-packages

Then a server that just doesn't do x11 or doesn't go games has no need to
keep up with available x11 or games packages.





[EMAIL PROTECTED]   

punki.fi To: debian-devel@lists.debian.org  

(Samicc: (bcc: Vince 
Mulhollon/Brookfield/Norlight) 
Haahtinen)   Fax to:

 Subject: Re: package pool and big 
Packages.gz file 
01/04/2001  

03:01 PM









On Fri, Jan 05, 2001 at 03:02:15AM +0800, zhaoway wrote:
> my proposal to resolve big Packages.gz is through package
> pool system.
>
> add 36 or so new debian package, namely,
>
> [a-zA-Z0-1]-packages-gz_date_all.deb
>
> contents of each is quite obvious. ;-)
> and a virtual unstable-packages-gz depends on all of them. finished.
>
> apt-get update should deal with it

how about diffs bethween dinstall runs?..

packages-010102-010103.gz
packages-010103-010104.gz
packages.gz

apt would download the changes after the last update, and merge these to
the
package file, if the file gets corrupted, it would attempt to do a full
update.

This wouldn't be a big difference in the load that the master-ftp has to
handle, atleast when some 7 of these would be stored at maximum.

Regards, Sami Haahtinen

--
every nerd knows how to enjoy the little things of life,
like: rm -rf windows


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]

Re: Rambling apt-get ideas

[Vince Mulhollon]

With the raging flame war going on about MUAs, I'm embarassed to mail this
with lotus notes, but, hey, its all I have at work.

Back on topic, I would have thought that package distribution was a one
time shot.  Caches are for people who would otherwise download the
slashdot.org header graphic fifty times a day.  Whereas each individual
debian machine should only have to download the latest perl .deb once in
it's "life".  If I apt-get upgrade through my http cache, all I do is flood
the cache with megs of data I'll never download again.

I'm not sure about the overhead is minimal for less than a thousand
clients.  I have 18 or so debian workstations at work.  If it takes 5
minutes to transfer all the .debs to upgrade one machine, then I think it
would take a unicast system slightly less than 18*5 minutes (about 1 1/2
hours) to upgrade, vs 5 minutes for a multicast system to upgrade.  A
unicast upgrade could be an "start it and go to lunch" process whereas a
multicast upgrade would be a "get a cup of coffee" process.  If I had a
hundred machines to upgrade, the comparison would be even greater.  Yeah,
wasting 17*5 minutes is not the end of the world, but why not try harder to
do better?

The concept of the system I'm discussing, is one "master" machine downloads
the .deb via http.  Then it multicasts the .deb to all the other machines
at once.  All of them are on the same subnet so some variety of layer 2
multicast / broadcast would work, although it would be nice to go beyond
the subnet if necessary.

I agree that the discussion about new installs points out that sometimes,
"pull" based systems have an advantage.  I'm pointing out that sometimes,
"push" based systems have an advantage.  And I'm motiviated because I
believe my situation at work is one of those situations where "push" is the
better answer.





Matt

ZimmermanTo: debian-devel@lists.debian.org  

<[EMAIL PROTECTED]cc: (bcc: Vince 
Mulhollon/Brookfield/Norlight) 
rg>  Fax to:

Sent by: MattSubject: Re: Rambling apt-get 
ideas
Zimmerman   

<[EMAIL PROTECTED]  
 
t>  





01/04/2001  

01:45 AM









On Fri, Dec 29, 2000 at 11:11:01PM +0100, [EMAIL PROTECTED] wrote:

> Why not look at this from a different perspective? I don't know if it may
be
> useful or not for upgrading machines, but the multicast server would be a
> very nice thing for mass installations.

I still disagree.  Multicast is the wrong solution.  Multicast data is
basically equivalent to a cache with zero object TTL.  Packets (objects)
are
stored (by a network device) until a client needs them (immediately), at
which
point they are served (multicasted/broadcasted) and expired (discarded)

Re: Rambling apt-get ideas

[Vince Mulhollon]

Yes, that was kind of my point.

An analogy would be that we don't need dpkg because most of its
functionality could be done by a mixture of tar, gzip, and perl (and maybe
make to handle dependancies).

My point being, that yes I already use squid as a proxy server for a whole
network of apt-geting debian boxes and after only a little work it works
OK, but something using IP multicast would be better due to lower network
utilization.  True, doing multiple simultaneous upgrades means eventually
an upgrade would kill all the machines simultaneously, and my high end
pentiums are going to decompress the gzip parts much faster than my old
386s, although there are probably ways around that, just because all the
.debs are distributed all at once in one multicast burst doesn't mean they
have to be installed all at once.  Anyway, squid does not do IP multicast
to multiple simultaneous clients, last time I checked.  Another cool
ability of an integrated cache would be that the "fetching" machine could
maintain a list of all the machines it pushed the new .deb to, and when all
the "client" machines have a copy of the new .deb, clear it from the cache.
With a squid solution, squid has to guess if its OK to clear the cached
.deb based upon access time, size, etc.  Even worse, my squid only caches
files less than 8 megs, thus each machine downloads its own copy of emacs,
etc.  A cache for general web use "works", but a cache designed
specifically for .deb packages would work better.

Most of the ideas I brought up, I already do something similar, in a manual
and hackish manner, involving ugly perl scripts and config files I would be
embarassed to publicly show.

I suppose I could configure my two dozen workstations at work "all at once"
"remotely" by doing some kind of weird hack with expect and ssh.  But it
might be cooler to do that with directly with debconf, again using IP
multicast.

Or another example, a network wide shared apt-get cache.  I suppose you
could just NFS mount all the machines onto one apt-get cache on one
machine.  There might be file locking issues.  There would be security and
authentication issues.  The one server would have to have all the disk
space for the cache.  And it would be a manual PITA to the configure for
each machine involved.  Would be cooler, cleaner, and more efficient to
have the system  do the same functionality as a core feature.

Another example is adding transport protocols to apt-get.  I suppose given
a strange brew of named pipes, NFS mounts, loopback devices, and "file:"
lines in /etc/apt/sources.list I could find a way for apt-get to pull .debs
over freenet, or over FSP, or over DCC chat on IRC.

The general idea of my post is that I do some unusual hacks involving
apt-get already, and I can think of even stranger and more useful hacks.
But why make and use a wierd custom hack, when the idea could be cleanly
built right into the infrastructure instead, for everyone to automatically
and easily use? (although I don't know enough apt-get to do it myself)





Matt

ZimmermanTo: debian-devel@lists.debian.org  
        
    <[EMAIL PROTECTED]cc: (bcc: Vince 
Mulhollon/Brookfield/Norlight) 
rg>  Fax to:

Sent by: MattSubject: Re: Rambling apt-get 
ideas
Zimmerman   

<[EMAIL PROTECTED]  
 
t>  





12/27/2000  

09:24 PM



    
    




On Wed, Dec 27, 2000 at 02:03:14PM -0600, Vince Mulhollon wrote:

> How

Rambling apt-get ideas

[Vince Mulhollon]

How about an "apt-getd" debian daemon.

Use a apt-get client to remotely mess with another workstations packages.
Messing with only one workstation at a time is boring.  How about multicast
to configure a hundred workstations instead, all at once?  And then have a
proxying apt-getd server multicast out the .deb files to all the machines
at the same time?

Link the apt-getd daemons on multiple workstations to create a network-wide
virtual .deb cache.  If workstation A downloaded the latest libc, then
workstation B's apt-getd will query workstation A and download the package
from workstation A instead of the debian website, automatically.  The
ultimate extension would be for your apt-getd on your workstation to query
apt-getd on the main debian website, instead of configuring http or ftp
transport methods.  Sort of like hacking proxy features onto apt-get.  Or
combine the freenet protocol into it.  Using freenet would make
distribution of non-US and non-free very interesting.

Perhaps a shared network workgroup structure.  Ten workstations with their
apt-getd's all talking to the server's apt-getd as clients.  Install a new
package on the server, and after a configurable random delay, all ten
client workstations will fetch and install the same new package.

Hacking NIS features onto apt-get.  "installedpackages.byname"?

How about selectable compression methods to balance processor speed vs
network speed?  Distribute debian as a product in .bz2 format over my 56K
modem to my fast Pentium, and then on the fly convert it to proxy totally
uncompressed .debs over my 10 meg ethernet to my 12 meg 386.

How about a new structure for compression.  apt-get-gzip provides gzip,
apt-get-bz2 provides bzip, apt-get-uudecode provides uudecode.  Automate
downloading of new compression methods or even new transport methods as
packages using the new format are downloaded.  Kind of like Microsoft's
video viewer downloaded new codecs automatically...

How about "automatic" "apt-get update"?  apt-get automatically does an
update whenever it determines it is needed.

How about eliminating the need for apt-get update for upgrading purposes?
Still need to download the entire cache to browse all the packages, but the
cache is getting big enought that some kind of piecemeal "apt-get update"
or perhaps "diff" based packages would be a good idea.

Is distributing the apt-get package cache via CVS a good idea, or is it
insane, is it a cool hack, or all of the above?

How about apt-get being able to somehow query and find other apt sites?  No
need to edit the apt sources list manually, if you try to install
task-helix-gnome it will find helix's site "automatically" and ask
permission before using it.

How about apt pinging the mirrors to find the closest / fastest one and
then using it, no matter where you are on the internet?  How about pinging
them all every week to find the closest / fastest 3, and then pinging those
three before each file download to find the fastest mirror at that instant?

How about using fsp as an apt-get transport method?  fsp can be set to do
traffic shaping, limiting the usage to perhaps 25% of your connection, if
you want.

How about linking apt-get and debconf into one program with all the above
features?

You can already do most of the above using a bunch of different packages
and scripts, but it "might" be easier to setup as "one big daemon".

Problems would be vastly heavier requirements and major security issues.





Alex Perry  

<[EMAIL PROTECTED]To: 
debian-devel@lists.debian.org  
e.net>   cc: (bcc: Vince 
Mulhollon/Brookfield/Norlight) 
 Fax to:

12/27/2000   Subject: Nice features in a pre 
package manager
01:12 PM









In addition to the previously-mentioned pipelining that installs
packages as soon as they're downloaded, so their deb can be deleted,
and has careful sequencing so that a package is not downloaded until
its dependencies have _already_ been met, it would be nice ...

to have the package requesting front end b