subject:"I wish to advocate linux"

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-10 Thread Brian

On Sun 10 Mar 2013 at 15:00:29 +1100, Zenaan Harkness wrote:

 Would it be possible to also pipe outgoing mail through procmail or
 similar, on its way to the MTA/SMTP server?

When I initially looked at this I thought maybe, but it did not seem
particularly friendly to do. More to the point, I wasn't prepared to
change anything in my MTA's configuration to get it working.  After all,
I became interested in this complaint about list mails plus CCs, not
because they are an annoyance to me, but as an intriguing problem.

A solution is possible if thinking is in terms of formail rather than
procmail.

There is a Debian package of proxsmtp. This program can proxy mail to a
local or remote MTA. More to the point, it can run a script which can
process the mail before passing it on. This one, for example:

   #!/bin/bash

   MID=$(date +%Y%m%d%H%M%Snoccsple...@example.com)
   TO=$(formail -zxTo:)

   if [ $TO = something which identifies debian-user ] ; then
 formail -I Message-ID: ${MID}
   fi

There we are! A Message-ID generator which can be used with MUAs other
than Mutti to mark list mails. Thank you very much for the nudge.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130310230658.GO32477@desktop

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-10 Thread Brian

On Sun 10 Mar 2013 at 00:37:59 -0700, Bob Proulx wrote:

 Zenaan Harkness wrote:
  
  Cool :)
  
  Thanks for sharing. Appreciated.
 
 +1.  I also think that is pretty cool.  Since Message-Id is one of the
 few that would be passed through.  However many clients do not do
 this.  I have many problem friends who reply with bad MTAs that break
 threads.
 
 Pretty cool just the same though.

Thank you.

An implementation of the idea is below.

If a CC arrives first, it is stored and its Message-ID recorded. A list
mail which comes in later with the same message-ID is saved and the
previous CC deleted using archmbox.

A list mail arriving first is saved and has its Message-ID recorded. A
later arriving CC is deleted because it has the same Message-Id.

A cron job using archmbox can move mails left in possiblecc to inbox at
a suitable time.

Note that another post

   http://lists.debian.org/debian-user/2013/03/msg00625.html

suggests a method for generating a Message-ID for the sent list mail
which does not depend on the use of Mutt.



SHELL=/bin/sh
TESTDIR=/home/brian/procmail-testing
MAILDIR=${TESTDIR}/received-mail
LOGFILE=${TESTDIR}/Proctest.log
LOG=--- Logging for ${LOGNAME}, 

#Troubleshooting:
VERBOSE=yes
LOGABSTRACT=all

FORMAIL=/usr/bin/formail
ARCHMBOX=/usr/bin/archmbox

# msgid.cache has all its data on one line. This does not suit the egrep
# line below.
MIDCACHE=`strings ${TESTDIR}/msgid.cache`

# Get the Message-ID of the mail. Remove leading whitespace.
# MID=`formail -zxMessage-ID` is thought to be less efficient than the
# following:
:0
* ^Message-ID: \/.*
{
 MID = $MATCH
}

# Recipe 1.
# These are list mails which are not a response to one of my posts. Grab
# them immediately.
:0:
* ^List-Id:.*debian-user.lists.debian.org
* !^In-Reply-To:.*noccsple...@example.com
${MAILDIR}/debian-user

# Recipe 2.
# A list mail which responds to a post of mine. Check if a Cc has aleady
# arrived and delete it if it has. Debian has an archmbox package.
:0Whc ${TESTDIR}/.archmbox.lock:
* ^List-Id:.*debian-user.lists.debian.org
* ^In-Reply-To:.*noccsple...@example.com
* ? echo ${MID} | egrep ${MIDCACHE}
| $ARCHMBOX -k -o -1 -x Message-ID=${MID}
~/procmail-testing/received-mail/possiblecc

# Recipe 3.
# Record Message-IDs of list mails which are in response to my posts. It
# shouldn't matter if a Cc is aleady deleted.
:0Whc: ${TESTDIR}/.msgid.cache.lock
* ^List-Id:.*debian-user.lists.debian.org
* ^In-Reply-To:.*noccsple...@example.com
| $FORMAIL -D 8192 ${TESTDIR}/msgid.cache

# Recipe 4.
# We want all list mail.
:0:
* ^List-Id:.*debian-user.lists.debian.org
* ^In-Reply-To:.*noccsple...@example.com
${MAILDIR}/debian-user

# Recipe 5.
# Check Message-ID of a Cc.
:0Whc: ${TESTDIR}/.msgid.cache.lock
* !^List-Id:.*debian-user.lists.debian.org
* ^In-Reply-To:.*noccsple...@example.com
| $FORMAIL -D 8192 ${TESTDIR}/msgid.cache

# Recipe 6.
# Cc has arrived after the list mail (unlikely). It is deleted.
:0 a:
${MAILDIR}/devnull

# Recipe 7.
# A possible Cc has arrived before the list mail (most likely). It is
# put somewhere safe and only deleted if Recipe 2 sees it exists.
:0
${MAILDIR}/possiblecc


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130310232353.GP32477@desktop

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-10 Thread David Guntner

Brian grabbed a keyboard and wrote:
 On Sun 10 Mar 2013 at 15:00:29 +1100, Zenaan Harkness wrote:
 
 Would it be possible to also pipe outgoing mail through procmail or
 similar, on its way to the MTA/SMTP server?
 
 When I initially looked at this I thought maybe, but it did not seem
 particularly friendly to do. More to the point, I wasn't prepared to
 change anything in my MTA's configuration to get it working.  After all,
 I became interested in this complaint about list mails plus CCs, not
 because they are an annoyance to me, but as an intriguing problem.
 
 A solution is possible if thinking is in terms of formail rather than
 procmail.
 
 There is a Debian package of proxsmtp. This program can proxy mail to a
 local or remote MTA. More to the point, it can run a script which can
 process the mail before passing it on. This one, for example:
 
#!/bin/bash
 
MID=$(date +%Y%m%d%H%M%Snoccsple...@example.com)
TO=$(formail -zxTo:)
 
if [ $TO = something which identifies debian-user ] ; then
  formail -I Message-ID: ${MID}
fi
 
 There we are! A Message-ID generator which can be used with MUAs other
 than Mutti to mark list mails. Thank you very much for the nudge.

Question:  Doesn't doing that mess things up for others, should you
reply to said message?  The In-Reply-To: field when you send your reply
is going to now reference the new Message-ID you just put in, and for
those who use readers with threading, won't that break the thread (since
they won't have any messages which are using your new locally-stored
Message-ID)?

 --Dave





signature.asc
Description: OpenPGP digital signature

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-10 Thread Bob Proulx

David Guntner wrote:
 Brian grabbed a keyboard and wrote:
   Would it be possible to also pipe outgoing mail through procmail or
   similar, on its way to the MTA/SMTP server?
  ...
  There is a Debian package of proxsmtp. This program can proxy mail to a
  local or remote MTA. More to the point, it can run a script which can
  process the mail before passing it on. This one, for example:
  ...
 MID=$(date +%Y%m%d%H%M%Snoccsple...@example.com)
 TO=$(formail -zxTo:)
  
 if [ $TO = something which identifies debian-user ] ; then
   formail -I Message-ID: ${MID}
 fi
  
  There we are! A Message-ID generator which can be used with MUAs other
  than Mutti to mark list mails. Thank you very much for the nudge.
 
 Question:  Doesn't doing that mess things up for others, should you
 reply to said message?  The In-Reply-To: field when you send your reply
 is going to now reference the new Message-ID you just put in, and for
 those who use readers with threading, won't that break the thread (since
 they won't have any messages which are using your new locally-stored
 Message-ID)?

This sets a specific Message-Id on outgoing mails only.  This isn't
changing any message that has been replied to.  These are *new*
messages which will be seen for the first time.  This is the same as
any new message posted to the mailing list.  Just setting the
message-id to that pattern conditionally.  It either gets the
NoCcsPlease (or similar) string or it gets the string that the MTA
assigns to it normally.  Either way it is a new message and a new
message id will be assigned to it.

Bob


signature.asc
Description: Digital signature

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-10 Thread David Guntner

Bob Proulx grabbed a keyboard and wrote:
 David Guntner wrote:
 Brian grabbed a keyboard and wrote:
 Would it be possible to also pipe outgoing mail through procmail or
 similar, on its way to the MTA/SMTP server?
 ...
 There is a Debian package of proxsmtp. This program can proxy mail to a
 local or remote MTA. More to the point, it can run a script which can
 process the mail before passing it on. This one, for example:
 ...
MID=$(date +%Y%m%d%H%M%Snoccsple...@example.com)
TO=$(formail -zxTo:)

if [ $TO = something which identifies debian-user ] ; then
  formail -I Message-ID: ${MID}
fi

 There we are! A Message-ID generator which can be used with MUAs other
 than Mutti to mark list mails. Thank you very much for the nudge.

 Question:  Doesn't doing that mess things up for others, should you
 reply to said message?  The In-Reply-To: field when you send your reply
 is going to now reference the new Message-ID you just put in, and for
 those who use readers with threading, won't that break the thread (since
 they won't have any messages which are using your new locally-stored
 Message-ID)?
 
 This sets a specific Message-Id on outgoing mails only.  This isn't
 changing any message that has been replied to.  These are *new*
 messages which will be seen for the first time.  This is the same as
 any new message posted to the mailing list.  Just setting the
 message-id to that pattern conditionally.  It either gets the
 NoCcsPlease (or similar) string or it gets the string that the MTA
 assigns to it normally.  Either way it is a new message and a new
 message id will be assigned to it.

Ok, thanks.  It was just that it looked like a recipe for a message
that's coming *in* to your mailbox and having the ID changed.  Thanks
for the clarification.

--Dave





signature.asc
Description: OpenPGP digital signature

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-09 Thread Brian

On Fri 08 Mar 2013 at 23:19:06 -0700, Bob Proulx wrote:

 But I am a pedantic sort and so must say that every message does have

To continue with the pedantry :) and to return to the issue raised in
this subthread, a CC is not a duplicate of a list mail. Put them side by
side and the difference is obvious. One result of focussing on a single
characteristic of a mail is that the suggested Procmail recipe would
effectively delete most of the list mail, which might not be a desired
outcome.

Fortunately, Mutt users have the opportunity to take advantage of its
ability to construct a custom Message-ID: header for a mail sent to
debian-user. Like so:

send-hook . 'unmy_hdr Message-ID:'
send-hook 'debian-user@lists\.debian\.org' 'my_hdr Message-ID:`date 
+%Y%m%d%H%M%S`noccsple...@example.com'

A mail with NoCcsPlease in its In-Reply-To or References headers can
only have had the mailing list mail as its source. However, the CC will
not contain a List-ID: header. This makes it possible to distinguish
between a list mail and a CC. Procmail recipes based on these two
conditions can now file list mail with certainty and, if desired, delete
CCs.

How this could be implemented in other MUAs depends on the capability of
the mailer. It works nicely with Mutt because of the behind-the-scenes
send-hook facility. Icedove and KMail can alter the portion of the
Message-ID: header after the @, but whether this could be made automatic
in the same way as Mutt I do not know. Header rewriting by an MTA may
also be a possibility, but I know nothing about that either.

It is reported that some mailers do not produce In-Reply-To: and
References: headers when replying to a mail. Well, you can't win 'em all.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130309135613.GK32477@desktop

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-09 Thread Zenaan Harkness

On 3/10/13, Brian a...@cityscape.co.uk wrote:
On Fri 08 Mar 2013 at 23:19:06 -0700, Bob Proulx wrote:

But I am a pedantic sort and so must say that every message does have

To continue with the pedantry :) and to return to the issue raised in
this subthread, a CC is not a duplicate of a list mail. Put them side by
..
Fortunately, Mutt users have the opportunity to take advantage of its
ability to construct a custom Message-ID: header for a mail sent to
debian-user. Like so:

send-hook . 'unmy_hdr Message-ID:'
send-hook 'debian-user@lists\.debian\.org' 'my_hdr Message-ID:`date
+%Y%m%d%H%M%S`noccsple...@example.com'

A mail with NoCcsPlease in its In-Reply-To or References headers can
only have had the mailing list mail as its source. However, the CC will
not contain a List-ID: header. This makes it possible to distinguish
between a list mail and a CC. Procmail recipes based on these two
conditions can now file list mail with certainty and, if desired, delete
CCs.

Cool :)

Thanks for sharing. Appreciated.

How this could be implemented in other MUAs depends on the capability of
the mailer. It works nicely with Mutt because of the behind-the-scenes
send-hook facility. Icedove and KMail can alter the portion of the
Message-ID: header after the @, but whether this could be made automatic
in the same way as Mutt I do not know. Header rewriting by an MTA may
also be a possibility, but I know nothing about that either.

It is reported that some mailers do not produce In-Reply-To: and
References: headers when replying to a mail. Well, you can't win 'em all.

Would it be possible to also pipe outgoing mail through procmail or
similar, on its way to the MTA/SMTP server?

cheers
zenaan

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caosgnssmr+1nerqm0_w7h1pnw6mt2htlnmrh8qer6rtkqk3...@mail.gmail.com

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-09 Thread Bob Proulx

Zenaan Harkness wrote:
 Brian wrote:
  Fortunately, Mutt users have the opportunity to take advantage of its
  ability to construct a custom Message-ID: header for a mail sent to
  debian-user. Like so:
 
  send-hook . 'unmy_hdr Message-ID:'
  send-hook 'debian-user@lists\.debian\.org' 'my_hdr Message-ID:`date
  +%Y%m%d%H%M%S`noccsple...@example.com'
 
  A mail with NoCcsPlease in its In-Reply-To or References headers can
  only have had the mailing list mail as its source. However, the CC will
  not contain a List-ID: header. This makes it possible to distinguish
  between a list mail and a CC. Procmail recipes based on these two
  conditions can now file list mail with certainty and, if desired, delete
  CCs.
 
 Cool :)
 
 Thanks for sharing. Appreciated.

+1.  I also think that is pretty cool.  Since Message-Id is one of the
few that would be passed through.  However many clients do not do
this.  I have many problem friends who reply with bad MTAs that break
threads.

Pretty cool just the same though.

 Would it be possible to also pipe outgoing mail through procmail or
 similar, on its way to the MTA/SMTP server?

Mutt has the $sendmail variable.  The manual has a section Change
Settings Based Upon Message Recipients that gives this teaser.

  send2-hook is executed after send-hook, and can, e.g., be used to set
  parameters such as the $sendmail variable depending on the message's
  sender address.

Which implies to me (although I have not tried it) that you could pipe
messages for particular addresses through whatever filter you wanted
and could automatically add headers or track outbound messages.  As
long as you consistently used mutt to do the sending.

Bob


signature.asc
Description: Digital signature

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-08 Thread Robert McKittrick

Somehow, I got on the debian help list. Pleas get me (mckitt1...@gmail.com)
off. I think my problems were due to bad sectors on my hard drive. I will
try again when I get a new one. I have the debian 1-8 i386 iso's burned to
dvds.
best of luck
bob


On Sun, Mar 3, 2013 at 3:44 PM, Bob Proulx b...@proulx.com wrote:

 David Guntner wrote:
  Bob Proulx grabbed a keyboard and wrote:
   For one I use the mailing list headers List-Id and List-Post.  Those
   are the standard headers and those are the best ones to use for filing
   mailing list messages.  Smart MUAs use those to know how to do a
   list-reply.  Therefore the copy I want is the copy that comes from the
   mailing list.
 
  Not every MUA does, however.  The one I'm using, for example, does not
  (or if it does, I've never figured out how to turn that feature on...).
   Therefor, I've also got a Procmail recipe that adds a Reply-To:
  pointing back to the list on my local copy (of debian-user, since it
  doesn't add one itself - on lists that do so, I don't use that rule) so
  that when I hit reply, it goes back to the list as it should since most
  of the time a reply should go back to the list when replying to a
  posting on the list.  And I don't want to have to remember to do it
  manually each time I reply. :-)

 My takeaway is that you have applied a workaround that shouldn't be
 needed to a problem that shouldn't exist.  Applying Reply-To destroys
 the sender's use of Reply-To which is reserved for them to use.

 The classic line here is, Now you have two problems.  :-)

  It all depends on your experiences and own requirements.  I for one am
  on a decade+ old list that was home grown - the guy running it rolled
  his own, so to speak.  It doesn't use a subject tag, and it has never
  had those now-standard List-ID headers, nor is it likely to anytime in
  the future.  So even if I *were* using a MUA that understands those
  headers, it would do me no good.

 I would nag your buddy into adding those headers.  It will help modern
 mail user agents to be able to do the right thing automatically.

  It has never occurred to me to ever filter based in a List-ID field,
  since back in the old days when I started doing this, they hadn't yet
  come into existence. :-)

 Every decade or so it is good to take a breath and look around and
 make smart upgrades to systems.  The Debian mailing lists have been
 around for a long time and are basically a home grown system too
 (using Smartlist) but they comply with modern standards.  I operate
 several Majordomo mailing lists and they all comply with the modern
 standards.  It is really as easy piping the message through formail
 and having it add the headers.

  And even *after* coming into existence, you
  still have to *send* your message to the list in question, thus the To:
  or Cc: will *always* be there, regardless of the presence (or lack
  thereof) of a List-ID header.  Also, by filtering on those (To, Cc), it
  works 100% of the time - even if the above recipe deletes the list copy
  if it came in second. :-)

 For a nasty example, I hate it when people BCC mailing lists.  Then
 the To and CC fields are not able to reply to the mailing list because
 they don't include it.  But since List-Post is added by the mailing
 list that value is correct.  But that is an example of something that
 shouldn't be happening.  Many lists block bcc to the list since that
 is an anti-spam strategy too.

  For myself, this is what I use specifically for the Debian users list:
  ...
  It will pretty much catch the string being looked for if it shows up
  *anywhere* in the message headers. :-)  Since I've never filtered based
  on a header which may-or-may-not be there, deleting the second,
  duplicate copy of a message has never caused a problem even if that one
  was the list-processed copy.
 
  In fact, I would argue that using the above filter (TO_) is *less*
  problematic than the method you use, since deleting a duplicate
  Message-ID does have the potential to remove the copy that actually went
  through the list - it doesn't matter which one got to you first, since
  it *still* gets filtered into the correct folder.
 
  But again, it's all a matter of personal taste, personal experiences and
  personal requirements (like I said, I'm on a really old mailing list
  which has never had List-ID headers and most likely hell will freeze
  over before it gets them; the list has been around longer than the RFC
  which defines List-ID).

 Yep.

   P.S.  Here is the procmail rules I use to file all Debian mailing list
   messages.
  
   :0
   * ^List-Id: .*debian-[-a-zA-Z0-9]+\.lists\.debian\.org
   * ^List-Id: .*debian-\/[-a-zA-Z0-9]+
   Lists/debian/$MATCH/
  
   :0
   * ^List-Id: .*[-a-zA-Z0-9]+\.lists\.alioth\.debian\.org
   * ^List-Id: .*\/[-a-zA-Z0-9]+
   Lists/debian/$MATCH/
 
  That's great for filing (and cool to know about, for mailing lists which
  include those standard headers).  How does it get rid of

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-08 Thread Lisi Reisz

On Friday 08 March 2013 16:40:50 Robert McKittrick wrote:
 Somehow, I got on the debian help list. Pleas get me (mckitt1...@gmail.com)
 off. I think my problems were due to bad sectors on my hard drive. I will
 try again when I get a new one. I have the debian 1-8 i386 iso's burned to
 dvds.

We unfortunately can't do it for you.  You have to do it yourself.  Here's 
how:

To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

You need to unsubscribe from the email address which the list has for you.

In case anyone wishes to point out to Bob that this information is on the end 
of every email, it was not at the end of Bob's email, so give him the benefit 
of the doubt and spare him - please?

 best of luck
Thanks!

HTH
Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201303082250.30442.lisi.re...@gmail.com

Re: Two copies of E-Mail (Re: I wish to advocate linux)

2013-03-08 Thread Bob Proulx

Lisi Reisz wrote:
 In case anyone wishes to point out to Bob that this information is
 on the end of every email, it was not at the end of Bob's email, so
 give him the benefit of the doubt and spare him - please?

I know what you meant and I agree.  Confusingly there are also two
Bobs in that thread. :-)

But I am a pedantic sort and so must say that every message does have
the unsubscribe instructions added to the bottom of the message.  But
whether it is displayed or not depends upon your mailer.  Signed
messages like mine usually cause the mailer to only display the signed
part of the message.  Additional parts are hidden.

Look at the raw message.  Scroll down to the bottom.  The mailing list
includes them on each message.  But your mailer doesn't show you
anything outside the signed portion.  Additionally the headers of
every message also includes subscribe and unsubscribe information.  It
was just a shame that it was my message that was replied to since most
of the messages are not signed.  The majority of the messages will
have that text plainly dislayed.

To add some value to this message I will say that in the last 5704
messages sent to debian-user in the last 120 days there were there
were 34 posters who signed 775 messages.  There were 764 posters who
did not sign 764 messages.  There were 4.3% (34) of the posters
signing 13.6% (775) of the messages.  There were 95.7% (764) of the
posters not signing 86.4% (4929) of the messages.  There were an
average of 47.5 messages per day.

Bob


signature.asc
Description: Digital signature

Re: Moving from a proprietary OS - unnecessarily inful experience -- was [Re: I wish to advocate linux]

2013-03-07 Thread Morel Bérenger

Le Mar 5 mars 2013 16:37, Martin McCormick a écrit :
 Miles Fidelman writes:
 In Linux/Unix in general, we have a concept that is
 rather old of output being something you can send where it needs to go
 because you may not always predict where somebody will need to send it for
 a particular job.

 In Windows and nitch operating systems for many
 purposes, Some designer just figured the screen was good for everybody and
 there is no way to divert text and numbers to any other device.

Well, sorry, I have to disagree here.
The short (and trollesque) version:
*Linux:
_ systemd: happy trolling, I won't go further :P
_ xorg: this link
(http://wayland.freedesktop.org/faq.html#heading_toc_j_6) explains
correctly that Xorg needs tons of stuff which is no longer used nowadays.
I think we often call unused stuff: bloat.
*Windows:
_ coreutils: are implemented. Just an example, of course, since I myself
am able to implement tools I do in a portable way, and I love to create
CLI stuff. Drawing windows is quite boring IMHO...

The longer version:
The problem is not *nix vs windows, or linux vs whatever, and the problem
is not age of dev, too.

It is only a problem of philosophy. UNIX starting philosophy was that
softwares should only do one thing, and do it well. It also states that
they should use text human readable inputs and outputs.
Few months ago (maybe 2 years?), I have simply made the link with object
oriented programming.

In both ways of thinking, you have highly specialized softwares/classes
and easy to understand interfaces.
But, I also think that both ways of thinking are hard to follow, because
they require the ability to *focus* on one task at a time, to refrain the
will to add useful features, to accept that the first idea you had
and/or stuff other says are not the best solutions, and many other
qualities.
All those qualities needs time to be acquired.
But how many depends on people: some will understand basics of OOP quite
fast, other will need years. I am (I hope I *was* but I can not judge
that, only other people can say if a software is clean or not. And when I
encounter a kind of problem for the first time, I'm still doing dirty code
first...) in the second group.

When you have understood OOP's principles, you notice that your programs
are simple libraries, for which you write front-ends (command line or
ncurses or gtk or qt... those are only front-ends anyway). CLI interfaces
are easier to debug (because they are easier to automate) so I prefer to
firstly implement this one, but not always (a drawing software does not
really take sense in CLI, by example. At least, _I_ do not see the
point.).
Strangely, when I take a look at projects, I more often see one binary
containing logic and interface (and sometimes more than one interface... I
did not take a close enough look at aptitude, but I bet all source code is
in the same binary?).
And I bet it was the same 15 years ago. My teachers tried to taught me to
do like that... When I think about that, I feel quite happy to have
started learning long before having programming lessons.

 Younger people tend to be cought up in what's here now
 and, if they are not careful, they think it is as good as it gets.

But, their teachers said them that if the user is not happy, he will buy
hardware. Yes, really. I have heard mines saying that about memory usage,
and I bet that if at that moment I had asked them about blind people and
such kind of stuff they would have said do not worry about that too.
And my teacher who said that people have just to buy some more RAM units
was not really someone I would qualify of young man.

 That is just one example of countless other examples and
 I don't wish for a minute that we were in an earlier time, but
 let's value collective wisdom. It can sure save us a lot of trouble if we
 take advantage of it.

Well, when things come to computer sciences, I would not trust too
strongly the collective wisdom. Take a look at modern stuff, and you will
understand:
HTML5, an adaptation of a network protocol specialized in downloads with
format detection, is now used to stream videos, play games... and people
says that's a good news.
XML is now often seen as the ultimate format (and HTML5 is only derived
from it, of course...), but it is very, very verbose. Considering that
network bandwith is not an infinite resource, and that parsing XML is not
something which cost nothing, I have real difficulties to understand
why... JSON sometimes takes the advantage on XML. It is a little less
verbose, so I think it is a little better.
Nowadays, your favorite IDE will probably implement a plug-in interface.
This interface will be specific to IDE, of course. Some of it's uses will
be, by example, to know your files' names, and where they are. Most IDE's
users will quickly say that it is easier than command-line stuff... but
why those tools does not simply use ls or dir (depending on the OS) ?

Those are a small samples of collective wisdom, linked

Re: Moving from a proprietary OS - unnecessarily inful experience -- was [Re: I wish to advocate linux]

2013-03-05 Thread Martin McCormick

Miles Fidelman writes:
 Which leads me to take just a little issue with your comment that younger
 people have more useful experience. I'm actually not entirely sure that's
 true. If anything, younger people have narrower (or at least different)
 experience.

I tend to agree. Lisi is right that the experience of
younger people is more relevant to today's world but I also
think of that old quotation which says that those who do not
learn from history are doomed to keep repeating the same
mistakes and that is so, so true.

Those of us who also happen to be blind are painfully
aware of how useless a modern device is when there is no way to
find out other than eyeballs focused on a screen, what that
device is doing.

In Linux/Unix in general, we have a concept that is
rather old of output being something you can send where it needs
to go because you may not always predict where somebody will
need to send it for a particular job. The smart guys and girls
back in the day were not thinking about blind people but were
instead not wanting to nail shut any doors that might be needed
later.

In Windows and nitch operating systems for many
purposes, Some designer just figured the screen was good for
everybody and there is no way to divert text and numbers to any
other device. A person who is blind can't feed it in to a speech
synthesizer or Braille display. A repair technician can't
capture the output for service purposes. The door for further
use of the data is glued shut.

This is the difference between solving a problem in the
short term versus solving that and many more problems for all
times.

Younger people tend to be cought up in what's here now
and, if they are not careful, they think it is as good as it
gets.

Those of us who have been around the block a few times
know better how it should be and groan when yet another screen
gadget comes out that you can't use if the screen is not
visible.

That is just one example of countless other examples and
I don't wish for a minute that we were in an earlier time, but
let's value collective wisdom. It can sure save us a lot of
trouble if we take advantage of it.

It kind of reminds me of the squirrels and electric
power poles. Ever so often, we hear a raucous explosion in the
neighborhood. A squirrel has just learned a mortal lesson that
7200 volts will make your body explode and ruin your day.
Squirrels do not have a history of symbolic language or written
communication so if some other squirrels see their comrade change from
carbon-based life form to just a hand full of carbon in a
millisecond, they have no way to tell the rest of the squirrels
not to walk around on all those neat perches at the tops of the
poles, and so ten minutes later, another squirrel, another
explosion. I sometimes wonder how much smarter are we than those
squirrels? I guess that's for the philosophy mailing list.:-)

Martin McCormick


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201303051537.r25fbvit052...@x.it.okstate.edu

Re: Moving from a proprietary OS - unnecessarily inful experience -- was [Re: I wish to advocate linux]

2013-03-05 Thread Lisi Reisz

On Tuesday 05 March 2013 15:37:31 Martin McCormick wrote:
 Miles Fidelman writes:
  Which leads me to take just a little issue with your comment that
  younger people have more useful experience. I'm actually not entirely
  sure that's true. If anything, younger people have narrower (or at least
  different) experience.

   I tend to agree. Lisi is right that the experience of
 younger people is more relevant to today's world 

That is neither what I said nor what I meant.  I said:  But ***many*** much 
younger people have more useful 
experience.  Stars added this time.

I do not think that age is relevant to whether one's opinion is worth having 
or not, nor to whether a person has relevant experience or not.  Some people 
have relevant experience, some do not.  And age has little to do with it.  
Except in so far as my age group did not grow up with computers.

So I do not think that the experience of younger people is more relevant to 
today's world.  Sometimes it is, sometimes it isn't.

 but I also 
 think of that old quotation which says that those who do not
 learn from history are doomed to keep repeating the same
 mistakes and that is so, so true.

In my experience, human beings rarely in fact learn from history.  Sadly. 

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201303051557.22233.lisi.re...@gmail.com

Re: Moving from a proprietary OS - unnecessarily inful experience -- was [Re: I wish to advocate linux]

2013-03-05 Thread Martin McCormick

What I like about *nix is that it builds on the
experience of 3 decades plus a lot more sound theory. Nobody has
scrapped anything that is truly useful to cut corners and that
is what I find impressive.

I don't think anything is served by a battle of the
young guns versus the old codgers, but the young guns have more
history to learn and, if they really learn it, age isn't an
issue. It is all about knowledge. Someone once said that before
you tear down a fence, you should learn why it was built in the
first place.

I guess that at 61, I am either an old young gun or
turning in to a young old codger but I like to think about the
future much more than the past because a lot of what is
happening now is going to eventually be much better than it is
now as long as we don't loose track of why certain design
principles are just as necessary now as they were in 1968 or so
when Unix began at Bell Labs.

Martin McCormick


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201303051656.r25guijg053...@x.it.okstate.edu

Re: Moving from a proprietary OS - unnecessarily inful experience -- was [Re: I wish to advocate linux]

2013-03-05 Thread Chris Bannister

On Tue, Mar 05, 2013 at 10:56:18AM -0600, Martin McCormick wrote:
   What I like about *nix is that it builds on the
 experience of 3 decades plus a lot more sound theory. Nobody has
 scrapped anything that is truly useful to cut corners and that
 is what I find impressive.
 
   I don't think anything is served by a battle of the
 young guns versus the old codgers, but the young guns have more
 history to learn and, if they really learn it, age isn't an
 issue. It is all about knowledge. Someone once said that before

Data is not information, information is not knowledge, knowledge is not
understanding, understanding is not wisdom. ~Clifford Stoll

SCNR

-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130305182300.GA20982@tal

1 2 >

1 - 100 of 179 matches

Mail list logo