From: "hannah commodore" <hannah(a)tinfoilhat.net>
> I've been using the CuBox from Solid Run for an XBMC player - No inbuilt
> optical drive, but it has USB and could easily use one external. My media
> is served via NFS
>
> http://www.solid-run.com/
> http://cubox-i.com/
Sounds cool!
There are images for Debian. Do you know whether they contain closed
source binaries? Can you upgrade from official Debian repositories?
(Info for other distributions would be welcomed too).
Thanks
Peter
On 28/04/14 13:21, hannah commodore wrote:
>
> On 25 Apr 2014, at 22:08, Daniel Jitnah <djitnah(a)greenwareit.com.au> wrote:
>
>> By the way, I believe "John Wayne" did this ... ride his
>> horse to a place and change to a new horse somewhere on the trip and
>> continued his trip on another horse!!!
>
> This was actually normal Pony Express practice. The riders would swap horses
> at each station, where the horse could recoup and await the next rider to
> come along
>
Yes, I was pointing out that its not a new idea at all!
Daniel.
> hannah
>
Hi all,
I am putting my DVD collection onto a hard drive and I am using DVDRIP,
and I have been unsuccessful in getting subtitles to display in the end
file. How do I configure DVDRIP to grab the subtitles please?
Andrew Greig
Some comments based on a number of points by Rick Moen........
>> You haven't been using GRUB nearly that long.
>Quite right. And I've been seriously tempted to give that piece of junk
>the heave-ho and go back to lilo. (On EFI, there's elilo.)
>It wasn't broken, and I am annoyed by distros fixing what wasn't broken.
>(Your mileage may differ.)
Lilo is still availible on Debian under "expert install" and works very
well. I dislike grub greatly and have always had problems with it. Lilo is
simple and I understand it and its limitations very well. The more complex
something is made the chances it has to breakdown in some way!
>> having multiple drive controller technologies - sata and sas, for
>> example - is not at all uncommon.
>I've already stated my view that this is something to avoid (concerning
>main storage) if reasonably possible - and also stated that my view
>applies within the scope of the usage scenarios I've found myself in
>over the past 21 years of Linux use. I've also said that I think it's a
>great idea to, at minimum, retain UUID-based lines in one's /etc/fstab
>as comments in case the information therein is ever needed.
I used for a while the combination of SCSI (3 hard drives) and a PATA data
drive. (reason for this set up was large scsi drives being difficult to get)
It for most part was not satisfactory, the Linux kernel having some kind of
built in bias far PATA. For instance when uodating the kernel with lilo one
had to unplug the PATA otherwise the lilo command would fail.
As for UUID's I do not use them mainly for the reasons given by Craig and
have never really had any problems. As for UUID's there is little info
about them and how to use them and in a recent experiment one a system
using them....
On a UUID enabled system (before I changed it back to using device's) I
swapped a pair disks between devices. On reboot system failed as it could
not mount the drives. I had assumed according to the UUID docs that the
drives would be mounted according to UUID to mount point mapping given in
fstab, this did not occur.
Lindsay
Hi,
Are Ubuntu still making Alternate Install CDs for their new releases?
Want to do some stuff to the hard disk before the actual install of Trusty.
Otherwise: Should I just do the trial run and do things via a terminal
window there, or boot up off an old Alternate Install CD?
Ta,
Carl
Bayswater
I mentioned in my previous post that I was getting an "invalid HTTP
request" error on search's.
Now this is caused by the Debian built package including a problematical
version of libcurl (/usr/lib/googleearth/libcurl.so.4), to fix the above
problem all that is required is to remove this library (googleearth will
use the systems libcurl). I did this by renaming libcurl.
Note, the Debian package supplied by the google earth web site does not
have a version of libcurl with it.
Lindsay
Finally got it working on Debian 7.4. NVidia closed src driver was removed
and reinstalled, google earth mostly works OK, I say mostly as search does
not work but comes up with an "invalid HTTP request" error, everything else
though seems to work.
Interestingly the package from google earth works, the Debian generated
package comes up with a library error message from one of the Qt libraries.
This may be fixable, a post on the google earth help forums provides a
archive of 4 Qt libraries that the post say create some problems on Debian
based distributions. The two versions APPEARS to be able to co-exist as the
main exicutable runs under different names.
Lindsay
Many thanks for the replies, unfortunately nothing has so far worked.
A small correction the distribution used is actually current Debian stable.
A search on the net shows a lot of people are having problems on both
Debian and Ubuntu. Interestingly the symptoms on my system do not match any
of the above problems.
It seems to be worth a try to get rid of the NVdia closed src drivers and
see what happens as quite a number of cures have invloved playing around
with the closed src driver files.
Various solutions have been put up and it appears that clear it does work
on some systems. Google earth though appears to be quite a fragile/picky
program. In my case it certainly worked on Debian 6.0.
Of my 4 systems one is running Debian 7.4 i386, another 7.4 amd64, the
third debian testing i386. The forth is running 6.0 i386, GE was working on
this (note 1), unfortunately this has had an Intel 530 series SSD fail
recently and is out of action till I get around to replacing the drive. I
will keep it at Debian 6.0 and see if GE (still) works on it.............
Note 1, the amount of Debian i386 in the above list, 3 out of 4 machines,
is because I use wine I have compiled myself (a later version of wine than
Debian had being required). Now the debian packages of wine do work on my
amd64 machine but I simply have not been able to get wine to compile on
amd64 inspite of following a number of sugestions from various forums.
Lindsay
From: "Toby Corkindale" <toby(a)dryft.net>
> On 16 April 2014 13:00, James Harper <james.harper(a)bendigoit.com.au>
> Last time this came up, in 2013, you checked the inbound packets, and
> reported:
> "I can confirm what we thought - pings <= 1492 bytes get a response,
> pings > 1492 bytes get no response, not even a 'fragmentation
> required'."
Sorry, I did not read all of your conversation before, just remember bits
and pieces but it really reminds me of the introduction of a new ADSL
router a few months ago.
(From my e-mail conversation to the ISP then:
---
With the old one[old router], I can ping up to 1464 bytes (ping -s 1464 -D
www.zeit.de), above it fails.
The new one I can ping just up to 1430 bytes (ping -s 1430 -D
www.zeit.de), 1432 is too much.
BTW, on the old one I can ping with bigger packets (e.g. 1600 bytes) as
long as I allow fragmentation.
So, there is something blocking packets bigger than 1430 bytes
(ICMP+header), compared to 1464 on the old link.
If I have packets above 1464 my end complains (ping: sendto: Message too
long) because it knows its own MTU. So the 1430 limit is not on my end, it
is further away.
..
P.S. After this, I set the MTU at 1458 at the proxy server (not the
gateway itself which sits between proxy and the ADSL modem). Then it
works.
---
I have no access to the ADSL router so I had to report from the device
behind it (a FreeBSD router).
The ADSL router was doing PPPoE.
In-between the technician considered a faulty ADSL router but finally
figured out: THe ADSL router had a configuration error (not a hardware
problem)
I vaguely remember that it had to do with path MTU discovery and blocked
ICMP packages further upstream (so the result was not the same on all
websites, hence my test with the "reliably failing" www.zeit.de website),
as described here:
http://en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD
Unfortunately I cannot access the ASDSL router so I do not know exactly
what the change in the config was.
Regards
Peter
I have tried to run google earth on current debian testing, both the
package from google-earth and the one built by debians google-earth-package.
Both of these when run cause the X server to crash back to the console with
a segmentation violation, the initial loading screen shows, the screen
switches to full screen with a black background, the crash occurs after
another second or so. Anyone have any idea's, I may install Debian stable
(7.4) and see if that works.
Lindsay
