On Fri, Feb 19, 2010 at 01:39:53AM +0530, Jeffrin Jose wrote:
> On Thu, Feb 18, 2010 at 08:08:48AM -0500, Thomas H. George wrote:
> >
> > Any recommendations or experience with this problem?
> >
> hello.
> You can try
> http://www.mythtv.org/download
> You can get MythTV from working debian-multimedia.org
> repositories.
>
> /Jeffrin.
>
>
> —
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of “unsubscribe”. Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/20100218200953.GA4286@debianlabs
>
Re: Amarok 2.2.1 proxy issue
On Fri, Feb 19, 2010 at 09:41:16PM +0530, Jeffrin Jose wrote:
> On Thu, Feb 18, 2010 at 02:51:28PM -0700, Bjorn Meyer wrote:
> > Hi all.
> >
> > I am wondering if anyone else has run into this issue, and found a resolution.
> >
> > I am finding that Amarok 2.2.1 will not detect the global KDE settings for the
> > proxy server. So I am unable to stream music and it will not look up the
> > lyrics.
> You can try global proxy settings using konqueror.The global
> proxy setting may not be working because konqueror is in the offline
> mode.
>
> > However, if I run “export http_proxy=http://192.168.1.1:8080” in a console
> > session, then run /usr/bin/amarok, I am able to stream again. Lyrics, still
> > don’t show up, but I’m not too worried about that.
> you may do one thing.Edit ~/.kde/share/config/kioslaverc
> and try adding ..
>
> ProxyType=1
> http_proxy=http://192.168.1.1:8080
>
> Save and Restart Amarok.
>
> /Jeffrin.
>
>
> —
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of “unsubscribe”. Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/20100219161116.GA2153@debianlabs
>
glxinfo – show information about the GLX implementation
UNIX Command
$glxinfo | grep direct
direct rendering: Yes
GL_EXT_Cg_shader, GL_EXT_depth_bounds_test, GL_EXT_direct_state_access,
$
UNIX Explanation
The glxinfo program shows information about the OpenGL and GLX implementations running on a given X display.
http://www.opengl.org/documentation/
http://en.wikipedia.org/wiki/OpenGL
glxinfo
ahiliation:~$glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
The glxinfo program shows information about the OpenGL and GLX implementations running on a given X display.
http://www.opengl.org/documentation/
http://en.wikipedia.org/wiki/OpenGL
hcitool
ahiliation:~$hcitool inq
Inquiring …
Inquiry failed.: No such device
ahiliation:~$
hcitool is used to configure Bluetooth connections and send some special command to Bluetooth devices.
apt-get update
ahiliation:~$sudo apt-get update
[sudo] password for jeffrin:
Get:1 http://dl.google.com stable Release.gpg [189B]
Ign http://dl.google.com stable/main Translation-en_IN
Hit http://http.us.debian.org sid Release.gpg
Get:2 http://dl.google.com stable Release [2,540B]
Ign http://dl.google.com stable/main Packages/DiffIndex
Get:3 http://dl.google.com stable/main Packages [871B]
Ign http://http.us.debian.org sid/main Translation-en_IN
Ign http://http.us.debian.org sid/contrib Translation-en_IN
Hit http://http.us.debian.org sid Release
Hit http://http.us.debian.org sid/main Packages/DiffIndex
Hit http://http.us.debian.org sid/contrib Packages/DiffIndex
Hit http://http.us.debian.org sid/main Sources/DiffIndex
Hit http://http.us.debian.org sid/contrib Sources/DiffIndex
Fetched 3,600B in 5s (630B/s)
Reading package lists… Done
ahiliation:~$
update is used to resynchronize the package index files from their sources
HOWTO run badblocks command
Block I $badblocks /dev/hda1 ^C Interrupted at block 137600 $badblocks -b 1 -c 0 /dev/hda1 badblocks: File too large while trying to determine device size $badblocks -b 1500 -c 0 /dev/hda1 ^C Interrupted at block 0 Block II $badblocks -b 1500 -c 64 /dev/hda1 Weird value (96000) in do_read Weird value (96000) in do_read Weird value (96000) in do_read .^C interrupted at block 1792
TODO Fix Block II.
http://e2fsprogs.sourceforge.net
badblocks
Block I
debianlabs:~# badblocks /dev/hda1
^C
Interrupted at block 137600
debianlabs:~# badblocks -b 1 -c 0 /dev/hda1
badblocks: File too large while trying to determine device size
debianlabs:~# badblocks -b 1500 -c 0 /dev/hda1
^C
Interrupted at block 0
Block II
debianlabs:~# badblocks -b 1500 -c 64 /dev/hda1
Weird value (96000) in do_read
Weird value (96000) in do_read
Weird value (96000) in do_read
.^C
interrupted at block 1792
TODO Fix Block II.
http://e2fsprogs.sourceforge.net
Re: Bash question: get output as a variable?
On Fri, Feb 05, 2010 at 09:01:45AM -0700, Paul E Condon wrote:
On 20100205_135919, Alexey Salmin wrote:
On Fri, Feb 5, 2010 at 1:20 PM, Javier Barroso wrote:
On Fri, Feb 5, 2010 at 1:06 AM, Stephen Powell wrote:
> >> On Thu, 4 Feb 2010 17:42:45 -0500 (EST), Javier Barroso wrote:
> >>> In this case output goes to stderr, so:
> >>>
> >>> tar -zcvf – * –exclude-from $EXCLUDES 2> /tmp/data$$ | openssl …
> >>
> >> Is that something you just have to find out by trial and error?
> >> I checked the man page for tar, and there’s nothing in there about
> >> the -v output being written to stderr. ?I’ll take your word for it,
> >> but in the general case, it’s hard to tell. ?Since stdout and
> >> stderr both default to the terminal, and since the doc doesn’t
> >> say, how else would you know other than by trial and error?
> > If you are using stdout as tar output, including filenames there will
> > corrupt that output, so it is logical that in this case filenames goes
> > to stderr.
> >
> > Sorry my bad english, I hope you understand my opinion
> >
>
> That’s true: programs using stdout for data output certainly have to
> use stderr as a way to report any additional info.
>
> Alexey
A comment towards ‘how would I know’:
Traditional Unix and traditional C both made provision for stdin,
stdout, and stderr. When Stroustrup, et al., started working on C++
and its earlier predicessors, someone recognized the need for a fourth
stdXXX, namely stdlog. I think it was/is a good idea, but it has
never gained enough traction to justify all the changes that would be
required if it were introduced into the POSIX standard. Instead, the
community has kept the name stderr, but changed the usage to something
that might better be named stdmsg, indicating both errors and action
logging. Its the sort of historical development that doesn’t get recorded
in any man page (or at least any man page that newbies know about).
HTH
—
Paul E Condon
pecondon@mesanetworks.net
—
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of “unsubscribe”. Trouble? Contact listmaster@lists.debian.org