How to uninstall Emacs?

[Rodolfo Medina]

Hi all.

I recently installed Emacs after downloading it from git repositories. Suppose
I would like to uninstall it - I want to try how the Emacs distribution
provided by Debian works and then, perhaps, reinstall Emacs from git. How can
I completely uninstall it?

Thanks for any help.

Rodolfo

[J. David Boyd]

Post by Rodolfo Medina
Hi all.
I recently installed Emacs after downloading it from git repositories. Suppose
I would like to uninstall it - I want to try how the Emacs distribution
provided by Debian works and then, perhaps, reinstall Emacs from git. How can
I completely uninstall it?
Thanks for any help.
Rodolfo

If you compiled and built it yourself with 'make install', go to the build
directory and try 'make uninstall'.

Dave

[Eli Zaretskii]

Date: Wed, 08 Apr 2015 18:29:07 +0000
I recently installed Emacs after downloading it from git repositories. Suppose
I would like to uninstall it - I want to try how the Emacs distribution
provided by Debian works and then, perhaps, reinstall Emacs from git. How can
I completely uninstall it?

"make uninstall", of course. Assuming you have the source tree for
the version you want to uninstall.

[Bob Proulx]

Post by Rodolfo Medina
I recently installed Emacs after downloading it from git
repositories. Suppose I would like to uninstall it - I want to try
how the Emacs distribution provided by Debian works and then,
perhaps, reinstall Emacs from git. How can I completely uninstall
it?

Or you could simply try the Debian one without uninstalling your
version. When you compile from git sources and 'make install' it will
install emacs into /usr/local/bin/emacs. Since PATH includes
/usr/local/bin ahead of /usr/bin calling emacs calls your locally
compiled binary first.

To avoid this you can simply call the system packaged version
directly. You can do this even with your locally compiled one
installed in /usr/local/bin.

/usr/bin/emacs

Calling it specifically by that path will invoke the system packaged
version. You can verify this by looking at the emacs version. The
version is usually displayed near the bottom of the start up splash
screen. If not (I customize mine away) you can ask it directly.

M-x emacs-version

If you have customizations in your dot emacs file you can test the
stock system configuration with the -q option. The -q option
instructs emacs not to load an init file.

/usr/bin/emacs -q

Bob

[Jorge]

[Since I just subscribed, I do not have the original message to reply to]

To be able to easily uninstall Emacs, I installed it in a prefix.
Configure it with
$ ./configure --prefix=/usr/local/$emacs_version
Then when you type
$ sudo make install
it will install into the chosen prefix. Then create symlinks into
/usr/local/bin
$ sudo ln -sirv $prefix/bin/* /usr/local/bin

Later, to uninstall:
$ sudo rm -rI $prefix
$ find -L -type l /usr/local/bin
<Review the list of broken links in /usr/local/bin. Confirm you want
to remove them all>
$ sudo find -L -type l /usr/local/bin -exec rm {} +

Regards

[Jorge]

[Since I just subscribed, I do not have the original message to reply to]

To be able to easily uninstall Emacs, I installed it in a prefix.
Configure it with:
$ ./configure --prefix=/usr/local/$emacs_version
Then when you type:
$ sudo make install
it will install into the chosen prefix. Then create symlinks into
/usr/local/bin:
$ sudo ln -sirv $prefix/bin/* /usr/local/bin

Later, to uninstall:
$ sudo rm -rI $prefix
$ find -L -type l /usr/local/bin
<Review the list of broken links in /usr/local/bin. Confirm you want
to remove them all>
$ sudo find -L -type l /usr/local/bin -exec rm {} +

Regards

[Emanuel Berg]

Post by Jorge
To be able to easily uninstall Emacs, I installed it
in a prefix. Configure it with: $ ./configure
--prefix=/usr/local/$emacs_version Then when you
type: $ sudo make install it will install into the
chosen prefix. Then create symlinks into
/usr/local/bin: $ sudo ln -sirv $prefix/bin/*
/usr/local/bin
Later, to uninstall: $ sudo rm -rI $prefix $ find -L
-type l /usr/local/bin <Review the list of broken
links in /usr/local/bin. Confirm you want to remove
them all> $ sudo find -L -type l /usr/local/bin -exec
rm {} +

On an aptitude system (e.g. Debian, the Ubuntus, and
so on) you don't have to bother uninstalling programs
because they are just binaries (and sometimes scripts)
that lie passively unless you invoke them: they are
put into their respective boxes in the filesystem and
do not interfere with other programs - they are also
small, so disk space shortage cannot be remedied that
way either.

The package manager is the best way to not have to
deal with the make, configure, and 'make install'
dance, and you don't have to fiddle the symlinks,
either.

Of course it is still possible to uninstall - sudo
aptitude remove - but that is mostly done (seldom)
when the upgrade/installation process has had some
dust in its machinery and you need to give it
a fresh start.

[Emanuel Berg]

Post by Bob Proulx
Or you could simply try the Debian one without
uninstalling your version. When you compile from git
sources and 'make install' it will install emacs
into /usr/local/bin/emacs. Since PATH includes
/usr/local/bin ahead of /usr/bin calling emacs calls
your locally compiled binary first.
To avoid this you can simply call the system
packaged version directly. You can do this even with
your locally compiled one installed in
/usr/local/bin.
/usr/bin/emacs
Calling it specifically by that path will invoke the
system packaged version. You can verify this by
looking at the emacs version. The version is usually
displayed near the bottom of the start up splash
screen. If not (I customize mine away) you can ask
it directly.
M-x emacs-version
If you have customizations in your dot emacs file
you can test the stock system configuration with the
-q option. The -q option instructs emacs not to load
an init file.
/usr/bin/emacs -q

Because of Jorge's smokescreens I got the impression
that I couldn't see the OP either, but now when I read
it this is the best answer. Mine is still correct in
principle tho :)

[Rodolfo Medina]

Post by Emanuel Berg

Post by Bob Proulx
Or you could simply try the Debian one without
uninstalling your version. When you compile from git
sources and 'make install' it will install emacs
into /usr/local/bin/emacs. Since PATH includes
/usr/local/bin ahead of /usr/bin calling emacs calls
your locally compiled binary first.
To avoid this you can simply call the system
packaged version directly. You can do this even with
your locally compiled one installed in
/usr/local/bin.
/usr/bin/emacs
Calling it specifically by that path will invoke the
system packaged version. You can verify this by
looking at the emacs version. The version is usually
displayed near the bottom of the start up splash
screen. If not (I customize mine away) you can ask
it directly.
M-x emacs-version
If you have customizations in your dot emacs file
you can test the stock system configuration with the
-q option. The -q option instructs emacs not to load
an init file.
/usr/bin/emacs -q

Because of Jorge's smokescreens I got the impression
that I couldn't see the OP either, but now when I read
it this is the best answer. Mine is still correct in
principle tho :)

Thanks to all who replied. There was really no need to uninstall Emacs from
git to taste Emacs from Debian. To do that, as suggested, I did:

# aptitude install emacs24

. Then, to start it,

$ emacs24

; whereas, to start Emacs from git,

$ emacs

Bye

Rodolfo

[Bob Proulx]

Post by Rodolfo Medina
Thanks to all who replied. There was really no need to uninstall Emacs from
# aptitude install emacs24

Let me suggest this additionally. Because of ideological differences
between two of the best free(dom) software organizations the emacs
documentation is in the non-free section. I prefer not to rehash it
again because this has been discussed many times before. But you want
the emacs documentation too.

# aptitude install emacs24-common-non-dfsg

That will install the docs if you have the non-free section included
in your /etc/apt/sources.list file. Here is an example. You didn't
say which version you were using so I will guess Jessie by the emacs24
version.

deb http://http.debian.net/debian jessie main contrib non-free

Additionally instead of installing "emacs24" directly it is better to
install the "emacs" package. That will always depend upon the best
version available. Previously it was emacs23. In Jessie it is
emacs24. In this way emacs is automatically upgraded. If only
emacs24 is installed then the assumption is that you don't want to
upgrade when emacs25 becomes available.

Also I recommend to install the emacs-lisp source too. The disk space
isn't a concern these days. The .el files are nice to have in
addition to the compiled .elc files. And there are some other emacs
goodies too. Here is a full recommendation.

# aptitude install emacs emacs24-common-non-dfsg emacs24-el emacs-goodies-el

That would be a much more fair comparison of functionalities.

Post by Rodolfo Medina
. Then, to start it,
$ emacs24
; whereas, to start Emacs from git,
$ emacs

Ah! Yes. That will work. Since emacs24 exists as /usr/bin/emacs24
and doesn't exist in the emacs from git. Very good.

Bob

[Rodolfo Medina]

Then, what about the above emacs24-common-non-dfsg
package? Will it be also automatically upgraded to
future Emacs versions?

The package manager is like a tree data structure.
It determines what software depend on what other
software. It does compilation order, to. If software
C depends on B and B depends on A, and you don't have
A and B but install C, you'll get A and B in the
bargain. If you then attempts to uninstall B while
under the influence, the package manager will tell you
this will break C, which will make you sober up a bit.
If you still want to do it the next day it is of
1) Don't worry about it.
software which you don't use don't bother anyone,
they aren't bulky on the disk and they don't run in
the supposed "background", they are just a binary
file mostly up to no good so just let them be.
3) Don't be conservative installing stuff for the same
reason as (2) - whenever you think "maybe" you need
it, it "might" be the thing you look for, that
"sounds" interesting, etc. - that means you should
install it (again, unless the package manager warns
you it'll break something)
4) Be conservative with upgrades. There is no need to
be hysterical about it. Not every piece of software
needs to be at the most advanced version.
Upgrade your main software once in a while.
The rest of the software will upgrade automatically
in time - if you do it explicitly, do it for
a reason (e.g., you suspect you've come across
a bug that has been fixed in a more recent
version). Don't do it because you are hysterical
about it.
Remember, "the only thing to fear is fear itself".
The computer is a machine which is fun to muck around
with, but it is also a tool to do useful things.
If you muck around too much, that will be all you do,
because it'll reproduce. There are nuances: Elisp
programming mucking can be educative and productive in
the long run, but being neurotic about version numbers
and inter-software dependencies is on the flip side of
it. You know what I'm saying?

I do and much agree with you. I just wish to let Debian to automatically
upgrade my Emacs.

Thanks,

Rodolfo

[Rodolfo Medina]

No need As of now emacs depends (and so pulls in)
emacs24 At some future point it may change that to
emacs25 when you can (if you wish) remove emacs24
[There are some minor niggles about manual and auto
installed tho...]

There can be several problems which is to be expected
with some 40 000 packs, but if you strictly adhere to
the humpty-dumpty rules of thumb I just posted it
should assure you a minimal dosage of problems.
However, if the installer (aptitude) chokes, it is
always a good idea to read the output as often the
problems can be easily dealt with. For example, it can
mkdir: cannot create directory ‘a/b/c/d’: No such file or directory
as the result of a command 'mkdir a/b/c/d' - yep, that
should have come with the '-p' or '--parents' option,
and realizing that you can manually create the
directory path to make the aptitude command work if
you invoke it yet again the same way.
And so on. In particular, if aptitude chokes, you
don't need to reinstall the entire system!
Another source of annoyance is the division between
the KDE and GNOME tools. Because they depend on
different graphics libraries, installing a simple tool
(which may have an excellent CLI and in essence
doesn't even have anything to do with graphics or the
desktop) you are still required to get the whole
KDE/GNOME tool chain! This is even more annoying as
there is absolutely no need for it save for some
people's hysteria for a consistent "look and feel",
where it is more important that everything looks the
same (and it doesn't even look good at that) instead
on focusing on what the tool does. The result of this
is that tools become dependent on other tools (and
libraries) for no reason with respect to the
functionality or purpose of the tool, but only as
a consequence of the "look and feel" hysteria.
An example is 'gnome-terminal' and a zillion other
pieces of software with the gnome- prefix that
shouldn't have anything to do with GNOME.
So use xterm!

About Gnome, I just posted a message on debian users list concerned with what
you write.

Bye

Rodolfo

[Rodolfo Medina]

Post by Bob Proulx

Post by Rodolfo Medina
Thanks to all who replied. There was really no need to uninstall Emacs from
# aptitude install emacs24

Let me suggest this additionally. Because of ideological differences
between two of the best free(dom) software organizations the emacs
documentation is in the non-free section. I prefer not to rehash it
again because this has been discussed many times before. But you want
the emacs documentation too.
# aptitude install emacs24-common-non-dfsg
That will install the docs if you have the non-free section included
in your /etc/apt/sources.list file. Here is an example. You didn't
say which version you were using so I will guess Jessie by the emacs24
version.
deb http://http.debian.net/debian jessie main contrib non-free

Thanks: in my sources.list I have the non-free section:

deb http://ftp.debian.org/debian/ unstable main contrib non-free

Post by Bob Proulx
Additionally instead of installing "emacs24" directly it is better to
install the "emacs" package. That will always depend upon the best
version available. Previously it was emacs23. In Jessie it is
emacs24. In this way emacs is automatically upgraded. If only
emacs24 is installed then the assumption is that you don't want to
upgrade when emacs25 becomes available.

To do so, I should now:

# aptitude purge emacs24
# aptitude install emacs

? Then, what about the above emacs24-common-non-dfsg package? Will it be also
automatically upgraded to future Emacs versions?

Post by Bob Proulx
Also I recommend to install the emacs-lisp source too. The disk space
isn't a concern these days. The .el files are nice to have in
addition to the compiled .elc files. And there are some other emacs
goodies too. Here is a full recommendation.
# aptitude install emacs emacs24-common-non-dfsg emacs24-el emacs-goodies-el
That would be a much more fair comparison of functionalities.

Post by Rodolfo Medina
. Then, to start it,
$ emacs24
; whereas, to start Emacs from git,
$ emacs

Ah! Yes. That will work. Since emacs24 exists as /usr/bin/emacs24
and doesn't exist in the emacs from git. Very good.
Bob

Thanks again.

Rodolfo

[Bob Proulx]

Post by Rodolfo Medina

Post by Bob Proulx
deb http://http.debian.net/debian jessie main contrib non-free

deb http://ftp.debian.org/debian/ unstable main contrib non-free

Oh! You are running sid. And using the truly global generic
ftp.debian.org alias for klecker2.snt.utwente.nl. AFAIK that is a
single machine. That isn't so good.

It would be better to use the http.debian.net redirector service for a
geographically dynamic redirection. It is relatively new but has been
proving itself very useful and robust.

Additionally when running sid there are times when transitions occur
and dependent packages are removed. It is a best practice for sid
users to also include testing too. That way during transitions things
generally continue to be intallable. This is just one of the things
that person running Sid Unstable is expected to know. Because
Unstable isn't recommended for people who don't.

I recommend this for you for a generic Sid Unstable system.

deb http://http.debian.net/debian sid main contrib non-free
deb-src http://http.debian.net/debian sid main contrib non-free

deb http://http.debian.net/debian testing main contrib non-free
deb-src http://http.debian.net/debian testing main contrib non-free

Post by Rodolfo Medina
# aptitude purge emacs24
# aptitude install emacs
?

No. Do not purge 'emacs24' as the installation of 'emacs' would
immediately install 'emacs24' again. That would be silly.

emacs pulls in emacs24
emacs24 pulls in emacs24-bin-common plus a zillion other libraries
emacs24-bin-common pulls in emacs24-common
emacs24-common pulls in emacsen-common

In previous days emacs pulled in emacs23 and a similar dependency
change for v23. In the future emacs will pull in emacs25 and a
similar dependency chain for v25.

I strongly suggest that new users run one of the stable software
distribution releases. Debian Jessie 8 is due out April 25th. At
this point in time Jessie 8 would be the best OS version to run.
Unstable is too crazy of a place for non-combatants. It has been
frozen for many months in preparation for release. That lulls people
into a false sense of stability. But immediately after the release
the floodgates on changes for Unstable are going to be open and
Unstable will once again live up to its name.

Post by Rodolfo Medina
Then, what about the above emacs24-common-non-dfsg package? Will it be also
automatically upgraded to future Emacs versions?

I don't know what aptitude does with "Suggests:" relationships. I
don't use aptitude and am not familiar with it. I use apt-get and I
believe that apt-get will not upgrade Suggests. Therefore
emacs25-common-non-dfsg (emphasis on 25) will need a manual install at
that time. But I hear that aptitude is more agressive at installing
more. So I don't know.

Bob

[Rodolfo Medina]

Post by Bob Proulx

Post by Rodolfo Medina

Post by Bob Proulx
deb http://http.debian.net/debian jessie main contrib non-free

deb http://ftp.debian.org/debian/ unstable main contrib non-free

Oh! You are running sid. And using the truly global generic
ftp.debian.org alias for klecker2.snt.utwente.nl. AFAIK that is a
single machine. That isn't so good.
It would be better to use the http.debian.net redirector service for a
geographically dynamic redirection. It is relatively new but has been
proving itself very useful and robust.

Thanks, I'll do so.

Post by Bob Proulx
Additionally when running sid there are times when transitions occur
and dependent packages are removed. It is a best practice for sid
users to also include testing too. That way during transitions things
generally continue to be intallable. This is just one of the things
that person running Sid Unstable is expected to know. Because
Unstable isn't recommended for people who don't.
I recommend this for you for a generic Sid Unstable system.
deb http://http.debian.net/debian sid main contrib non-free
deb-src http://http.debian.net/debian sid main contrib non-free
deb http://http.debian.net/debian testing main contrib non-free
deb-src http://http.debian.net/debian testing main contrib non-free

Thanks. The two last lines relatives to `testing' will be used by the system
only if the first two, relatives to `sid', should fail?

Post by Bob Proulx

Post by Rodolfo Medina
# aptitude purge emacs24
# aptitude install emacs
?

No. Do not purge 'emacs24' as the installation of 'emacs' would
immediately install 'emacs24' again. That would be silly.
Additionally instead of installing "emacs24" directly it is better to
install the "emacs" package. That will always depend upon the best
version available. Previously it was emacs23. In Jessie it is
emacs24. In this way emacs is automatically upgraded. If only
emacs24 is installed then the assumption is that you don't want to
upgrade when emacs25 becomes available.

Thanks,

Rodolfo

[Emanuel Berg]

This is just one of the things that person running
Sid Unstable is expected to know. Because Unstable
isn't recommended for people who don't.

That is a bit exaggerated especially if we talk
a computer for desktop use with no indispensible
service relying on the computer's
around-the-clock functionality.

What you don't know you can learn by crashing the
computer because you didn't know it. If you do that,
you'll know for sure you didn't know it :)

[Bob Proulx]

Post by Emanuel Berg

This is just one of the things that person running
Sid Unstable is expected to know. Because Unstable
isn't recommended for people who don't.

That is a bit exaggerated especially if we talk
a computer for desktop use with no indispensible
service relying on the computer's
around-the-clock functionality.

If you treat it as you are suggesting, as a victim system for testing
and learning, then I agree. Play. Learn.

Post by Emanuel Berg
What you don't know you can learn by crashing the
computer because you didn't know it. If you do that,
you'll know for sure you didn't know it :)

But the problem is that people don't actually do that very often.
They don't learn first with a victim system and then work through the
problems. Instead people run their critical production servers that
way. They run their main desktops that way. And then when they have
problems they complain that the OS is terrible, it crashed their
desktop, they can't read their email, help!, and they sling enough mud
at it. They can't wait to move off that terrible horrible
distribution and move to the next one which is a thousand times
better. Really! I see this all of the time!

I decided to keep a log of problems on my Sid system. Without going
into great detail since 2011-04-03 to the current day I have had 142
serious problems with Sid that required manual interaction to
correct. Some of those are small problems. Some of those are very
serious problems. Sid is the development and test environment for the
Stable release.

Many of the problems are related to package dependencies. Perhaps
most of them. A Sid user needs to be skilled in identifying package
dependencies, will need to hold packages, will need to manually
install older versions of packages to avoid bugs, will need to
explicitly choose newer versions to migrate across transitions.

Sid has been frozen for six months or so as preparation for Jessie 8
being release. Jessie 8 is scheduled for relase in two weeks. After
that Sid will be unfrozen after six months or so of freeze. That will
open the floodgates. History is sometimes a good predictor of future
behavior. If this unfreeze is similar to any of the previous
unfreezes then there will be 3-4 months of serious thrash and breakage
flood through Sid. There will be a lot of people who will say, "I
have been using Sid solid for the last year and it has been great."
Yes. For the last year. That was while it was in development and
enterring freeze. They haven't seen the winter thaw of spring. We
are in winter and everything is frozen. But Spring is coming![1]

Bob

[1] With apologies to Game of Thrones.

[Rodolfo Medina]

Post by Bob Proulx

Post by Emanuel Berg

This is just one of the things that person running
Sid Unstable is expected to know. Because Unstable
isn't recommended for people who don't.

That is a bit exaggerated especially if we talk
a computer for desktop use with no indispensible
service relying on the computer's
around-the-clock functionality.

If you treat it as you are suggesting, as a victim system for testing
and learning, then I agree. Play. Learn.

Post by Emanuel Berg
What you don't know you can learn by crashing the
computer because you didn't know it. If you do that,
you'll know for sure you didn't know it :)

But the problem is that people don't actually do that very often.
They don't learn first with a victim system and then work through the
problems. Instead people run their critical production servers that
way. They run their main desktops that way. And then when they have
problems they complain that the OS is terrible, it crashed their
desktop, they can't read their email, help!, and they sling enough mud
at it. They can't wait to move off that terrible horrible
distribution and move to the next one which is a thousand times
better. Really! I see this all of the time!

I've been using Debian for nine years now and have never thought nor do I think
to change. Sid difficult to use? Perhaps, but I want to try. And learn at my
own risk. Also Linux instead of Windows was difficult, also plain TeX instead
of LaTeX, also Emacs instead of any other text editor were difficult to use and
they discouraged me to do so, but I've been using all them for many years now
and am happy with them. With Debian Sid I will see. Maybe I'll get back to
Stable, maybe not.

Thanks,

Rodolfo

[Bob Proulx]

Post by Rodolfo Medina
I've been using Debian for nine years now and have never thought nor
do I think to change.

After nine years you would be considered a seasoned veteran! :-)

Post by Rodolfo Medina
Sid difficult to use? Perhaps, but I want to try. And learn at my
own risk.

Then please go for it! Don't let me talk you out of it. :-)

It can be a firehose of information, lots of it, but I suggest that as
a Sid Unstable user monitor the debian-***@lists.debian.org mailing
list. This can be read through the web archives as well as through a
standard email reader. Jessie 8 is due to be released April 25th. At
that time there will be a lot of changes happening for the next few
months. Don't be shy about asking questions about Unstable or Testing
there as that is the place to do it. For the most part other people
will hit the problems first and talk about it and one can simply read
the information there first and be forewarned about it.

Post by Rodolfo Medina
Also Linux instead of Windows was difficult, also plain TeX instead
of LaTeX, also Emacs instead of any other text editor were difficult
to use and they discouraged me to do so, but I've been using all
them for many years now and am happy with them. With Debian Sid I
will see. Maybe I'll get back to Stable, maybe not.

The best thing about working at the levels that you describe above is
that you know how everything works. You get to understand it all.
When something breaks you get to fix it and by doing so gain the
experience to do something more difficult next time.

I also suggest that people keep a journey log of their travels through
the system. Memory is a fickle thing. Confirmation bias is always
skewing our beliefs. The palest ink is better than the strongest
memory. Keeping data on the reality can keep us objective.

Bob

[Emanuel Berg]

Post by Bob Proulx
I also suggest that people keep a journey log of
their travels through the system. Memory is a fickle
thing. Confirmation bias is always skewing our
beliefs. The palest ink is better than the strongest
memory. Keeping data on the reality can keep
us objective.

The best journey log in computing is the sweet
initialization files for Emacs and the shell (bash,
zsh, etc.). Those are actually programs - tools, not
mere "initialization".

So, instead of writing "today I learned how to do word
padding in zsh ...", you save that particular function
where you used it in such a file, as in (third line in the
function body)

rup () {
local word=$1
local rudict=~/ru.txt
echo -n ${(r:12:: :)word} >> $rudict
trans -b -p en:ru $word | tee -a $rudict
trans -b -p en:ru $word > /dev/null
}

Next time you experience the need to do that, you
think - "...didn't I do that in that function that
did...", and then you just look it up.

Not to say there is anything wrong with the natural
language log but I would suspect you'd be bored pretty
soon doing it and stop eventually. The init file
method amounts to the same but is more fun and
productive (not forgetting the main purpose, to give
you access to the actual functions).

Another things is to always bookmark things you Google
(if you find a solution, of course). Problems tend to
reoccur and finding the same page isn't that easy,
always. When you bookmark, be sure to name the
bookmark not the name of the page, but the command or
function name or syntax that solves your particular
problem. That way, in time, you'll not have to follow
the bookmark links but the bookmark titles will be
a small reference to encountered (and solved)
problems, and the links can be followed only when
needed. Also, the extra effort to setup a bookmark
will offer a pause for the brain to assimilate
the new knowledge.

[Rusi]

Post by Emanuel Berg

Post by Bob Proulx
I also suggest that people keep a journey log of
their travels through the system. Memory is a fickle
thing. Confirmation bias is always skewing our
beliefs. The palest ink is better than the strongest
memory. Keeping data on the reality can keep
us objective.

The best journey log in computing is the sweet
initialization files for Emacs and the shell (bash,
zsh, etc.). Those are actually programs - tools, not
mere "initialization".

Say my system broke -- wouldn't boot.
Had to tweak the kernel line of grub to boot it -- acpi=off
That tweak was temporary -- so that line does not make it to /etc/default/grub

So which initialization file should hold that info for the next time I need it?

[Bob Proulx]

Post by Bob Proulx
I also suggest that people keep a journey log of their travels
through the system. Memory is a fickle thing. Confirmation bias is
always skewing our beliefs. The palest ink is better than the
strongest memory. Keeping data on the reality can keep us
objective.

The best journey log in computing is the sweet initialization files
for Emacs and the shell (bash, zsh, etc.). Those are actually
programs - tools, not mere "initialization".
So, instead of writing "today I learned how to do word padding in
zsh ...", you save that particular function where you used it in
such a file, as in (third line in the function body)

Such a journey log would be useful. Many people keep blog of their
experiences to share with others. I have benefited greatly from those
blogs and love to read them.

However I was thinking of something slightly different for this. For
example let me pick a section of active Sid time from my Sid system log.

2013-10-15 Nasty bug.
If using straight /dev/mdX then the system is unbootable.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726237

2013-10-22 opening a new bash shell now complains:
bash: data/zeitgeist-daemon.bash_completion: No such file or directory
bash: data/zeitgeist-daemon.bash_completion: No such file or directory
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727089
zeitgeist-core is a dependency of rhythmbox-plugins

2013-11-06 30.0.1599.101-2 chromium: Running without the SUID sandbox!
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728823
workaround: ln -s chromium-sandbox /usr/lib/chromium/chrome-sandbox
2013-11-08 Fixed in 30.0.1599.101-3.

2013-11-24 Is this the end of xpdf?
The following packages will be REMOVED:
xpdf
The following packages will be upgraded:
fontconfig-config libfontconfig1 libfontconfig1-dev
3 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
I held all four packages so as to prevent apt breakage.

2013-11-28 dovecot upgrade requires manual attention to adjust the SSL
certificate locations and to merge in new config file.

2013-12-07 dist-upgrade wants to remove libreoffice
This is due to libharfbuzz0b replacing libharfbuzz0a.
2013-12-08 Okay the next day with the next package upload.

2013-12-23 dist-upgrade normally, all appeared good,
upgrade openssl 1.0.1e-4 1.0.1e-5
except sshd fails to run with:
OpenSSL version mismatch. Built against 1000105f, you have 10001060
This is a deja-bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732940
pulled openssl back to version 1.0.1e-4, didn't fix things
tried to pull libcrypto but failed due to dependency hell
See that a new openssh 1:6.4p1-2 was uploaded to fix this problem.
Waited it out until the new openssh was available for download.
Installed it. All seemed to have been fixed. But it was several
hours of inop sshd until the new package was uploaded.

2013-12-29 Rebooting required purging hal.
[158492.039848] udevd[12606]: failed to execute
'/lib/udev/socket:@/org/freedesktop/hal/udev_event'
'socket:@/org/freedesktop/hal/udev_event': No such file or directory
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726374#10
This is due to deprecated syntax used by hal in the
/lib/udev/rules.d/90-hal.rules file. The "+=" syntax is deprecated.
Solution: Remove hal. The Debian hal maintainer reports that it is
now deprecated. Nothing should depend upon hal anymore. If
installing a new Jessie system hal would not be installed anymore.

2013-12-29 Sometime in the previous apache upgrades.
[proxy_html:notice] [pid 2496] AH01425: I18n support in
mod_proxy_html requires mod_xml2enc. Without it, non-ASCII
characters in proxied pages are likely to display incorrectly.
Solution: a2enmod xml2enc
http://apache.webthing.com/svn/apache/filters/proxy_html/mod_proxy_html.c
*** NOTICE TO PACKAGERS
This module now relies on mod_xml2enc for i18n support.
You should make mod_xml2enc a dependency in your packages.

And the log goes on. That was during an active time in the
development of Debian Sid Unstable. At the present time Sid has been
frozen for the last six months or so in preparation for release of
Jessie 8. It is scheduled to thaw on April 25th.

Bob

[Emanuel Berg]

Such a journey log would be useful. Many people keep
blog of their experiences to share with others.
I have benefited greatly from those blogs and love
to read them.
However I was thinking of something slightly
different for this. For example let me pick
a section of active Sid time from my Sid system log.
2013-10-15 Nasty bug. If using straight /dev/mdX
then the system is unbootable.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726237
...

Yes, it is very good idea and doesn't conflict with
"my" idea, which is to make tools out of tools as you
go along: aliases, shell functions, Emacs defuns, and
possibly other things as well.

But I also believe in writing as a way to support
memory and enhance understanding. That is one (of
many) reasons I write here, actually.

It is just your idea conflicts with my personality.
As soon as I solve a problem, a want a new problem to
solve, instead of describing what just happened, i.e
what is in the past already. That is why the "tool out
of tools" approach fits me better because that is
self-documenting, and instantly so: at the moment of
"solvation" the tool-out-of-tools that did it is
already in some init file, so you're ready to move on.

It is like the islands of the Pacific ocean.
When Europeans come to those islands and put the
natives to work the Europeans are so impressed by
their work habits and skills they give them cigarettes
for a month in advance. However, the very next day the
natives come back all dizzy, green faced. They live
too much in the moment for that kind of system.
The Europeans realize they should only give them two
cigarettes every day when work concludes (along with
other goods, of course). You know what I'm saying?
I'm the same way.

[Bob Proulx]

Post by Emanuel Berg
It is just your idea conflicts with my personality.

Chuckle! :-)

Post by Emanuel Berg
As soon as I solve a problem, a want a new problem to
solve, instead of describing what just happened, i.e
what is in the past already.

When I was 20 years old I didn't need any memory aides help me
remember anything. Years have past and now I find those hints that
take me to the related bug reports to be needed for me to re-cache in
memory what I need to know about a particular problem. Many of those
be deja-bugs again in the future. Being able to review the history
and get up to speed faster by reading those bug reports helps.

Post by Emanuel Berg
That is why the "tool out
of tools" approach fits me better because that is
self-documenting, and instantly so: at the moment of
"solvation" the tool-out-of-tools that did it is
already in some init file, so you're ready to move on.

Whatever works for you. I am simply making suggestions at this
point.

Post by Emanuel Berg
It is like the islands of the Pacific ocean.

I didn't like your analogy. I understand what you are trying to say.
That everyone is unique (just like everyone else) and you have your
own unique ways that work for you. Same as my unique ways work for
me. That is fine! :-)

Bob

[Emanuel Berg]

Post by Bob Proulx
When I was 20 years old I didn't need any memory
aides help me remember anything. Years have past and
now I find those hints that take me to the related
bug reports to be needed for me to re-cache in
memory what I need to know about a particular
problem.

Many years ago I read a book called "Programmers at
work" -

@book{programmers-at-work,
title = {Programmers at Work: Interviews With 19 Programmers Who Shaped the Computer},
author = {Susan Lammers},
publisher = {Tempus Books},
year = {July 1989},
ISBN = {1556152116}
}

- in which I think it was Charles Simonyi (the
inventor of "Hungarian Notation") who played a little
game every time he went to sleep. He'd visualize
a castle with ten rooms, and in every room there are
ten items.

I tried this game myself but was a bit disappointed
because I realized you could "cheat" but putting only
weapons in the armory, only clothes in the wardrobe,
etc. Or you could have only items with the first
letter A in the first room, then B..., etc.

I don't know if this really improved my memory but
sometimes it made me sleep, probably because it shut
out other thoughts so brought relaxation.

On the whole, memory does not improve with age (as
does nothing) but I don't think 20 year olds
necessarily have good memory. Many of them don't have
good memory and that relates to them having a short
radar in time and in space. If they really put their
"mind" into remembering things they would. But living
in the moment - which is their spaciality - can work
against them and this is visible for example in young
people telling people the same stories over and over.
"You already told us that." "Oh, I did."

Post by Bob Proulx
Many of those be deja-bugs again in the future.
Being able to review the history and get up to speed
faster by reading those bug reports helps.

Problems reoccur or are variations of old problems.
That's the basic truth to it all. It is like
a computer cache. Proximity in space and time.

[Emanuel Berg]

Post by Rodolfo Medina
I've been using Debian for nine years

Only nine years?! Then you are in over your head.
Stick to the basics, young apprentice.

:)

Post by Rodolfo Medina
now and have never thought nor do I think to change.
Sid difficult to use? Perhaps, but I want to try.
And learn at my own risk. Also Linux instead of
Windows was difficult, also plain TeX instead of
LaTeX, also Emacs instead of any other text editor
were difficult to use and they discouraged me to do
so, but I've been using all them for many years now
and am happy with them. With Debian Sid I will see.
Maybe I'll get back to Stable, maybe not.

Indeed, learn to identify what is most powerful, don't
think of what is difficult - just go with it.

I agree fullheartedly except I don't think there is
a gain using plain TeX *instead* of LaTeX. Better tod
mix styles where appropriate and thus have the best of
both worlds.

[Emanuel Berg]

Post by Bob Proulx
But the problem is that people don't actually do
that very often. They don't learn first with
a victim system and then work through the problems.
Instead people run their critical production servers
that way. They run their main desktops that way.
And then when they have problems they complain that
the OS is terrible, it crashed their desktop, they
can't read their email, help!, and they sling enough
mud at it. They can't wait to move off that terrible
horrible distribution and move to the next one which
is a thousand times better. Really! I see this all
of the time!

OK, perhaps Sid shouldn't be used by Debian beginners
but you don't need to be a wizard to use it. If you
are an aspiring wizard perhaps using it will take you
closer to wizardry, at least if you have a parallel
system so you can still do stuff and don't have to
spend too much time fixing Sid.

Post by Bob Proulx
Many of the problems are related to package
dependencies. Perhaps most of them. A Sid user needs
to be skilled in identifying package dependencies,
will need to hold packages, will need to manually
install older versions of packages to avoid bugs

Indeed, you get to do such stuff.

I did this once - it was the image viewer gliv, which
I wanted because it can do slideshows, but the latest
version (in Debian Sid) had a bug and terminated on
startup. Once "down"graded it worked fine.

Temporarily change /etc/apt/sources.list and then

sudo aptitude install PACKAGE=VERSION

after finding out the sought-after version's number.

But I don't remember many such problems from my Sid
days. What might explain it is on the whole I don't
use aptitude that much, because I already have zsh and
Emacs :) But I definitely did install new
programs habitually.

[Rusi]

Post by Bob Proulx

Post by Emanuel Berg

This is just one of the things that person running
Sid Unstable is expected to know. Because Unstable
isn't recommended for people who don't.

That is a bit exaggerated especially if we talk
a computer for desktop use with no indispensible
service relying on the computer's
around-the-clock functionality.

If you treat it as you are suggesting, as a victim system for testing
and learning, then I agree. Play. Learn.

Nice word -- victim system.
One of the big lacks I find in computer users (and educators) is the need to
change hats.
There is the victim system hat, the valuable system hat and perhaps many others.
We always tend to choose 'my most comfortable hat' not the most appropriate one.
The most comfortable Sahara hat is unlikely to be the most comfortable Siberia one

[Emanuel Berg]

Post by Rusi
Nice word -- victim system.

Too negative. Experimentation system?

Post by Rusi
One of the big lacks I find in computer users (and
educators) is the need to change hats. There is the
victim system hat, the valuable system hat and
perhaps many others. We always tend to choose 'my
most comfortable hat' not the most appropriate one.
The most comfortable Sahara hat is unlikely to be
the most comfortable Siberia one

Well, this discussion can go both south and east.

You should not choose the most comfortable hat, but
the most *powerful* hat, and this regardless of your
current skills in hats. In time, you will master the
most powerful hat (or actually whatever hat you
choose) and at that time it will also be the most
comfortable hat, by far.

You shouldn't adapt too much because then you'll be at
the mercy of external events and forces. They will
make the agenda, not you: if you adapt all the time by
definition your one step behind.

You should adapt but only within the frame that is
you, the frame that has proven to hold and which you
have adapted to you body and mind during hundreds of
hours. If that frame took you all the way to the spot
right in front of the Siberian tiger, to throw it away
right there is suicide - better to rely on it!

It is just like the Colosseum of paleo-Rome.
There were many weapons from which the gladiators (and
gladiatrices?) could choose from. But the most deadly
warriors had mastered just one or two. In turn, by
mastering them, they could adapt to any other warrior
using whatever weapon in front of them.

Besides, Siberia is very hot in the summer :)

[Rusi]

Post by Emanuel Berg

Post by Rusi
Nice word -- victim system.

Too negative. Experimentation system?

Well whatever works for you

[To Bob]

Any suggestions for making a victim (oops experimental) windows running on a VM running on stock (debian/ubuntu) linux?
I dabbled in virtualbox for a while but could not get it to work.
[Actually dabbled too little to say for sure]
I guess the goto-point nowadays is VMWare?
There seem to be too many options... as usual...

Post by Emanuel Berg
Besides, Siberia is very hot in the summer :)

Yeah I guess you would know better 😅
[Its nearing 40° C out here]

[Bob Proulx]

Post by Rusi
[To Bob]
Any suggestions for making a victim (oops experimental) windows
running on a VM running on stock (debian/ubuntu) linux?

I am fortunate that I don't need to work with MS-Windows. That means
that I only know about it through hearsay. But you are wanting to run
MS-Windows on GNU/Linux? Is that right? Why?

If you are on MS-Windows and want to create a VM I hear good things
about VirtualBox. However that name recognition does not extend in
the reverse direction. VirtualBox on GNU/Linux is not very good. It
was declared unsupportable by the Linux kernel folks a while back.[1]
I don't think that situation has changed. So unfortunately people
running on MS-Windows often have good results with VirtualBox there.
Then they try to transfer that knowledge to running VirtualBox on a
Linux kernel system and though it sometimes works the general
experience isn't not great overall. I inherited a Fedora system
running VirtualBox and I found the experience lacking. I eventually
converted it to something different.

[1] http://phoronix.com/scan.php?page=news_item&px=OTk5Mw

Post by Rusi
I dabbled in virtualbox for a while but could not get it to work.
[Actually dabbled too little to say for sure]

VirtualBox on MS-Windows? Or on GNU/Linux? On a Linux kernel system
my experience with it was not good either.

Post by Rusi
I guess the goto-point nowadays is VMWare?
There seem to be too many options... as usual...

On GNU/Linux my reading of the two most popular free(dom) software
virtualization systems is Xen and KVM. Xen has a longer history. KVM
is the newcomer rising star. Which to pick? Probably the answer
depends upon everything. I think there will be strong advocates for
each. I think each can do the task well. The choice is yours.

Personally I am running a libvirt encapsulation of KVM for my VM
systems for both testing and production. It is robust and relatively
simple to work with. But I know that someone running Xen would say
the same thing. libvirt will encapsulate either. It is basically
happy scripts to hide some of the underlying complexity.

http://libvirt.org/

Bob

[Jim Diamond]

Post by Bob Proulx

Post by Rusi
[To Bob]
Any suggestions for making a victim (oops experimental) windows
running on a VM running on stock (debian/ubuntu) linux?

I am fortunate that I don't need to work with MS-Windows. That means
that I only know about it through hearsay. But you are wanting to run
MS-Windows on GNU/Linux? Is that right? Why?
If you are on MS-Windows and want to create a VM I hear good things
about VirtualBox. However that name recognition does not extend in
the reverse direction. VirtualBox on GNU/Linux is not very good. It
was declared unsupportable by the Linux kernel folks a while back.[1]
I don't think that situation has changed. So unfortunately people
running on MS-Windows often have good results with VirtualBox there.
Then they try to transfer that knowledge to running VirtualBox on a
Linux kernel system and though it sometimes works the general
experience isn't not great overall. I inherited a Fedora system
running VirtualBox and I found the experience lacking. I eventually
converted it to something different.
[1] http://phoronix.com/scan.php?page=news_item&px=OTk5Mw

That is almost 5 years old. Don't you think it is a bit irrelevant to
the current year?

FWIW I use virtualbox (Linux host, mostly Linux guests) regularly and
haven't seen any problems I can even tenuously connect to it.

The mileage of people still living in 2011 may vary.

Cheers.
Jim

[Bob Proulx]

Post by Jim Diamond

VirtualBox on GNU/Linux is not very good. It was declared
unsupportable by the Linux kernel folks a while back.[1] I don't
think that situation has changed.
[1] http://phoronix.com/scan.php?page=news_item&px=OTk5Mw

That is almost 5 years old. Don't you think it is a bit irrelevant to
the current year?

As I said, "I don't think that situation has changed." My own
experiences with it have not been great either.

If you have other experiences with it to report then that is great. I
would much rather hear that things are working wonderfully rather than
that things are in a sorry state.

Post by Jim Diamond
FWIW I use virtualbox (Linux host, mostly Linux guests) regularly and
haven't seen any problems I can even tenuously connect to it.

That is wonderful. I will note this down as one person with good
recent experiences with it. :-)

Post by Jim Diamond
The mileage of people still living in 2011 may vary.

There are a lot of moribund projects on the net. If they don't get
care, love, and attention then they stay that way and a few years
means nothing. Adding years does not magically fix things. Adding
care and effort fixes things through the sweat of the brow. Years
without effort means nothing.

Bob

[Alexis]

Post by Jim Diamond
FWIW I use virtualbox (Linux host, mostly Linux guests)
regularly and haven't seen any problems I can even tenuously
connect to it.

To add Merely Another Data Point, three machines i manage run
Windows 7 guests, and access the Internet, on Debian Wheezy hosts,
on two distinct LANs, using the Debian packages provided on the
virtualbox.org site[1], without problems.


Alexis.

[1] Because the Debian-provided package doesn't provide certain
functionality, such as USB support for the guest OS - due, i
think, to licensing issues.

[Jim Diamond]

Post by Bob Proulx

Post by Jim Diamond

VirtualBox on GNU/Linux is not very good. It was declared
unsupportable by the Linux kernel folks a while back.[1] I don't
think that situation has changed.
[1] http://phoronix.com/scan.php?page=news_item&px=OTk5Mw

That is almost 5 years old. Don't you think it is a bit irrelevant to
the current year?

As I said, "I don't think that situation has changed." My own
experiences with it have not been great either.

Sorry to hear that. Perhaps there is something peculiar about your
system or your usage.

Post by Bob Proulx
If you have other experiences with it to report then that is great. I
would much rather hear that things are working wonderfully rather than
that things are in a sorry state.

Post by Jim Diamond
FWIW I use virtualbox (Linux host, mostly Linux guests) regularly and
haven't seen any problems I can even tenuously connect to it.

That is wonderful. I will note this down as one person with good
recent experiences with it. :-)

Infinitely better than none, I suppose.

Post by Bob Proulx

Post by Jim Diamond
The mileage of people still living in 2011 may vary.

There are a lot of moribund projects on the net. If they don't get
care, love, and attention then they stay that way and a few years
means nothing. Adding years does not magically fix things. Adding
care and effort fixes things through the sweat of the brow. Years
without effort means nothing.

Are you somehow implying that virtualbox is not actively being
maintained? Perhaps if you peruse
https://www.virtualbox.org/wiki/Changelog
you will change your mind.

Jim

[Rodolfo Medina]

Post by Rodolfo Medina

Post by Bob Proulx
Additionally instead of installing "emacs24" directly it is better to
install the "emacs" package. That will always depend upon the best
version available. Previously it was emacs23. In Jessie it is
emacs24. In this way emacs is automatically upgraded. If only
emacs24 is installed then the assumption is that you don't want to
upgrade when emacs25 becomes available.

# aptitude purge emacs24
# aptitude install emacs

I did so, and seems all right.

Rodolfo

[Bob Proulx]

Post by Rodolfo Medina

Post by Rodolfo Medina

Post by Bob Proulx
Additionally instead of installing "emacs24" directly it is
better to install the "emacs" package. That will always depend
upon the best version available. Previously it was emacs23. In
Jessie it is emacs24. In this way emacs is automatically
upgraded. If only emacs24 is installed then the assumption is
that you don't want to upgrade when emacs25 becomes available.

# aptitude purge emacs24
# aptitude install emacs

I did so, and seems all right.

The end result is okay but it wastefully removes emacs24 and then
immediately installs it again. 'emacs24' is a dependency of the
current 'emacs'. Why remove what will be immediately re-installed?

See this for a more full answer and description:

http://lists.gnu.org/archive/html/help-gnu-emacs/2015-04/msg00174.html

Additionally this too:

http://lists.gnu.org/archive/html/help-gnu-emacs/2015-04/msg00178.html

Bob

[Rodolfo Medina]

Post by Bob Proulx

Post by Rodolfo Medina

Post by Rodolfo Medina

Post by Bob Proulx
Additionally instead of installing "emacs24" directly it is
better to install the "emacs" package. That will always depend
upon the best version available. Previously it was emacs23. In
Jessie it is emacs24. In this way emacs is automatically
upgraded. If only emacs24 is installed then the assumption is
that you don't want to upgrade when emacs25 becomes available.

# aptitude purge emacs24
# aptitude install emacs

I did so, and seems all right.

The end result is okay but it wastefully removes emacs24 and then
immediately installs it again. 'emacs24' is a dependency of the
current 'emacs'. Why remove what will be immediately re-installed?

Maybe it was enough simply

# aptitude install emacs

. The reason to install `emacs' package having emacs24 already installed is

Post by Bob Proulx

Post by Rodolfo Medina

Post by Rodolfo Medina

Post by Bob Proulx
Additionally instead of installing "emacs24" directly it is
better to install the "emacs" package. That will always depend
upon the best version available. Previously it was emacs23. In
Jessie it is emacs24. In this way emacs is automatically
upgraded. If only emacs24 is installed then the assumption is
that you don't want to upgrade when emacs25 becomes available.

http://lists.gnu.org/archive/html/help-gnu-emacs/2015-04/msg00174.html
http://lists.gnu.org/archive/html/help-gnu-emacs/2015-04/msg00178.html

Yes, it's our present thread.

Thanks,

Rodolfo

[Emanuel Berg]

Post by Bob Proulx
# aptitude install emacs emacs24-common-non-dfsg
emacs24-el emacs-goodies-el

If we include emacs-goodies-el in that elite crew we
might as well mention debian-el as well.

[Thien-Thi Nguyen]

() Rodolfo Medina <***@gmail.com>
() Wed, 08 Apr 2015 18:29:07 +0000

Suppose I would like to uninstall it

method 42:

At some point, an asteroid will hit the earth. That may or
may not wipe out civilization as we know it, but if you move
your computer to the right place, it will surely uninstall
Emacs. At that point, it really doesn't matter what remains.

[Rodolfo Medina]

Post by Thien-Thi Nguyen
() Wed, 08 Apr 2015 18:29:07 +0000
Suppose I would like to uninstall it
At some point, an asteroid will hit the earth. That may or
may not wipe out civilization as we know it, but if you move
your computer to the right place, it will surely uninstall
Emacs. At that point, it really doesn't matter what remains.

Yes, I agree! ;-)

Rodolfo