f



It's 2008, and Linux can't move big files

"Hardy just cannot cope with big file moving on MY SYSTEM. I tried moving a 
file of 1 Gig and the whole system just froze. Only 1 out of 5 or 6 can be 
successful without crashing. I am running my STABLEST 2.6.24.18. I have no 
luck with other verions, they are the worst in terms of stability WHILE 
MOVING BIG FILES."

http://ubuntuforums.org/showthread.php?t=844005



0
nospam11 (18349)
7/12/2008 3:46:09 AM
comp.os.linux.advocacy 124139 articles. 3 followers. Post Follow

65 Replies
594 Views

Similar Articles

[PageSpeed] 40

On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:

> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
> or 6 can be successful without crashing. I am running my STABLEST
> 2.6.24.18. I have no luck with other verions, they are the worst in
> terms of stability WHILE MOVING BIG FILES."
> 
> http://ubuntuforums.org/showthread.php?t=844005

Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
command, it will make no difference how big it is, and it will happen 
instantaneously. Mainly because all that does is to change it's name. FWIW 
- I have copied files over 1gb many times with absolutely no problem.
0
ray65 (5421)
7/12/2008 1:36:54 PM
"ray" <ray@zianet.com> wrote in message 
news:6drqbmF42nu0U2@mid.individual.net...
> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>
>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>> or 6 can be successful without crashing. I am running my STABLEST
>> 2.6.24.18. I have no luck with other verions, they are the worst in
>> terms of stability WHILE MOVING BIG FILES."
>>
>> http://ubuntuforums.org/showthread.php?t=844005
>
> Well, DooFuS if you actually tried to MOVE the file, with the 'mv'
> command, it will make no difference how big it is, and it will happen
> instantaneously. Mainly because all that does is to change it's name. 
> FWIW
> - I have copied files over 1gb many times with absolutely no problem.


Only if you're moving the file across the same physical volume.




** Posted from http://www.teranews.com **
0
Ezekiel
7/12/2008 1:41:08 PM
ray <ray@zianet.com> wrote:
> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
> 
>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>> or 6 can be successful without crashing. I am running my STABLEST
>> 2.6.24.18. I have no luck with other verions, they are the worst in
>> terms of stability WHILE MOVING BIG FILES."
>> 
>> http://ubuntuforums.org/showthread.php?t=844005
> 
> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
> command, it will make no difference how big it is, and it will happen 
> instantaneously. Mainly because all that does is to change it's name. FWIW 
> - I have copied files over 1gb many times with absolutely no problem.

Takes a few seconds sometimes. All depends from whence you are moving the
file, and to where?
-- 
|   spike1@freenet.co.uk   | "I'm alive!!! I can touch! I can taste!         |
|   Andrew Halliwell BSc   |  I can SMELL!!!  KRYTEN!!! Unpack Rachel and    |
|            in            |  get out the puncture repair kit!"              |
|     Computer Science     |     Arnold Judas Rimmer- Red Dwarf              |
0
spike11 (2375)
7/12/2008 1:48:52 PM
ray <ray@zianet.com> writes:

> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>
>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>> or 6 can be successful without crashing. I am running my STABLEST
>> 2.6.24.18. I have no luck with other verions, they are the worst in
>> terms of stability WHILE MOVING BIG FILES."
>> 
>> http://ubuntuforums.org/showthread.php?t=844005
>
> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
> command, it will make no difference how big it is, and it will happen 
> instantaneously. Mainly because all that does is to change it's name. FWIW 
> - I have copied files over 1gb many times with absolutely no problem.

Well it seems your needs and system are typically COLAtarded. This is
not the case in a multi volume/partition system a lot of the time.
0
hadronquark2 (7213)
7/12/2008 2:02:04 PM
On Sat, 12 Jul 2008 14:48:52 +0100, Andrew Halliwell wrote:

> ray <ray@zianet.com> wrote:
>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>> 
>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>> or 6 can be successful without crashing. I am running my STABLEST
>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>> terms of stability WHILE MOVING BIG FILES."
>>> 
>>> http://ubuntuforums.org/showthread.php?t=844005
>> 
>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv'
>> command, it will make no difference how big it is, and it will happen
>> instantaneously. Mainly because all that does is to change it's name.
>> FWIW - I have copied files over 1gb many times with absolutely no
>> problem.
> 
> Takes a few seconds sometimes. All depends from whence you are moving the
> file, and to where?

Still not as long as it takes DooFu$ to remove his head from his arse.

-- 
Is a M$ "Certificate of Authenticity"
for Vista, a junk bond?
0
wp16 (1499)
7/12/2008 2:18:35 PM
ray wrote:

> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
> 
>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>> or 6 can be successful without crashing. I am running my STABLEST
>> 2.6.24.18. I have no luck with other verions, they are the worst in
>> terms of stability WHILE MOVING BIG FILES."
>>
>> http://ubuntuforums.org/showthread.php?t=844005
> 
> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
> command, it will make no difference how big it is, and it will happen 
> instantaneously. Mainly because all that does is to change it's name. FWIW 
> - I have copied files over 1gb many times with absolutely no problem.

D00Fu$ has proved he is a computer illiterate. Since DOS/Windows used
the same technique for ages. It was called REN (Rename), the only way to
"move" a file from one directory to another.

Great "Windows Expert" :-)

-- 
|_|0|_| Marti T. van Lin
|_|_|0| http://ml2mst.googlepages.com
|0|0|0| http://ubuntusteunpuntdaalhof.googlepages.com
0
ml2mst1 (1210)
7/12/2008 2:49:36 PM
"ml2mst" <ml2mst@gmail.com> wrote in message 
news:g5agaj$idf$1@news.albasani.net...
> ray wrote:
>
>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>>
>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>> or 6 can be successful without crashing. I am running my STABLEST
>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>> terms of stability WHILE MOVING BIG FILES."
>>>
>>> http://ubuntuforums.org/showthread.php?t=844005
>>
>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv'
>> command, it will make no difference how big it is, and it will happen
>> instantaneously. Mainly because all that does is to change it's name. 
>> FWIW
>> - I have copied files over 1gb many times with absolutely no problem.
>
> D00Fu$ has proved he is a computer illiterate. Since DOS/Windows used
> the same technique for ages.

Whereas you are simply illiterate. Try reading the post for a change instead 
of pulling stuff out of your ass. (No pun intended.)

DFS simply posted a link to what somebody else posted in the Ubuntu forums. 
For some reason you don't seem capable of grasping this.



> It was called REN (Rename), the only way to
> "move" a file from one directory to another.
>
> Great "Windows Expert" :-)

You're not an expert in anything other than being an idiot. REN is *NOT* the 
only way to "move" a file in Windows. There's a command called "move" that 
does this. REN also works but it was replaced with "move" many years ago. 
But don't let that fact stop idiots like you from claiming that "ren" is the 
*only way* to "move" a file because it clearly isn't.



> -- 
> |_|0|_| Marti T. van Lin
> |_|_|0| http://ml2mst.googlepages.com
> |0|0|0| http://ubuntusteunpuntdaalhof.googlepages.com



** Posted from http://www.teranews.com **
0
Ezekiel
7/12/2008 2:59:24 PM
* ml2mst peremptorily fired off this memo:

> ray wrote:
>
>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>> 
>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>> or 6 can be successful without crashing. I am running my STABLEST
>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>> terms of stability WHILE MOVING BIG FILES."
>>>
>>> http://ubuntuforums.org/showthread.php?t=844005
>> 
>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
>> command, it will make no difference how big it is, and it will happen 
>> instantaneously. Mainly because all that does is to change it's name. FWIW 
>> - I have copied files over 1gb many times with absolutely no problem.
>
> D00Fu$ has proved he is a computer illiterate. Since DOS/Windows used
> the same technique for ages. It was called REN (Rename), the only way to
> "move" a file from one directory to another.
>
> Great "Windows Expert" :-)

The person who posted that article on the Ubuntu forum is either /lying/
or fat-fingered something in the install.  Even if one thinks Nautilus
might be the problem.

Also, sometimes one sees threads where the idiots posting to it are
thrashing needlessly.

For example, I was looking for help using XMMS2 with Streamtuner, and I
came across a thread where the first poster said "XMMS2 doesn't work
with Streamtuner".  Rather than actually figure out why, the thread
immediately devolved into suggestions to try GUI players such as
Audacious.

Idiocy, pure and simple.

-- 
<mjg59> Damnit. I've got a month to write a paper. This involves
        actually writing the chunks of code I'm going to be talking
        about.
<asuffield> find a bunch of students and give it to them as an exercise
<mjg59> asuffield: I'm surrounded by a bunch of students. Last time I
        let them touch code, I came back and found they'd rewritten
        all the C++ code in C and all the C code in C++
<asuffield> mwahaha
<mjg59> AND BROKE THE BUILD
0
linonut (8350)
7/12/2008 4:17:31 PM
Ezekiel wrote:

> 
> "ml2mst" <ml2mst@gmail.com> wrote in message
> news:g5agaj$idf$1@news.albasani.net...
>> ray wrote:
>>
>>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>>>
>>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>>> or 6 can be successful without crashing. I am running my STABLEST
>>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>>> terms of stability WHILE MOVING BIG FILES."
>>>>
>>>> http://ubuntuforums.org/showthread.php?t=844005
>>>
>>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv'
>>> command, it will make no difference how big it is, and it will happen
>>> instantaneously. Mainly because all that does is to change it's name.
>>> FWIW
>>> - I have copied files over 1gb many times with absolutely no problem.
>>
>> D00Fu$ has proved he is a computer illiterate. Since DOS/Windows used
>> the same technique for ages.
> 
> Whereas you are simply illiterate. Try reading the post for a change
> instead of pulling stuff out of your ass. (No pun intended.)
> 
> DFS simply posted a link to what somebody else posted in the Ubuntu
> forums. For some reason you don't seem capable of grasping this.


BWAHAHAHAHHAHAHHAHAHAHAHHA!!!!

But, but, but, you are the same socks doofus and Ezekiel.
Both are dead duck fsckers and both support each other from behind.
And Weisberger, these socks of yours - why are you pounding your socks so
hard? The kill file is making your asstroturfing business a little slow for
you?



0
7/12/2008 10:27:07 PM
In article <%L4ek.27$dP6.1@bignews1.bellsouth.net>,
 Linonut <linonut@bollsouth.nut> wrote:
> The person who posted that article on the Ubuntu forum is either /lying/
> or fat-fingered something in the install.  Even if one thinks Nautilus
> might be the problem.

Or maybe he's moving the file across filesystems, and so it is actually 
a copy and delete?

There are known cases where that can get slow, and make the system 
sluggish, on Linux.  I finally found a good explanation of this problem, 
BTW:

   <http://www.reddit.com/info/6qhzc/comments/c04lvzu>

Another possibility that comes to mind: suppose he's using some kind of 
fast search system, and when me moves the file, it tries to index the 
file in the new location?  Some search system indexers can be slow and 
use a lot of resources on big files.

-- 
--Tim Smith
0
reply_in_group (13194)
7/12/2008 11:09:17 PM
On Fri, 11 Jul 2008 23:46:09 -0400, DFS <nospam@dfs_.com> wrote:
>"Hardy just cannot cope with big file moving on MY SYSTEM. I tried moving a 
>file of 1 Gig and the whole system just froze. Only 1 out of 5 or 6 can be 
>successful without crashing. I am running my STABLEST 2.6.24.18. I have no 
>luck with other verions, they are the worst in terms of stability WHILE 
>MOVING BIG FILES."

>http://ubuntuforums.org/showthread.php?t=844005


It's because you're a fucking idiot and have probably overclocked your system,
played vollyball with your hard drive, or alowed rats to live in your case.

I move 2-30G files routinely.  Linux hasn't the slightest problem.  Read the
fucking documentation on the file system you're using. 

Newsflash:  only microsoft has had a problem embracing file system
technology newer than thirty years old.  ext3, XFS, and the file system by 
the murdurer reseifer are simply wonderful and will *never* have the
problems you describe.
0
aznomad.3 (962)
7/13/2008 12:03:07 AM
On Sat, 12 Jul 2008 16:49:36 +0200, ml2mst <ml2mst@gmail.com> wrote:
>ray wrote:

>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>> 
>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>> or 6 can be successful without crashing. I am running my STABLEST
>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>> terms of stability WHILE MOVING BIG FILES."
>>>
>>> http://ubuntuforums.org/showthread.php?t=844005
>> 
>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
>> command, it will make no difference how big it is, and it will happen 
>> instantaneously. Mainly because all that does is to change it's name. FWIW 
>> - I have copied files over 1gb many times with absolutely no problem.

>D00Fu$ has proved he is a computer illiterate. Since DOS/Windows used
>the same technique for ages. It was called REN (Rename), the only way to

dumfuck is a fucking idiot.  Actually, he gives fucking idiots a bad name.
0
aznomad.3 (962)
7/13/2008 12:03:45 AM
On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:

> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried moving a 
> file of 1 Gig and the whole system just froze. Only 1 out of 5 or 6 can be 
> successful without crashing. I am running my STABLEST 2.6.24.18. I have no 
> luck with other verions, they are the worst in terms of stability WHILE 
> MOVING BIG FILES."
> 
> http://ubuntuforums.org/showthread.php?t=844005

All the more reason for NOT using Linux for video or audio.
Those files tend to be huge....

Go Linux!!!
You GO Girl!!!

(Don't get excited now Marti or HPT, I mean REAL girls, not your castrated
*girlfriend*.



-- 
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/
0
brick_n_straw (4058)
7/13/2008 12:27:19 AM
jOn Sat, 12 Jul 2008 16:09:17 -0700, Tim Smith 
<reply_in_group@mouse-potato.com> wrote:

> In article <%L4ek.27$dP6.1@bignews1.bellsouth.net>,
>  Linonut <linonut@bollsouth.nut> wrote:
>> The person who posted that article on the Ubuntu forum is either /lying/
>> or fat-fingered something in the install.  Even if one thinks Nautilus
>> might be the problem.
>
> Or maybe he's moving the file across filesystems, and so it is actually 
> a copy and delete?
>
> There are known cases where that can get slow, and make the system 
> sluggish, on Linux.  I finally found a good explanation of this problem, 
> BTW:
>
>    <http://www.reddit.com/info/6qhzc/comments/c04lvzu>

It is not clear to me why the system would become CPU bound by writing 
to disk unless the drive does not support DMA or it is disabled.  The 
example he gave was for a DVD, not for a regular disk.  Perhaps that has 
something to do with it.  Of course it is always possible for a driver 
to be written in a foolish way, or for the hardware to be defective in 
design, but I don't think that is the general case for a normal disk.

So I tried a quick experiment.  While typing this I did a cp -a of a 3 
GB directory.  It does not seem to be impeding interactive performance.  
How about tarring that directory?  Nope, that seems fine too.  87% idle, 
load ave of 1.1 or so, commands seem to run at a reasonable speed.  How 
about copying the resulting tar file?  No, that seems to work ok too.

Certainly starting a big app like oowriter takes a lot longer than 
normal.  That is disk-intensive and the disk is busy with the light on 
solid.  But the system is not CPU bound and other things are running 
fine.

This is on my lowly 1.6 GHz Pentium-M laptop.  But it does have working 
DMA support for the disk and an up-to-date kernel (2.6.25).

I'm not saying the described behavior _never_ happens, but I think you 
have to go looking for cases where it does.


-- 
 -| Bob Hauck
 -| http://www.haucks.org/
0
postmaster6 (1752)
7/13/2008 12:38:00 AM
On Sat, 12 Jul 2008 20:38:00 -0400, Bob Hauck wrote:

> jOn Sat, 12 Jul 2008 16:09:17 -0700, Tim Smith 
> <reply_in_group@mouse-potato.com> wrote:
> 
>> In article <%L4ek.27$dP6.1@bignews1.bellsouth.net>,
>>  Linonut <linonut@bollsouth.nut> wrote:
>>> The person who posted that article on the Ubuntu forum is either /lying/
>>> or fat-fingered something in the install.  Even if one thinks Nautilus
>>> might be the problem.
>>
>> Or maybe he's moving the file across filesystems, and so it is actually 
>> a copy and delete?
>>
>> There are known cases where that can get slow, and make the system 
>> sluggish, on Linux.  I finally found a good explanation of this problem, 
>> BTW:
>>
>>    <http://www.reddit.com/info/6qhzc/comments/c04lvzu>
> 
> It is not clear to me why the system would become CPU bound by writing 
> to disk unless the drive does not support DMA or it is disabled.  The 
> example he gave was for a DVD, not for a regular disk.  Perhaps that has 
> something to do with it.  Of course it is always possible for a driver 
> to be written in a foolish way, or for the hardware to be defective in 
> design, but I don't think that is the general case for a normal disk.
> 
> So I tried a quick experiment.  While typing this I did a cp -a of a 3 
> GB directory.  It does not seem to be impeding interactive performance.  
> How about tarring that directory?  Nope, that seems fine too.  87% idle, 
> load ave of 1.1 or so, commands seem to run at a reasonable speed.  How 
> about copying the resulting tar file?  No, that seems to work ok too.
> 
> Certainly starting a big app like oowriter takes a lot longer than 
> normal.  That is disk-intensive and the disk is busy with the light on 
> solid.  But the system is not CPU bound and other things are running 
> fine.
> 
> This is on my lowly 1.6 GHz Pentium-M laptop.  But it does have working 
> DMA support for the disk and an up-to-date kernel (2.6.25).
> 
> I'm not saying the described behavior _never_ happens, but I think you 
> have to go looking for cases where it does.

Most good tech's will use a tar of a huge directory to test filesystems,
hdisks etc.
This way the programs (ie:Veritas etc) are eliminated....

In the past I have had some weird stuff with Linux copying large, very
large, video files but nothing consistent that I could pin down and this
was over a year ago and with PCLinuxOS at the time.
I never could figure what was going on but I did have an hdisk die at one
point later so I'm assuming that might have contributed which is why I
would not blame Linux at all.

The Windows files were on NTFS partitions on different disks so it's really
apples and oranges, just in case ya'll were wondering.

-- 
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/
0
brick_n_straw (4058)
7/13/2008 1:54:29 AM
On Jul 12, 9:54=A0pm, "Moshe Goldfarb." <brick_n_st...@gmail.com> wrote:
> On Sat, 12 Jul 2008 20:38:00 -0400, Bob Hauck wrote:
> > jOn Sat, 12 Jul 2008 16:09:17 -0700, Tim Smith
> > <reply_in_gr...@mouse-potato.com> wrote:
>
> >> In article <%L4ek.27$dP...@bignews1.bellsouth.net>,
> >> =A0Linonut <lino...@bollsouth.nut> wrote:
> >>> The person who posted that article on the Ubuntu forum is either /lyi=
ng/
> >>> or fat-fingered something in the install. =A0Even if one thinks Nauti=
lus
> >>> might be the problem.
>
> >> Or maybe he's moving the file across filesystems, and so it is actuall=
y
> >> a copy and delete?
>
> >> There are known cases where that can get slow, and make the system
> >> sluggish, on Linux. =A0I finally found a good explanation of this prob=
lem,
> >> BTW:
>
> >> =A0 =A0<http://www.reddit.com/info/6qhzc/comments/c04lvzu>
>
> > It is not clear to me why the system would become CPU bound by writing
> > to disk unless the drive does not support DMA or it is disabled. =A0The
> > example he gave was for a DVD, not for a regular disk. =A0Perhaps that =
has
> > something to do with it. =A0Of course it is always possible for a drive=
r
> > to be written in a foolish way, or for the hardware to be defective in
> > design, but I don't think that is the general case for a normal disk.
>
> > So I tried a quick experiment. =A0While typing this I did a cp -a of a =
3
> > GB directory. =A0It does not seem to be impeding interactive performanc=
e. =A0
> > How about tarring that directory? =A0Nope, that seems fine too. =A087% =
idle,
> > load ave of 1.1 or so, commands seem to run at a reasonable speed. =A0H=
ow
> > about copying the resulting tar file? =A0No, that seems to work ok too.
>
> > Certainly starting a big app like oowriter takes a lot longer than
> > normal. =A0That is disk-intensive and the disk is busy with the light o=
n
> > solid. =A0But the system is not CPU bound and other things are running
> > fine.
>
> > This is on my lowly 1.6 GHz Pentium-M laptop. =A0But it does have worki=
ng
> > DMA support for the disk and an up-to-date kernel (2.6.25).
>
> > I'm not saying the described behavior _never_ happens, but I think you
> > have to go looking for cases where it does.
>
> Most good tech's will use a tar of a huge directory to test filesystems,
> hdisks etc.
> This way the programs (ie:Veritas etc) are eliminated....
>
> In the past I have had some weird stuff with Linux copying large, very
> large, video files but nothing consistent that I could pin down and this
> was over a year ago and with PCLinuxOS at the time.
> I never could figure what was going on but I did have an hdisk die at one
> point later so I'm assuming that might have contributed which is why I
> would not blame Linux at all.
>
> The Windows files were on NTFS partitions on different disks so it's real=
ly
> apples and oranges, just in case ya'll were wondering.
>
> --
> Moshe Goldfarb
> Collector of soaps from around the globe.
> Please visit The Hall of Linux Idiots:http://linuxidiots.blogspot.com/

First of all, many did not read the Ubuntu Forum Post ....
Second, 64 bit is unstable, to everybody but those in Cola.
Third, it does not seem to happen on every ubuntu users
machine, but enought to be a problem.  Personally, suggesting
that somebody TERMINAL is just crazy.  First you say there is no
reason to terminal, and now, we have a reason.  A bug.  Now
we are into fights on the right way to move a file.

If you are going linux, and i do linux, you want to stay with
stuff that has proved to be stable, or you are looking to tweek
and debug.

DFS just reported the problem.  Why you beating up on him.

0
psycgeeks (479)
7/13/2008 2:37:52 AM
Ezekiel argued:

> "ml2mst" <ml2mst@gmail.com> wrote in message 
> news:g5agaj$idf$1@news.albasani.net...
>> ray wrote:
>>
>>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>>>
>>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>>> or 6 can be successful without crashing. I am running my STABLEST
>>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>>> terms of stability WHILE MOVING BIG FILES."
>>>>
>>>> http://ubuntuforums.org/showthread.php?t=844005
>>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv'
>>> command, it will make no difference how big it is, and it will happen
>>> instantaneously. Mainly because all that does is to change it's name. 
>>> FWIW
>>> - I have copied files over 1gb many times with absolutely no problem.
>> D00Fu$ has proved he is a computer illiterate. Since DOS/Windows used
>> the same technique for ages.
> 
> DFS simply posted a link to what somebody else posted in the Ubuntu forums. 

He's been doing this crap for months.

> For some reason you don't seem capable of grasping this.

Yeah right :-D

>> It was called REN (Rename), the only way to
>> "move" a file from one directory to another.
>>
>> Great "Windows Expert" :-)
> 
> REN is *NOT* the only way to "move" a file in Windows. There's a command called "move" that 
> does this.

Correct, "move" was added to DOS 7 (Win95), REN, was the only way to
"move" files in DOS for years.

Bye bye!

-- 
|_|0|_| Marti T. van Lin
|_|_|0| http://ml2mst.googlepages.com
|0|0|0| http://ubuntusteunpuntdaalhof.googlepages.com
0
ml2mst1 (1210)
7/13/2008 3:53:49 AM
AZ Nomad schreef:
> On Sat, 12 Jul 2008 16:49:36 +0200, ml2mst <ml2mst@gmail.com> wrote:
>> ray wrote:
> 
>>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>>>
>>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>>> or 6 can be successful without crashing. I am running my STABLEST
>>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>>> terms of stability WHILE MOVING BIG FILES."
>>>>
>>>> http://ubuntuforums.org/showthread.php?t=844005
>>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
>>> command, it will make no difference how big it is, and it will happen 
>>> instantaneously. Mainly because all that does is to change it's name. FWIW 
>>> - I have copied files over 1gb many times with absolutely no problem.
> 
>> D00Fu$ has proved he is a computer illiterate. Since DOS/Windows used
>> the same technique for ages. It was called REN (Rename), the only way to
> 
> dumfuck is a fucking idiot.  Actually, he gives fucking idiots a bad name.

Indeed, I tried to have a serious conversation with him, a couple of
years ago, but finally gave up.

He doesn't realize, the solution to all the problems he posts are given
in the same treat:

"I get a Hardy lockup any time I try to move any size file by dragging
and dropping. I got around it by copy/paste."

Oooh [Ctrl]+[C] plus [Ctrl]+ [V] (exactly the same as in M$ Windows).

Yet, of course that's a bit too complicated for the average luser.

Cheers

-- 
|_|0|_| Marti T. van Lin
|_|_|0| http://ml2mst.googlepages.com
|0|0|0| http://ubuntusteunpuntdaalhof.googlepages.com
0
ml2mst1 (1210)
7/13/2008 4:15:33 AM
On Sun, 13 Jul 2008 06:15:33 +0200, ml2mst wrote:


> Oooh [Ctrl]+[C] plus [Ctrl]+ [V] (exactly the same as in M$ Windows).
> 
> Yet, of course that's a bit too complicated for the average luser.


I haven't read the whole thread, but why would that be a solution?  If 
it's an actual solution, then I would describe that as a bug which should 
be fixed.  Is it dependant on the windows manager?


-Thufir
0
hawat.thufir (2846)
7/13/2008 4:31:24 AM
DFS wrote:

> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried moving
> a file of 1 Gig and the whole system just froze. Only 1 out of 5 or 6 can
> be successful without crashing. I am running my STABLEST 2.6.24.18. I have
> no luck with other verions, they are the worst in terms of stability WHILE
> MOVING BIG FILES."
> 
> http://ubuntuforums.org/showthread.php?t=844005

Bullshit.

-- 
RonB
"There's a story there...somewhere"
0
ronb02noSPAM (7426)
7/13/2008 4:57:52 AM
RonB wrote:
> DFS wrote:
>
>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>> moving a file of 1 Gig and the whole system just froze. Only 1 out
>> of 5 or 6 can be successful without crashing. I am running my
>> STABLEST 2.6.24.18. I have no luck with other verions, they are the
>> worst in terms of stability WHILE MOVING BIG FILES."
>>
>> http://ubuntuforums.org/showthread.php?t=844005
>
> Bullshit.

They're all lying, WRonG.  Linux is perfect. 


0
nospam11 (18349)
7/13/2008 4:59:28 AM
On 2008-07-12, Andrew Halliwell <spike1@ponder.sky.com> wrote:
> ray <ray@zianet.com> wrote:
>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>> 
>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>> or 6 can be successful without crashing. I am running my STABLEST
>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>> terms of stability WHILE MOVING BIG FILES."
>>> 
>>> http://ubuntuforums.org/showthread.php?t=844005
>> 
>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
>> command, it will make no difference how big it is, and it will happen 
>> instantaneously. Mainly because all that does is to change it's name. FWIW 
>> - I have copied files over 1gb many times with absolutely no problem.
>
> Takes a few seconds sometimes. All depends from whence you are moving the
> file, and to where?

That's correct. If you move the file from one filesystem to another it
would take longer than a move within a filesystem, which is almost
instantaneous.

-- 
Regards,

Gregory.
Gentoo Linux - Penguin Power
0
ZekeGregory (6440)
7/13/2008 5:00:11 AM
On 2008-07-13, Psyc Geek (TAB) <psycgeeks@yahoo.com> wrote:
> On Jul 12, 9:54�pm, "Moshe Goldfarb." <brick_n_st...@gmail.com> wrote:
>> On Sat, 12 Jul 2008 20:38:00 -0400, Bob Hauck wrote:
>> > jOn Sat, 12 Jul 2008 16:09:17 -0700, Tim Smith
>> > <reply_in_gr...@mouse-potato.com> wrote:
>>
>> >> In article <%L4ek.27$dP...@bignews1.bellsouth.net>,
>> >> �Linonut <lino...@bollsouth.nut> wrote:
>> >>> The person who posted that article on the Ubuntu forum is either /lying/
>> >>> or fat-fingered something in the install. �Even if one thinks Nautilus
>> >>> might be the problem.
>>
>> >> Or maybe he's moving the file across filesystems, and so it is actually
>> >> a copy and delete?
>>
>> >> There are known cases where that can get slow, and make the system
>> >> sluggish, on Linux. �I finally found a good explanation of this problem,
>> >> BTW:
>>
>> >> � �<http://www.reddit.com/info/6qhzc/comments/c04lvzu>

    "can't copy big files with Linux"?

    Total hogwash.

    Been doing this since slackware '96. Not only has Linux always performed much
better than Windows while doing huge nasty IO operations but you can add decoding
and encoding multimedia on top of that and not miss a beat.

    In '98 it was mp3.

    In '08 it's h264.

[deletia]

    It can be moves, moves across filesystems, copies, copies across the network. It
can be small files or huge files and can be hundreds of gigabytes at a time.

-- 

        Linux: Because I don't want to push pretty buttons.          |||
	       I want the pretty buttons to push themelves.         / | \

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------       
                http://www.usenet.com
0
jedi (14753)
7/13/2008 6:06:19 AM
On 2008-07-13, Gregory Shearman <ZekeGregory@netscape.net> wrote:
> On 2008-07-12, Andrew Halliwell <spike1@ponder.sky.com> wrote:
>> ray <ray@zianet.com> wrote:
>>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>>> 
>>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>>> or 6 can be successful without crashing. I am running my STABLEST
>>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>>> terms of stability WHILE MOVING BIG FILES."

....assuming he's using a default type Ubuntu install that's beyond bizarre.

>>>> 
>>>> http://ubuntuforums.org/showthread.php?t=844005
>>> 
>>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
>>> command, it will make no difference how big it is, and it will happen 
>>> instantaneously. Mainly because all that does is to change it's name. FWIW 
>>> - I have copied files over 1gb many times with absolutely no problem.
>>
>> Takes a few seconds sometimes. All depends from whence you are moving the
>> file, and to where?

....a n00b working with Ubuntu? It's bound to be a system carved up as one big
fat root partition.

>
> That's correct. If you move the file from one filesystem to another it
> would take longer than a move within a filesystem, which is almost
> instantaneous.

    A single filesystem move is just going to be tweaking some pointers.
A move between filesystems is going to be a copy and then a detete.

-- 

        Linux: Because I don't want to push pretty buttons.          |||
	       I want the pretty buttons to push themelves.         / | \

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------       
                http://www.usenet.com
0
jedi (14753)
7/13/2008 6:11:02 AM
On 2008-07-13, DFS <nospam@dfs_.com> wrote:
> RonB wrote:
>> DFS wrote:
>>
>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>> moving a file of 1 Gig and the whole system just froze. Only 1 out
>>> of 5 or 6 can be successful without crashing. I am running my
>>> STABLEST 2.6.24.18. I have no luck with other verions, they are the
>>> worst in terms of stability WHILE MOVING BIG FILES."
>>>
>>> http://ubuntuforums.org/showthread.php?t=844005
>>
>> Bullshit.
>
> They're all lying, WRonG.  Linux is perfect. 

....and no one posts nonsense to public discussion forums.

-- 

        Linux: Because I don't want to push pretty buttons.          |||
	       I want the pretty buttons to push themelves.         / | \

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------       
                http://www.usenet.com
0
jedi (14753)
7/13/2008 6:11:32 AM
On Sun, 13 Jul 2008 05:00:11 +0000, Gregory Shearman wrote:


> That's correct. If you move the file from one filesystem to another it
> would take longer than a move within a filesystem, which is almost
> instantaneous.


ROFL.  What a shocker.  It's just counter-intuitive that drag-and-drop 
would give different results than copy-paste.


-Thufir
0
hawat.thufir (2846)
7/13/2008 8:05:40 AM
JEDIDIAH wrote:

> On 2008-07-13, DFS <nospam@dfs_.com> wrote:
>> RonB wrote:
>>> DFS wrote:
>>>
>>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>>> moving a file of 1 Gig and the whole system just froze. Only 1 out
>>>> of 5 or 6 can be successful without crashing. I am running my
>>>> STABLEST 2.6.24.18. I have no luck with other verions, they are the
>>>> worst in terms of stability WHILE MOVING BIG FILES."
>>>>
>>>> http://ubuntuforums.org/showthread.php?t=844005
>>>
>>> Bullshit.
>>
>> They're all lying, WRonG.  Linux is perfect.
> 
> ...and no one posts nonsense to public discussion forums.

I've moved too many big files in Linux. The original point is pure bullshit.
Even a moron like DuFuS knows he's lying when he parrots crap like this.

-- 
RonB
"There's a story there...somewhere"
0
ronb02noSPAM (7426)
7/13/2008 8:16:02 AM
JEDIDIAH wrote:

> It can be moves, moves across filesystems, copies, copies across the
> network. It can be small files or huge files and can be hundreds of
> gigabytes at a time.

Yep. Obviously the WinTroll is projecting Vista ME's inadequacies on to
Linux.

-- 
RonB
"There's a story there...somewhere"
0
ronb02noSPAM (7426)
7/13/2008 8:17:48 AM
JEDIDIAH <jedi@nomad.mishnet> writes:

> On 2008-07-13, Gregory Shearman <ZekeGregory@netscape.net> wrote:
>> On 2008-07-12, Andrew Halliwell <spike1@ponder.sky.com> wrote:
>>> ray <ray@zianet.com> wrote:
>>>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>>>> 
>>>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>>>> or 6 can be successful without crashing. I am running my STABLEST
>>>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>>>> terms of stability WHILE MOVING BIG FILES."
>
> ...assuming he's using a default type Ubuntu install that's beyond bizarre.
>
>>>>> 
>>>>> http://ubuntuforums.org/showthread.php?t=844005
>>>> 
>>>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
>>>> command, it will make no difference how big it is, and it will happen 
>>>> instantaneously. Mainly because all that does is to change it's name. FWIW 
>>>> - I have copied files over 1gb many times with absolutely no problem.
>>>
>>> Takes a few seconds sometimes. All depends from whence you are moving the
>>> file, and to where?
>
> ...a n00b working with Ubuntu? It's bound to be a system carved up as one big
> fat root partition.
>
>>
>> That's correct. If you move the file from one filesystem to another it
>> would take longer than a move within a filesystem, which is almost
>> instantaneous.
>
>     A single filesystem move is just going to be tweaking some pointers.
> A move between filesystems is going to be a copy and then a detete.

*chuckle*

Look at them falling over themselves to be the techy advocate. Yes, we
all know. And its been posted 100 times now.

-- 
I really think XP is going to be a flop. Between the glut of hardware out
there (and slowing down of purchasing), and the fact that W2K is
sufficient for so many casual users.... I just don't see it taking off.
               comp.os.linux.advocacy - where they put the lunacy in advocacy
0
hadronquark2 (7213)
7/13/2008 10:52:30 AM
On Jul 12, 6:46 am, "DFS" <nospam@dfs_.com> wrote:
> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried moving a
> file of 1 Gig and the whole system just froze.

> Only 1 out of 5 or 6 can be
> successful without crashing. I am running my STABLEST 2.6.24.18. I have no
> luck with other verions, they are the worst in terms of stability WHILE
> MOVING BIG FILES."

It depends on which file system and which architecture is being used.
Ext2 file systems don't like big files, Reiser, Ext3, and JFS can
handle 2^64 length files.

It also depends on whether you need to seek or not.  Seek on 32 bit
file systems is 2^32 bits where seek on 64 bit file systems is 2^64
bits.

Seek is important if you are using bulk transfer technologies such as
bit-torrent, since torrent breaks the file into chunks and transfers
multiple chunks concurrently.  The chunks are "placed" using the fseek/
lseek commands.  There are also library options that can be compiled
in that will give you 64 bit seek on a 32 bit OS, but you have to
compile the 64 bit library, and then specify the 64 bit library in
your makefile or link command.

> http://ubuntuforums.org/showthread.php?t=844005

0
rex.ballard (3732)
7/13/2008 11:21:28 AM
thufir wrote:
> On Sun, 13 Jul 2008 05:00:11 +0000, Gregory Shearman wrote:
>
>
>> That's correct. If you move the file from one filesystem to another
>> it would take longer than a move within a filesystem, which is almost
>> instantaneous.
>
>
> ROFL.  What a shocker.  It's just counter-intuitive that drag-and-drop
> would give different results than copy-paste.


Or that GUI copy/paste changes file attributes differently than the cp 
command

If you copy a file from the Gnome (2.14.3) desktop by right-clicking and 
using the Copy and Paste commands in the shortcut menu, the Modified 
timestamp of the copy is the same as the original, and the Accessed time 
changes.

But if you copy a file via the console, using the cp command, both the 
Modified and Accessed timestamps of the copy are changed to the current 
system timestamp.

Linux: we're just confused



0
nospam11 (18349)
7/13/2008 12:04:38 PM
On 13 Jul 2008 05:00:11 GMT, Gregory Shearman
<ZekeGregory@netscape.net> wrote:

>On 2008-07-12, Andrew Halliwell <spike1@ponder.sky.com> wrote:
>> ray <ray@zianet.com> wrote:
>>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>>> 
>>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>>> or 6 can be successful without crashing. I am running my STABLEST
>>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>>> terms of stability WHILE MOVING BIG FILES."
>>>> 
>>>> http://ubuntuforums.org/showthread.php?t=844005
>>> 
>>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
>>> command, it will make no difference how big it is, and it will happen 
>>> instantaneously. Mainly because all that does is to change it's name. FWIW 
>>> - I have copied files over 1gb many times with absolutely no problem.
>>
>> Takes a few seconds sometimes. All depends from whence you are moving the
>> file, and to where?
>
>That's correct. If you move the file from one filesystem to another it
>would take longer than a move within a filesystem, which is almost
>instantaneous.

Funny how Linuxtards cannot tell the difference between a filesystem
(e.g. ext0, MurderFS..) and a volume or partition...

0
otto901 (493)
7/13/2008 12:45:04 PM
* Tim Smith peremptorily fired off this memo:

> In article <%L4ek.27$dP6.1@bignews1.bellsouth.net>,
>  Linonut <linonut@bollsouth.nut> wrote:
>> The person who posted that article on the Ubuntu forum is either /lying/
>> or fat-fingered something in the install.  Even if one thinks Nautilus
>> might be the problem.
>
> Or maybe he's moving the file across filesystems, and so it is actually 
> a copy and delete?
>
> There are known cases where that can get slow, and make the system 
> sluggish, on Linux.  I finally found a good explanation of this problem, 
> BTW:
>
>    <http://www.reddit.com/info/6qhzc/comments/c04lvzu>
>
> Another possibility that comes to mind: suppose he's using some kind of 
> fast search system, and when me moves the file, it tries to index the 
> file in the new location?  Some search system indexers can be slow and 
> use a lot of resources on big files.

The article that Displaced Fan Syndrome posted never really came to a
final resolution of the issue, I think.

The article you quote is interesting.  I'm doing a 4 Gb copy across
hard-drives, and its only using 40% CPU, though.  No impact whatsover on
the rest of the system that I can see.

-- 
Tcl tends to get ported to weird places like routers.
		-- Larry Wall in <199710071721.KAA19014@wall.org>
0
linonut (8350)
7/13/2008 2:48:19 PM
* JEDIDIAH peremptorily fired off this memo:

>     "can't copy big files with Linux"?
>
>     Total hogwash.
>
>     Been doing this since slackware '96. Not only has Linux always
>     performed much better than Windows while doing huge nasty IO
>     operations but you can add decoding and encoding multimedia on top
>     of that and not miss a beat.
>
>     It can be moves, moves across filesystems, copies, copies across
>     the network. It can be small files or huge files and can be
>     hundreds of gigabytes at a time.

The only proviso is large-file copying over a Samba filesystem.
As far as I can tell, it preserves the limitations of a Windows share,
so that a 4 Gb copy (I think that is the boundary) will crap out.

-- 
Under a government which imprisons any unjustly, the true place for a
just man is also a prison.
		-- Henry David Thoreau
0
linonut (8350)
7/13/2008 2:51:49 PM
On Jul 13, 7:59 am, "DFS" <nospam@dfs_.com> wrote:
> RonB wrote:
> > DFS wrote:
>
> >> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
> >> moving a file of 1 Gig and the whole system just froze. Only 1 out
> >> of 5 or 6 can be successful without crashing. I am running my
> >> STABLEST 2.6.24.18. I have no luck with other verions, they are the
> >> worst in terms of stability WHILE MOVING BIG FILES."
>
> >>http://ubuntuforums.org/showthread.php?t=844005
>
> > Bullshit.
>
> They're all lying, WRonG.  Linux is perfect.

Re-reading the article, it looks like he needs to do an fsck on the
file-system.
If Linux crashed during the move, there could be unallocated blocks
that need to be reclaimed as a result of a reboot.  Normally, this is
done automatically, if the mount detects that there is an issue with
the drive, but it does ask the user if they want to do the recovery
and the user can say no.  Of course, if you do that, you have a bunch
of files allocated to the file that wasn't closed, so the inodes may
not have been updated.

Very hard to see from the article what might have been the issue, or
even how to recreate the problem.  I've known of a couple of WinTroll
Linux benchmarks where they deliberately slowed down the system
(turning off cache for Linux, and turning it on for Windows), but
without a detail description of the exact tests being run, it's hard
to tell what the problem might have been.

There are a few possible explanations for this type of problem, they
could range from insufficient i-nodes to insufficient storage, to
special applications to corrupted hardware or disk format.  I'm not
going to call the author a liar, but without more information, it
occurs to me as yet another "flatfish" style troll being passed off as
a legitimate finding.

I hope Microsoft gave the guy a handsome pay-off.
0
rex.ballard (3732)
7/13/2008 3:07:57 PM
On Sat, 12 Jul 2008 19:37:52 -0700 (PDT), Psyc Geek (TAB) 
<psycgeeks@yahoo.com> wrote:

> First of all, many did not read the Ubuntu Forum Post ....

True.  I am totally uninterested in whatever problems DFS is making 
up today.  He's in my killfile for a reason.  I was answering Tim's 
post.


> Second, 64 bit is unstable, to everybody but those in Cola.

Hogwash.


> Personally, suggesting that somebody TERMINAL is just crazy.  

First, the verb "to terminal" is a new one on me.  I learn something 
every day in here.

Second, in terms of filing a useful bug report one might want to 
"terminal" in order to find out whether the problem is with the GUI 
or the kernel.

But even so, I wasn't suggesting anything.  I just did a copy the way I 
usually would for a quick test.  I don't care if you and DFS are afraid 
of the command line.


> If you are going linux, and i do linux, you want to stay with stuff 
> that has proved to be stable, or you are looking to tweek and debug.

You do Linux like I do gymnastics.  It is excruciating to watch.


-- 
 -| Bob Hauck
 -| http://www.haucks.org/
0
postmaster6 (1752)
7/13/2008 4:15:00 PM
On Sun, 13 Jul 2008 04:21:28 -0700 (PDT), Rex Ballard 
<rex.ballard@gmail.com> wrote:

> It depends on which file system and which architecture is being used. 
> Ext2 file systems don't like big files, Reiser, Ext3, and JFS can 
> handle 2^64 length files.

If his problem was the file size itself, it would fail at 2 GiB - 1 
bytes, or at 4 GiB, not at one GiB.  However, all modern Linux 
filesystems support > 4 GiB files.

What ext2/3 doesn't like is big directories, ones with tens of thousands 
or more files.  It will create and use such directories, but becomes 
very slow at certain operations.

Reiser was designed to better handle this situation, especially for the 
common case of lots of small files.  There are tradeoffs of course, it 
is not the case that ReiserFS is "better" than ext3 for all use cases.


> It also depends on whether you need to seek or not.  Seek on 32 bit
> file systems is 2^32 bits where seek on 64 bit file systems is 2^64
> bits.

Not if the program was compiled with large file support, which has been 
available since the 2.4 kernel.  Most distros compile their apps with 
this enabled.


> There are also library options that can be compiled in that will give 
> you 64 bit seek on a 32 bit OS, but you have to compile the 64 bit 
> library, and then specify the 64 bit library in your makefile or link 
> command.

Um, no, that's false.  All you need is "gcc -D_FILE_OFFSET_BITS=64" and 
then ensure that you use off_t instead of int for specifying the offset 
in calls to the seek functions.

You can also explicitly ask for large file support with the O_LARGEFILE 
flag to open().


-- 
 -| Bob Hauck
 -| http://www.haucks.org/
0
postmaster6 (1752)
7/13/2008 4:49:05 PM
* Bob Hauck peremptorily fired off this memo:

> On Sat, 12 Jul 2008 19:37:52 -0700 (PDT), Psyc Geek (TAB) 
> <psycgeeks@yahoo.com> wrote:
>
>> First of all, many did not read the Ubuntu Forum Post ....
>
> True.  I am totally uninterested in whatever problems DFS is making 
> up today.  He's in my killfile for a reason.  I was answering Tim's 
> post.
>
>> Second, 64 bit is unstable, to everybody but those in Cola.
>
> Hogwash.

I enjoy 64-bit Debian unstable.  And, with updates, my 64-bit system
gets better and better, with me doing nothing more than running aptitude
every couple days.

A couple days ago, I noticed that I was now able to hear the /audio/ in
YouTube.  Previously, even with nspluginwrapper, I wasn't even getting
a response out of YouTube links.

Today, I look at homer's link:

   http://uk.youtube.com/watch?v=5NoGbLI3ePA

And now it works fully.  In Iceweasel 3.  All I had to do was wait
(YouTube is very low on my list of wants.)

Forward progress with updates.  Cool.

> But even so, I wasn't suggesting anything.  I just did a copy the way I 
> usually would for a quick test.  I don't care if you and DFS are afraid 
> of the command line.

Many Windows-only people are.

>> If you are going linux, and i do linux, you want to stay with stuff 
>> that has proved to be stable, or you are looking to tweek and debug.
>
> You do Linux like I do gymnastics.  It is excruciating to watch.

I suspect they follow the advice of this "fortune":

-- 
Never tell a lie unless it is absolutely convenient.
0
linonut (8350)
7/13/2008 5:32:39 PM
Linonut <linonut@bollsouth.nut> writes:

> * Bob Hauck peremptorily fired off this memo:
>
>> On Sat, 12 Jul 2008 19:37:52 -0700 (PDT), Psyc Geek (TAB) 
>> <psycgeeks@yahoo.com> wrote:
>>
>>> First of all, many did not read the Ubuntu Forum Post ....
>>
>> True.  I am totally uninterested in whatever problems DFS is making 
>> up today.  He's in my killfile for a reason.  I was answering Tim's 
>> post.
>>
>>> Second, 64 bit is unstable, to everybody but those in Cola.
>>
>> Hogwash.
>
> I enjoy 64-bit Debian unstable.  And, with updates, my 64-bit system
> gets better and better, with me doing nothing more than running aptitude
> every couple days.
>
> A couple days ago, I noticed that I was now able to hear the /audio/ in
> YouTube.  Previously, even with nspluginwrapper, I wasn't even getting
> a response out of YouTube links.

Thats funny. It all "just worked" for Peter and you ages ago. You loons
have no idea how fundamental this type of stuff is to the average
desktop user.

But this is why you are widely known as "Liarnut".
0
hadronquark2 (7213)
7/13/2008 5:46:36 PM
On Sun, 13 Jul 2008 19:46:36 +0200, Hadron wrote:

> Linonut <linonut@bollsouth.nut> writes:
> 
>> * Bob Hauck peremptorily fired off this memo:
>>
>>> On Sat, 12 Jul 2008 19:37:52 -0700 (PDT), Psyc Geek (TAB)
>>> <psycgeeks@yahoo.com> wrote:
>>>
>>>> First of all, many did not read the Ubuntu Forum Post ....
>>>
>>> True.  I am totally uninterested in whatever problems DFS is making up
>>> today.  He's in my killfile for a reason.  I was answering Tim's post.
>>>
>>>> Second, 64 bit is unstable, to everybody but those in Cola.
>>>
>>> Hogwash.
>>
>> I enjoy 64-bit Debian unstable.  And, with updates, my 64-bit system
>> gets better and better, with me doing nothing more than running aptitude
>> every couple days.
>>
>> A couple days ago, I noticed that I was now able to hear the /audio/ in
>> YouTube.  Previously, even with nspluginwrapper, I wasn't even getting a
>> response out of YouTube links.
> 
> Thats funny. It all "just worked" for Peter and you ages ago. You loons
> have no idea how fundamental this type of stuff is to the average desktop
> user.
> 
> But this is why you are widely known as "Liarnut".

Of course using 64-bit IE on 64-bit Vista just works with Youtube.   NOT
At least with Linux there is nspluginwrapper.  Where is the equivalent for
Windows? 

Bug

0
bugbuster1 (179)
7/13/2008 6:08:23 PM
DFS wrote:
> 
> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried moving a
> file of 1 Gig and the whole system just froze. Only 1 out of 5 or 6 can be
> successful without crashing. I am running my STABLEST 2.6.24.18. I have no
> luck with other verions, they are the worst in terms of stability WHILE
> MOVING BIG FILES."
> 
> http://ubuntuforums.org/showthread.php?t=844005

We wanted all you Windows fanbois to have a genuine Vista experience, so
we crippled the copies we shipped to you.

-- 
Paul Hovnanian	paul@hovnanian.com
-----------------------------------------------------------------------
Have gnu, will travel.
0
Paul261 (1126)
7/13/2008 6:16:54 PM
Paul Hovnanian P.E. wrote:
> DFS wrote:
>>
>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>> moving a file of 1 Gig and the whole system just froze. Only 1 out
>> of 5 or 6 can be successful without crashing. I am running my
>> STABLEST 2.6.24.18. I have no luck with other verions, they are the
>> worst in terms of stability WHILE MOVING BIG FILES."
>>
>> http://ubuntuforums.org/showthread.php?t=844005
>
> We wanted all you Windows fanbois to have a genuine Vista experience,
> so we crippled the copies we shipped to you.

In other words, you shipped them as is.



0
nospam11 (18349)
7/13/2008 8:51:09 PM
On 2008-07-13, OK <otto@kaiser.de> wrote:
> On 13 Jul 2008 05:00:11 GMT, Gregory Shearman
><ZekeGregory@netscape.net> wrote:
>
>>On 2008-07-12, Andrew Halliwell <spike1@ponder.sky.com> wrote:
>>> ray <ray@zianet.com> wrote:
>>>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>>>> 
>>>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>>>> or 6 can be successful without crashing. I am running my STABLEST
>>>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>>>> terms of stability WHILE MOVING BIG FILES."
>>>>> 
>>>>> http://ubuntuforums.org/showthread.php?t=844005
>>>> 
>>>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
>>>> command, it will make no difference how big it is, and it will happen 
>>>> instantaneously. Mainly because all that does is to change it's name. FWIW 
>>>> - I have copied files over 1gb many times with absolutely no problem.
>>>
>>> Takes a few seconds sometimes. All depends from whence you are moving the
>>> file, and to where?
>>
>>That's correct. If you move the file from one filesystem to another it
>>would take longer than a move within a filesystem, which is almost
>>instantaneous.
>
> Funny how Linuxtards cannot tell the difference between a filesystem
> (e.g. ext0, MurderFS..) and a volume or partition...

Funny how you don't make any sense.

Who are these "Linuxtards" who can't tell the difference between a
filesystem and a partition?

Each filesystem contains its own table of inodes to filenames.

Moving within a filesystem only means a change of entry in this table,
between filesystems it means a copy then delete.

-- 
Regards,

Gregory.
Gentoo Linux - Penguin Power
0
ZekeGregory (6440)
7/14/2008 7:31:19 AM
Gregory Shearman <ZekeGregory@netscape.net> wrote:
>> Funny how Linuxtards cannot tell the difference between a filesystem
>> (e.g. ext0, MurderFS..) and a volume or partition...
> 
> Funny how you don't make any sense.
> 
> Who are these "Linuxtards" who can't tell the difference between a
> filesystem and a partition?
> 
> Each filesystem contains its own table of inodes to filenames.
> 
> Moving within a filesystem only means a change of entry in this table,
> between filesystems it means a copy then delete.
 
Indeed, and poor old OK is so dim, he doesn't realise that there are
occasions where such a filesystem may actually be ON the same partition as
the one you're copying from.

Such as, for example, a loop device mounted image file or initrd.

Yes, OK, imagine that. two filesystems on the same partition.
And with the use of RAID, you could have the same filesystem on TWO
partitions... Imagine that, too! Shocking, isn't it?
-- 
|   spike1@freenet.co.uk   |                                                 |
|   Andrew Halliwell BSc   | "The day Microsoft makes something that doesn't |
|            in            |  suck is probably the day they start making     |
|     Computer science     |  vacuum cleaners" - Ernst Jan Plugge            |
0
spike11 (2375)
7/14/2008 8:04:15 AM
Bob Hauck <postmaster@localhost.localdomain> wrote:
> On Sat, 12 Jul 2008 19:37:52 -0700 (PDT), Psyc Geek (TAB) 
> <psycgeeks@yahoo.com> wrote:
> 
>> First of all, many did not read the Ubuntu Forum Post ....
> 
> True.  I am totally uninterested in whatever problems DFS is making 
> up today.  He's in my killfile for a reason.  I was answering Tim's 
> post.
> 
> 
>> Second, 64 bit is unstable, to everybody but those in Cola.
> 
> Hogwash.

Indeed. Linux has had 64bit usable for the past 7 years.
Long before the 64bit cluestick thwapped bill gates about the head.
(OK. I know windows did have a 64bit version of windows NT out at one point,
but that got dumped when they dropped all but the intel x86 range for
windows... And the itanium version... how well did that sell again?

:)

>> Personally, suggesting that somebody TERMINAL is just crazy.  
> 
> First, the verb "to terminal" is a new one on me.  I learn something 
> every day in here.
> 
> Second, in terms of filing a useful bug report one might want to 
> "terminal" in order to find out whether the problem is with the GUI 
> or the kernel.
> 
> But even so, I wasn't suggesting anything.  I just did a copy the way I 
> usually would for a quick test.  I don't care if you and DFS are afraid 
> of the command line.

even more more so, if the terminal is such a hindrance, why are microsoft
trying to play catchup once again with their new "powershell" thing?

Perhaps because their DOS window was so useless? 

>> If you are going linux, and i do linux, you want to stay with stuff 
>> that has proved to be stable, or you are looking to tweek and debug.
> 
> You do Linux like I do gymnastics.  It is excruciating to watch.

I think it's rather quaint and amusing.
:)
-- 
|                          |What to do if you find yourself stuck in a crack|
|  spike1@freenet.co.uk    |in the ground beneath a giant boulder, which you|
|                          |can't move, with no hope of rescue.             |
|  Andrew Halliwell BSc    |Consider how lucky you are that life has been   |
|           in             |good to you so far...                           |
|    Computer Science      |   -The BOOK, Hitch-hiker's guide to the galaxy.|
0
spike11 (2375)
7/14/2008 9:49:35 AM
On 14 Jul 2008 07:31:19 GMT, Gregory Shearman
<ZekeGregory@netscape.net> wrote:

>On 2008-07-13, OK <otto@kaiser.de> wrote:
>> On 13 Jul 2008 05:00:11 GMT, Gregory Shearman
>><ZekeGregory@netscape.net> wrote:
>>
>>>On 2008-07-12, Andrew Halliwell <spike1@ponder.sky.com> wrote:
>>>> ray <ray@zianet.com> wrote:
>>>>> On Fri, 11 Jul 2008 23:46:09 -0400, DFS wrote:
>>>>> 
>>>>>> "Hardy just cannot cope with big file moving on MY SYSTEM. I tried
>>>>>> moving a file of 1 Gig and the whole system just froze. Only 1 out of 5
>>>>>> or 6 can be successful without crashing. I am running my STABLEST
>>>>>> 2.6.24.18. I have no luck with other verions, they are the worst in
>>>>>> terms of stability WHILE MOVING BIG FILES."
>>>>>> 
>>>>>> http://ubuntuforums.org/showthread.php?t=844005
>>>>> 
>>>>> Well, DooFuS if you actually tried to MOVE the file, with the 'mv' 
>>>>> command, it will make no difference how big it is, and it will happen 
>>>>> instantaneously. Mainly because all that does is to change it's name. FWIW 
>>>>> - I have copied files over 1gb many times with absolutely no problem.
>>>>
>>>> Takes a few seconds sometimes. All depends from whence you are moving the
>>>> file, and to where?
>>>
>>>That's correct. If you move the file from one filesystem to another it
>>>would take longer than a move within a filesystem, which is almost
>>>instantaneous.
>>
>> Funny how Linuxtards cannot tell the difference between a filesystem
>> (e.g. ext0, MurderFS..) and a volume or partition...
>
>Funny how you don't make any sense.
>
>Who are these "Linuxtards" who can't tell the difference between a
>filesystem and a partition?
>
>Each filesystem contains its own table of inodes to filenames.
>
>Moving within a filesystem only means a change of entry in this table,
>between filesystems it means a copy then delete.

Yeah, right:

http://en.wikipedia.org/wiki/File_system

Now go back do whathever idiots do.
0
otto901 (493)
7/14/2008 12:03:22 PM
OK <otto@kaiser.de> wrote:
>>Funny how you don't make any sense.
>>
>>Who are these "Linuxtards" who can't tell the difference between a
>>filesystem and a partition?
>>
>>Each filesystem contains its own table of inodes to filenames.
>>
>>Moving within a filesystem only means a change of entry in this table,
>>between filesystems it means a copy then delete.
> 
> Yeah, right:
> 
> http://en.wikipedia.org/wiki/File_system

And your point was...?
We know what a filesystem is, moron. We know the limitations and what
happens when you cross filesystem boundaries.
As has been explained in this thread several times...
 
> Now go back do whathever idiots do.

Only idiot here seems to be you, who can't tell the difference between the
RELEVANCE of a filesystem and partition.
-- 
|   spike1@freenet.co.uk   |                                                 |
|   Andrew Halliwell BSc   | "ARSE! GERLS!! DRINK! DRINK! DRINK!!!"          |
|            in            | "THAT WOULD BE AN ECUMENICAL MATTER!...FECK!!!! |
|     Computer Science     | - Father Jack in "Father Ted"                   |
0
spike11 (2375)
7/14/2008 12:24:49 PM
On Mon, 14 Jul 2008 14:03:22 +0200, OK <otto@kaiser.de> wrote:
> On 14 Jul 2008 07:31:19 GMT, Gregory Shearman
><ZekeGregory@netscape.net> wrote:

>>Each filesystem contains its own table of inodes to filenames.
>>
>>Moving within a filesystem only means a change of entry in this table,
>>between filesystems it means a copy then delete.
>
> Yeah, right:
>
> http://en.wikipedia.org/wiki/File_system

So you don't actually know what you're talking about.  I think you need 
to re-read that article again, as they use "filesystem" in exactly the 
way the OP did.  For example:

  "In many situations, file systems other than the root need to be 
  available as soon as the operating system has booted. All Unix-like 
  systems therefore provide a facility for mounting file systems at boot 
  time. System administrators define these file systems in the 
  configuration file fstab, which also indicates options and mount 
  points."


> Now go back do whathever idiots do.

http://en.wikipedia.org/wiki/Dunning-Kruger_effect


-- 
 -| Bob Hauck
 -| http://www.haucks.org/
0
postmaster6 (1752)
7/14/2008 1:02:48 PM
On Sun, 13 Jul 2008 19:46:36 +0200, Hadron wrote:

> Linonut <linonut@bollsouth.nut> writes:
> 
>> * Bob Hauck peremptorily fired off this memo:
>>
>>> On Sat, 12 Jul 2008 19:37:52 -0700 (PDT), Psyc Geek (TAB) 
>>> <psycgeeks@yahoo.com> wrote:
>>>
>>>> First of all, many did not read the Ubuntu Forum Post ....
>>>
>>> True.  I am totally uninterested in whatever problems DFS is making 
>>> up today.  He's in my killfile for a reason.  I was answering Tim's 
>>> post.
>>>
>>>> Second, 64 bit is unstable, to everybody but those in Cola.
>>>
>>> Hogwash.
>>
>> I enjoy 64-bit Debian unstable.  And, with updates, my 64-bit system
>> gets better and better, with me doing nothing more than running aptitude
>> every couple days.
>>
>> A couple days ago, I noticed that I was now able to hear the /audio/ in
>> YouTube.  Previously, even with nspluginwrapper, I wasn't even getting
>> a response out of YouTube links.
> 
> Thats funny. It all "just worked" for Peter and you ages ago. You loons
> have no idea how fundamental this type of stuff is to the average
> desktop user.
> 
> But this is why you are widely known as "Liarnut".

It's just like the fonts issue, the wireless networking issue and a 1000
other issues that Linux has or still has.

The Linux loons deny it tooth and nail, like the fonts, despite reams of
web pages offering advice on how to make things better.

Then when the problem, say fonts, gets fixed, the Linux loons start
claiming how much better it looks.

They are so FOS it's not even funny.

LIEing for LIEnux is the name of the game in COLA.
-- 
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/
0
brick_n_straw (4058)
7/14/2008 1:37:03 PM
* Bob Hauck peremptorily fired off this memo:

> On Mon, 14 Jul 2008 14:03:22 +0200, OK <otto@kaiser.de> wrote:
>
>> Now go back do whathever idiots do.
>
> http://en.wikipedia.org/wiki/Dunning-Kruger_effect

   Kruger and Dunning noted a number of previous studies which tend to
   suggest that in skills as diverse as reading comprehension, operating
   a motor vehicle, and playing chess or tennis, "ignorance more
   frequently begets confidence than does knowledge".

OK is very confident!

-- 
I trust the first lion he meets will do his duty.
		-- J. P. Morgan on Teddy Roosevelt's safari
0
linonut (8350)
7/14/2008 1:41:02 PM
Moshe Goldfarb. wrote:

> It's just like the fonts issue, the wireless networking issue and a
> 1000 other issues that Linux has or still has.
>
> They are so FOS it's not even funny.
>
> LIEing for LIEnux is the name of the game in COLA.

The joke's on them and their guilty consciences for their lies and coverups.



0
nospam11 (18349)
7/14/2008 1:46:35 PM
On 2008-07-14, DFS <nospam@dfs_.com> wrote:
> Moshe Goldfarb. wrote:
>
>> It's just like the fonts issue, the wireless networking issue and a
>> 1000 other issues that Linux has or still has.

The "fonts issue" was overblown 10 years ago. Nevermind today.

Wifi can be a hardware support issue.

Although wifi in general SUCKS. It doesn't matter what OS you're using.

How many different versions of the wifi protocol are there now?

I can't see any of my n00b friends or family successfully navigating that mess.

>>
>> They are so FOS it's not even funny.
>>
>> LIEing for LIEnux is the name of the game in COLA.
>
> The joke's on them and their guilty consciences for their lies and coverups.

Stop projecting.

-- 

        Linux: Because I don't want to push pretty buttons.          |||
	       I want the pretty buttons to push themelves.         / | \

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------       
                http://www.usenet.com
0
jedi (14753)
7/14/2008 2:39:21 PM
On Mon, 14 Jul 2008 09:39:21 -0500, JEDIDIAH <jedi@nomad.mishnet> wrote:
>On 2008-07-14, DFS <nospam@dfs_.com> wrote:
>> Moshe Goldfarb. wrote:
>>
>>> It's just like the fonts issue, the wireless networking issue and a
>>> 1000 other issues that Linux has or still has.

>The "fonts issue" was overblown 10 years ago. Nevermind today.
You have to feel sorry for flatty and dumbfuck.  They're still running at
640x480 resolution as they can't figure out how to set a higher resolution.

At VGA resolution, font rendering is a pretty critical issue.

Personally I run at 1600x1200 and don't have to put up with 5x7 character
graphics like dumfuck.



>Wifi can be a hardware support issue.
real fun with windows when you have to sneakernet the driver to get wifi
working.   Somebody wanting vista would have to buy new hardware as it doesn't
support many old chipsets.  Of course, they would have to get a new computer
anyway due to the insane resource requirements.

Linux has all the drivers in the distro.  To set up my wifi on
my laptop, what I had to do was <nothing>.

0
aznomad.3 (962)
7/14/2008 2:47:39 PM
On Mon, 14 Jul 2008 09:39:21 -0500, JEDIDIAH wrote:

> On 2008-07-14, DFS <nospam@dfs_.com> wrote:
>> Moshe Goldfarb. wrote:
>>
>>> It's just like the fonts issue, the wireless networking issue and a
>>> 1000 other issues that Linux has or still has.
> 
> The "fonts issue" was overblown 10 years ago. Nevermind today.

Yea, so that's why there were so many "Font How-To" pages around.

The Font De-Uglification one comes to mind as one of the more popular ones.

It was only CLI based people stilling living in the 1970's who didn't have
a problem.

People like you Jedi......

> Wifi can be a hardware support issue.
> 
> Although wifi in general SUCKS. It doesn't matter what OS you're using.
> 
> How many different versions of the wifi protocol are there now?
> 
> I can't see any of my n00b friends or family successfully navigating that mess.

Just did it with a Cisco/Linksys wireless router.

Put CD in the tray and follow the instructions.

Worked like a champ and every mobile device saw the router fine.
Any idiot can do it.

Try that with Linux..

>>>
>>> They are so FOS it's not even funny.
>>>
>>> LIEing for LIEnux is the name of the game in COLA.
>>
>> The joke's on them and their guilty consciences for their lies and coverups.
> 
> Stop projecting.

Nobody is projecting, we are simply exposing all of you for the liars that
you are.


-- 
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/
0
brick_n_straw (4058)
7/14/2008 3:03:36 PM
On Mon, 14 Jul 2008 09:47:39 -0500, AZ Nomad wrote:

> On Mon, 14 Jul 2008 09:39:21 -0500, JEDIDIAH <jedi@nomad.mishnet> wrote:
>>On 2008-07-14, DFS <nospam@dfs_.com> wrote:
>>> Moshe Goldfarb. wrote:
>>>
>>>> It's just like the fonts issue, the wireless networking issue and a
>>>> 1000 other issues that Linux has or still has.
> 
>>The "fonts issue" was overblown 10 years ago. Nevermind today.
> You have to feel sorry for flatty and dumbfuck.  They're still running at
> 640x480 resolution as they can't figure out how to set a higher resolution.
> 
> At VGA resolution, font rendering is a pretty critical issue.

Actually we feel sorry for you Linux fools.

It must have been embarrassing having a "Font-De-Uglification" How-To for
the font problem you zealots claimed, back then, didn't exist.

BTW you claimed the same, or similar about sound, wireless and just about
everything that didn't work for most people using Linux.

Of course it all worked *flawlessly* for you zealots.

 
> Personally I run at 1600x1200 and don't have to put up with 5x7 character
> graphics like dumfuck.

I would hardly call twin LCD widescreen, 19 inch, monitors VGA.....

Took all of 5 minutes to install on my Nvidia video card and I was able to
use the great Nvida software to tune every single option if I wanted to.

I have my track view in Nuendo on one monitor and my mixer on the other.
Works GREAT!

Linux?

Yea, good luck get dual monitors to work.

 

> 
> 
>>Wifi can be a hardware support issue.
> real fun with windows when you have to sneakernet the driver to get wifi
> working.   Somebody wanting vista would have to buy new hardware as it doesn't
> support many old chipsets.  Of course, they would have to get a new computer
> anyway due to the insane resource requirements.
> 
> Linux has all the drivers in the distro.  To set up my wifi on
> my laptop, what I had to do was <nothing>.

For you mayb, but not for a lot of people.
Then there is Wep/WPA/WPAII etc....

Like I replied to Jebediah, slap the Cisco CD in, select the options you
want, with full context help screens of course, and hit enter.
It tests the link, sets everything up and it works fine.

If you want to fine tune it, you can do that as well.

Linux?

Hahahhahah!

The average user doesn't stand a chance with ndiswrapper etc...


-- 
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/
0
brick_n_straw (4058)
7/14/2008 3:10:15 PM
In comp.os.linux.advocacy, DFS
<nospam@dfs_.com>
 wrote
on Fri, 11 Jul 2008 23:46:09 -0400
<TMVdk.13994$1I.7867@bignews4.bellsouth.net>:
> "Hardy just cannot cope with big file moving on MY SYSTEM.
> I tried moving a file of 1 Gig and the whole system just
> froze. Only 1 out of 5 or 6 can be successful without
> crashing. I am running my STABLEST 2.6.24.18. I have no 
> luck with other verions, they are the worst in terms of
> stability WHILE MOVING BIG FILES."
>
> http://ubuntuforums.org/showthread.php?t=844005
>

No doubt Vista is far more effective at moving large files,
as it only moves them half as fast.  ;-)

In any event, sounds like a potential problem with Linux
indeed; could be a heretofore undetected deadlock.  Best I
can do at this point is secure another system, set it up
to allow remote logging from your stricken system, have
your stricken system remote log to the logging system,
and then hope for the best as you try to copy additional
files, to see if a panic() comes through.  If that doesn't
work, modification of the kernel to put in additional
debugging statements might be useful.

A less reliable alternative is to ssh in, do the move,
and see if the system is truly frozen or still responds
to remote CLI commands.  Clearly there are multiple issues
here, and I for one don't have enough data, but have seen
similar, if less problematic, pauses on my nx9010, which
I believe have to do with overloading of the disk-to-CPU
transfer path.  (My kernel version: 2.6.24-tuxonice-r9.
However, I doubt the tuxonice patches make any difference.)

Another try is to XNest :1, DISPLAY=:1 ssh -CXY,
gnome-session, and one should then be able to do the
move in what amounts to a self-contained remote session.
(I'm assuming you're doing the move graphically.)

The thread does not mention filesystem type, which doesn't help.
I suspect ext3 but would have to fire up my Ubuntu LiveDisc.

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
** Posted from http://www.teranews.com **
0
ewill5 (11075)
7/14/2008 3:46:34 PM
On 2008-07-14, AZ Nomad <aznomad.3@PremoveOBthisOX.COM> wrote:
> On Mon, 14 Jul 2008 09:39:21 -0500, JEDIDIAH <jedi@nomad.mishnet> wrote:
>>On 2008-07-14, DFS <nospam@dfs_.com> wrote:
>>> Moshe Goldfarb. wrote:
>>>
>>>> It's just like the fonts issue, the wireless networking issue and a
>>>> 1000 other issues that Linux has or still has.
>
>>The "fonts issue" was overblown 10 years ago. Nevermind today.
> You have to feel sorry for flatty and dumbfuck.  They're still running at
> 640x480 resolution as they can't figure out how to set a higher resolution.

    That is the origin of this nonsense.

    Back when PCs were running 640x480 @ 14", Unix workstations were running 
1280x1024 @ 19". Even with the coder-centric extras, the success of a font
ultimately has more to do with the artist than the coder.

>
> At VGA resolution, font rendering is a pretty critical issue.
>
> Personally I run at 1600x1200 and don't have to put up with 5x7 character
> graphics like dumfuck.

[deletia]

-- 

        Linux: Because I don't want to push pretty buttons.          |||
	       I want the pretty buttons to push themelves.         / | \

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------       
                http://www.usenet.com
0
jedi (14753)
7/14/2008 5:10:22 PM
JEDIDIAH <jedi@nomad.mishnet> writes:

> On 2008-07-14, AZ Nomad <aznomad.3@PremoveOBthisOX.COM> wrote:
>> On Mon, 14 Jul 2008 09:39:21 -0500, JEDIDIAH <jedi@nomad.mishnet> wrote:
>>>On 2008-07-14, DFS <nospam@dfs_.com> wrote:
>>>> Moshe Goldfarb. wrote:
>>>>
>>>>> It's just like the fonts issue, the wireless networking issue and a
>>>>> 1000 other issues that Linux has or still has.
>>
>>>The "fonts issue" was overblown 10 years ago. Nevermind today.
>> You have to feel sorry for flatty and dumbfuck.  They're still running at
>> 640x480 resolution as they can't figure out how to set a higher resolution.
>
>     That is the origin of this nonsense.
>
>     Back when PCs were running 640x480 @ 14", Unix workstations were running 
> 1280x1024 @ 19". Even with the coder-centric extras, the success of a font
> ultimately has more to do with the artist than the coder.

Sure - if the system has properly registered the font and made it
available in the DE of choice. Sadly, too many times, this was NOT the
case in LINUX  - *hence* the plethora of how tos and fixes.

Don't deny it was a mess. In some cases it still is.
0
hadronquark2 (7213)
7/14/2008 7:50:40 PM
On 2008-07-14, Hadron <hadronquark@googlemail.com> wrote:
> JEDIDIAH <jedi@nomad.mishnet> writes:
>
>> On 2008-07-14, AZ Nomad <aznomad.3@PremoveOBthisOX.COM> wrote:
>>> On Mon, 14 Jul 2008 09:39:21 -0500, JEDIDIAH <jedi@nomad.mishnet> wrote:
>>>>On 2008-07-14, DFS <nospam@dfs_.com> wrote:
>>>>> Moshe Goldfarb. wrote:
>>>>>
>>>>>> It's just like the fonts issue, the wireless networking issue and a
>>>>>> 1000 other issues that Linux has or still has.
>>>
>>>>The "fonts issue" was overblown 10 years ago. Nevermind today.
>>> You have to feel sorry for flatty and dumbfuck.  They're still running at
>>> 640x480 resolution as they can't figure out how to set a higher resolution.
>>
>>     That is the origin of this nonsense.
>>
>>     Back when PCs were running 640x480 @ 14", Unix workstations were running 
>> 1280x1024 @ 19". Even with the coder-centric extras, the success of a font
>> ultimately has more to do with the artist than the coder.
>
> Sure - if the system has properly registered the font and made it
> available in the DE of choice. Sadly, too many times, this was NOT the

     Fonts are registered at the level of X, not the desktop.

     If you have a font "properly registered" than it can be used by
an Xaw application. Nevermind "desktops".

> case in LINUX  - *hence* the plethora of how tos and fixes.
>
> Don't deny it was a mess. In some cases it still is.

     When't the last time you installed a 3rd party font in Windows
by yourself manually? How did you do it? If you can't describe this
process off the top of you're head then you are just blowing a lot
of hot air.

-- 

        Linux: Because I don't want to push pretty buttons.          |||
	       I want the pretty buttons to push themelves.         / | \

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------       
                http://www.usenet.com
0
jedi (14753)
7/14/2008 8:56:36 PM
In comp.os.linux.advocacy, JEDIDIAH
<jedi@nomad.mishnet>
 wrote
on Mon, 14 Jul 2008 15:56:36 -0500
<slrng7nfc4.slq.jedi@nomad.mishnet>:
> On 2008-07-14, Hadron <hadronquark@googlemail.com> wrote:
>> JEDIDIAH <jedi@nomad.mishnet> writes:
>>
>>> On 2008-07-14, AZ Nomad <aznomad.3@PremoveOBthisOX.COM> wrote:
>>>> On Mon, 14 Jul 2008 09:39:21 -0500, JEDIDIAH <jedi@nomad.mishnet> wrote:
>>>>>On 2008-07-14, DFS <nospam@dfs_.com> wrote:
>>>>>> Moshe Goldfarb. wrote:
>>>>>>
>>>>>>> It's just like the fonts issue, the wireless networking issue and a
>>>>>>> 1000 other issues that Linux has or still has.
>>>>
>>>>>The "fonts issue" was overblown 10 years ago. Nevermind today.
>>>> You have to feel sorry for flatty and dumbfuck.  They're still running at
>>>> 640x480 resolution as they can't figure out how to set a higher resolution.
>>>
>>>     That is the origin of this nonsense.
>>>
>>>     Back when PCs were running 640x480 @ 14", Unix workstations were running 
>>> 1280x1024 @ 19". Even with the coder-centric extras, the success of a font
>>> ultimately has more to do with the artist than the coder.
>>
>> Sure - if the system has properly registered the font and made it
>> available in the DE of choice. Sadly, too many times, this was NOT the
>
>      Fonts are registered at the level of X, not the desktop.

Not 100% sure of that, though I do wonder how the Gnome
font requester is actually implemented.  X has some weird
hacks in there, as it was designed before TrueType.

>
>      If you have a font "properly registered" than it can be used by
> an Xaw application. Nevermind "desktops".

I doubt Xaw would work 100% with a font specification such as

   -adobe-courier-bold-r-normal--0-0-100-100-m-0-iso10646-1

but then, I'm not sure one should be using that particular
font spec anyway; it's a placeholder.  It turns out X fonts
are a bit of a historical mess; see for instance
http://www.faqs.org/faqs/fonts-faq/part15/

This does not preclude their usefulness, of course, and most
people don't use raw X11 font handling anyway, but go through
something like cairo or pango, or higher level.  There are some
issues regarding proper string handling for UTF-8.

>
>> case in LINUX  - *hence* the plethora of how tos and fixes.
>>
>> Don't deny it was a mess. In some cases it still is.
>
>      When't the last time you installed a 3rd party font in Windows
> by yourself manually? How did you do it? If you can't describe this
> process off the top of you're head then you are just blowing a lot
> of hot air.
>

I would think third party fonts are click-and-go, much like the rest of
Windows software.  Then again, I've not tried it either.

-- 
#191, ewill3@earthlink.net
Useless C/C++ Programming Idea #1123133:
void f(FILE * fptr, char *p) { fgets(p, sizeof(p), fptr); }
** Posted from http://www.teranews.com **
0
ewill5 (11075)
7/14/2008 9:51:43 PM
On Mon, 14 Jul 2008 08:46:34 -0700, The Ghost In The Machine wrote:

> In comp.os.linux.advocacy, DFS
> <nospam@dfs_.com>
>  wrote
> on Fri, 11 Jul 2008 23:46:09 -0400
> <TMVdk.13994$1I.7867@bignews4.bellsouth.net>:
>> "Hardy just cannot cope with big file moving on MY SYSTEM.
>> I tried moving a file of 1 Gig and the whole system just
>> froze. Only 1 out of 5 or 6 can be successful without
>> crashing. I am running my STABLEST 2.6.24.18. I have no 
>> luck with other verions, they are the worst in terms of
>> stability WHILE MOVING BIG FILES."
>>
>> http://ubuntuforums.org/showthread.php?t=844005
>>
> 
> No doubt Vista is far more effective at moving large files,
> as it only moves them half as fast.  ;-)

The topic is about Linux not Vista.
You seem to have a fixation with Vista for some reason Ghost.


-- 
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/
0
brick_n_straw (4058)
7/14/2008 11:05:15 PM
On 2008-07-14, The Ghost In The Machine <ewill@sirius.tg00suus7038.net> wrote:
> In comp.os.linux.advocacy, JEDIDIAH
><jedi@nomad.mishnet>
>  wrote
> on Mon, 14 Jul 2008 15:56:36 -0500
><slrng7nfc4.slq.jedi@nomad.mishnet>:
>> On 2008-07-14, Hadron <hadronquark@googlemail.com> wrote:
>>> JEDIDIAH <jedi@nomad.mishnet> writes:
>>>
>>>> On 2008-07-14, AZ Nomad <aznomad.3@PremoveOBthisOX.COM> wrote:
>>>>> On Mon, 14 Jul 2008 09:39:21 -0500, JEDIDIAH <jedi@nomad.mishnet> wrote:
>>>>>>On 2008-07-14, DFS <nospam@dfs_.com> wrote:
>>>>>>> Moshe Goldfarb. wrote:
>>>>>>>
>>>>>>>> It's just like the fonts issue, the wireless networking issue and a
>>>>>>>> 1000 other issues that Linux has or still has.
>>>>>
>>>>>>The "fonts issue" was overblown 10 years ago. Nevermind today.
>>>>> You have to feel sorry for flatty and dumbfuck.  They're still running at
>>>>> 640x480 resolution as they can't figure out how to set a higher resolution.
>>>>
>>>>     That is the origin of this nonsense.
>>>>
>>>>     Back when PCs were running 640x480 @ 14", Unix workstations were running 
>>>> 1280x1024 @ 19". Even with the coder-centric extras, the success of a font
>>>> ultimately has more to do with the artist than the coder.
>>>
>>> Sure - if the system has properly registered the font and made it
>>> available in the DE of choice. Sadly, too many times, this was NOT the
>>
>>      Fonts are registered at the level of X, not the desktop.
>
> Not 100% sure of that, though I do wonder how the Gnome
> font requester is actually implemented.  X has some weird
> hacks in there, as it was designed before TrueType.

....I can't say that I've been forced to find out really.

>
>>
>>      If you have a font "properly registered" than it can be used by
>> an Xaw application. Nevermind "desktops".
>
> I doubt Xaw would work 100% with a font specification such as
>
>    -adobe-courier-bold-r-normal--0-0-100-100-m-0-iso10646-1

Been there, did that... ages ago.

>
> but then, I'm not sure one should be using that particular
> font spec anyway; it's a placeholder.  It turns out X fonts
> are a bit of a historical mess; see for instance
> http://www.faqs.org/faqs/fonts-faq/part15/

As ugly as dealing with X fonts are manually, there's no reason
they can't be percieved as being as "smooth" as their Windows
counterparts. The whole point of an OS is to "hide the ugly".

>
> This does not preclude their usefulness, of course, and most
> people don't use raw X11 font handling anyway, but go through
> something like cairo or pango, or higher level.  There are some
> issues regarding proper string handling for UTF-8.
>
>>
>>> case in LINUX  - *hence* the plethora of how tos and fixes.
>>>
>>> Don't deny it was a mess. In some cases it still is.
>>
>>      When't the last time you installed a 3rd party font in Windows
>> by yourself manually? How did you do it? If you can't describe this
>> process off the top of you're head then you are just blowing a lot
>> of hot air.
>>
>
> I would think third party fonts are click-and-go, much like the rest of
> Windows software.  Then again, I've not tried it either.


-- 
	Apple: because TRANS.TBL is an mp3 file. It really is!      |||
								   / | \

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------       
                http://www.usenet.com
0
jedi (14753)
7/14/2008 11:15:41 PM
In comp.os.linux.advocacy, Moshe Goldfarb.
<brick_n_straw@gmail.com>
 wrote
on Mon, 14 Jul 2008 19:05:15 -0400
<1qlbdef8zi5d8$.1i2du6mo0jhbe$.dlg@40tude.net>:
> On Mon, 14 Jul 2008 08:46:34 -0700, The Ghost In The Machine wrote:
>
>> In comp.os.linux.advocacy, DFS
>> <nospam@dfs_.com>
>>  wrote
>> on Fri, 11 Jul 2008 23:46:09 -0400
>> <TMVdk.13994$1I.7867@bignews4.bellsouth.net>:
>>> "Hardy just cannot cope with big file moving on MY SYSTEM.
>>> I tried moving a file of 1 Gig and the whole system just
>>> froze. Only 1 out of 5 or 6 can be successful without
>>> crashing. I am running my STABLEST 2.6.24.18. I have no 
>>> luck with other verions, they are the worst in terms of
>>> stability WHILE MOVING BIG FILES."
>>>
>>> http://ubuntuforums.org/showthread.php?t=844005
>>>
>> 
>> No doubt Vista is far more effective at moving large files,
>> as it only moves them half as fast.  ;-)
>
> The topic is about Linux not Vista.
> You seem to have a fixation with Vista for some reason Ghost.
>

Are we not allowed to discuss the performance of competitive solutions?

-- 
#191, ewill3@earthlink.net
Windows Vista.  It'll Fix Everything(tm).
** Posted from http://www.teranews.com **
0
ewill5 (11075)
7/15/2008 6:39:11 PM
On Jul 13, 7:49 pm, Bob Hauck <postmas...@localhost.localdomain>
wrote:
> On Sun, 13 Jul 2008 04:21:28 -0700 (PDT), Rex Ballard
>
> <rex.ball...@gmail.com> wrote:
> > It depends on which file system and which architecture is being used.
> > Ext2 file systems don't like big files, Reiser, Ext3, and JFS can
> > handle 2^64 length files.
>
> If his problem was the file size itself, it would fail at 2 GiB - 1
> bytes, or at 4 GiB, not at one GiB.  However, all modern Linux
> filesystems support > 4 GiB files.
>
> What ext2/3 doesn't like is big directories, ones with tens of thousands
> or more files.  It will create and use such directories, but becomes
> very slow at certain operations.
>
> Reiser was designed to better handle this situation, especially for the
> common case of lots of small files.  There are tradeoffs of course, it
> is not the case that ReiserFS is "better" than ext3 for all use cases.
>
> > It also depends on whether you need to seek or not.  Seek on 32 bit
> > file systems is 2^32 bits where seek on 64 bit file systems is 2^64
> > bits.
>
> Not if the program was compiled with large file support, which has been
> available since the 2.4 kernel.  Most distros compile their apps with
> this enabled.
>
> > There are also library options that can be compiled in that will give
> > you 64 bit seek on a 32 bit OS, but you have to compile the 64 bit
> > library, and then specify the 64 bit library in your makefile or link
> > command.



> Um, no, that's false.  All you need is "gcc -D_FILE_OFFSET_BITS=64" and
> then ensure that you use off_t instead of int for specifying the offset
> in calls to the seek functions.

Which makes me suspect that the WinTroll who wrote this "impartial"
article, might not have been using the cp command, but instead, his
own custom written "copy" command.

> You can also explicitly ask for large file support with the O_LARGEFILE
> flag to open().

Making me even more suspicious that the author wasn't using a
"standard" copy utility like cp.

When I've done benchmarks copying a 7200 RPM internal drive to a 7200
RPM external USB drive, Windows XP have me average speeds of around
300 Kbytes per second.  Linux, with EXT3 file systems gave me average
speeds of around 1200 kbytes per second.  The speed was limited by the
rotational speed of the drives as well as the lack of striping.

When using Linux with a SAN array, the speed can increase to almost 40
megabytes per second, but much of that is the SAN array doing the
work, caching huge buffers, often several megabytes during each
rotation of the disk and writing a whole "cylinder" at a time (many
drives now have no relationship to the dimensions specified in LBA.
For example, the LBA says 63 SPT, 255 tracks per cylinder, but the
real geometry is more like 4000 sectors per track, and 4 tracks per
cylinder, with the ability to write all 4 tracks concurrently.  This
is why SATA and SAS drives have those 16 megabyte buffers.


> --
>  -| Bob Hauck
>  -|http://www.haucks.org/

0
rex.ballard (3732)
7/15/2008 7:52:21 PM
On Tue, 15 Jul 2008 11:39:11 -0700, The Ghost In The Machine wrote:

> In comp.os.linux.advocacy, Moshe Goldfarb.
> <brick_n_straw@gmail.com>
>  wrote
> on Mon, 14 Jul 2008 19:05:15 -0400
> <1qlbdef8zi5d8$.1i2du6mo0jhbe$.dlg@40tude.net>:
>> On Mon, 14 Jul 2008 08:46:34 -0700, The Ghost In The Machine wrote:
>>
>>> In comp.os.linux.advocacy, DFS
>>> <nospam@dfs_.com>
>>>  wrote
>>> on Fri, 11 Jul 2008 23:46:09 -0400
>>> <TMVdk.13994$1I.7867@bignews4.bellsouth.net>:
>>>> "Hardy just cannot cope with big file moving on MY SYSTEM.
>>>> I tried moving a file of 1 Gig and the whole system just
>>>> froze. Only 1 out of 5 or 6 can be successful without
>>>> crashing. I am running my STABLEST 2.6.24.18. I have no 
>>>> luck with other verions, they are the worst in terms of
>>>> stability WHILE MOVING BIG FILES."
>>>>
>>>> http://ubuntuforums.org/showthread.php?t=844005
>>>>
>>> 
>>> No doubt Vista is far more effective at moving large files,
>>> as it only moves them half as fast.  ;-)
>>
>> The topic is about Linux not Vista.
>> You seem to have a fixation with Vista for some reason Ghost.
>>
> 
> Are we not allowed to discuss the performance of competitive solutions?

Sure, but when the person says Linux does xxxxxyyyzz it's far better to
rebut the accusation than say, "so what Vista does zzzzyyyyxxx"...

-- 
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/
0
brick_n_straw (4058)
7/16/2008 1:51:00 AM
Reply: