2:18 p.m.
After burning 3 DVD's, and reading them back to compute sha256sum.
all three of them generated these error messages during readback,
and all 3 messages show the error was past the 4gb offset.
Is this a media issue or is it the burner?
A side question: why does the block io layer assume that all media
have 512 byte sectors?
[ 977.862167] sr 1:0:0:0: [sr0] FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 977.862175] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current]
[ 977.862179] sr 1:0:0:0: [sr0] Add. Sense: Unrecovered read error
[ 977.862182] sr 1:0:0:0: [sr0] CDB:
[ 977.862186] Read(10): 28 00 00 22 33 38 00 00 40 00
[ 977.862197] blk_update_request: I/O error, dev sr0, sector 8965376
[ 981.369440] sr 1:0:0:0: [sr0] FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 981.369448] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current]
[ 981.369452] sr 1:0:0:0: [sr0] Add. Sense: Unrecovered read error
[ 981.369455] sr 1:0:0:0: [sr0] CDB:
[ 981.369458] Read(10): 28 00 00 22 33 78 00 00 40 00
[ 981.369471] blk_update_request: I/O error, dev sr0, sector 8965600
[ 986.544988] sr 1:0:0:0: [sr0] FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 986.544996] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current]
[ 986.545000] sr 1:0:0:0: [sr0] Add. Sense: Unrecovered read error
[ 986.545024] sr 1:0:0:0: [sr0] CDB:
[ 986.545027] Read(10): 28 00 00 22 33 70 00 00 02 00
[ 986.545043] blk_update_request: I/O error, dev sr0, sector 8965568
[ 986.545051] Buffer I/O error on dev sr0, logical block 1120696, async
page read
1:36 a.m.
On Sat, 2015-04-04 at 13:11 -0600, Pete Travis wrote:
After viewing lots of graphs from really serious PSU testing (ie
jonnyguru.com), I decided that "PSUs are most efficient at 50-60%
capacity" was a good enough generalization. If you work out the
maximum draw of your system, add around 40%, and find a quality! power
supply in that range, you're set.
Yes, it's very hard to estimate how much power you will need, especially
as you don't have proper specs, or any specs, on your hardware. None of
my hardware ever came with any, and I place dubious faith with any
technical details that you get from things like the data that dmidecode
retrieves from your hardware.
You really need to know peak and average power requirements, and from
which supply. If you happened to have something that said it needs 12
watts, you need to know whether that's 12 watts from the 12 volt or the
5 volt supply, or both, and in what proportions from each. Without that
level of details, it's all guesswork.
Also, it's somewhat hit and miss to guess at where a switchmode power
supply is operating efficiently and reliably. They're not efficient
when underloaded (when your supply can provide much more than you're
actually using), and not reliably when run too close to the limit
(having no overheads to cope with extra demands).
Emphasis on quality, though. The dramatically cheaper ones lie, or
state consumption rather than output, use some esoteric metric for
wattage specs, or otherwise aren't actually capable of what they
claim.
Kind of like the fanciful PMPO stereo specifictions, where we get tiny
computer speakers claiming that they're 100 watts, when they can barely
manage 1 watt.
The theory behind PMPO (peak music power output) is a fanciful idea
based on something like if a device can supply 1 watt for 10 seconds, it
(allegedly) can supply 10 watts for 1 second, or (allegedly) 100 watts
for a 1/10 of a second, because overly simplistic maths has been used,
with no regard for what the circuit could actually do. Of course,
manufacturers add other random bogus factors to the formula.
I have as much faith in computer supply claims, regarding power, as I do
with the shonky amplifier power claims.
--
tim@localhost ~]$ uname -rsvp
Linux 3.18.9-100.fc20.i686 #1 SMP Mon Mar 9 17:04:05 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
2:11 p.m.
On Apr 2, 2015 2:38 AM, "g" <geleem(a)bellsouth.net> wrote:
On 04/01/2015 11:40 PM, Robin Laing wrote:
> On 2015-04-01 19:15, g wrote:
>> On 04/01/2015 02:18 PM, jd1008 wrote:
>>> After burning 3 DVD's, and reading them back to compute sha256sum.
>>> all three of them generated these error messages during readback,
>>> and all 3 messages show the error was past the 4gb offset.
>>>
>>> Is this a media issue or is it the burner?
>>
>> 1- burn dvd at 2 speeds lower than what you used and had failure.
>>
>> if ok, problem is either burner or blanks.
>>
>> 2- burn dvd at failure speed on a different burner.
>>
>> if ok, get a new burner. if failure, may be blanks.
>>
>> 3- try different program or burn from command line.
>>
>>> A side question: why does the block io layer assume that all media
>>> have 512 byte sectors?
>>
>> i believe that is a carry over from disk formatting started by the
>> IBM PC. [do not hold me to that]
>>
>
> Also watch power supply voltages.
>
> I have ran into two power supplies that caused issues with CD
> burning. Couldn't supply that little extra bit of current during
> the burn process. To burners later, I finally found it.
this is true.
a few years back, a poster asked for recommendations on building up
system and had a lot of responses.
my response of getting a power supply with at least a 20% factor,
and that a 30% factor would be even better due to my considering
future additions or changes.
i was met with opposition and even ridicule from a poster who
stated that he had never seen need.
too many 'builders' are unaware of such factors and will end up
with a system that gets flaky when additions and upgrades are
made.
such is a prime reason for 'ready made' failures.
back to dvd checksum errors and a great surprise that i just had.
due to need for centos 6.6 i386 for a system that i am putting
together for home control use, i decided to burn the iso to a
dvd rw disk using k3b and all went well including k3b ok'ing
the burn.
after closing k3b i ran 'sha256sum /dev/sr1 > sr1' with disk still
in the usb drive i burned it with. checksum failed.
so decided to moved disk to the internal burner to see how it check.
'sha256sum /dev/sr0 > sr0' produce correct sha256sum.
having run check on the usb burner many time before when using k3b
and cl and i have gotten good checks, i was surprised.
am i going to worry about it. hell no. 2 out of 3 good checks tells
me that Murphy is at it again. ((GBWG))
--
peace out.
in a world with out fences, who needs gates.
CentOS GNU/Linux 6.6
tc,hago.
g
.
--
users mailing list
After viewing lots of graphs from really serious PSU testing (ie
jonnyguru.com), I decided that "PSUs are most efficient at 50-60% capacity"
was a good enough generalization. If you work out the maximum draw of your
system, add around 40%, and find a quality! power supply in that range,
you're set.
Emphasis on quality, though. The dramatically cheaper ones lie, or state
consumption rather than output, use some esoteric metric for wattage specs,
or otherwise aren't actually capable of what they claim.
--Pete
1:14 a.m.
On Fri, 2015-04-03 at 08:17 -0600, Ronal B Morse wrote:
I've deduced that the best predictor of success with optical
media is
country of manufacture. My preference, in order is:
Japan
Taiwan
everything else goes straight to recycle.
I seem to recall reading similar experiences, elsewhere.
Taio Yuden (Japan, Taiwan) are the most reliable in my experience.
Depending upon where you are they may be branded JVC. Note that JVC
sources from many places so check the country of manufacture. Japanese
produced media is not usually available in stores in the US, but you
can find them easily on the Internet.
I can't remember seeing any of those on sale, anywhere. Back in my days
of using tapes for video production, I had preferred suppliers and I'd
order in bulk. But since then, I haven't had a bulk need so I just wait
for a good price on a brand I want in the local shops. That's getting
harder to do, so I might have to go back to ordering them. Thing is,
the local pro suppliers aren't really bothered with supporting this, pro
work usually goes around on a hard drive, or USB stick. DVDs aren't
good enough (far too much video compression).
Verbatim (Taiwan) generally pretty good. I can't say the same
for
Verbatim (India).
The ones I rely on are from Taiwan, I can't say that I've seen any from
India, around here.
For some mysterious reason, TY and Verbatim (Taiwan) sell for a
premium over other media. I wonder if there is a correlation?
Maybe they know they're /that/ much better than the others, and have
found people are willing to pay for it. They are more expensive than
the crap brands, around here, as well. Crap ones don't even come on a
spindle, there's just a stack of them bound in plastic wrap, all grazing
and scuffing each other.
--
tim@localhost ~]$ uname -rsvp
Linux 3.18.9-100.fc20.i686 #1 SMP Mon Mar 9 17:04:05 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
9:17 a.m.
On Fri, 2015-04-03 at 18:20 +1030, Tim wrote:
On Thu, 2015-04-02 at 11:11 -0600, jd1008 wrote:
> made by Sony, which I thought paid better attention to the quality of
> production
I seem to recall that Sony doesn't actually make their own. But
regardless of how well media may be regarded, you often need to make
compatibility tests with your own equipment.
Many years ago, I tried out various different brands, on purpose. Some
were just awful (a friend used to buy the cheapest, with nearly a 30%
failure rate - around 1 in 3 discs needed to be thrown away). I found
Verbatim to be the best with my equipment, and it was a significantly
noticeable difference.
Compared to others, a freshly inserted disc was recognised the fastest
(so it was easier to focus on and read the codes), some will sit there
going whiz-whur, whiz-whur in the drive, for prolonged periods, while it
attempts to figure out what's being inserted. I can only remember
having about three discs fail during burn in the last several years
(which is a hell of lot better than brands my friend has used). The
discs have remained easily readable many years later (and that is a
fault that a lot of people don't even think about). While some people
may only require a backup to last a few weeks before it becomes too
out-of-date to be useful, other people need long-term archival storage.
It's getting harder to go out and buy discs, retail, here. I suspect
because the movie piracy black market has changed to watching them as
files on a computer, rather than inserting a disc into a player plugged
into a television set. There are only a few disc varieties available,
mostly terribly cheapies. It's also harder to buy boxes or sleeves,
than it used to be. It's more than a bit annoying to not have something
to put your discs in.
--
tim@localhost ~]$ uname -rsvp
Linux 3.18.9-100.fc20.i686 #1 SMP Mon Mar 9 17:04:05 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
I used to work for an advertising/PR firm that used optical media for
client pitches and attitude modification presentations. We'd go through
a couple of hundred blanks a quarter.
From that experience I've deduced that the best predictor of
success
with optical media is country of manufacture. My preference, in order
is:
Japan
Taiwan
everything else goes straight to recycle.
Taio Yuden (Japan, Taiwan) are the most reliable in my experience.
Depending upon where you are they may be branded JVC. Note that JVC
sources from many places so check the country of manufacture. Japanese
produced media is not usually available in stores in the US, but you can
find them easily on the Internet.
Verbatim (Taiwan) generally pretty good. I can't say the same for
Verbatim (India).
For some mysterious reason, TY and Verbatim (Taiwan) sell for a premium
over other media. I wonder if there is a correlation?
RBM
2:57 a.m.
On Thu, 2015-04-02 at 11:13 -0600, jd1008 wrote:
Problem with k3b is that it refuses to force 2X speed.
The media, drive, or a combination of the two, may not support it.
Media lists a series of speeds that it supports, the burner only has
so-many different power levels that the laser can be operated at, the
burning software needs to take account of it. To change burn speeds,
the laser power need to be adjusted (faster speed, more laser power;
slower speeds, dimmer laser).
Oddly, I began to see discs that couldn't do 1× burning, several years
ago. Which immediately puts them out of use for many standalone video
DVD recorders, the older ones that went direct to disc in real time.
--
tim@localhost ~]$ uname -rsvp
Linux 3.18.9-100.fc20.i686 #1 SMP Mon Mar 9 17:04:05 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
2:50 a.m.
On Thu, 2015-04-02 at 11:11 -0600, jd1008 wrote:
made by Sony, which I thought paid better attention to the quality
of
production
I seem to recall that Sony doesn't actually make their own. But
regardless of how well media may be regarded, you often need to make
compatibility tests with your own equipment.
Many years ago, I tried out various different brands, on purpose. Some
were just awful (a friend used to buy the cheapest, with nearly a 30%
failure rate - around 1 in 3 discs needed to be thrown away). I found
Verbatim to be the best with my equipment, and it was a significantly
noticeable difference.
Compared to others, a freshly inserted disc was recognised the fastest
(so it was easier to focus on and read the codes), some will sit there
going whiz-whur, whiz-whur in the drive, for prolonged periods, while it
attempts to figure out what's being inserted. I can only remember
having about three discs fail during burn in the last several years
(which is a hell of lot better than brands my friend has used). The
discs have remained easily readable many years later (and that is a
fault that a lot of people don't even think about). While some people
may only require a backup to last a few weeks before it becomes too
out-of-date to be useful, other people need long-term archival storage.
It's getting harder to go out and buy discs, retail, here. I suspect
because the movie piracy black market has changed to watching them as
files on a computer, rather than inserting a disc into a player plugged
into a television set. There are only a few disc varieties available,
mostly terribly cheapies. It's also harder to buy boxes or sleeves,
than it used to be. It's more than a bit annoying to not have something
to put your discs in.
--
tim@localhost ~]$ uname -rsvp
Linux 3.18.9-100.fc20.i686 #1 SMP Mon Mar 9 17:04:05 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
1:55 p.m.
On 04/02/2015 12:44 PM, John Pilkington wrote:
On 02/04/15 18:13, jd1008 wrote:
>
>
> On 04/02/2015 02:56 AM, John Pilkington wrote:
>> On 01/04/15 20:18, jd1008 wrote:
>>> After burning 3 DVD's, and reading them back to compute sha256sum.
>>> all three of them generated these error messages during readback,
>>> and all 3 messages show the error was past the 4gb offset.
>>>
>>> Is this a media issue or is it the burner?
>>>
>>
>> I burn DVDs from iso images using the k3b verify option, but I don't
>> think you can separate the two parts.
>>
>> After iso creation and before burning I use implantisomd5; checkisomd5
>> then does what it says.
>>
>> For explanation see:
>>
>> http://www.g-loaded.eu/2006/10/07/verify-a-burned-cddvd-image-on-linux/
>>
>> HTH
>>
>> John P
>>
> Problem with k3b is that it refuses to force 2X speed.
Do you *want* a slow burn? I rarely have problems at 8x. Verbatim
DVD+R rated at 16x. But obviously many other factors can cause
problems too. And I'm using SL7, el7 near-clone, which is rare here,
IIRC.
John
at 2X, the burning is more reliable and produces recordings that are
more durable.
You do not have to take my word for it.
I know engineers who worked for manufacturers where they
were designing and producing cd/dvd burners.
1:44 p.m.
On 02/04/15 18:13, jd1008 wrote:
On 04/02/2015 02:56 AM, John Pilkington wrote:
> On 01/04/15 20:18, jd1008 wrote:
>> After burning 3 DVD's, and reading them back to compute sha256sum.
>> all three of them generated these error messages during readback,
>> and all 3 messages show the error was past the 4gb offset.
> >> Is this a media issue or is it the burner?
> > I burn DVDs from iso images
using the k3b verify option, but I don't
> think you can separate the two parts.
> After iso creation and before burning I use implantisomd5;
checkisomd5
> then does what it says.
> For explanation see:
>
http://www.g-loaded.eu/2006/10/07/verify-a-burned-cddvd-image-on-linux/
> HTH
> John P
Problem with k3b is that it refuses to force 2X speed.
Do you *want* a slow burn? I rarely have problems at 8x. Verbatim
DVD+R rated at 16x. But obviously many other factors can cause problems
too. And I'm using SL7, el7 near-clone, which is rare here, IIRC.
John
12:13 p.m.
On 04/02/2015 02:56 AM, John Pilkington wrote:
On 01/04/15 20:18, jd1008 wrote:
> After burning 3 DVD's, and reading them back to compute sha256sum.
> all three of them generated these error messages during readback,
> and all 3 messages show the error was past the 4gb offset.
>
> Is this a media issue or is it the burner?
>
I burn DVDs from iso images using the k3b verify option, but I don't
think you can separate the two parts.
After iso creation and before burning I use implantisomd5; checkisomd5
then does what it says.
For explanation see:
http://www.g-loaded.eu/2006/10/07/verify-a-burned-cddvd-image-on-linux/
HTH
John P
Problem with k3b is that it refuses to force 2X speed.
12:12 p.m.
On 04/01/2015 10:40 PM, Robin Laing wrote:
On 2015-04-01 19:15, g wrote:
>
>
> On 04/01/2015 02:18 PM, jd1008 wrote:
>> After burning 3 DVD's, and reading them back to compute sha256sum.
>> all three of them generated these error messages during readback,
>> and all 3 messages show the error was past the 4gb offset.
>>
>> Is this a media issue or is it the burner?
>
> 1- burn dvd at 2 speeds lower than what you used and had failure.
>
> if ok, problem is either burner or blanks.
>
> 2- burn dvd at failure speed on a different burner.
>
> if ok, get a new burner. if failure, may be blanks.
>
> 3- try different program or burn from command line.
>
>> A side question: why does the block io layer assume that all media
>> have 512 byte sectors?
>
> i believe that is a carry over from disk formatting started by the
> IBM PC. [do not hold me to that]
>
>
Also watch power supply voltages.
I have ran into two power supplies that caused issues with CD burning.
Couldn't supply that little extra bit of current during the burn
process. To burners later, I finally found it.
Good point. One burner is internal,
the other is external.
My problem turned out to be the media, as you can see in my reply to g.
12:11 p.m.
On 04/01/2015 08:24 PM, Robert Nichols wrote:
On 04/01/2015 02:18 PM, jd1008 wrote:
> After burning 3 DVD's, and reading them back to compute sha256sum.
> all three of them generated these error messages during readback,
> and all 3 messages show the error was past the 4gb offset.
The DVDs will have some zero padding appended, and that will affect
the SHA256 sums. You have to be careful not to read more bytes from
the DVD than there are in the original ISO file.
Right, which is indeed how I try to compute a dvd's checksum.
At any rate, problem turned out to be the media, which is disappointing
because they are made by Sony, which I thought paid better attention
to the quality of production.
12:09 p.m.
On 04/01/2015 07:15 PM, g wrote:
On 04/01/2015 02:18 PM, jd1008 wrote:
> After burning 3 DVD's, and reading them back to compute sha256sum.
> all three of them generated these error messages during readback,
> and all 3 messages show the error was past the 4gb offset.
>
> Is this a media issue or is it the burner?
1- burn dvd at 2 speeds lower than what you used and had failure.
This has been my
method always at 2X speed.
if ok, problem is either burner or blanks.
It turned out to be the blanks. My eyes
are not what they used
to be. When I examined the outer edges I notices the strange
manufacturing blemishes that became apparent under the direct
sunlight.
Thanks.
3:56 a.m.
On 01/04/15 20:18, jd1008 wrote:
After burning 3 DVD's, and reading them back to compute
sha256sum.
all three of them generated these error messages during readback,
and all 3 messages show the error was past the 4gb offset.
Is this a media issue or is it the burner?
I burn DVDs from iso images using the k3b verify option, but I don't
think you can separate the two parts.
After iso creation and before burning I use implantisomd5; checkisomd5
then does what it says.
For explanation see:
http://www.g-loaded.eu/2006/10/07/verify-a-burned-cddvd-image-on-linux/
HTH
John P
11:40 p.m.
On 2015-04-01 19:15, g wrote:
On 04/01/2015 02:18 PM, jd1008 wrote:
> After burning 3 DVD's, and reading them back to compute sha256sum.
> all three of them generated these error messages during readback,
> and all 3 messages show the error was past the 4gb offset.
>
> Is this a media issue or is it the burner?
1- burn dvd at 2 speeds lower than what you used and had failure.
if ok, problem is either burner or blanks.
2- burn dvd at failure speed on a different burner.
if ok, get a new burner. if failure, may be blanks.
3- try different program or burn from command line.
> A side question: why does the block io layer assume that all media
> have 512 byte sectors?
i believe that is a carry over from disk formatting started by the
IBM PC. [do not hold me to that]
Also watch power supply voltages.
I have ran into two power supplies that caused issues with CD burning.
Couldn't supply that little extra bit of current during the burn
process. To burners later, I finally found it.
9:24 p.m.
On 04/01/2015 02:18 PM, jd1008 wrote:
After burning 3 DVD's, and reading them back to compute
sha256sum.
all three of them generated these error messages during readback,
and all 3 messages show the error was past the 4gb offset.
The DVDs will have some zero padding appended, and that will affect
the SHA256 sums. You have to be careful not to read more bytes from
the DVD than there are in the original ISO file.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
8:15 p.m.
On 04/01/2015 02:18 PM, jd1008 wrote:
After burning 3 DVD's, and reading them back to compute
sha256sum.
all three of them generated these error messages during readback,
and all 3 messages show the error was past the 4gb offset.
Is this a media issue or is it the burner?
1- burn dvd at 2 speeds lower than what you used and had failure.
if ok, problem is either burner or blanks.
2- burn dvd at failure speed on a different burner.
if ok, get a new burner. if failure, may be blanks.
3- try different program or burn from command line.
A side question: why does the block io layer assume that all media
have 512 byte sectors?
i believe that is a carry over from disk formatting started by the
IBM PC. [do not hold me to that]
--
peace out.
in a world with out fences, who needs gates.
CentOS GNU/Linux 6.6
tc,hago.
g
.
3:38 a.m.
On 04/01/2015 11:40 PM, Robin Laing wrote:
On 2015-04-01 19:15, g wrote:
> On 04/01/2015 02:18 PM, jd1008 wrote:
>> After burning 3 DVD's, and reading them back to compute sha256sum.
>> all three of them generated these error messages during readback,
>> and all 3 messages show the error was past the 4gb offset.
>>
>> Is this a media issue or is it the burner?
>
> 1- burn dvd at 2 speeds lower than what you used and had failure.
>
> if ok, problem is either burner or blanks.
>
> 2- burn dvd at failure speed on a different burner.
>
> if ok, get a new burner. if failure, may be blanks.
>
> 3- try different program or burn from command line.
>
>> A side question: why does the block io layer assume that all media
>> have 512 byte sectors?
>
> i believe that is a carry over from disk formatting started by the
> IBM PC. [do not hold me to that]
>
Also watch power supply voltages.
I have ran into two power supplies that caused issues with CD
burning. Couldn't supply that little extra bit of current during
the burn process. To burners later, I finally found it.
this is true.
a few years back, a poster asked for recommendations on building up
system and had a lot of responses.
my response of getting a power supply with at least a 20% factor,
and that a 30% factor would be even better due to my considering
future additions or changes.
i was met with opposition and even ridicule from a poster who
stated that he had never seen need.
too many 'builders' are unaware of such factors and will end up
with a system that gets flaky when additions and upgrades are
made.
such is a prime reason for 'ready made' failures.
back to dvd checksum errors and a great surprise that i just had.
due to need for centos 6.6 i386 for a system that i am putting
together for home control use, i decided to burn the iso to a
dvd rw disk using k3b and all went well including k3b ok'ing
the burn.
after closing k3b i ran 'sha256sum /dev/sr1 > sr1' with disk still
in the usb drive i burned it with. checksum failed.
so decided to moved disk to the internal burner to see how it check.
'sha256sum /dev/sr0 > sr0' produce correct sha256sum.
having run check on the usb burner many time before when using k3b
and cl and i have gotten good checks, i was surprised.
am i going to worry about it. hell no. 2 out of 3 good checks tells
me that Murphy is at it again. ((GBWG))
--
peace out.
in a world with out fences, who needs gates.
CentOS GNU/Linux 6.6
tc,hago.
g
.
3306
days inactive
3310
days old
17 comments
8 participants
participants (8)
-
g -
JD -
John Pilkington -
Pete Travis -
Robert Nichols -
Robin Laing -
Ronal B Morse -
Tim