Recommendation on video card?

[Petter Adsen]

I have an AMD HD5450 card in my desktop, which has been mostly
adequate for me, but now it is time to retire it.

Can anyone recommend a more recent card that works well with X? I'm
using two screens, so I will need at least two outputs - preferably
digital. I have been quite happy with AMD, so I'd like to stick with
that, and I prefer not using the fglrx driver if possible. One
thing that would be nice is hardware decoding of video, with something
later than UVD2.

At some point I will probably also need to get a third screen, so
something that has three outputs or would run nicely with a second
video card that has additional outputs is a big bonus.

I use no 3D software, no games, and nothing I can think of that needs a
powerful GPU. It might be nice with 4K support, though.

Everything online talks about what cards to get for gaming, but that is
irrelevant to me. Does anyone have a recommendation for a good card for
a desktop?

Petter

-- 
"I'm ionized"
"Are you sure?"
"I'm positive."


pgph0J4wvPPvl.pgp
Description: OpenPGP digital signature

Re: reading an empty directory after reboot is very slow

[Vincent Lefevre]

On 2015-04-23 10:10:54 -0500, David Wright wrote:
> Quoting Vincent Lefevre (vinc...@vinc17.net):
> > On 2015-04-22 23:28:46 -0500, David Wright wrote:
> > > No, I wasn't expecting mutt to use mairix. But I thought you might be
> > > using it. Otherwise, why do you index them?
> > 
> > I use mairix when I need a "body" search first, otherwise such a
> > search would be awfully slow with Mutt. Then I can open the generated
> > folder with Mutt, and try to do more filtering to find what I want.
> 
> I was under the impression that mairix could do both.

mairix does two things: index mail messages and search. For the latter
operation, it just creates a mail folder with the results. If I need
to refine a search, I can either re-run mairix (a new mail folder is
created) or use the search feature of the MUA (e.g. Mutt) after opening
the folder created by mairix.

> > > I also wondered what the problem would be with putting the thousands
> > > of emails in a general purpose database.
> > 
> > But Mutt can't use such a database.
> 
> I was thinking of a scenario where you retrieve the matching emails
> and place them in a scratch directory, then run mutt on that folder
> so you can still read the results with an email interface.

This is exactly what mairix does. No need for a database. Well, mairix
has a database for its index, but it is just the index (it doesn't
contain the messages themselves). For what mairix does, it is better
to use the maildir format since mairix just creates symbolic links to
the matching messages, while if the mbox format were used, it would
have to copy the entire messages. With the maildir format, mairix is
always immediate (once the database is in the cache, otherwise this
takes a few seconds).

> Of course I have no idea whether you're trying to match a few emails
> or thousands at a time.

For some searches, it's more practical to do this entirely from Mutt,
because it allows interactivity without losing the context (with mairix,
I would have to restart Mutt for each new refined search).

Anyway remember that the main slowness I have is when I retag messages.
I could improve my script to cache the message-id -> filename mapping,
which would make it much faster. But what I like to understand is why
my current script is so much slower than Mutt (when the mailbox is not
in the cache), while both are reading about the same data. I'll have
to do some tests with slight changes in my script to see if this makes
a difference. Hmm... something I've just thought about is to look at
the cache size in both cases:
  1. Drop the caches. Open the mailbox with Mutt.
  2. Drop the caches. Use my script.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150424073529.ga6...@xvii.vinc17.org

Re: qemu-kvm and glusterfs support

[Florian Ernst]

Hello there,

On Fri, Apr 24, 2015 at 07:50:59AM +0300, Risto Paavola wrote:
> In Debian Jessie, why qemu-kvm has been compiled without glusterfs network
> disk type support?

"""Until glusterfs packaging
is sane I think it's not a good idea to introduce glusterfs support.

Also this is not really easy thing, because it brings us several non-
trivial dependencies to the binary packages and users already complained
about too much dependencies qemu has."""
 (actually,
this bugreport came too late to affect Jessie; but this is where the
maintainer states his position)

However, if you need a Debian-based system with recent qemu-kvm and
support for various network disk types, I'd recommend Proxmox. I haven't
used it with glusterfs for quite some time (preferring ceph instead),
but it appears well-integrated.

HTH,
Flo


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150424074558.gq25...@fernst.no-ip.org

Re: reading an empty directory after reboot is very slow

[Vincent Lefevre]

On 2015-04-23 11:22:11 -0500, David Wright wrote:
> Quoting Vincent Lefevre (vinc...@vinc17.net):
> > On 2015-04-23 11:31:27 +0200, Nicolas George wrote:
> > > Le quartidi 4 floréal, an CCXXIII, Vincent Lefevre a écrit :
> > > > David's test shows that the renamed file is missed.
> > > 
> > > No, it shows that the renamed file is NOT missed: he renamed the
> > > entry for inode 497003 from file2 into a long name, and that
> > > entry is returned, exactly once, under its old name. The "oops,
> > > file2 stat() fails" only shows the race condition between
> > > readdir() return and stat(); I am sure that if he printed
> > > dirent.d_ino instead of stat.st_ino, it would have printed
> > > 497003.
> 
> Yes, it would. See below as to why I printed the stat() version.
> 
> But actually, the answer is no. dirent.d_ino could fail as well.
> readdir is not thread-safe so the dirent could get clobbered between
> the call to readdir and printing it.

This doesn't matter here: the thread-safeness applies to a single
process with multiple threads. Here one considers a single-threaded
program. Note also that in a multi-threaded program, the full
readdir call is concerned by the lack of thread-safeness, not just
dirent.d_ino; said otherwise, you mustn't use concurrent readdir in
multiple threads (and readdir_r isn't a solution either since it can
yield a buffer overflow with arbitrary C libraries).

> > I only focused on the inode number and I thought that David's test was
> > printing dirent.d_ino (which was the obvious thing to do). Now, after
> > re-reading carefully what he said:
> > 
> >   "I scan the directory with readdir, then stat the file to obtain its
> >^^^
> >inode number."
> >
> > 
> > Indeed, this is the wrong way to do!
> 
> Well, the program I filched, because filch it I did, printed more
> *interesting* stuff about the file, stuff like the size etc.
> I switched it to printing the (to most people, boring) inode number
> because, *for the purpose of this exercise*, the inode number acts as
> a unique identifier for a file which has just changed name.

Except that you don't show anything special: it is obvious that there
is a race condition on the filename when doing a file rename and
reading the directory containing that file at the same time, i.e. one
can either get the old filename or the new filename. This will be true
with *any* filesystem (I mean, the behavior is not specified).

> > So, there's a need for a new test.
> 
> Feel free to write it.

No need, you have agreed above that the dirent.d_ino is correct
(except in case of programming error).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150424080410.gb6...@xvii.vinc17.org

the correct way to read a big directory? Mutt?

[Vincent Lefevre]

I'm starting a new thread since "reading an empty directory after
reboot is very slow" is quite long, and the subject has changed a
bit. Now that I think I've found the reason, this one may be short. :)

My disk is a traditional hard disk, not SSD, and the filesystem is
ext3.

The problem is the following: I have a Perl script that reads a big
maildir directory, and when data from this directory are not in the
cache, this script is much slower than Mutt (without header cache).
One can assume that the files are very small (see below): < 100 bytes.
I've done a test with "grep -qr" (without matches so that all the
files are read), and it is also slow. In my script, if I don't read
the files at all, this is fast, so that the problem comes from the
reading of these files.

Now, the test. First, I create a big maildir folder with:


#!/bin/sh

set -e

dir=maildir-test
rm -rf "$dir"
maildirmake "$dir"

for i in `seq 5000`
do
  date=$((1000+i))
  cat < "$dir/cur/$date.1.host:2,S"
From: 
Subject: $date
Message-ID: <$d...@vinc17.org>

test $i
EOF
done


ypig:~> sudo drop-caches && sh -c "time mutt -F /dev/null -f maildir-test"
0.11user 0.19system 0:02.41elapsed 12%CPU (0avgtext+0avgdata 9584maxresident)k
47728inputs+0outputs (18major+6360minor)pagefaults 0swaps

ypig:~> sudo drop-caches && sh -c "time grep -qr zzz maildir-test"
Command exited with non-zero status 1
0.03user 0.33system 0:34.63elapsed 1%CPU (0avgtext+0avgdata 4268maxresident)k
44336inputs+0outputs (4major+492minor)pagefaults 0swaps

ypig:~> sudo drop-caches && sh -c "time labels2arc maildir-test"
[...]
0.28user 0.26system 0:35.95elapsed 1%CPU (0avgtext+0avgdata 6308maxresident)k
48120inputs+0outputs (8major+758minor)pagefaults 0swaps

where drop-caches is a script that does the following:

sync
echo 3 > /proc/sys/vm/drop_caches

Note that the number of inputs is almost the same in these 3 cases,
But only Mutt is really fast. So, I've looked at strace output.
Here are some excerpts:

* With Mutt:

[...]
11777 14:47:11 open("maildir-test/cur/1009.1.host:2,S", O_RDONLY) = 3
11777 14:47:11 fstat(3, {st_mode=S_IFREG|0644, st_size=80, ...}) = 0
11777 14:47:11 mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1e529c
11777 14:47:11 lseek(3, 0, SEEK_CUR)= 0
11777 14:47:11 read(3, "From: \nSubject: 100"..., 4096) = 80
11777 14:47:11 fstat(3, {st_mode=S_IFREG|0644, st_size=80, ...}) = 0
11777 14:47:11 close(3) = 0
11777 14:47:11 munmap(0x7f1e529c, 4096) = 0
11777 14:47:11 open("maildir-test/cur/1010.1.host:2,S", O_RDONLY) = 3
11777 14:47:11 fstat(3, {st_mode=S_IFREG|0644, st_size=81, ...}) = 0
11777 14:47:11 mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1e529c
11777 14:47:11 lseek(3, 0, SEEK_CUR)= 0
11777 14:47:11 read(3, "From: \nSubject: 100"..., 4096) = 81
11777 14:47:11 fstat(3, {st_mode=S_IFREG|0644, st_size=81, ...}) = 0
11777 14:47:11 close(3) = 0
11777 14:47:11 munmap(0x7f1e529c, 4096) = 0
11777 14:47:11 write(1, "\33[76;25H10/5000 (0%)", 20) = 20
11777 14:47:11 open("maildir-test/cur/1011.1.host:2,S", O_RDONLY) = 3
11777 14:47:11 fstat(3, {st_mode=S_IFREG|0644, st_size=81, ...}) = 0
11777 14:47:11 mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1e529c
11777 14:47:11 lseek(3, 0, SEEK_CUR)= 0
11777 14:47:11 read(3, "From: \nSubject: 100"..., 4096) = 81
11777 14:47:11 fstat(3, {st_mode=S_IFREG|0644, st_size=81, ...}) = 0
11777 14:47:11 close(3) = 0
11777 14:47:11 munmap(0x7f1e529c, 4096) = 0
[...]

* With grep:

[...]
11789 14:47:42 openat(6, "1009.1.host:2,S", O_RDONLY|O_NOFOLLOW) = 3
11789 14:47:42 fstat(3, {st_mode=S_IFREG|0644, st_size=80, ...}) = 0
11789 14:47:42 ioctl(3, TCGETS, 0x7ffdcdff2d40) = -1 ENOTTY (Inappropriate 
ioctl for device)
11789 14:47:42 read(3, "From: \nSubject: 100"..., 32768) = 80
11789 14:47:42 read(3, "", 32768)   = 0
11789 14:47:42 close(3) = 0
11789 14:47:42 openat(6, "10003090.1.host:2,S", O_RDONLY|O_NOFOLLOW) = 3
11789 14:47:42 fstat(3, {st_mode=S_IFREG|0644, st_size=83, ...}) = 0
11789 14:47:42 ioctl(3, TCGETS, 0x7ffdcdff2d40) = -1 ENOTTY (Inappropriate 
ioctl for device)
11789 14:47:42 read(3, "From: \nSubject: 100"..., 32768) = 83
11789 14:47:42 read(3, "", 32768)   = 0
11789 14:47:42 close(3) = 0
11789 14:47:42 openat(6, "10004692.1.host:2,S", O_RDONLY|O_NOFOLLOW) = 3
11789 14:47:42 fstat(3, {st_mode=S_IFREG|0644, st_size=83, ...}) = 0
11789 14:47:42 ioctl(3, TCGETS, 0x7ffdcdff2d40) = -1 ENOTTY (Inappropriate 
ioctl for device)
11789 14:47:42 read(3, "From: \nSubject: 100"..., 32768) = 83
11789 14:47:42 read(3, "", 32768)   = 0
11789 14:47:42 close(3) = 0
[...]

* With my script:

[...]
11954 14:50:52 open("maildir-test/cur/1009.1.host:2,S", O_

Re: reading an empty directory after reboot is very slow

[Vincent Lefevre]

On 2015-04-24 09:35:29 +0200, Vincent Lefevre wrote:
> Anyway remember that the main slowness I have is when I retag messages.
> I could improve my script to cache the message-id -> filename mapping,
> which would make it much faster. But what I like to understand is why
> my current script is so much slower than Mutt (when the mailbox is not
> in the cache), while both are reading about the same data. I'll have
> to do some tests with slight changes in my script to see if this makes
> a difference. Hmm... something I've just thought about is to look at
> the cache size in both cases:
>   1. Drop the caches. Open the mailbox with Mutt.
>   2. Drop the caches. Use my script.

I think I've found the reason. See the new thread:

  Subject: the correct way to read a big directory? Mutt?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150424135338.ga6...@ypig.lip.ens-lyon.fr

Re: the correct way to read a big directory? Mutt?

[Nicolas George]

Le quintidi 5 floréal, an CCXXIII, Vincent Lefevre a écrit :
> Mutt uses a
> different order, and after a look at its mh.c source file, I can see
> that it sorts the files by inode number (see maildir_delayed_parsing
> function). IMHO, this is a good choice because, specially in big
> directories, doing that may lead to contiguous files on the disk,
> and I think that it is the reason why Mutt is much faster.

This is the corresponding entry in Mutt's ChangeLog:

2005-01-27 18:45:37  Florian Weimer (roessler)

* mh.c, configure.in: Read files in maildir folders in inode
order; this seems to reduce seek overhead on Linux.  Enabled by
default; to disable, run configure with --disable-inodesort.
(By way of Mario d'Itri.)

Mario looks like a typo for Marco; Marco d'Itri is a known name in the Linux
community, although I do not quite remember for what (sorry if you happen to
read that).

Reading the mailing-lists archives around that date may be interesting.

> Now I wonder whether the use of the hash by ext3 is a good idea...
> 
> Alternatively, I suppose that a SSD disk could improve things.

Well, filesystems can not be optimized for every use. Having myriads of
small files has always been a bad idea anyway, it trashes the inode and
dentries cache, it costs extra disk bandwidth (because you can not read half
a sector at the end of the file) and latency (because of all the seeks, even
when reading in order, it will be more fragmented than a single file), etc.
Of course, nowadays, huge RAM and SSD will mitigate the issue.

It is a tragedy that a standard, robust and efficient format for mailboxes
was never designed and adopted.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

"Debian From Scratch" - what _WAS_ it?

[Richard Owlett]

In doing some digging for a personal project, I've come across 
tantalizing references to "Debian From Scratch". Using that as a 
Google search term gets lots of posts that can be summed up as 
"it no longer exists".


Did it have a homepage of some sort? I'm looking for a URL to 
feed to the "Wayback Machine" [http://archive.org/web/web.php].


In particular I'm looking for what the project's goals had been. 
{i.e. food for thought}


TIA


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

Archive: https://lists.debian.org/553a5ac6.4030...@cloud85.net

Re: the correct way to read a big directory? Mutt?

[Vincent Lefevre]

On 2015-04-24 16:12:15 +0200, Nicolas George wrote:
> This is the corresponding entry in Mutt's ChangeLog:
> 
> 2005-01-27 18:45:37  Florian Weimer (roessler)

Yes, I eventually found this changeset too, by searching for "inode"
in Mutt's changelog.

> Reading the mailing-lists archives around that date may be interesting.

I've found that in my mail archive (thanks to "mairix inode"):

Date: Mon, 6 Oct 2003 10:04:04 +0200
From: Florian Weimer 
To: mutt-...@mutt.org
Subject: Maildir parsing optimization for ext3/Linux 2.6

Linux 2.6 adds hashed directory support to ext3.  As a result, readdir()
returns directory entries in a pretty wild order.  Opening files in
this order results in enormous seek overhead.  This overhead can be
reduced if the files are sorted by inode number first.

Without the patch below, mutt needs 200 seconds to open a maildir folder
with 18,500 messages which does not reside in the dentry/page cache.  If
the patch is applied, less than 15 seconds are required.  If the folder
is in cache, 3.1 vs. 3.3 seconds are needed.

If necessary, I can add some autoconf hackery to activate this
optimization only on Linux systems (where the d_ino field is always
available).

[...]

Date: Thu, 29 Nov 2007 12:35:29 +0100
From: Rocco Rutte 
To: mutt-...@mutt.org
Subject: [PATCH] Re-introduce inode sorting

Hi,

sorry that this is going to be longer, the subject is quite tricky.

The inode sorting patch was sent to mutt-dev in:

  http://does-not-exist.org/mail-archives/mutt-dev/msg00205.html

saying that it can speed it uncached maildir parsing from 200 to 15 seconds
making it more than 13 times faster, some concerns were raised and the code
disabled by default.

For #2981 I've been doing some tests on my gentoo box and can confirm this
factor roughly (10 minutes for >300k messages compared to far over 2 hours).
This almost renders mutt unusable for larger folders that aren't cached yet
(e.g.  an internal structure change requires a full cache rebuild or a user
just giving mutt a try).

Googling for some messages on the kernel mailing list turns out that not doing
inode sorting on dir_index-enabled ext3 filesystems effectively makes apps
access inodes in nearly random order, so that explains the slowdown. I think
mutt needs inode sorting.

[...]

> > Now I wonder whether the use of the hash by ext3 is a good idea...
> > 
> > Alternatively, I suppose that a SSD disk could improve things.
> 
> Well, filesystems can not be optimized for every use. Having myriads of
> small files has always been a bad idea anyway, it trashes the inode and
> dentries cache, it costs extra disk bandwidth (because you can not read half
> a sector at the end of the file) and latency (because of all the seeks, even
> when reading in order, it will be more fragmented than a single file), etc.

Yes, you already said that in the mutt-dev list in 2006. :-)
Nothing has changed. :-( Well, except...

> Of course, nowadays, huge RAM and SSD will mitigate the issue.
> 
> It is a tragedy that a standard, robust and efficient format for mailboxes
> was never designed and adopted.

I agree.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150424151153.ga26...@ypig.lip.ens-lyon.fr

Re: "Debian From Scratch" - what _WAS_ it?

[Curt]

On 2015-04-24, Richard Owlett  wrote:
> In doing some digging for a personal project, I've come across 
> tantalizing references to "Debian From Scratch". Using that as a 
> Google search term gets lots of posts that can be summed up as 
> "it no longer exists".
>
> Did it have a homepage of some sort? I'm looking for a URL to 
> feed to the "Wayback Machine" [http://archive.org/web/web.php].
>
> In particular I'm looking for what the project's goals had been. 
> {i.e. food for thought}
>

https://lists.debian.org/debian-devel/2006/04/msg00633.html

-- 



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnmjko8n.2ab.cu...@einstein.electron.org

Re: "Debian From Scratch" - what _WAS_ it?

[Richard Owlett]

Curt wrote:

On 2015-04-24, Richard Owlett  wrote:

In doing some digging for a personal project, I've come across
tantalizing references to "Debian From Scratch". Using that as a
Google search term gets lots of posts that can be summed up as
"it no longer exists".

Did it have a homepage of some sort? I'm looking for a URL to
feed to the "Wayback Machine" [http://archive.org/web/web.php].

In particular I'm looking for what the project's goals had been.
{i.e. food for thought}



https://lists.debian.org/debian-devel/2006/04/msg00633.html



Thank you. The Wayback Machine has some good page captures.



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

Archive: https://lists.debian.org/553a704e.8030...@cloud85.net

Re: Recommendation on video card?

[Ric Moore]

On 04/24/2015 03:23 AM, Petter Adsen wrote:

I have an AMD HD5450 card in my desktop, which has been mostly
adequate for me, but now it is time to retire it.

Can anyone recommend a more recent card that works well with X? I'm
using two screens, so I will need at least two outputs - preferably
digital. I have been quite happy with AMD, so I'd like to stick with
that, and I prefer not using the fglrx driver if possible. One
thing that would be nice is hardware decoding of video, with something
later than UVD2.

At some point I will probably also need to get a third screen, so
something that has three outputs or would run nicely with a second
video card that has additional outputs is a big bonus.

I use no 3D software, no games, and nothing I can think of that needs a
powerful GPU. It might be nice with 4K support, though.

Everything online talks about what cards to get for gaming, but that is
irrelevant to me.


Actually it is relevant. People use "gaming" as a benchmark. If it works 
well for gaming, then you are set, just in case you find that you 
actually need some horsepower, or don't want to be annoyed with tearing, 
etc. You just never know. Especially if you want to drive multi-monitors 
with multi-cards.


AMD and Intel have been less than stellar, in the past, for higher-end 
support. Just a quick search finds an older nvidia GT610 PciE with 2 
gigs of vram for $40 with free shipping on Amazon. I'm running two older 
GT520's for four monitors. Works a charm with the nvidia drivers and 
tweaking the bios to turn off the built-in video. I did have to install 
a larger power supply to keep it all from over-heating, the average 500 
watt supply is too marginal for this load, IMHO.


Be sure to check for the openGL version which should be equal to or 
higher than version 2.0. So, IMHO it's better to have too much, than not 
enough! But, that is just my two cents:) 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


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

Archive: https://lists.debian.org/553a70ff.5030...@gmail.com

Difficulty downgrading a mistakenly installed non-stable package

[Kynn Jones]

I try to keep my system as close to 100% stable as possible.  In spite
of this, a version of libp11-kit0 that is ahead of stable "somehow"
snuck into my system:

$ apt-cache policy libp11-kit0
libp11-kit0:
  Installed: 0.20.7-1~bpo70+1
  Candidate: 0.20.7-1~bpo70+1
  Version table:
 *** 0.20.7-1~bpo70+1 0
100 /var/lib/dpkg/status
 0.12-3 0
500 http://debian.csail.mit.edu/debian/ stable/main amd64 Packages
500 http://ftp.us.debian.org/debian/ stable/main amd64 Packages


I tried unsuccessfully to downgrade libp11-kit0 to the version from
stable, like this:

$ aptitude reinstall -f libp11-kit0
The following packages will be REINSTALLED:
  libp11-kit0
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove
and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
E: I wasn't able to locate a file for the libp11-kit0 package.
This might mean you need to manually fix this package.
E: I wasn't able to locate a file for the libp11-kit0 package.
This might mean you need to manually fix this package.
E: Internal error: couldn't generate list of packages to download

I didn't have more luck with dpkg:

$ dpkg --force-remove-reinstreq --purge libp11-kit0
dpkg: dependency problems prevent removal of libp11-kit0:amd64:
 gnome-shell depends on libp11-kit0 (>= 0.2); however:
  Package libp11-kit0:amd64 is to be removed.
 libgnutls26:amd64 depends on libp11-kit0 (>= 0.11).
 libgck-1-0 depends on libp11-kit0 (>= 0.11).
 nautilus-sendto-empathy depends on libp11-kit0 (>= 0.2).
 libgnutls-openssl27:amd64 depends on libp11-kit0 (>= 0.11).
 glib-networking:amd64 depends on libp11-kit0 (>= 0.11).
 libgnutls-deb0-28:amd64 depends on libp11-kit0 (>= 0.20.7).
 libgcr-3-1 depends on libp11-kit0 (>= 0.6).

dpkg: error processing libp11-kit0:amd64 (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 libp11-kit0:amd64

How can I downgrade this libp11-kit0?

Thanks in advance!

kj


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAFvQaj5962mNAdQv9+4qKFQw5dM6EM3AH4Kwe2xCX7=natu...@mail.gmail.com

Re: Difficulty downgrading a mistakenly installed non-stable package

[Bob Proulx]

Kynn Jones wrote:
> $ apt-cache policy libp11-kit0
> libp11-kit0:
>   Installed: 0.20.7-1~bpo70+1
>   Candidate: 0.20.7-1~bpo70+1
>   Version table:
>  *** 0.20.7-1~bpo70+1 0
> 100 /var/lib/dpkg/status
>  0.12-3 0
> 500 http://debian.csail.mit.edu/debian/ stable/main amd64 Packages
> 500 http://ftp.us.debian.org/debian/ stable/main amd64 Packages
>...
> How can I downgrade this libp11-kit0?

The usual way is to specify the explicit version number.

  apt-get install libp11-kit0=0.12-3

Upgrading is automatic but downgrading requires an explicit version.

Bob


signature.asc
Description: Digital signature

Re: Difficulty downgrading a mistakenly installed non-stable package

[Brian]

On Fri 24 Apr 2015 at 12:37:36 -0400, Kynn Jones wrote:

> I try to keep my system as close to 100% stable as possible.  In spite
> of this, a version of libp11-kit0 that is ahead of stable "somehow"
> snuck into my system:
> 
> $ apt-cache policy libp11-kit0
> libp11-kit0:
>   Installed: 0.20.7-1~bpo70+1
>   Candidate: 0.20.7-1~bpo70+1
>   Version table:
>  *** 0.20.7-1~bpo70+1 0
> 100 /var/lib/dpkg/status
>  0.12-3 0
> 500 http://debian.csail.mit.edu/debian/ stable/main amd64 Packages
> 500 http://ftp.us.debian.org/debian/ stable/main amd64 Packages

libp11-kit0 wasn't installed by mistake and didn't sneak onto your
system uninvited. Backports will pull in packages and versions of
packages which are not in a stable release.

Bug makes interesting reading; especially when it contains

  > In my opinion it's very good when backports is default in sources.list.

  My opinion is that I don't want to push ticking time bombs into the hands
  of our users. And that's exactly what defaulting to enabling backports
  was.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150424175030.go22...@copernicus.demon.co.uk

Re: Difficulty downgrading a mistakenly installed non-stable package

[Brian]

On Fri 24 Apr 2015 at 18:50:30 +0100, Brian wrote:

> Bug makes interesting reading; especially when it contains

#764982 in case anyone was wondering, :)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/24042015185527.7a08296f2...@desktop.copernicus.demon.co.uk

Re: Difficulty downgrading a mistakenly installed non-stable package

[Bob Proulx]

Kynn Jones wrote:
> I try to keep my system as close to 100% stable as possible.  In spite
> of this, a version of libp11-kit0 that is ahead of stable "somehow"
> snuck into my system:
> 
> $ apt-cache policy libp11-kit0
> libp11-kit0:
>   Installed: 0.20.7-1~bpo70+1
>   Candidate: 0.20.7-1~bpo70+1
>   Version table:
>  *** 0.20.7-1~bpo70+1 0
> 100 /var/lib/dpkg/status
>  0.12-3 0
> 500 http://debian.csail.mit.edu/debian/ stable/main amd64 Packages
> 500 http://ftp.us.debian.org/debian/ stable/main amd64 Packages

I went back and looked at your previous messages to the list.  I see
this from you previously:

> As part of a work-related requirement, I need to install ia32-libs on
> my (mostly stable) Debian laptop.
> 
> Unfortunately, it turns out that ia32-libs conflicts, indirectly, with
> *the one lone package* that I have explicitly installed from a Debian
> release other than stable, namely emacs24-lucid from wheezy-backports.
> 
> The immediate cause of the conflict is the package libp11-kit0, but
> the full dependency chain goes like this:
> 
> emacs24-lucid depends on libgnutls-deb0-28 (>= 3.3.0) depends on 
> libp11-kit0 (>= 0.20.7)

There you go!  It wasn't "somehow".  It was installed as an explicit
installation by you when you installed it from backports.  Everything
makes perfect sense.

Before downgrading it you would need to remove the emacs24-lucid
backport that you installed that pulled it in first.  Along with the
other dependencies too.

On the other hand you say you want emacs24-lucid from backports.  In
which case that means you also want libp11-kit0 from backports to
supply the dependency for it too.  Seems reasonable to me.  Keep it! :-)

Bob


signature.asc
Description: Digital signature

Re: Difficulty downgrading a mistakenly installed non-stable package

[Kynn Jones]

On Fri, Apr 24, 2015 at 1:50 PM, Brian  wrote:
> On Fri 24 Apr 2015 at 12:37:36 -0400, Kynn Jones wrote:
>
>> I try to keep my system as close to 100% stable as possible.  In spite
>> of this, a version of libp11-kit0 that is ahead of stable "somehow"
>> snuck into my system:
>>
>> $ apt-cache policy libp11-kit0
>> libp11-kit0:
>>   Installed: 0.20.7-1~bpo70+1
>>   Candidate: 0.20.7-1~bpo70+1
>>   Version table:
>>  *** 0.20.7-1~bpo70+1 0
>> 100 /var/lib/dpkg/status
>>  0.12-3 0
>> 500 http://debian.csail.mit.edu/debian/ stable/main amd64 
>> Packages
>> 500 http://ftp.us.debian.org/debian/ stable/main amd64 Packages
>
> libp11-kit0 wasn't installed by mistake and didn't sneak onto your
> system uninvited. Backports will pull in packages and versions of
> packages which are not in a stable release.

You're right, that's exactly what happened!  (The reason I thought
otherwise is that I misinterpreted some of `aptitude`'s output.  I
won't bore you with the details.)

Searching for libp11-kit0 in /var/log/aptitude.1.gz I found the line

[UPGRADE] libp11-kit0:amd64 0.12-3 -> 0.20.7-1~bpo70+1

just a couple of lines below the line

[INSTALL] emacs24-lucid:amd64

Sure enough, emacs24-lucid is one of only two packages (the other one
being emacs24-el) that I've installed from outside of stable, and both
come from wheezy-backports.

Thanks for your comments.

And @Bob, thanks also for your suggestion.  The output I got when I tried
it included the lines

The following packages have unmet dependencies:
 libgnutls-deb0-28 : Depends: libp11-kit0 (>= 0.20.7) but 0.12-3
is to be installed.
The following actions will resolve these dependencies:

 Remove the following packages:
1) emacs24-lucid
2) libgnutls-deb0-28

...and seeing `emacs24-lucid` there was what set me on the "Road to
Enlightenment." ;)

kj


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAFvQaj7Dm1DRywMvtHP5KpYRLWE=oM=+-h30+3kw2amuu53...@mail.gmail.com

Re: the correct way to read a big directory? Mutt?

[David Wright]

Quoting Vincent Lefevre (vinc...@vinc17.net):

> [...]
> 
> One can see an obvious difference: grep and my script both read the
> files in the directory order (I know that this is the case with my
> script, and grep's behavior is identical), which can be regarded as
> random due to the use of a hash (see the other thread). Mutt uses a
> different order, and after a look at its mh.c source file, I can see
> that it sorts the files by inode number (see maildir_delayed_parsing
> function). IMHO, this is a good choice because, specially in big
> directories, doing that may lead to contiguous files on the disk,
> and I think that it is the reason why Mutt is much faster.

Well that's a relief. I was getting worried about there being some
"magic" involved when you said you didn't use cacheing. So, looking
back at https://lists.debian.org/debian-user/2015/04/msg01265.html ,

 "In which case, if you want to know how come mutt is so fast, take a
 look at the source. Just to mention one optimisation I would consider:
 slurp the directory and sort the entries by inode. Open the files in
 inode order.
 And another: it's probably faster to slurp bigger chunks of each file
 (with an intelligent guess of the best buffer size) and use a fast
 search for \nMessage-ID rather than reading and checking line by line."

perhaps my second suggestion would also contribute to a speed-up. Here,
it does come down to "black magic": I can't understand the methods
they use to string-search so quickly in regular expressions etc.

(Note: obviously these suggestions were not original.)

> Now I wonder whether the use of the hash by ext3 is a good idea...

I don't see why. Directory-hashing only slows down the process of
obtaining the inode numbers from the directory. With a simple linear
directory, you might get that list of inode numbers more quickly,
and it might even be closer to being sorted.

But that's all fairly localised on the disk, and sorting is quick.
The major speed-up that you've demonstrated is made by accessing the
file contents from a sorted list of inode numbers (correlating with
the position of the files on the disk).

So in the absence of sorting (ie with general purpose tools like grep),
doing away with hashing will speed up the special case of reading all
the files in (a) just one entire directory (b) which hasn't had the
entries jumbled by insertion/deletion/renaming of files and (c) which
is specified using the directory's name (like grep -r ).
And should you read the whole directory by specifying /*,
you lose the benefit and thrash the disk again.

I have useful little bash functions that return the alphabetically
first or last, or the most recently modified file among the filenames
supplied. Perhaps I'll write one to take a list of filenames and return
them all, but sorted into inode order. (Maybe it already exists.)

Cheers,
David.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150424213951.GA13410@alum

Re: can't automatically launch lxde

[James]

On 04/24/2015 02:47 AM, Petter Adsen wrote:

On Thu, 23 Apr 2015 19:00:31 -0400
James  wrote:



On 04/22/2015 10:42 PM, James wrote:


On 04/21/2015 11:46 PM, Gary Dale wrote:

On 21/04/15 08:21 PM, James wrote:

I installed lxde as a gui desktop but I can't get it to run
automatically.
I need to login as me and then do sudo kdm (sudo lxdm doesn't
work).



It sounds like kdm isn't starting automatically, so you probably
don't have any gui starting (is this correct?).

Correct.

You probably have kdm or lxdm installed but not both, which is why
only one starts. Lxdm is not a Debian package so if you are
running Debian, that would explain it.

I am running Debian Jessie and I have lxde 8.
I think I just installed the lxde package.
https://wiki.debian.org/LXDE#LXDE_in_Debian


The easiest way to fix the problem may be to:

sudo apt-get purge kdm
sudo apt-get install kdm

This should fix any corruption that may have occurred and should
set up kdm to run on startup. If you prefer lxdm, simply change
the install line to lxdm (assuming that you are running Ubuntu).

sudo apt-get install lxde
Reading package lists... Done
Building dependency tree
Reading state information... Done
lxde is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I purged kdm and still no GUI starts, I had to use startx.

What happens when you do "sudo systemctl restart lightdm.service"? And
what's in /var/log/lightdm/lightdm.log?

Petter


sudo systemctl restart lightdm.service

Nothing happens.
There are no entries in /var/log/lightdm/lightdm.log

sudo systemctl status lightdm.service says:

lightdm.service - Light Display Manager
   Loaded: loaded (/lib/systemd/system/lightdm.service; enabled)
   Active: failed (Result: start-limit) since Fri 2015-04-24 19:08:31 
EDT; 1min 57s ago

 Docs: man:lightdm(1)
  Process: 1510 ExecStartPre=/bin/sh -c [ "$(cat 
/etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/lightdm" ] 
(code=exited, status=1/FAILURE)


Apr 24 19:08:31 cheetah systemd[1]: Failed to start Light Display Manager.
Apr 24 19:08:31 cheetah systemd[1]: Unit lightdm.service entered failed 
state.
Apr 24 19:08:31 cheetah systemd[1]: lightdm.service start request 
repeated too quickly, refusing to start.

Apr 24 19:08:31 cheetah systemd[1]: Failed to start Light Display Manager.
Apr 24 19:08:31 cheetah systemd[1]: Unit lightdm.service entered failed 
state.\




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

Archive: https://lists.debian.org/553ace6b.7090...@lockie.ca

Re: the correct way to read a big directory? Mutt?

[Vincent Lefevre]

On 2015-04-24 16:39:51 -0500, David Wright wrote:
[...]
>  And another: it's probably faster to slurp bigger chunks of each file
>  (with an intelligent guess of the best buffer size) and use a fast
>  search for \nMessage-ID rather than reading and checking line by line."

This is not that simple. I want my script to be very reliable.
In particular, if there is a message without a Message-ID and
with "\nMessage-ID" in the body, I want to detect it. This kind
of thing really happens in practice (though this is rare), e.g.
due to some buggy mail software that breaks the headers and put
a part of them in the body. I also want to check the format of
the headers and possible duplicate Message-ID. What my script
really does is:

while ()
  {
/^[\t ]/ and next;
/^\S+:/ || (!$from++ && /^From /)
  or die "$proc: bad message format ($file)";
/^Message-ID:\s+(<\S+>)( \(added by .*\))?$/i or next;
defined $files{$1}
  and die "$proc: duplicate message-id $1 ($files{$1} and $file)\n";
$files{$1} = $file;
last;
  }

[...]
> And should you read the whole directory by specifying /*,
> you lose the benefit and thrash the disk again.

With zsh, I often do things like: grep ... /**/*.c

One can choose to sort the result, but zsh doesn't support sorting
by inode number. I've sent a feature request.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150425003907.gb12...@xvii.vinc17.org

Re: reading an empty directory after reboot is very slow

[David Wright]

Quoting Vincent Lefevre (vinc...@vinc17.net):
> On 2015-04-23 11:22:11 -0500, David Wright wrote:
> > Quoting Vincent Lefevre (vinc...@vinc17.net):
> > > On 2015-04-23 11:31:27 +0200, Nicolas George wrote:
> > > > Le quartidi 4 floréal, an CCXXIII, Vincent Lefevre a écrit :
> > > > > David's test shows that the renamed file is missed.
> > > > 
> > > > No, it shows that the renamed file is NOT missed: he renamed the
> > > > entry for inode 497003 from file2 into a long name, and that
> > > > entry is returned, exactly once, under its old name. The "oops,
> > > > file2 stat() fails" only shows the race condition between
> > > > readdir() return and stat(); I am sure that if he printed
> > > > dirent.d_ino instead of stat.st_ino, it would have printed
> > > > 497003.
> > 
> > Yes, it would. See below as to why I printed the stat() version.

Well, that's what I thought, because of the cacheing. But Nicolas
asked me to try using thousands of files, and so here we are,
ie, your "new test":

~ $ for j in `seq 1` ; do mkdir /tmp/testdir/file$j ; done
~ $ ./a.out /tmp/testdir/ > lsout1
~ $ ./a.out /tmp/testdir/ > lsout2 ← here I renamed file2621
~ $ ./a.out /tmp/testdir/ > lsout3
~ $ wc lsout*
 10003  40009 237834 lsout1
 10002  40005 237809 lsout2 ← missing entry
 10003  40009 237890 lsout3
 30008 120023 713533 total
~ $ 

~ $ cat lsout1
1 I: 488780 .
2 I: 488641 ..
3 I: 872200 file1133
4 I: 920449 file5197
...
3262 I: 880852 file1940
3263 I: 896998 file3481
3264 I: 961277 file9216
3265 I: 945402 file7637
3266 I: 904859 file4197
3267 I: 879726 file1241
3268 I: 880694 file1782
3269 I: 945545 file7773
3270 I: 937554 file7267
sleeping
3271 I: 921316 file5736
3272 I: 945551 file7779
...
9998 I: 872083 file1016
 I: 937210 file6923
1 I: 912739 file4685
10001 I: 888626 file2621
10002 I: 896549 file3032
~ $ 

~ $ cat lsout2
1 I: 488780 .
2 I: 488641 ..
3 I: 872200 file1133
4 I: 920449 file5197
...
3262 I: 880852 file1940
3263 I: 896998 file3481
3264 I: 961277 file9216
3265 I: 945402 file7637
3266 I: 904859 file4197
3267 I: 879726 file1241
3268 I: 880694 file1782
3269 I: 945545 file7773
3270 I: 937554 file7267
sleeping
3271 I: 921316 file5736
3272 I: 945551 file7779
...
9998 I: 872083 file1016
 I: 937210 file6923
1 I: 912739 file4685
10001 I: 896549 file3032
~ $ 

~ $ cat lsout3
1 I: 488780 .
2 I: 488641 ..
3 I: 872200 file1133
4 I: 920449 file5197
...
3262 I: 880852 file1940
3263 I: 896998 file3481
3264 I: 888626 file2621file2621file2621file2621file2621file2621file2621file2621
3265 I: 961277 file9216
3266 I: 945402 file7637
3267 I: 904859 file4197
3268 I: 879726 file1241
3269 I: 880694 file1782
3270 I: 945545 file7773
sleeping
3271 I: 937554 file7267
3272 I: 921316 file5736
...
9998 I: 953898 file8808
 I: 872083 file1016
1 I: 937210 file6923
10001 I: 912739 file4685
10002 I: 896549 file3032
~ $ 

So we have a file gone AWOL because it was renamed during this
program's execution. (The I numbers here come from dirent;
there's no call of stat.)

> > > I only focused on the inode number and I thought that David's test was
> > > printing dirent.d_ino (which was the obvious thing to do). Now, after
> > > re-reading carefully what he said:
> > > 
> > >   "I scan the directory with readdir, then stat the file to obtain its
> > >^^^
> > >inode number."
> > >
> > > 
> > > Indeed, this is the wrong way to do!
> > 
> > Well, the program I filched, because filch it I did, printed more
> > *interesting* stuff about the file, stuff like the size etc.
> > I switched it to printing the (to most people, boring) inode number
> > because, *for the purpose of this exercise*, the inode number acts as
> > a unique identifier for a file which has just changed name.
> 
> Except that you don't show anything special: it is obvious that there
> is a race condition on the filename when doing a file rename and
> reading the directory containing that file at the same time, i.e. one
> can either get the old filename or the new filename. This will be true
> with *any* filesystem (I mean, the behavior is not specified).

That's what I originally said. Here it is again, from your posting at
https://lists.debian.org/debian-user/2015/04/msg01157.html

On 2015-04-15 14:13:43 -0500, David Wright wrote:
> Quoting Kushal Kumaran (kus...@locationd.net):
> > Moving entries around breaks ongoing readdir operations.  If a readdir
> > has gone past the file being removed, and you moved the last entry
> > there, the entry being moved would be missed, despite *it* not being the
> > entry added or removed.
> 
> I don't think this matters. There's no guarantee that another process 
← me
> isn't writing to that directory while you are working your way along
> the entries.

But with the current solution (no automatic moving of an entry), you
← you
can't miss an entry that hasn't been removed.

Yo

Re: the correct way to read a big directory? Mutt?

[Vincent Lefevre]

On 2015-04-24 16:39:51 -0500, David Wright wrote:
> Well that's a relief. I was getting worried about there being some
> "magic" involved when you said you didn't use cacheing. So, looking
> back at https://lists.debian.org/debian-user/2015/04/msg01265.html ,
> 
>  "In which case, if you want to know how come mutt is so fast, take a
>  look at the source. Just to mention one optimisation I would consider:
>  slurp the directory and sort the entries by inode. Open the files in
>  inode order.

When you said that, I didn't know that this was taken from Mutt (or
perhaps you suggested that without looking at the Mutt source?).

This is now done in my script, but I had to use the ReadDir module
from CPAN, since both readdir implementations in Perl (the standard
readdir Perl function and POSIX::readdir) just return the file name.
And this ReadDir module isn't available in a Debian package.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150425004617.ga12...@xvii.vinc17.org

Re: Recommendation on video card?

[Igor Cicimov]

On 25/04/2015 2:36 AM, "Ric Moore"  wrote:
>
> On 04/24/2015 03:23 AM, Petter Adsen wrote:
>>
>> I have an AMD HD5450 card in my desktop, which has been mostly
>> adequate for me, but now it is time to retire it.
>>
I have Radeon HD 6570 (MSI one) in my MythTV Ubuntu-14.04 backend. It is
128-bit 1GB DDR3 low profile card it has OpenGL 4.1, DirectX 11 and VAAPI
support and its reasonably priced. Highly recommended for desktop if you
are after radeon card especially if you like watching movies from time to
time.

Anyway, this is how I pick a card ... I go to
http://www.videocardbenchmark.net and choose a card(s) from the range I'm
after and then look for the best price I can find.

>> Can anyone recommend a more recent card that works well with X? I'm
>> using two screens, so I will need at least two outputs - preferably
>> digital. I have been quite happy with AMD, so I'd like to stick with
>> that, and I prefer not using the fglrx driver if possible. One
>> thing that would be nice is hardware decoding of video, with something
>> later than UVD2.
>>
>> At some point I will probably also need to get a third screen, so
>> something that has three outputs or would run nicely with a second
>> video card that has additional outputs is a big bonus.
>>
>> I use no 3D software, no games, and nothing I can think of that needs a
>> powerful GPU. It might be nice with 4K support, though.
>>
>> Everything online talks about what cards to get for gaming, but that is
>> irrelevant to me.
>
>
> Actually it is relevant. People use "gaming" as a benchmark. If it works
well for gaming, then you are set, just in case you find that you actually
need some horsepower, or don't want to be annoyed with tearing, etc. You
just never know. Especially if you want to drive multi-monitors with
multi-cards.
>
> AMD and Intel have been less than stellar, in the past, for higher-end
support. Just a quick search finds an older nvidia GT610 PciE with 2 gigs
of vram for $40 with free shipping on Amazon. I'm running two older GT520's
for four monitors. Works a charm with the nvidia drivers and tweaking the
bios to turn off the built-in video. I did have to install a larger power
supply to keep it all from over-heating, the average 500 watt supply is too
marginal for this load, IMHO.
>
> Be sure to check for the openGL version which should be equal to or
higher than version 2.0. So, IMHO it's better to have too much, than not
enough! But, that is just my two cents:) 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
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a
subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: https://lists.debian.org/553a70ff.5030...@gmail.com
>

Re: reading an empty directory after reboot is very slow

[Vincent Lefevre]

On 2015-04-24 19:41:03 -0500, David Wright wrote:
> Well, that's what I thought, because of the cacheing. But Nicolas
> asked me to try using thousands of files, and so here we are,
> ie, your "new test":
> 
> ~ $ for j in `seq 1` ; do mkdir /tmp/testdir/file$j ; done
> ~ $ ./a.out /tmp/testdir/ > lsout1
> ~ $ ./a.out /tmp/testdir/ > lsout2 ← here I renamed file2621
> ~ $ ./a.out /tmp/testdir/ > lsout3
> ~ $ wc lsout*
>  10003  40009 237834 lsout1
>  10002  40005 237809 lsout2 ← missing entry
>  10003  40009 237890 lsout3
>  30008 120023 713533 total
> ~ $ 
[...]
> So we have a file gone AWOL because it was renamed during this
> program's execution. (The I numbers here come from dirent;
> there's no call of stat.)

So, I would say that this is a bug. POSIX says in
http://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html

  If a file is removed from or added to the directory after the most
  recent call to opendir() or rewinddir(), whether a subsequent call
  to readdir() returns an entry for that file is unspecified.

But when a file is renamed, it is nowhere said that the file is
removed from and/or added to the directory. The POSIX spec just
says that the file is "renamed".

[...]
> You said that without "Bob's move", you couldn't miss an entry that
> hasn't been removed.
> 
> I've demonstrated that you can.

Because of a *bug*. With a conforming implementation, you can't.

(And if a renamed file were regarded as an entry that was removed,
then this would mean that your example would not be correct, because
this would not be "an entry that hasn't been removed".)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150425010834.gc12...@xvii.vinc17.org

Re: the correct way to read a big directory? Mutt?

[David Wright]

Quoting Vincent Lefevre (vinc...@vinc17.net):
> On 2015-04-24 16:39:51 -0500, David Wright wrote:
> > Well that's a relief. I was getting worried about there being some
> > "magic" involved when you said you didn't use cacheing. So, looking
> > back at https://lists.debian.org/debian-user/2015/04/msg01265.html ,
> > 
> >  "In which case, if you want to know how come mutt is so fast, take a
> >  look at the source. Just to mention one optimisation I would consider:
> >  slurp the directory and sort the entries by inode. Open the files in
> >  inode order.
> 
> When you said that, I didn't know that this was taken from Mutt (or
> perhaps you suggested that without looking at the Mutt source?).

I think I had been reading around the ext2/3/4 filesystem descriptions
and happened upon this trick at some random link close by.

> This is now done in my script, but I had to use the ReadDir module
> from CPAN, since both readdir implementations in Perl (the standard
> readdir Perl function and POSIX::readdir) just return the file name.
> And this ReadDir module isn't available in a Debian package.

Python's library function listdir suffers the same way. If you want
the inode, you have to call stat to get it. (I haven't looked for
external modules like ReadDir as I don't have very large directories.)

Cheers,
David.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150425024141.GC13410@alum

Re: boot-time messages, /init touch not found

[Mike Kupfer]

The Wanderer wrote:

> If that doesn't help, then I'd advise that you expand the initramfs /
> initrd file from under /boot into an empty directory, and see what it
> contains. It may very well be missing either bin/touch or some related
> thing.

Indeed, it's missing bin/touch.  Thanks for the detailed directions.

regards,
mike


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/7958.1429930887@allegro.localdomain

Re: reading an empty directory after reboot is very slow

[David Wright]

Quoting Vincent Lefevre (vinc...@vinc17.net):
> On 2015-04-24 19:41:03 -0500, David Wright wrote:
> > Well, that's what I thought, because of the cacheing. But Nicolas
> > asked me to try using thousands of files, and so here we are,
> > ie, your "new test":
> > 
> > ~ $ for j in `seq 1` ; do mkdir /tmp/testdir/file$j ; done
> > ~ $ ./a.out /tmp/testdir/ > lsout1
> > ~ $ ./a.out /tmp/testdir/ > lsout2 ← here I renamed file2621
> > ~ $ ./a.out /tmp/testdir/ > lsout3
> > ~ $ wc lsout*
> >  10003  40009 237834 lsout1
> >  10002  40005 237809 lsout2 ← missing entry
> >  10003  40009 237890 lsout3
> >  30008 120023 713533 total
> > ~ $ 
> [...]
> > So we have a file gone AWOL because it was renamed during this
> > program's execution. (The I numbers here come from dirent;
> > there's no call of stat.)
> 
> So, I would say that this is a bug. POSIX says in
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html

It may well be. But I'm just presenting facts about the
filesystems that I assumed you were using when you posted
https://lists.debian.org/debian-user/2015/04/msg00651.html ,
not the theory of a POSIX-compliant system.

>   If a file is removed from or added to the directory after the most
>   recent call to opendir() or rewinddir(), whether a subsequent call
>   to readdir() returns an entry for that file is unspecified.
> 
> But when a file is renamed, it is nowhere said that the file is
> removed from and/or added to the directory. The POSIX spec just
> says that the file is "renamed".
> 
> [...]
> > You said that without "Bob's move", you couldn't miss an entry that
> > hasn't been removed.
> > 
> > I've demonstrated that you can.
> 
> Because of a *bug*. With a conforming implementation, you can't.
> 
> (And if a renamed file were regarded as an entry that was removed,
> then this would mean that your example would not be correct, because
> this would not be "an entry that hasn't been removed".)

It may be a bug. It may be a misfeature in the interests of
performance. I don't know. When writing big programs, decisions have
to be taken.

But my demonstration stands. If you want to reject my observations by
bringing in POSIX-compliance as a precondition for my tests, that
would be both inconsiderate (ie you'd be telling me I've wasted my
time doing all the tests that you encouraged me to perform), and a
post disputation argument.

This thread would have taken a different course if you'd posted
"But with a POSIX-compliant filesystem, as ext3/4 is supposed to be,
you can't miss an entry that hasn't been removed." Then I could have
looked at the docs and skipped all the tests.

Cheers,
David.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150425030137.GD13410@alum

Re: nfs problems

[briand]

On Thu, 23 Apr 2015 23:54:45 -0600
Bob Proulx  wrote:

> bri...@aracnet.com wrote:
> > however the client side mount commands are apparently wrong because
> > I get this:
> > 
> > mount.nfs4: mounting server:/nfs4exports/home/user1 failed, reason given by 
> > server:
> >   No such file or directory
> > 
> > and as usual the error message is completely unhelpful because
> > /nfs4exports/home/user1 most certainly DOES exist on the server.
> 
> Hmm...  Guessing...  What is in /etc/exports?  'exportfs -a'?  What
> does 'showmount -e' show?
> 
> Bob

well that was quite newbie of me to not provide exportfs wasn't it ?

i did finally get things working :

  exportfs

  /home/user1 
192.168.1.1/24(rw,root_squash,insecure,anonuid=501,anongid=501,async,no_subtree_check)

and then

  /etc/fstab

  server:/home/user1  /mnt/home/user1   nfs4  rw,hard,intr  0 0


and finally

  sudo mount /mnt/home/user1 

now works.  I'm sure I had a mismatch between all of the files in terms of path 
somehow, but i never really did figure out what i did wrong.

i'm not sure what the point of using:

  /home /nfs4exports/home none bind 0 0

as a mount point is.  Seems like using that provided some way to simplify the 
set-up.  or maybe it is simplifying the set-up and i just don't realize it.

Brian


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150424214248.1462d...@cedar.deldotd.com