My Time Warner connection is the opposite, I get 60KB/s for maybe 30 seconds, then it zooms up to 400-600 KB/s whatever my limit is. It's like this for every single http transfer, I only notice it when the actual transfer speeds are reported by the software, not the average speed that's typical.
I hope you got a hell of a deal on that standalone BRD player... My PS3 wakes up and loads/ejects a disc in 2 or 3 seconds. The movie starts in 25 seconds. That's powered off, shoving a disc in, waking up automatically, loading it, and playing movie with auto-start on. No auto-start would take a few extra seconds to navigate the menu manually.
On the other hand, I hope you got a hell of a good deal on that HD-DVD player also, because 2 minutes really sucks.
The more advantage one takes of library functions, however, the more advantage one will get out of the hardware if it appears underneath the software. I kind of touched on that in my other post. If the OS strictly controlled the SPU, and offered several commonly used programs, it could host them just like shared libraries. Applications could take turns sending data to the same SPU, using the same program. The OS would have to decide how many SPUs to allocate to a given program or which programs to run if all SPU's are booked. Current multithreaded math libraries probably would be ideal candidates for Cell optimization though.
when all your game consoles, televisions, PCs, digital cameras, and so on can contribute their unused processing time and their particular features to most efficiently achieve your work. I can't find the articles anywhere, but I think I remember the early Cell marketing literature having these crazy diagrams with game consoles, PC's, TV's etc, all working together like one big machine. I thought it was a bunch of crap, but now I understand the architecture better, and with some cluster glue like you mentioned it really could be possible. Obviously there are latencies involved, but one Cell processor at the other end of a Gig-E connection could encode MP3's at an ungodly rate =)
hardening it into a 1/4" plate steel box on a 4x6 I-beam, mounted into a 500-pound footing I grew up in rural Maine, and those are meant to protect mail from snowplows, not baseball bats or thieves. Really, identity thieves in rural Maine? We rarely even lock our front doors. Let me guess, the I-beam protrudes quite a ways out from the base towards the road too, huh? You think that was to save it from a drive-by and a teen with long arms and a welding torch?
Sometimes you see splinters on it, shards of a Louisville Slugger in the ditch Ever seen a mailbox hit by a snowplow?
You new to Maine or are you the one smashing people's "secured" mailboxes?;)
Your post really got me thinking about how a standard desktop OS WOULD take advantage of an architecture like the Cell (I mentioned in my last post that they currently don't). For applications that offload work to the GPU, it's fairly simple, the logged on user already has full access to the video card basically. Now if we have several coprocessors with no specific function attached to them, how should the OS provision them on a multiuser system? Should applications be allowed to request free SPU's in a cooperative multitasking manner and directly write programs to them? I'm not too familiar with the lower level workings of the Cell, but maybe the OS could implement task switching on the SPUs in a preemptive multitasking fashion. Or, should only the OS be able to write SPU programs, enabling it to share common programs with multiple applications at once. That last one raises additional questions like how does the OS decide to distribute SPU program requests among available SPU's, and do you stall when all SPU's are in use, or is it worth swapping programs in and out of them on the run?
These things could all be done with current SMP systems, but aren't. Instead only general purpose threading support is provided and it's up to each application to decide what the heck to use a thread for. This is why we have almost nothing that can automatically scale to a variable number of processors, besides the OS itself. That's why I'm a little doubtful that existing software would benefit in the short-term from something like the Cell. There are frameworks that could already be in place but aren't, yet people whine and complain about how hard multi-threaded programming and Cell programming is. Helllloooooooooo! Sorry, I guess I should write them myself before running my mouth off...
A normal multithreaded application isn't going to magically run parallelized on a Cell BE. Currently they only have one general purpose CPU with a number of specialized coprocessors.
So, yes, many applications use SMP to do parallel work, but few of those do it in a way that makes sense on a Cell BE. IOW, merely running the audio subsystem of a game in a separate thread won't scale to a system with specialized coprocessors.
Do you think there are many threaded applications out there that use a model where the main logic is in one thread that farms data out to threads on other processors to crunch data in bulk? Standard OS's do not use this model, they only make use of multiple identical processors. Well, unless you count an accelerated graphics system, because a GPU is used this way. How many applications today could take advantage of having several coprocessors without a significant amount of work? Probably just a handful of experimental ones that try to offload work onto the GPU.
From TFA:
The labels contend that the music publishers have gotten fat as their business has starved and want the payment method rewritten. According to papers filed by the RIAA at the Copyright Royalty Board, the labels want the board to reduce the rate to 8% of wholesale revenue. The current rate is about 9 cents per song, but it often is lowered in negotiations with the record companies. That money usually is split 50-50 between the publisher and the songwriter. and
"Record companies are suffering a contraction of their business at a time when music publisher revenues and margins have increased markedly," the trade group wrote. "While record companies have been forced to drastically cut costs and employees, music publisher catalogs have increased in value due to steadily rising mechanical royalty rates and alternative revenue streams made possible, but not enjoyed, by record companies." So to be clear, we're not talking about the artist's cut, we're talking about the publisher's and songwriter's?...and the publishers are the ones doing less work for internet downloads now right? I mean that's what you said. Did I miss the part in the article where anyone claims the ARTISTS should receive less in royalties? Songwriters even? Maybe the idea is that the publisher shouldn't be taking a 50/50 cut for something marketed & sold by Apple and on iTunes? The labels couldn't just come out and say that as it's between the publishers and songwriters, but they can squeeze the publisher.
BTW, I just learned everything I know about the music industry from wikpedia in less than five minutes! To be fair though, the stupid/. summary & title set you all up.
I'm not even going to try answering that question.
Obviously a country that can send robots instead of soldiers to fight is way more likely to become 'war happy' - so I'm not sure this robot thing is a good idea at all. Hold on a minute, we're a tremendously long way away from replacing all, most, or any significant portion of soldiers on the field with robots. Even if it were the case, when the hell did robotic killing machines start coming cheap, and in infinite supply? The ability to fight at war will always depend on the amount of resources, efficiency, and a strong will (not only on the front lines).
Loss of life alone on the battlefield doesn't slow war. Loss of a means and will to fight does. Means to fight doesn't all of a sudden exclude able bodied men and women should whomever or whatever is on the front lines fail them. Switching out men for machines will be a very subtle change in the grand scheme of things, but it ought to lend to at least a slightly stronger will to fight.
I'm sure it will still work for you, and look as good as it ever has, but it seems from your post that you've never actually seen either high-def format on your equipment. The appeal isn't that DVDs suck (with upconversion they do alright), it's that the newer formats look better.
You still might be right about not "winning", but I think as long as newer, higher quality TV sets such as yours become more common place, the demand for better quality video will follow.
The difference with your failed audio formats here is that most people still listened to music with crappy headphones/earbuds/computer speakers, while on the video side, there IS a demand for higher quality displays. Who knows, maybe all the buzz surrounding home theater that HDTV is creating will also pave the way for new audio formats? Surround sound systems fit HDTVs like gloves.
It's hard for me to buy into this "neither format will win" meme unless HDTV is failing altogether. As it stands, downloadable HD, and even sat/cable HD doesn't stand up to Blu-ray/HD-DVD. In quality, not convenience anyway. I'll still rent DVDs from Redbox, download from iTunes, and buy Blu-ray all at the same time as long as they're available, for cost/convenience/quality reasons. It's a great time to be a movie addict! =)
This isn't the same deal as Microsoft killing Unix vendors, or software providers. Microsoft doesn't compete at all in the storage market, and EMC is a very strong (probably stronger) influence at the enterprise level. Microsoft also has to compete against _existing_ "poor man's" virtualization solutions, which even VMware already provides. Microsoft WILL have to make a better product to win this. Can they? They don't really have room for a ME or Vista in this case. They could drag it on for a while, but it'll wind up just like their console or portable music player efforts.
For instance, does "lower price for Windows Vista used on virtualized computers" apply to microsoft VPC only or to all hypervisors? If they don't want to be grilled by the DoJ about it, I think we know the answer.
Clearly this QT issue is a bug, not an intentional DRM limitation. Don't be a douche and play this like Apple INTENDED to disable AE due to DRM policy.
I also understand how useful dtrace can be, and while allowing processes to opt out of tracing is somewhat unfortunate from certain points of view, HOW does it make Apple as vile as you make them out to be?
Jobs isn't an angle, Apple is a business, they want your money. Tell us something we don't know. Their products speak for themselves, and the fact that they ported dtrace AT ALL says a lot. Apple's DRM policies and implementations are far less restricting than Microsoft's. I dare you to prove otherwise. Go ahead, bring out the worst of Leopard DRM against the worst of Vista DRM, lets compare right here and now.
I think he knew that already. The term we don't understand is "core stack". I've never heard of it either, but I think the parent post is on the right track with stack trace from a core dump. In this case, I'm fairly sure the origins of "core" are irrelevant and possibly misleading.
Perl 5 is a interpreter which happens to grok Perl 5. just "happens to"? It's pretty explicit. Does Perl 5 do anything else? Why not just say what you're really getting at, instead of redefining history.
Perl 6 is meant to run on a (Parrot) VM, whereas earlier versions of Perl were interpreted. From the looks of your link, it is being implemented outside the Parrot VM also.
Reading Perl, and comprehending the subtle differences between Solaris, Linux and Windows versions already gives me headaches, now there will be different implementations of each? Wow. I hope that works out.
What are you talking about? You do lose data anytime you overwrite tapes unless you backup something static. Data == point in time snapshot. How large your tape pool is determines how far back you can keep those.
If you are constantly adding new tapes to the system, that is another thing. You don't need to ever overwrite tapes in that case, so I don't know what you meant. You might copy an old tape to a new tape after a couple years or something, but not juggle them around.
With a fixed number of tapes, YOU LOSE DATA after X days.
Moosesocks is on the right track. Tape recycling is standard practice. The EOP (probably) didn't have a proper email archiving solution in place at the time. They have a very honest IT staff, and there's reason to believe they performed the best they could with the resources they had. They also wouldn't archive email if they weren't told to, so it's hard to call it negligence on the IT staff's part. At some point the requirement to archive mail one way or another apparently DID come down, so I have a hard time blaming upper levels as well. However, this "using RNC email for official business' stuff I keep hearing in the news IS negligence IMHO. I believe it was done BECAUSE the White House really did have good IT policy.
It is "Best Practice" to reuse backup tapes. They could have implemented email archival in a number of ways, separate from backup tape retention.
placed significant burdens on businesses The EOP on the other hand, pretty much writes it's own rules. Believe it.
Not saying this is all a good thing, but don't pin it on backup admins or politicians being savvy enough to understand how backup retention really works. Even when the policy from above is to keep for "three months", there is no guarantee that backups wont be kept longer than that.
AFAIK, they don't ever reuse tapes now, and haven't for the past couple years. They may or may not also have a separate email archiving system.
Remember, retention is only part of the problem. The archived email still has to be easily accessible, so relevant documents can be produced in a timely manner. A normal tape backup system, even with infinite retention, doesn't ensure this by itself.
I can't find any solid information on Remote Disc outside Apple's site. The demo video says it can be used to install new versions of OS X, so wouldn't that mean the disc has to be available at the EFI layer? I hope they don't just mean upgrades, and an install is impossible. The Air page says the Remote Disc software is used to do the wireless migrations that TDM used to be used for. Not the same thing as using TDM to fix a broken system, I know.
I think Firewire will be around at least as long as optical drives are, in Macs anyway. They must have been pressed for space in that little flip down panel. Check out the video, I thought it was just a plastic cover till they showed it. All three ports actually flip down.
Don't lose hope yet, it isn't quite clear how Remote Disc works. If Sun hardware can boot from NFS shares, I wouldn't toss out the idea of Apple pulling something similar off with EFI, wirelessly./shrug
Slashdot Mirror
My Time Warner connection is the opposite, I get 60KB/s for maybe 30 seconds, then it zooms up to 400-600 KB/s whatever my limit is. It's like this for every single http transfer, I only notice it when the actual transfer speeds are reported by the software, not the average speed that's typical.
I hope you got a hell of a deal on that standalone BRD player... My PS3 wakes up and loads/ejects a disc in 2 or 3 seconds. The movie starts in 25 seconds. That's powered off, shoving a disc in, waking up automatically, loading it, and playing movie with auto-start on. No auto-start would take a few extra seconds to navigate the menu manually.
On the other hand, I hope you got a hell of a good deal on that HD-DVD player also, because 2 minutes really sucks.
I hope Cell comes to desktops soon!
Cool, thanks for the link! Good to know there's a name for it. I hope it reaches the desktop someday.
Let me guess, the I-beam protrudes quite a ways out from the base towards the road too, huh? You think that was to save it from a drive-by and a teen with long arms and a welding torch? Sometimes you see splinters on it, shards of a Louisville Slugger in the ditch Ever seen a mailbox hit by a snowplow?
You new to Maine or are you the one smashing people's "secured" mailboxes?
Yuck, at that point, why not just implement secure access cards?
Your post really got me thinking about how a standard desktop OS WOULD take advantage of an architecture like the Cell (I mentioned in my last post that they currently don't). For applications that offload work to the GPU, it's fairly simple, the logged on user already has full access to the video card basically. Now if we have several coprocessors with no specific function attached to them, how should the OS provision them on a multiuser system? Should applications be allowed to request free SPU's in a cooperative multitasking manner and directly write programs to them? I'm not too familiar with the lower level workings of the Cell, but maybe the OS could implement task switching on the SPUs in a preemptive multitasking fashion. Or, should only the OS be able to write SPU programs, enabling it to share common programs with multiple applications at once. That last one raises additional questions like how does the OS decide to distribute SPU program requests among available SPU's, and do you stall when all SPU's are in use, or is it worth swapping programs in and out of them on the run?
These things could all be done with current SMP systems, but aren't. Instead only general purpose threading support is provided and it's up to each application to decide what the heck to use a thread for. This is why we have almost nothing that can automatically scale to a variable number of processors, besides the OS itself. That's why I'm a little doubtful that existing software would benefit in the short-term from something like the Cell. There are frameworks that could already be in place but aren't, yet people whine and complain about how hard multi-threaded programming and Cell programming is. Helllloooooooooo! Sorry, I guess I should write them myself before running my mouth off...
A normal multithreaded application isn't going to magically run parallelized on a Cell BE. Currently they only have one general purpose CPU with a number of specialized coprocessors.
So, yes, many applications use SMP to do parallel work, but few of those do it in a way that makes sense on a Cell BE. IOW, merely running the audio subsystem of a game in a separate thread won't scale to a system with specialized coprocessors.
Do you think there are many threaded applications out there that use a model where the main logic is in one thread that farms data out to threads on other processors to crunch data in bulk? Standard OS's do not use this model, they only make use of multiple identical processors. Well, unless you count an accelerated graphics system, because a GPU is used this way. How many applications today could take advantage of having several coprocessors without a significant amount of work? Probably just a handful of experimental ones that try to offload work onto the GPU.
ALL of these processors don't go to Sony, IBM has other uses.
I wish we could moderate you "+100, delete all other posts, close thread, next article please"
BTW, I just learned everything I know about the music industry from wikpedia in less than five minutes! To be fair though, the stupid
Methinks 'plays media' would be the primary concern.
Loss of life alone on the battlefield doesn't slow war. Loss of a means and will to fight does. Means to fight doesn't all of a sudden exclude able bodied men and women should whomever or whatever is on the front lines fail them. Switching out men for machines will be a very subtle change in the grand scheme of things, but it ought to lend to at least a slightly stronger will to fight.
I'm sure it will still work for you, and look as good as it ever has, but it seems from your post that you've never actually seen either high-def format on your equipment.
The appeal isn't that DVDs suck (with upconversion they do alright), it's that the newer formats look better.
You still might be right about not "winning", but I think as long as newer, higher quality TV sets such as yours become more common place, the demand for better quality video will follow.
The difference with your failed audio formats here is that most people still listened to music with crappy headphones/earbuds/computer speakers, while on the video side, there IS a demand for higher quality displays. Who knows, maybe all the buzz surrounding home theater that HDTV is creating will also pave the way for new audio formats? Surround sound systems fit HDTVs like gloves.
It's hard for me to buy into this "neither format will win" meme unless HDTV is failing altogether. As it stands, downloadable HD, and even sat/cable HD doesn't stand up to Blu-ray/HD-DVD. In quality, not convenience anyway. I'll still rent DVDs from Redbox, download from iTunes, and buy Blu-ray all at the same time as long as they're available, for cost/convenience/quality reasons. It's a great time to be a movie addict! =)
That's what I suspected too, new contracts vs. existing AT&T customers. I thought all of Slashdot had gone insane until I read your post.
Here, Gates isn't an angle, Microsoft is a business, they want your money too. Is that fair?
Care to elaborate on your claim?
This isn't the same deal as Microsoft killing Unix vendors, or software providers. Microsoft doesn't compete at all in the storage market, and EMC is a very strong (probably stronger) influence at the enterprise level.
Microsoft also has to compete against _existing_ "poor man's" virtualization solutions, which even VMware already provides. Microsoft WILL have to make a better product to win this. Can they? They don't really have room for a ME or Vista in this case. They could drag it on for a while, but it'll wind up just like their console or portable music player efforts. For instance, does "lower price for Windows Vista used on virtualized computers" apply to microsoft VPC only or to all hypervisors? If they don't want to be grilled by the DoJ about it, I think we know the answer.
Clearly this QT issue is a bug, not an intentional DRM limitation. Don't be a douche and play this like Apple INTENDED to disable AE due to DRM policy.
I also understand how useful dtrace can be, and while allowing processes to opt out of tracing is somewhat unfortunate from certain points of view, HOW does it make Apple as vile as you make them out to be?
Jobs isn't an angle, Apple is a business, they want your money. Tell us something we don't know. Their products speak for themselves, and the fact that they ported dtrace AT ALL says a lot. Apple's DRM policies and implementations are far less restricting than Microsoft's. I dare you to prove otherwise. Go ahead, bring out the worst of Leopard DRM against the worst of Vista DRM, lets compare right here and now.
You've just got an axe to grind, buddy.
I think he knew that already. The term we don't understand is "core stack". I've never heard of it either, but I think the parent post is on the right track with stack trace from a core dump. In this case, I'm fairly sure the origins of "core" are irrelevant and possibly misleading.
Perl 6 is meant to run on a (Parrot) VM, whereas earlier versions of Perl were interpreted. From the looks of your link, it is being implemented outside the Parrot VM also.
Reading Perl, and comprehending the subtle differences between Solaris, Linux and Windows versions already gives me headaches, now there will be different implementations of each? Wow. I hope that works out.
What are you talking about? You do lose data anytime you overwrite tapes unless you backup something static. Data == point in time snapshot. How large your tape pool is determines how far back you can keep those.
If you are constantly adding new tapes to the system, that is another thing. You don't need to ever overwrite tapes in that case, so I don't know what you meant. You might copy an old tape to a new tape after a couple years or something, but not juggle them around.
With a fixed number of tapes, YOU LOSE DATA after X days.
Moosesocks is on the right track. Tape recycling is standard practice. The EOP (probably) didn't have a proper email archiving solution in place at the time. They have a very honest IT staff, and there's reason to believe they performed the best they could with the resources they had. They also wouldn't archive email if they weren't told to, so it's hard to call it negligence on the IT staff's part. At some point the requirement to archive mail one way or another apparently DID come down, so I have a hard time blaming upper levels as well. However, this "using RNC email for official business' stuff I keep hearing in the news IS negligence IMHO. I believe it was done BECAUSE the White House really did have good IT policy.
Exchange can't grow forever.
Yes, with 3rd party archiving software/hardware it technically might be able to, but this is a somewhat recent possibility.
Not saying this is all a good thing, but don't pin it on backup admins or politicians being savvy enough to understand how backup retention really works. Even when the policy from above is to keep for "three months", there is no guarantee that backups wont be kept longer than that.
AFAIK, they don't ever reuse tapes now, and haven't for the past couple years. They may or may not also have a separate email archiving system.
Remember, retention is only part of the problem. The archived email still has to be easily accessible, so relevant documents can be produced in a timely manner. A normal tape backup system, even with infinite retention, doesn't ensure this by itself.
I can't find any solid information on Remote Disc outside Apple's site. The demo video says it can be used to install new versions of OS X, so wouldn't that mean the disc has to be available at the EFI layer? I hope they don't just mean upgrades, and an install is impossible. The Air page says the Remote Disc software is used to do the wireless migrations that TDM used to be used for. Not the same thing as using TDM to fix a broken system, I know.
/shrug
I think Firewire will be around at least as long as optical drives are, in Macs anyway. They must have been pressed for space in that little flip down panel. Check out the video, I thought it was just a plastic cover till they showed it. All three ports actually flip down.
Don't lose hope yet, it isn't quite clear how Remote Disc works. If Sun hardware can boot from NFS shares, I wouldn't toss out the idea of Apple pulling something similar off with EFI, wirelessly.