Are you using a browser to download files over HTTP? Most browsers have horrible resume support. Try something like GetRight (for Windows) or even wget -c. I've never run into a problem with those but I wouldn't trust Firefox to handle a large download correctly.
Torrents are pretty nifty, but they're more complicated to support (need a seeder, etc) and much less reliable over slow connections. Generating SHA1 hashes for a 2GB file takes a while, so you can't just drop a file in the web directory and serve it immediately.
The size of the company plays a part, though. If IBM or General Motors stops buying ads in a newspaper, it'll hurt, but probably not enough to convince the newspaper to significantly edit its content to appease corporations -- well, no more than usual, anyways. Likewise, Apple is not a major seller of computer books, even in the context of Mac-related books, so I wouldn't think it would have a big effect on Wiley.
But when you get to a point where a boycott could do serious damage -- which tends to be the point of a boycott, although this case is more symbolic than anything -- then I'd say there ought to be a really good reason for it.
Even if all a kids learns in a computer class is that to switch x and y one has to write z=x,x=y, y=x, that is such a fundamental concept that it is time well spent.
Of course, it could potentially confuse them more, since = is used in math for equality, but = means assignment in programming (at least for the most popular languages.)
True, but in Python you have things like sort() built-in to the language instead of writing it yourself or getting a third-party library. A natural programming language will probably have even more built-in generic functions.
And it's not like you need a really fast computer when 95% of the time the program is sitting around waiting for user input. Obviously, not everything should be written in an interpreted language, but for some things it really doesn't matter how fast it goes.
I don't think it would be that bad. It'd be akin to using a higher-level language like Python, where you don't care how something is sorted when you call list.sorted(), just that it's sorted. Some people think that Python is horribly inefficient, but it turns out that even 100x slower than C isn't too bad for many applications.
Well, GAIM and DeadAIM both archive IMs and let you search through them. They could probably add a full-text search if people were actually interested in that.
Re:not violate the copyrights on their students' w
on
Cheating Made Easy
·
· Score: 1
Our school uses TurnItIn.com but also has an opt-out option that involves extra work. The alternate option doesn't seem worth the trouble though.
Okay, let's look at System 7.5 running on a 100 mhz PPC. Not quite as fast as System 6, but could use 24-bit color, watch videos, play MP3s, surf the web, render PDFs, use instant messaging, compose home movies, download photos from a camera. Consumer DVD/CD-R burning didn't exist back then.
I set up Basillisk II (a 68k emulator) and had it run Mac OS 7.6 on a 633 mhz Celeron. Absolutely blazing fast.
It wasn't perfect, of course. And the lack of preemptive multitasking, memory protection, journaling filesystems wasn't so great -- although it could have been done back then if they chose to. But there isn't that much we can do now that couldn't be done on OS 7 -- if the hardware were up to the job, at least. Not bad for something nearly a decade old.
A better statement is that the programs had fewer features then. No videoconferencing over IM systems or revision-tracking word processors. No super-complicated Javascript+DOM stuff in browsers.
I think a big reason why software is slower today is flexibility, compatibility, and programmer time. Software on the Classic Mac OS didn't make much use of non-system libraries. Changing stuff in the system involved writing extensions that would override code in the system ROM. Making your own window decoration and widget styles involved clever hacks. Handles required locking and unlocking code to manage memory efficiently.
Nowadays, we have widget toolkits, which -- as mentioned elsewhere in this discussion -- require tons of libraries. Abstraction everywhere. C++, Java, C#, Objective-C, Perl, Python, etc. Preemptive multitasking has overhead. Compatibility layers and emulators. No more hand-written assembly or highly-optimized graphics tricks -- well, except in games. All of this to make the programmers' lives easier, and get a product done quicker. Which is good, because software is pretty cheap now. And we get a lot of useful features.
You still only have one connection open. Pipelining just says, "I want this list of URIs" and the server returns the pages in order -- over the same persistant connection that a non-pipelined request would take place. I don't see that as hogging connections.
Gmail has an attachment size limit. Around 10 megabytes I think, so that'll get you around 2-3 MP3s. I don't know if you can get around that with multiple emails.
The screenshots look incredibly ordinary. No emulated Windows programs, or even anything that looks remarkably different from Fedora Core. It doesn't look that much easier to use either.
We'll see how useful it really is when the reviews come out.
From a societal point of view, nobody cares, because the person that came out of the transporter acts just like you and thinks everything worked just fine.
Barring those aliens with extradimensional senses, you wouldn't know if it actually killed the person or not just as nobody knows what happens after death.
Write support is (supposedly) safe, because it will *only* let you do things that are safe. Pretty much limited to writing to an existing file without changing the size.
Slashdot Mirror
Are you using a browser to download files over HTTP? Most browsers have horrible resume support. Try something like GetRight (for Windows) or even wget -c. I've never run into a problem with those but I wouldn't trust Firefox to handle a large download correctly.
Torrents are pretty nifty, but they're more complicated to support (need a seeder, etc) and much less reliable over slow connections. Generating SHA1 hashes for a 2GB file takes a while, so you can't just drop a file in the web directory and serve it immediately.
The size of the company plays a part, though. If IBM or General Motors stops buying ads in a newspaper, it'll hurt, but probably not enough to convince the newspaper to significantly edit its content to appease corporations -- well, no more than usual, anyways. Likewise, Apple is not a major seller of computer books, even in the context of Mac-related books, so I wouldn't think it would have a big effect on Wiley.
But when you get to a point where a boycott could do serious damage -- which tends to be the point of a boycott, although this case is more symbolic than anything -- then I'd say there ought to be a really good reason for it.
Even if all a kids learns in a computer class is that to switch x and y one has to write z=x,x=y, y=x, that is such a fundamental concept that it is time well spent.
Of course, it could potentially confuse them more, since = is used in math for equality, but = means assignment in programming (at least for the most popular languages.)
Anyone else remember that Dr. Who episode Inferno, with the drilling project and infectious goo?
Bad HTML there. http://flashblock.mozdev.org/
Use flashblock.
If I remember correctly, Tanenbaum also said the x86 was going to die soon enough too.
True, but in Python you have things like sort() built-in to the language instead of writing it yourself or getting a third-party library. A natural programming language will probably have even more built-in generic functions.
And it's not like you need a really fast computer when 95% of the time the program is sitting around waiting for user input. Obviously, not everything should be written in an interpreted language, but for some things it really doesn't matter how fast it goes.
I don't think it would be that bad. It'd be akin to using a higher-level language like Python, where you don't care how something is sorted when you call list.sorted(), just that it's sorted. Some people think that Python is horribly inefficient, but it turns out that even 100x slower than C isn't too bad for many applications.
It might be a little rigid, but not necessarily that bad. HyperTalk goes:
put the sum of var1 and var2 into varX
or:
set varX to the sum of var1 and var2
or:
add var1 and var2
put the result into varX
The Roomba Defender?
Could always order online and ship to the U.S. Embassy of your choice.
Well, GAIM and DeadAIM both archive IMs and let you search through them. They could probably add a full-text search if people were actually interested in that.
Our school uses TurnItIn.com but also has an opt-out option that involves extra work. The alternate option doesn't seem worth the trouble though.
Okay, let's look at System 7.5 running on a 100 mhz PPC. Not quite as fast as System 6, but could use 24-bit color, watch videos, play MP3s, surf the web, render PDFs, use instant messaging, compose home movies, download photos from a camera. Consumer DVD/CD-R burning didn't exist back then.
I set up Basillisk II (a 68k emulator) and had it run Mac OS 7.6 on a 633 mhz Celeron. Absolutely blazing fast.
It wasn't perfect, of course. And the lack of preemptive multitasking, memory protection, journaling filesystems wasn't so great -- although it could have been done back then if they chose to. But there isn't that much we can do now that couldn't be done on OS 7 -- if the hardware were up to the job, at least. Not bad for something nearly a decade old.
A better statement is that the programs had fewer features then. No videoconferencing over IM systems or revision-tracking word processors. No super-complicated Javascript+DOM stuff in browsers.
I think a big reason why software is slower today is flexibility, compatibility, and programmer time. Software on the Classic Mac OS didn't make much use of non-system libraries. Changing stuff in the system involved writing extensions that would override code in the system ROM. Making your own window decoration and widget styles involved clever hacks. Handles required locking and unlocking code to manage memory efficiently.
Nowadays, we have widget toolkits, which -- as mentioned elsewhere in this discussion -- require tons of libraries. Abstraction everywhere. C++, Java, C#, Objective-C, Perl, Python, etc. Preemptive multitasking has overhead. Compatibility layers and emulators. No more hand-written assembly or highly-optimized graphics tricks -- well, except in games. All of this to make the programmers' lives easier, and get a product done quicker. Which is good, because software is pretty cheap now. And we get a lot of useful features.
No, it's more like: this software distributes its source code to anyone who wants it, and you are not allowed to interfere with that.
You still only have one connection open. Pipelining just says, "I want this list of URIs" and the server returns the pages in order -- over the same persistant connection that a non-pipelined request would take place. I don't see that as hogging connections.
There's an advisory listed on dot.kde.org that seems similar, although not as bad.
The fact that they're purging backup tapes is pretty impressive already. Do we know that Hotmail/Yahoo do that?
Gmail has an attachment size limit. Around 10 megabytes I think, so that'll get you around 2-3 MP3s. I don't know if you can get around that with multiple emails.
I'm curious how GPUs stack up against the Altivec engine in G4/G5s.
The screenshots look incredibly ordinary. No emulated Windows programs, or even anything that looks remarkably different from Fedora Core. It doesn't look that much easier to use either.
We'll see how useful it really is when the reviews come out.
Jabber + voice chat would be awesome.
From a societal point of view, nobody cares, because the person that came out of the transporter acts just like you and thinks everything worked just fine.
Barring those aliens with extradimensional senses, you wouldn't know if it actually killed the person or not just as nobody knows what happens after death.
Write support is (supposedly) safe, because it will *only* let you do things that are safe. Pretty much limited to writing to an existing file without changing the size.
So it's not really full NTFS write support yet.