Re: Long neglected OS ... updating

[Joe]

On Thu, 03 Dec 2015 00:36:23 -0500
Harry Putnam  wrote:

> Resurrecting a neglected OS, need a little coaching about the output
> of `aptitude full-upgrade'.
> 

How 'long-neglected', and, importantly, which version is this?

If it is unstable, this may work, but I'd recommend using apt-get
rather than aptitude for this many packages. And as David says, it isn't
guaranteed  to work at all. I've lost two old unstables, which could no
doubt have been resurrected if I'd spent enough time, but it was easier
to reinstall.

-- 
Joe

Re: A stop job is running for...

[Nicolas George]

Le duodi 12 frimaire, an CCXXIV, Gene Heskett a écrit :
>  But it bugs the heck out of me that the guy/gal 
> doing the codeing doesn't watch the user lists, so it all has to wait on 
> someone qualified enough to wade thru the bug reporter forms and 
> actually file the bug.

Developer time is valuable.

> Thats quite often a week or more additional 
> delay before they are aware that there really is a problem.

Regarding support with guaranteed reaction time, you get exactly your
money's worth: 0.

> In the meantime, its hit another 200 users, discouraging them from ever 
> touching linux again.

If these people are so easily discouraged, and especially definitively
discouraged, they probably belong to the kind of people who only ever
complain and never contribute back. Maybe the community is better without
them.

> Unfortunately, the oar I steer this ship with could be swapped 
> for a toothpick and have exactly the same result.

Libre Software development is a meritocracy, not a democracy. Your oar is
exactly how large you make it. That means Linus' is larger than yours, of
course, and that is only right. I am still writing about steering oar.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Locale-related questions

[Martin Str|mberg]

In article  Nicolas George  
wrote:
> wchar_t portably. For starters, the i4s at microsoft decided that 64k
> characters should be enough for everyone, so if your cross-platform includes
> microsoftisms, you can not use wchar_t to represent an Unicode code point.
> The i4s at sun had other interesting ideas on how to make the coding for
> wchar_t itself depend on the locale.

I understand the reference to (the mess from) MS (although at that
time everyone in America did think 64k would be enough characters for
everyone, didn't they?), but not the one to Sun.

Were they the ones that made sure that C's wchar_t is standardized as
it it? Care to enlighten me?


-- 
MartinS

Re: Long neglected OS ... updating

[David Christensen]

On 12/02/2015 09:36 PM, Harry Putnam wrote:

Resurrecting a neglected OS, need a little coaching about the output
of `aptitude full-upgrade'.

...

Are there red flags in the above output that mean I need to do
preliminary work before `full-uptrade' ?


My goal is to *use* Debian, so I want stability.


I tried "apt-get dist-upgrade" in the past, and found it to be an 
exercise in frustration.  Even if it "worked", I typically ran into 
problems afterwards.



Only a backup, fresh system drive, fresh install, and restore cycle 
gives me the confidence I desire.



David

Long neglected OS ... updating

[Harry Putnam]

Resurrecting a neglected OS, need a little coaching about the output
of `aptitude full-upgrade'.

I want to know if this output is fairly typical or what one might
expect after neglecting an OS a good while...  but mostly if going
ahead is likely to land my subpar skilled behind in hot water.

I've stripped the hefty lists of pkgs leaving only what I thought
would be enough for an experienced hand to be able to offer an
educated opinion if this looks like a problematic  `full-upgrade' or
if it is one to pursue.

  aptitude upgrade
blah
blah

, 
|  aptitude full-upgrade
|
| The following NEW packages will be installed:
| [...]  
|  {141 pkgs}
|  
| The following packages will be REMOVED:
| [...]  
|  {76 pkgs}
| 
| The following packages will be upgraded:
| [...]  
|  {957 pkgs}
| 
| The following packages are RECOMMENDED but will NOT be installed:
| [...]  
|  { 19 pkgs}
| 
| [...]
| 
| The following packages have unmet dependencies:
| 
|  liblognorm2 : Breaks: liblognorm0 but 0.3.7-1 is installed.
|  libsigc++-2.0-0v5 : Conflicts: libsigc++-2.0-0c2a but 2.4.1-1 is installed.
|  libxapian22v5 : Conflicts: libxapian22 but 1.2.21-1 is installed.
|  libcwidget3v5 : Conflicts: libcwidget3 but 0.5.17-2 is installed.
|  libtag1v5-vanilla : Breaks: libtag1-vanilla but 1.9.1-2.1 is installed.
|  libtag1v5 : Conflicts: libtag1c2a but 1.9.1-2.1 is installed.
| 
| The following actions will resolve these dependencies:
| 
|   Remove the following packages:   
| 1)  aptitude   
| 2)  liblognorm0
| 3)  libtag1-vanilla
| 4)  libtag1c2a 
| 5)  synaptic   
| 
|   Keep the following packages at their current version:
| 6)  gstreamer0.10-plugins-good [Not Installed] 
| 7)  libcwidget3v5 [Not Installed]  
| 8)  libept1.4.16 [Not Installed]   
| 9)  libsigc++-2.0-0v5 [Not Installed]  
| 10) libxapian22v5 [Not Installed]  

NOTE: I'm a little puzzled at the above (6-10).  Seems to be a bit
of an oxymoron or something.

|   Leave the following dependencies unresolved: 
| 11) aptitude-common recommends aptitude
| 12) task-lxde-desktop recommends synaptic  
| 13) iceweasel recommends gstreamer0.10-plugins-good
| 
| Accept this solution? [Y/n/q/?] 
`

One thing bugging me is the idea of leaving the odd dependencies
unresolved (the last items 11, 12, 13)

Are there red flags in the above output that mean I need to do
preliminary work before `full-uptrade' ?

Re: X using ~ 35% of a CPU core

[Celejar]

On Wed, 02 Dec 2015 15:49:40 +0100
Sven Arvidsson  wrote:

> On Tue, 2015-12-01 at 18:14 -0500, Celejar wrote:
> > tried tailing the X log when I caught the problem occurring, and I
> > found zillions of these:
> > 
> [snipped log]
> > 
> > When the problem ceases (CPU usage back down to zero / normal), these
> > lines cease, too. Anyone know what this is, and / or how to fix it?
> 
> I think a bug report would be in order. 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806929

> As for a work-around, maybe it's possible to turn off logging for X, or
> at least make it less verbose?
> 
> It might be the case that the bug is actually fixed in a later version
> of the intel driver, but that might necessitate an upgrade to
> testing... 

Thanks for the help and suggestions. I'll see if I get any response
from the maintainers.

Celejar

Re: OT: reply styles, family matters

[Reco]

Hi.

On Wed, 2 Dec 2015 21:42:40 -0500
"Neal P. Murphy"  wrote:

> On Thu, 3 Dec 2015 13:34:58 +1300
> Chris Bannister  wrote:
> 
> > On Wed, Dec 02, 2015 at 08:47:00PM +0100, Erwan David wrote:
> > > Le 02/12/2015 20:41, Chris Bannister a écrit :
> > > > On Wed, Dec 02, 2015 at 02:21:04PM +1000, Stuart Longland wrote:
> > > >> I often counter that by passing my would-be reply through tac and
> > > >> top-post it that way.
> > > >>
> > > >> Then they see it from my perspective.
> > > > What is 'tac'?
> > > >
> > > TAC(1)
> > >
> > > User
> > > Commands  
> > >  
> > > TAC(1)
> > > 
> > > NAME
> > >tac - concatenate and print files in reverse
> > 
> > Ahh! So you can feed mp3s through it and listen for any messages from
> > the devil, no doubt. :)
> 
> tac only prints in reverse line order.
> 
> You have to print the file in reverse bit order for that to work. :)

And for this task they give "sox reverse" in Debian.

If only such trick could be used for video too - that would be
awesome :)

Reco

Re: A stop job is running for...

[Gene Heskett]

On Wednesday 02 December 2015 22:05:10 Neal P. Murphy wrote:

> On Thu, 3 Dec 2015 15:48:07 +1300
>
> Chris Bannister  wrote:
> > On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > > In the meantime, its hit another 200 users, discouraging them from
> > > ever touching linux again.  In that regard, we are our own worst
> > > enemy at times.  Unfortunately, the oar I steer this ship with
> > > could be swapped for a toothpick and have exactly the same result.
> >
> > Or you could be in the Windoze world ' stuck up *cough* *cough*
> > *whistle* *whistle* ... with no paddle.' :)
>
> And half a gnu.

And how is that best done on the barbie?

Sorry, couldn't resist, must do better.  Or do I get the Senior Citizen 
discount on this stuff?  As probably the oldest subscriber to this list 
at 81, does that count?  Or is there someone older yet?  ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: A stop job is running for...

[Gene Heskett]

On Wednesday 02 December 2015 21:48:07 Chris Bannister wrote:

> On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > In the meantime, its hit another 200 users, discouraging them from
> > ever touching linux again.  In that regard, we are our own worst
> > enemy at times.  Unfortunately, the oar I steer this ship with could
> > be swapped for a toothpick and have exactly the same result.
>
> Or you could be in the Windoze world ' stuck up *cough* *cough*
> *whistle* *whistle* ... with no paddle.' :)

Why the heck to do think I'm here Chris?  I don't allow winderz on the 
property unless I get suckered into trying to fix a box full of viri and 
keyloggers they picked up while trolling for good porn or the next get 
rich quick scheme?  I've already been there, done that, skipped the 
T-shirt, and swore I'd never do that again.  I have come to the 
conclusion that winderz lusers deserve what they get.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: A stop job is running for...

[Neal P. Murphy]

On Thu, 3 Dec 2015 15:48:07 +1300
Chris Bannister  wrote:

> On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > 
> > In the meantime, its hit another 200 users, discouraging them from ever 
> > touching linux again.  In that regard, we are our own worst enemy at 
> > times.  Unfortunately, the oar I steer this ship with could be swapped 
> > for a toothpick and have exactly the same result.
> 
> Or you could be in the Windoze world ' stuck up *cough* *cough* 
> *whistle* *whistle* ... with no paddle.' :)
> 

And half a gnu.

Re: A stop job is running for...

[Chris Bannister]

On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> 
> In the meantime, its hit another 200 users, discouraging them from ever 
> touching linux again.  In that regard, we are our own worst enemy at 
> times.  Unfortunately, the oar I steer this ship with could be swapped 
> for a toothpick and have exactly the same result.

Or you could be in the Windoze world ' stuck up *cough* *cough* 
*whistle* *whistle* ... with no paddle.' :)

-- 
"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

Re: OT: reply styles, family matters

[Neal P. Murphy]

On Thu, 3 Dec 2015 13:34:58 +1300
Chris Bannister  wrote:

> On Wed, Dec 02, 2015 at 08:47:00PM +0100, Erwan David wrote:
> > Le 02/12/2015 20:41, Chris Bannister a écrit :
> > > On Wed, Dec 02, 2015 at 02:21:04PM +1000, Stuart Longland wrote:
> > >> I often counter that by passing my would-be reply through tac and
> > >> top-post it that way.
> > >>
> > >> Then they see it from my perspective.
> > > What is 'tac'?
> > >
> > TAC(1)  
> >  
> > User
> > Commands
> >
> > TAC(1)
> > 
> > NAME
> >tac - concatenate and print files in reverse
> 
> Ahh! So you can feed mp3s through it and listen for any messages from
> the devil, no doubt. :)

tac only prints in reverse line order.

You have to print the file in reverse bit order for that to work. :)

Re: A stop job is running for...

[Gene Heskett]

On Wednesday 02 December 2015 14:02:50 Jape Person wrote:

> On 12/02/2015 01:21 PM, Gene Heskett wrote:
> > On Wednesday 02 December 2015 06:06:09 Martin Read wrote:
> >> On 02/12/15 03:07, James P. Wallen wrote:
> >>> Thanks for your response, Sven. It's nice to know that someone
> >>> else has seen this type of problem. I was thinking that this could
> >>> be self-inflicted. Perhaps that's a little less likely now.
> >>>
> >>> So, is this behavior controlled by systemd?
> >>>
> >>> I'm not trying to start a fracas. I'm really interested. What I'm
> >>> asking is, do I need to start poring over systemd documentation to
> >>> see if there might be a way to control this behavior?
> >>
> >> If a stop job is taking two minutes, that suggests that the service
> >> has one or more ExecStop lines defined in its service unit and that
> >> one of those commands is taking an unduly long time to complete for
> >> some reason.
> >>
> >> The default and per-service timeout values for stopping a service
> >> (after which systemd gives up and sends fatal signals to all of the
> >> service's processes) are configurable; see the
> >> systemd-system.conf(5) and systemd.service(5) man pages for
> >> details.
> >
> > 'scuse me, but shouldn't the errant process be fixed so it can stop
> > and clean up after itself?  Thats the real bug here.
> >
> >
> > Cheers, Gene Heskett
>
> It's occurred to me that, though I have occasionally seen service
> shutown issues with sysv-init, they were never as pervasive or
> repetitve as it has been since switching to systemd as the init
> system. And the issue seems to be happening with several different
> types of services. That at least begs the question as to whether the
> problem is really with the services themselves or with the way they
> are controlled by systemd.
>
> I'm guessing that this is just a sort of shakedown cruise problem,
> where it may be that those who develop and maintain some packages will
> have to customize those packages' service units to work properly with
> systemd OR that there are problems with systemd itself OR both.
>
> Or maybe end users like me just need to learn to deal with systemd.
> However, the idea of having end users edit service units hardly seems
> like an ideal routine.
>
> Regards,
> JP

I can agree with that. I can hack up a bash script now & then, but 
wholesale patching really is the sources problem once he/she is aware 
there is a problem.  But it bugs the heck out of me that the guy/gal 
doing the codeing doesn't watch the user lists, so it all has to wait on 
someone qualified enough to wade thru the bug reporter forms and 
actually file the bug.  Thats quite often a week or more additional 
delay before they are aware that there really is a problem.

In the meantime, its hit another 200 users, discouraging them from ever 
touching linux again.  In that regard, we are our own worst enemy at 
times.  Unfortunately, the oar I steer this ship with could be swapped 
for a toothpick and have exactly the same result.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: OT: reply styles, family matters

[Lisi Reisz]

On Wednesday 02 December 2015 04:21:04 Stuart Longland wrote:
> On 01/12/15 11:56, John Hasler wrote:
> > Bob Bernstein writes:
> >> With that as background, here is my question/request: is anyone aware
> >> of a spirited defence of our ideal method of "selective quoting," (for
> >> lack of a better label) one, say, that perhaps has achieved the status
> >> of a "net classic?" Surely some 'net genius has dealt these
> >> nay-sayers, who seem to LIKE top-posting, a solid uppercut?
> >
> > Waste of effort.  The usual reason for top-posting (or bottom-posting
> > without editing) is laziness.
>
> I often counter that by passing my would-be reply through tac and
> top-post it that way.
>
> Then they see it from my perspective.

That is brilliant!!  I can'tr wait to try it on a desreving recipient.

Now, has anyone got an equivalent to impose on People who WILL send HTML?

Lisi

Re: OT: reply styles, family matters

[Chris Bannister]

On Wed, Dec 02, 2015 at 08:47:00PM +0100, Erwan David wrote:
> Le 02/12/2015 20:41, Chris Bannister a écrit :
> > On Wed, Dec 02, 2015 at 02:21:04PM +1000, Stuart Longland wrote:
> >> I often counter that by passing my would-be reply through tac and
> >> top-post it that way.
> >>
> >> Then they see it from my perspective.
> > What is 'tac'?
> >
> TAC(1)
>
> User
> Commands  
>  
> TAC(1)
> 
> NAME
>tac - concatenate and print files in reverse

Ahh! So you can feed mp3s through it and listen for any messages from
the devil, no doubt. :)

Thanks everyone for the info.

-- 
"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

[HITB-Announce] HITB2016AMS Call for Papers

[Hafez Kamal]

The Call for Papers for the 7th annual Hack In The Box Security
Conference in The Netherlands is now open!

Call for Papers: http://cfp.hackinthebox.org/
Event Website: http://conference.hitb.org/hitbseccconf2016ams/

HITBSecConf has always been an attack oriented deep-knowledge research
event aimed at not only bringing the security community together, but
one that also highlights and showcases cutting edge research from up and
coming talent. If you're working on new ways to break out of sandboxes,
mess with millions of IoT devices or if you've found a new way to defend
these threats, we definitely want to see you on stage at HITBSecConf2016
- Amsterdam!

Held at the NH Grand Krasnapolsky in Amsterdam on the 26th and 27th of
May, the opening keynote will be delivered by Morgan Marquis-Boire, one
of the influential minds of IT Security and Italian WIRED's 50 people of
2014. On Day 2, Chris Evans formerly head of Google's Project Zero will
deliver the morning keynote and Sophia D'Antoine, who has been working
on malicious applications of hardware side channels, will deliver the
closing keynote.

We are looking for 60 and 120 minute offensive focused deep-knowledge
presentations. Research that is new, novel and preferably material
that has not been presented elsewhere before.

Submission Deadlines:

   Round #1 selection: 14th January 2016
   Round #2 selection: 14th February 2016

Each accepted submission will entitle the speaker(s) to
accommodation for 3 nights / 4 days and travel expense reimbursement
up to EUR1200.00 _per speaking slot_

Topics of interest include, but are not limited to the following:

  IoT Security
  Cloud Security
  File System Security
  3G/4G/WIMAX Security
  SS7/GSM/VoIP Security
  Security of Medical Devices
  Critical Infrastructure Security
  Smartphone / MobileSecurity
  Smart Card and Physical Security
  Network Protocols, Analysis and Attacks
  Applications of Cryptographic Techniques
  Side Channel Analysis of Hardware Devices
  Analysis of Malicious Code / Viruses / Malware
  Data Recovery, Forensics and Incident Response
  Hardware based attacks and reverse engineering
  Windows / Linux / OS X / *NIX Security Vulnerabilities
  Next Generation Exploit and Exploit Mitigation Techniques
  NFC, WLAN, GPS, HAM Radio, Satellite, RFID and Bluetooth Security

WHITE PAPER: If your presentation is short listed for inclusion into the
conference program, a technical white paper must also be provided for
review (3000 - 5000 words).

Your submissions will be reviewed by The HITB CFP Review Committee:

Charlie Miller, Uber Advanced Technology Center
Katie Moussouris, Chief Policy Officer, HackerOne
Marco Balduzzi, Lead Research Scientist, Trend Micro
Dr. Sophia Bekrar, Senior Security Researcher, Vupen
Itzik Kotler, Chief Technology Officer, Security Art
Cesar Cerrudo, Chief Technology Officer, IOActive
Jeremiah Grossman, Founder, Whitehat Security
Andrew Cushman, Senior Director, Microsoft
Saumil Shah, Founder CEO Net-Square
Thanh 'RD' Nguyen, THC, VNSECURITY
Alexander Kornburst, Red Database
Fredric Raynal, QuarksLab
Shreeraj Shah, Founder, BlueInfy
Emmanuel Gadaix, Founder, TSTF
Andrea Barisani, Inverse Path
Philippe Langlois, TSTF
Ed Skoudis, InGuardians
Haroon Meer, Thinkst
Chris Evans, Google
Raoul Chiesa, TSTF/ISECOM
rsnake, SecTheory
Gal Diskin, Palo Alto Networks
Skyper, THC

Note: We do not accept product or vendor related pitches. If you would
like to showcase your company's products or technology at the
conference, please email conferencei...@hackinthebox.org to request for
a sponsorship kit

Regards,
Hafez Kamal
Hack in The Box (M) Sdn. Bhd
36th Floor, Menara Maxis
Kuala Lumpur City Centre
50088 Kuala Lumpur, Malaysia
Tel: +603-26157299
Fax: +603-26150088

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 05:59 PM, Don Armstrong wrote:

On Wed, 02 Dec 2015, Jape Person wrote:

It's occurred to me that, though I have occasionally seen service
shutown issues with sysv-init, they were never as pervasive or
repetitve as it has been since switching to systemd as the init
system.


This is generally because sysv-init tends to not pay attention to
whether a particular service has actually stopped. Many init scripts
just send an appropriate signal, hope for the best, and return control.



Yes, that was my understanding. Sysv-init worked just fine for my my use 
cases, but I can easily see that the arrangement might not work so well 
for something like, say, a print server.



If your goal is just to shutdown the system regardless of what is
actually going on, that's great... but if you value your data, that's
not really a workable solution.

That said, most of these cases are bugs, not really cases where the
daemon is actually doing something; reporting the bugs when you run into
them will help them get fixed.



I finally found this older thread(1) which gave me some ideas as to how 
to proceed in trying to find the cause of the issue.


I want to be useful, but it takes a bit of time for those of us who 
fumble about in darkness to find the walls. We have to find one of those 
before we stand a chance of getting to the cave entrance. I may return 
if I don't first impale myself on a stalagmite.


;-)

JP

(1) https://bugzilla.redhat.com/show_bug.cgi?id=1044602

Cannot Setup DNS on Jessie

[fritz]

I have set up Jessie some time ago and have recently connected it to my 
home network however it is not resolving names via DNS. To get started I 
realize there are a few ways to set this up but I am assuming the Jessie 
install used NetworkManager. if I look in my running processes list I see:

  /usr/sbin/NetworkManager --no-daemon
Does this mean that it is presently running and subsuming the network 
management tasks?


Thanks
Fritz

Re: A stop job is running for...

[Don Armstrong]

On Wed, 02 Dec 2015, Jape Person wrote:
> It's occurred to me that, though I have occasionally seen service
> shutown issues with sysv-init, they were never as pervasive or
> repetitve as it has been since switching to systemd as the init
> system.

This is generally because sysv-init tends to not pay attention to
whether a particular service has actually stopped. Many init scripts
just send an appropriate signal, hope for the best, and return control.
 
If your goal is just to shutdown the system regardless of what is
actually going on, that's great... but if you value your data, that's
not really a workable solution.

That said, most of these cases are bugs, not really cases where the
daemon is actually doing something; reporting the bugs when you run into
them will help them get fixed.

-- 
Don Armstrong  http://www.donarmstrong.com

"You know," said Arthur, "it's at times like this, when I'm trapped in
a Vogon airlock with a man from Betelgeuse, and about to die from
asphyxiation in deep space that I really wish I'd listened to what my
mother told me when I was young."
"Why, what did she tell you?"
"I don't know, I didn't listen."
 –- Douglas Adams _The Hitchhikers Guide To The Galaxy_

Re: OT: reply styles, family matters

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Dec 03, 2015 at 08:41:44AM +1300, Chris Bannister wrote:
> On Wed, Dec 02, 2015 at 02:21:04PM +1000, Stuart Longland wrote:
> > 
> > I often counter that by passing my would-be reply through tac and
> > top-post it that way.
> > 
> > Then they see it from my perspective.
> 
> What is 'tac'?

Properly answered by others; just a little addendum: like 'cat' but
backwards :-)

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZfV1kACgkQBcgs9XrR2kZ0/wCfaF0XtymMDO3XGCu2yFSlurDw
1z8AnjKWWWZZ1tmEBOebATrvB6WW+PYa
=GnZW
-END PGP SIGNATURE-

Re: OT: reply styles, family matters

[Ric Moore]

On 12/02/2015 03:03 PM, John Hasler wrote:

Chris Bannister writes:
What is 'tac'?

DESCRIPTION
Write each FILE to standard output, last line first.


That's the beauty of UNIX. They have thought of everything you could 
ever possibly need, including backwards printing. :/ Ric




--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: OT: reply styles, family matters

[Ric Moore]

On 12/02/2015 12:19 PM, Bob Bernstein wrote:

On Wed, 2 Dec 2015, Mart van de Wege wrote:



If the only time you see interleaved comments is in 'fisked' pieces,
then I could understand not feeling comfortable when someone does that
in an email reply.


Yes, point well taken.


I suppose we can start to expect fisk offender lists soon? Maybe a 12 
step program?? "My name is RIC and I have fisked!" :) Ric



--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: OT: reply styles, family matters

[John Hasler]

Chris Bannister writes:
What is 'tac'?

DESCRIPTION
   Write each FILE to standard output, last line first.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: OT: reply styles, family matters

[Erwan David]

Le 02/12/2015 20:41, Chris Bannister a écrit :
> On Wed, Dec 02, 2015 at 02:21:04PM +1000, Stuart Longland wrote:
>> I often counter that by passing my would-be reply through tac and
>> top-post it that way.
>>
>> Then they see it from my perspective.
> What is 'tac'?
>
TAC(1)  
 
User
Commands
   
TAC(1)

NAME
   tac - concatenate and print files in reverse

Re: OT: reply styles, family matters

[Chris Bannister]

On Wed, Dec 02, 2015 at 02:21:04PM +1000, Stuart Longland wrote:
> 
> I often counter that by passing my would-be reply through tac and
> top-post it that way.
> 
> Then they see it from my perspective.

What is 'tac'?

-- 
"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

Re: Upgrade to Jessie lost all monitor resolutions except 1024x768

[Chris Bannister]

On Tue, Dec 01, 2015 at 11:25:16AM -0500, Felix Miata wrote:
> 
> Some people think "all information" should be saved for the future. Others
> don't. It's your choice. Be aware that "all information" in the case of Xorg
> logs and dmesg is voluminous, and like other mailing list info, stays on the
> Internet forever. As some small portion of Xorg.0.log is arguably personal,
> one may not wish it to be available forever. 

I'm intrigued, what personal/private information is in the Xorg log?

-- 
"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

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 02:04 PM, Michael Biebl wrote:

Am 02.12.2015 um 18:58 schrieb Jape Person:

On 12/02/2015 12:17 PM, Michael Biebl wrote:

In case you run into such a situation again, where a service is blocking
the shutdown you can of course just use force and pull the plug or use
sysrq b.
But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
systemd then will initiate a forced shutdown. See [1].


..


Do you think it's better just force the shutdown than to rummage around
in the service unit files? I'm loath to edit system configuration files
unless it's to configure something like smartmontools or some such --
you know, something that is more ordinarily edited in order to get it to
do some specific job.

I guess that argument could apply to service units, but I'm not used to
this stuff, yet.


In your case it seems to happen much more often, that the service does
not shutdown in a timely manner. So this should actually be investigated
properly.



Aye, there's the rub!

The phrase "investigated properly" would seem to indicate that someone 
who knows what s/he's doing would be performing the analysis.


How about me doing my usual thumb-fingered job on it, and then coming 
back here for advice when I have enough bruises on my forehead to prove 
that I have indeed been to the wall?


;-)


My remark regarding using a forced shutdown via ctrl+alt+-del is only
supposed to be a fix for very rare cases.

I also wouldn't consider it a proper fix to simply decrease the shutdown
timeout of the affected service. That's a hack at best.

Michael




Yes, I was beginning to be dimly aware. I don't like futzing around with 
files in system or root owned areas unless they are designed to be 
futzed with. Not only because I don't like having my modifications 
overwritten during upgrades (and I do always choose to write the 
maintainer's upgrade over my modification and then change it again as 
necessary), but also because I don't like knowing that all sorts of 
weird stuff might happen if I do something particularly stupid.


I am, after all, very experienced and accomplished at being particularly 
stupid. It's why I run testing. I like having a plausible explanation, 
other than my own ineptitude, for having things go wrong.


Have a nice day!

JP

Re: A stop job is running for...

[Michael Biebl]

Am 02.12.2015 um 18:58 schrieb Jape Person:
> On 12/02/2015 12:17 PM, Michael Biebl wrote:
>> In case you run into such a situation again, where a service is blocking
>> the shutdown you can of course just use force and pull the plug or use
>> sysrq b.
>> But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
>> systemd then will initiate a forced shutdown. See [1].

..

> Do you think it's better just force the shutdown than to rummage around
> in the service unit files? I'm loath to edit system configuration files
> unless it's to configure something like smartmontools or some such --
> you know, something that is more ordinarily edited in order to get it to
> do some specific job.
> 
> I guess that argument could apply to service units, but I'm not used to
> this stuff, yet.

In your case it seems to happen much more often, that the service does
not shutdown in a timely manner. So this should actually be investigated
properly.

My remark regarding using a forced shutdown via ctrl+alt+-del is only
supposed to be a fix for very rare cases.

I also wouldn't consider it a proper fix to simply decrease the shutdown
timeout of the affected service. That's a hack at best.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 01:21 PM, Gene Heskett wrote:

On Wednesday 02 December 2015 06:06:09 Martin Read wrote:


On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else
has seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm
asking is, do I need to start poring over systemd documentation to
see if there might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service
has one or more ExecStop lines defined in its service unit and that
one of those commands is taking an unduly long time to complete for
some reason.

The default and per-service timeout values for stopping a service
(after which systemd gives up and sends fatal signals to all of the
service's processes) are configurable; see the systemd-system.conf(5)
and systemd.service(5) man pages for details.


'scuse me, but shouldn't the errant process be fixed so it can stop and
clean up after itself?  Thats the real bug here.


Cheers, Gene Heskett



It's occurred to me that, though I have occasionally seen service 
shutown issues with sysv-init, they were never as pervasive or repetitve 
as it has been since switching to systemd as the init system. And the 
issue seems to be happening with several different types of services. 
That at least begs the question as to whether the problem is really with 
the services themselves or with the way they are controlled by systemd.


I'm guessing that this is just a sort of shakedown cruise problem, where 
it may be that those who develop and maintain some packages will have to 
customize those packages' service units to work properly with systemd OR 
that there are problems with systemd itself OR both.


Or maybe end users like me just need to learn to deal with systemd. 
However, the idea of having end users edit service units hardly seems 
like an ideal routine.


Regards,
JP

Re: A stop job is running for...

[Gene Heskett]

On Wednesday 02 December 2015 06:06:09 Martin Read wrote:

> On 02/12/15 03:07, James P. Wallen wrote:
> > Thanks for your response, Sven. It's nice to know that someone else
> > has seen this type of problem. I was thinking that this could be
> > self-inflicted. Perhaps that's a little less likely now.
> >
> > So, is this behavior controlled by systemd?
> >
> > I'm not trying to start a fracas. I'm really interested. What I'm
> > asking is, do I need to start poring over systemd documentation to
> > see if there might be a way to control this behavior?
>
> If a stop job is taking two minutes, that suggests that the service
> has one or more ExecStop lines defined in its service unit and that
> one of those commands is taking an unduly long time to complete for
> some reason.
>
> The default and per-service timeout values for stopping a service
> (after which systemd gives up and sends fatal signals to all of the
> service's processes) are configurable; see the systemd-system.conf(5)
> and systemd.service(5) man pages for details.

'scuse me, but shouldn't the errant process be fixed so it can stop and 
clean up after itself?  Thats the real bug here.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Problem installing Jessie {8.0} to USB flash drive

[Richard Owlett]

I have successful installed Squeeze {6.0.10} to a flash drive.
I can't seem to do the same with Jessie {8.0}.

All my installs are from purchased copies of DVD 1.
Both Squeeze and Jessie install to the hard drive without problems.

My first attempt with Jessie was using Expert mode but accepting 
all defaults except configuring network [none present] and 
setting clock to UTC. On reboot all I got was a blank screen and 
a flashing cursor.


On my second attempt I first installed Squeeze to the flash drive 
to verify that all hardware [and the operator ;] was functional. 
It/I was.


I then installed Squeeze to entire drive. It booted normally.
I shrank the Squeeze partition with Gparted and then attempted to 
install Jessie to the freed space. All appeared to go as expected.


HOWEVER, on reboot I saw the Grub screen created by the install 
of Squeeze.

I booted to Squeeze and ran update-grub.
On reboot there were now entries for both Squeeze and Jessie. 
BOTH could be started and appeared normal.


1. Is this a known problem? How would I search BTS for it?
2. How would I have the installer send all relevant log files to 
my hard drive?


TIA

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 12:17 PM, Michael Biebl wrote:

Am 02.12.2015 um 18:05 schrieb Jape Person:

On 12/02/2015 10:49 AM, David Wright wrote:

I have observed behaviour where, when the time limit of 90 seconds is
reached, the limit increases by another 90 seconds and nothing else
happens (for hours). eg

[ <*> ] A stop job is running for Manage, Install and Generate Color
Profiles (34min 54s / 36min)_

Fortunately, that hasn't happened for a few months. It's very
embarrassing when my laptop takes longer to close down than my
wife's W10.


Sounds like it could be hard to reproduce indeed.


Now *that* would be annoying.


In case you run into such a situation again, where a service is blocking
the shutdown you can of course just use force and pull the plug or use
sysrq b.
But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
systemd then will initiate a forced shutdown. See [1].

Regards,
Michael


http://www.freedesktop.org/software/systemd/man/systemd.html#SIGINT



Seven times. How lucky!

Heh.

Thank you, Michael.

Do you think it's better just force the shutdown than to rummage around 
in the service unit files? I'm loath to edit system configuration files 
unless it's to configure something like smartmontools or some such -- 
you know, something that is more ordinarily edited in order to get it to 
do some specific job.


I guess that argument could apply to service units, but I'm not used to 
this stuff, yet.


Thanks again,
JP

Re: OT: reply styles, family matters

[Bob Bernstein]

On Wed, 2 Dec 2015, Mart van de Wege wrote:

It may be that inline replies are associated with the practice 
of 'fisking' [...]


Yes. I stumbled into that mental association some time around 
3:30am ET, at which ungodly hour thoughts of fisking seem to 
rise of their own accord. 


[...] which in conservative circles is interleaving 
derogative comments with the target of derision's original 
content (usually a blog post).


My inner conservative wants to ask, "Are not liberals smart 
enough to fisk each other's written work?"


My inner liberal wants to ask, "Why are conservatives such a 
picky, fussy, argumentative bunch?


I believe most fisking is done by conservatives, but much of 
that activity, and certainly the best of it, is aimed at their 
conservative comrade's work.


If the only time you see interleaved comments is in 'fisked' 
pieces, then I could understand not feeling comfortable when 
someone does that in an email reply.


Yes, point well taken.

--
Bob Bernstein

Re: A stop job is running for...

[Michael Biebl]

Am 02.12.2015 um 18:05 schrieb Jape Person:
> On 12/02/2015 10:49 AM, David Wright wrote:
>> I have observed behaviour where, when the time limit of 90 seconds is
>> reached, the limit increases by another 90 seconds and nothing else
>> happens (for hours). eg
>>
>> [ <*> ] A stop job is running for Manage, Install and Generate Color
>> Profiles (34min 54s / 36min)_
>>
>> Fortunately, that hasn't happened for a few months. It's very
>> embarrassing when my laptop takes longer to close down than my
>> wife's W10.

Sounds like it could be hard to reproduce indeed.

> Now *that* would be annoying.

In case you run into such a situation again, where a service is blocking
the shutdown you can of course just use force and pull the plug or use
sysrq b.
But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
systemd then will initiate a forced shutdown. See [1].

Regards,
Michael


http://www.freedesktop.org/software/systemd/man/systemd.html#SIGINT
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 10:49 AM, David Wright wrote:

On Wed 02 Dec 2015 at 11:06:09 (+), Martin Read wrote:

On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else has
seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm asking
is, do I need to start poring over systemd documentation to see if there
might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service
has one or more ExecStop lines defined in its service unit and that
one of those commands is taking an unduly long time to complete for
some reason.

The default and per-service timeout values for stopping a service
(after which systemd gives up and sends fatal signals to all of the
service's processes) are configurable; see the
systemd-system.conf(5) and systemd.service(5) man pages for details.


I have observed behaviour where, when the time limit of 90 seconds is
reached, the limit increases by another 90 seconds and nothing else
happens (for hours). eg

[ <*> ] A stop job is running for Manage, Install and Generate Color Profiles 
(34min 54s / 36min)_

Fortunately, that hasn't happened for a few months. It's very
embarrassing when my laptop takes longer to close down than my
wife's W10.

Cheers,
David.



Now *that* would be annoying.

It's interesting that I have been unable to find bug reports about this. 
I guess it might be kind of hard to figure which packages to file a 
report against. I can imagine there might be a bit of finger-pointing 
between the systemd folks and the developers and maintainers of the 
various packages services when unfortunate interactions via the service 
units are hard to tease out.


It is at least nice to have a way to force an errant service to shut 
down -- assuming the scheme works. I haven't experimented yet, but 
that's on the schedule for later today. I suppose it's unlikely that 
forcing a service like CUPS or NTP to shut down will lead to other 
problems. I hope.

Can't configure gnome-terminal

[sdlee]

My gnome-terminal (version 3.4.1.1)seems to be broken, but can't find how to 
fix it. The main problem is I can't configure the profile. Normally this can 
be done through clicking Edit > Profiles > Edit. Right now when I click Edit 
in the Profiles dialogues, nothing happened as if I haven't click Edit 
button, but New and Delete button works as normal without a problem. How can 
I fix the problem?
Thanks

Re: A stop job is running for...

[David Wright]

On Wed 02 Dec 2015 at 11:06:09 (+), Martin Read wrote:
> On 02/12/15 03:07, James P. Wallen wrote:
> >Thanks for your response, Sven. It's nice to know that someone else has
> >seen this type of problem. I was thinking that this could be
> >self-inflicted. Perhaps that's a little less likely now.
> >
> >So, is this behavior controlled by systemd?
> >
> >I'm not trying to start a fracas. I'm really interested. What I'm asking
> >is, do I need to start poring over systemd documentation to see if there
> >might be a way to control this behavior?
> 
> If a stop job is taking two minutes, that suggests that the service
> has one or more ExecStop lines defined in its service unit and that
> one of those commands is taking an unduly long time to complete for
> some reason.
> 
> The default and per-service timeout values for stopping a service
> (after which systemd gives up and sends fatal signals to all of the
> service's processes) are configurable; see the
> systemd-system.conf(5) and systemd.service(5) man pages for details.

I have observed behaviour where, when the time limit of 90 seconds is
reached, the limit increases by another 90 seconds and nothing else
happens (for hours). eg

[ <*> ] A stop job is running for Manage, Install and Generate Color Profiles 
(34min 54s / 36min)_

Fortunately, that hasn't happened for a few months. It's very
embarrassing when my laptop takes longer to close down than my
wife's W10.

Cheers,
David.

Re: Xorg replaces TTY1

[Teemu Likonen]

Felix Miata [2015-12-02 01:52:18-05] wrote:

> /etc/X11/xorg.conf.d/00-keyboard.conf always works for me:
>
>   Section "InputClass"
>   Identifier "system-keyboard"
>   Option "XkbOptions" "terminate:ctrl_alt_bksp"
>   EndSection

I think /etc/default/keyboard is a good place too:

XKBOPTIONS=terminate:ctrl_alt_bksp,plus,some,other,settings

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 06:06 AM, Martin Read wrote:

The default and per-service timeout values for stopping a service (after
which systemd gives up and sends fatal signals to all of the service's
processes) are configurable; see the systemd-system.conf(5) and
systemd.service(5) man pages for details.




This could be useful. Time to wade into the man pages. I'm grateful.

Re: A stop job is running for...

[James P. Wallen]

On 12/02/2015 06:06 AM, Martin Read wrote:

On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else has
seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm asking
is, do I need to start poring over systemd documentation to see if there
might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service has
one or more ExecStop lines defined in its service unit and that one of
those commands is taking an unduly long time to complete for some reason.

The default and per-service timeout values for stopping a service (after
which systemd gives up and sends fatal signals to all of the service's
processes) are configurable; see the systemd-system.conf(5) and
systemd.service(5) man pages for details.




I'm going to look into this right away and do some testing to see if I 
can fix the problems on my system.


Thanks!

Re: X using ~ 35% of a CPU core

[Sven Arvidsson]

On Tue, 2015-12-01 at 18:14 -0500, Celejar wrote:
> tried tailing the X log when I caught the problem occurring, and I
> found zillions of these:
> 
[snipped log]
> 
> When the problem ceases (CPU usage back down to zero / normal), these
> lines cease, too. Anyone know what this is, and / or how to fix it?

I think a bug report would be in order. 

As for a work-around, maybe it's possible to turn off logging for X, or
at least make it less verbose?

It might be the case that the bug is actually fixed in a later version
of the intel driver, but that might necessitate an upgrade to
testing... 


-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 6FAB5CD5





signature.asc
Description: This is a digitally signed message part

Re: Can't startx as normal user

[Sven Arvidsson]

On Tue, 2015-12-01 at 22:23 -0300, Draco Metallium(Rodrigo S. Cañibano)
> > The NEWS entry should have been picked up by apt-listchanges:
> 
> I must have missed it. Thanks!

Looks like it was added after the change was made, so it's possible
that you made the upgrade before it was added.

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 6FAB5CD5





signature.asc
Description: This is a digitally signed message part

Re: Meld in Jessie: how to not install all the insane dependencies

[MI]

It looks like the meld package wants to install a full desktop with all the bells 
and whistles on my headless server.


So the question is: what is the best way to install meld without all the cruft?


I finally did install the previous version 1.6.1-1 (from Debian 7 Wheezy).

I only needed few dependencies, and it is actually much better than the version 
currently in Jessie. (I use meld over remote ssh X sessions, and the Jessie version 
of meld does something which prevents me from getting to the menu, saving references, 
etc.)


The old version is perfect for my needs. If others have the same problem I had, here 
is what I did:



# wget http://ftp.ch.debian.org/debian/pool/main/m/meld/meld_1.6.1-1_all.deb

# apt-get install python-gtk2 python-glade2 python-gobject-2

   The following extra packages will be installed:
  libglade2-0 liblapack3 python-cairo python-numpy
   Suggested packages:
  python-gtk2-doc python-gobject-2-dbg gfortran python-dev python-nose
   python-numpy-dbg python-numpy-doc
   The following NEW packages will be installed:
  libglade2-0 liblapack3 python-cairo python-glade2 python-gobject-2 
python-gtk2
   python-numpy

# dpkg -i meld_1.6.1-1_all.deb

That's all.

Re: A stop job is running for...

[Martin Read]

On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else has
seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm asking
is, do I need to start poring over systemd documentation to see if there
might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service has 
one or more ExecStop lines defined in its service unit and that one of 
those commands is taking an unduly long time to complete for some reason.


The default and per-service timeout values for stopping a service (after 
which systemd gives up and sends fatal signals to all of the service's 
processes) are configurable; see the systemd-system.conf(5) and 
systemd.service(5) man pages for details.

Re: OT: reply styles, family matters

[Mart van de Wege]

Bob Bernstein  writes:

> On Wed, 2 Dec 2015, Chris Bannister wrote:
>
>>> "Please don't respond line by line. It is patronizing and
>>> annoying."
>
>> What did he say when you asked what he meant by this? I mean, how on
>> earth could it possibly be patronising?
>
> I haven't asked him yet, in the interest of not muddying still
> waters. I've been thinking about his "patronizing" response and I
> believe it is an objection to the obvious clarity and precision that
> inline responses afford.

It may be that inline replies are associated with the practice of
'fisking', which in conservative circles is interleaving derogative
comments with the target of derision's original content (usually a blog
post).

If the only time you see interleaved comments is in 'fisked' pieces,
then I could understand not feeling comfortable when someone does that
in an email reply.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: Upgrade to Jessie lost all monitor resolutions except 1024x768

[Mart van de Wege]

Sven Arvidsson  writes:

> On Tue, 2015-12-01 at 16:39 -0500, Felix Miata wrote:
>> "Now", as in Stretch and/or Sid? I searched in Jessie and failed to
>> discover
>> any available firmware-amd-graphics. Is another repo besides main and
>> updates
>> required? I booted same machine to Stretch, and neither package was
>> found.
>> And, Stretch is also using FBDEV, like OP here, and stuck in
>> 1280x1024 on a
>> 1680x1050 display, with libdrm-radeon1, xserver-xorg-video-ati and
>> xserver-xorg-video-radeon installed. ???
>> 
>
> Sid and/or stretch, I don't recall exactly when the split was made.
>
> The clue is in the name, nonfree ;)

Ah yes. I knew I fixed it by installing firmware-linux-nonfree, as I
knew that pulled in the radeon firmware; I was unaware that it was split
in sid, and since I run sid on this laptop, I assumed that the split
that I found dated back to Jessie.

And you know what they say about assuming things... ;)

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.