ssh sucks for bulk data transfer. it is *not at all optimized* for such a use. its intended primarily for interactive traffic or low bandwidth (read: internet connection speed) traffic.
for bulk data transfer over high speed networks it blows chunks not only due to the crypto speed but also due to data buffering issues, loads upon loads of data copies (scp and sftp send all data through at least one local pipe with tiny buffers if not more), etc. the crypto dominates, but even with "-c none" its efficiency blows chunks.
and don't advocate tunneling over ssh as a solution either. TCP over TCP is a bad idea.
and if the target is a supercomputer or data center machine it probably -does not- have the CPU cycles to deal with the encryption overhead of such a large data transfers...
the benefit of the Athlon-64 / Opteron is that it is a blazingly fast x86 (32bit) CPU as well as having 64-bit stuff.
64bit code will be larger and gcc is currently much worse at generating code for x86-64. Only compile things that actually show a benefit from it as 64bit native if speed is what you desire.
i leave my monthly subscription going and log in to emusic once every 3-4 months and download 10-15 albums. now i can't do this. despite it being roughly the same number of tracks. *sigh*
PS - users should to keep in mind that emusic is watermarking all tracks you download using their download manager. The watermarking happens on the client side by the emusicdlm program itself. It also breaks several frames in the mp3.
The mp3s are downloaded unencrypted http from mp3.com with a unique (per user presumably) time-limited URL; a smart http proxy can download the unwatermarked versions for you.
since when is a web interface considered less easy to implement than a telnet command line interface? sheesh. web interfaces aren't usable over serial. implement them as client software, not on the device.
can they host concerts, publish parts of their album and art on the net with the rest available for download after paying $4? what compensation do the kids who create albums get if the teacher decides that theirs has not been distributed on the net?
make it real.
artists starve because they sign bad contracts and don't connect with the consumer directly for money and suupport. not because of internet piracy.
need to "keep honest people honest" (from the slides) huh?
Do you think an honest person would choose to buy your content under the rediculious "licensing" provisions most providers will use if they had any choice in the matter?
What we really *need* is to "keep honest monopolies honest"
^monopolies^governments
etc..
those slides are amateurish in content with no real value other than to promote CE makers buying extra intel cpus to put in their devices to no useful end.
i won't bother to buy or play a game that doesn't let me save my progress reasonably. i have a life in the *real world*. games are for entertainment value. if you blame save-games for letting you cheat to avoid a challenge than you're an undisciplined dimwit who probably drives SUVs up 14,000 foot mountains and wonders why hikers piss on your "car" when you get there.
it works just fine. the issue you're bringing up is glibc, not the filesystem. you need to be using glibc >=2.2. its really really pathetic that glibc versions prior to that did not define size_t as a 64 bit value. the bsds have been doing that for ages.
any correctly written application compiled with a glibc >=2.2 will support large files.
windows sucks. FAT32 can't have files larger than 2gb and its allocation unit is *FUCKING HUGE*. You can experiment with ext2 access programs and drivers for windows, etc. but they're not quite up to snuff yet. If you do that; create a small FAT partition containing the drivers for various OSes, and make the remaining partition ext2.
(why ext2 and not ext3? many tools for other OSes can't handle ext3)
how do you put this under the xmas tree, wrap as a birthday present or give to someone without good internet access?
all of those are reasons for retail boxes. if a publisher would wake up and not demand exclusive rights, they could sell a happy retail box of this for $10 more than the online version.
as being a bit too hackish and randomly thrown together.
unfortunate in many ways but it wasn't ready for the task. BK was designed specifically with Linus's job in mind because Larry was smart enough to realize that there are 1000s of Linus's out there doing the same job on projects in the hidden commercial software world.
its really that simple. If you don't like BKs license or author or whatnot, don't use it.
As long as it makes patch sets available that don't require anything more than ftp and patch, linus can continue to use it without preventing anyone from getting at the code trees.
Claiming that you have a right to use it because you really really need it and it started out so close to open source is no better than a crack addict whining, "but the first one was free!"
no. the first one wasn't free. BK has never had an open source licese. Now there are tons of tainted people who are forbidden by Grand Moof McVoy from ever writing a SCM in their entire life. And you know what? It was their own stupid mistake to limit themselves as such.
The Mitsubishi DiamondPro 900U (diamondfoo, whatever) has a built in usb hub and two usb upstream ports that it switches between when you switch between the BNC & VGA inputs via the simple button on the front.
only works for a two systems; but if that's all you need this is seriously convenient.
better hope windows doesn't whine about "you unplugged a device without asking me first" though. don't put anything other than your keyboard/mouse on its hub.
and kiss some chance of configuring your BIOS goodbye as many BIOSes won't support USB keyboards connected to a hub (this is a bios not being usb compliant problem). better off having a real keyboard on hand for bios config.
i hate multi disc CD players and multi album mp3 players that have a "random" mode that doesn't have the ability to treat it as "random album" rather than switching albums all of the time. many albums are best listened to in order.
however that doesn't mean good singles don't exist and stand on their own.
why aren't they protesting the fact that clearchannel only plays a single song from an album at once if they ever actually play more than one from an album at all?
Slashdot Mirror
ssh sucks for bulk data transfer. it is *not at all optimized* for such a use. its intended primarily for interactive traffic or low bandwidth (read: internet connection speed) traffic.
for bulk data transfer over high speed networks it blows chunks not only due to the crypto speed but also due to data buffering issues, loads upon loads of data copies (scp and sftp send all data through at least one local pipe with tiny buffers if not more), etc. the crypto dominates, but even with "-c none" its efficiency blows chunks.
and don't advocate tunneling over ssh as a solution either. TCP over TCP is a bad idea.
and if the target is a supercomputer or data center machine it probably -does not- have the CPU cycles to deal with the encryption overhead of such a large data transfers...
the benefit of the Athlon-64 / Opteron is that it is a blazingly fast x86 (32bit) CPU as well as having 64-bit stuff.
64bit code will be larger and gcc is currently much worse at generating code for x86-64. Only compile things that actually show a benefit from it as 64bit native if speed is what you desire.
i leave my monthly subscription going and log in to emusic once every 3-4 months and download 10-15 albums. now i can't do this. despite it being
roughly the same number of tracks. *sigh*
PS - users should to keep in mind that emusic is watermarking all tracks you download using their download manager. The watermarking happens on the client side by the emusicdlm program itself. It also breaks several frames in the mp3.
The mp3s are downloaded unencrypted http from mp3.com with a unique (per user presumably) time-limited URL; a smart http proxy can download the unwatermarked versions for you.
you used "XML" and "could this get rid of speed problems" in the same sentence.
not only are the two DIAMETRICALLY OPPOSED you show no evidence of X having serious speed problems.
since when is a web interface considered less easy to implement than a telnet command line interface? sheesh. web interfaces aren't usable over serial. implement them as client software, not on the device.
can they host concerts, publish parts of their album and art on the net with the rest available for download after paying $4? what compensation do the kids who create albums get if the teacher decides that theirs has not been distributed on the net?
make it real.
artists starve because they sign bad contracts and don't connect with the consumer directly for money and suupport. not because of internet piracy.
replace the burnt out capacitor
need to "keep honest people honest" (from the slides) huh?
Do you think an honest person would choose to buy your content under the rediculious "licensing" provisions most providers will use if they had any choice in the matter?
What we really *need* is to "keep honest monopolies honest"
^monopolies^governments
etc..
those slides are amateurish in content with no real value other than to promote CE makers buying extra intel cpus to put in their devices to no useful end.
ssh tunnels are very bad performance. what you want is a VPN.
unfortunately you can't replace the kernel on the box with one that supports cool things because of the proprietary broadcom driver.
(here's to whoever takes the time to write a thunking layer for the linksys 2.4.5 broadcom driver to let it work with modern 2.4.22+ kernels!)
i won't bother to buy or play a game that doesn't let me save my progress reasonably. i have a life in the *real world*. games are for entertainment value. if you blame save-games for letting you cheat to avoid a challenge than you're an undisciplined dimwit who probably drives SUVs up 14,000 foot mountains and wonders why hikers piss on your "car" when you get there.
it works just fine. the issue you're bringing up is glibc, not the filesystem. you need to be using glibc >=2.2. its really really pathetic that glibc versions prior to that did not define size_t as a 64 bit value. the bsds have been doing that for ages.
any correctly written application compiled with a glibc >=2.2 will support large files.
windows sucks. FAT32 can't have files larger than 2gb and its allocation unit is *FUCKING HUGE*. You can experiment with ext2 access programs and drivers for windows, etc. but they're not quite up to snuff yet. If you do that; create a small FAT partition containing the drivers for various OSes, and make the remaining partition ext2.
(why ext2 and not ext3? many tools for other OSes can't handle ext3)
how do you put this under the xmas tree, wrap as a birthday present or give to someone without good internet access?
all of those are reasons for retail boxes. if a publisher would wake up and not demand exclusive rights, they could sell a happy retail box of this for $10 more than the online version.
actually I believe Arch was the package i was thinking of as being dismissed. ignore the above post. nothing to read here. move along.
as being a bit too hackish and randomly thrown together.
unfortunate in many ways but it wasn't ready for the task. BK was designed specifically with Linus's job in mind because Larry was smart enough to realize that there are 1000s of Linus's out there doing the same job on projects in the hidden commercial software world.
its really that simple. If you don't like BKs license or author or whatnot, don't use it.
As long as it makes patch sets available that don't require anything more than ftp and patch, linus can continue to use it without preventing anyone from getting at the code trees.
Claiming that you have a right to use it because you really really need it and it started out so close to open source is no better than a crack addict whining, "but the first one was free!"
no. the first one wasn't free. BK has never had an open source licese. Now there are tons of tainted people who are forbidden by Grand Moof McVoy from ever writing a SCM in their entire life. And you know what? It was their own stupid mistake to limit themselves as such.
and admit that c++ was all a mistake. demand a full apology!
don't read just one popular program and assume that its a good representation of how to do things in the language.
yes, as those who've tried "it" have found, it apparently doesn't deserve to be called a driver at all.
i guess when you use google to search for something that doesn't exist and it returns the vapor.
they earn more by forcing the question to be asked even though they know the answer.
http://team.vantronix.net/ar5k/ is a linux driver for these chipsets as well.
More at 11.
The Mitsubishi DiamondPro 900U (diamondfoo, whatever) has a built in usb hub and two usb upstream ports that it switches between when you switch between the BNC & VGA inputs via the simple button on the front.
only works for a two systems; but if that's all you need this is seriously convenient.
better hope windows doesn't whine about "you unplugged a device without asking me first" though. don't put anything other than your keyboard/mouse on its hub.
and kiss some chance of configuring your BIOS goodbye as many BIOSes won't support USB keyboards connected to a hub (this is a bios not being usb compliant problem). better off having a real keyboard on hand for bios config.
you can't make 'em buy it.
i hate multi disc CD players and multi album mp3 players that have a "random" mode that doesn't have the ability to treat it as "random album" rather than switching albums all of the time. many albums are best listened to in order.
however that doesn't mean good singles don't exist and stand on their own.
why aren't they protesting the fact that clearchannel only plays a single song from an album at once if they ever actually play more than one from an album at all?
so what if stupid consumers are led to think that usb hard drives and cd drives suck?
that just means 1394 will become much more common.