The Tesla Roadster is in production now, which while it isn't the "big news" Model S, it proves that Tesla CAN get an all-electric vehicle into production as a street legal car.
Aptera has yet to prove that. Their oh-so-great vehicle has yet to enter production.
They're not the only ones pulling numbers out of their ass. You also seem to be too, unless you're finding the absolutely most expensive drive in any given capacity class.
For example, the 80GB Intel X25-M runs around $380, so is better than any of the prices you pulled up.
Obviously, it doesn't make sense to replace every drive in a server farm with SSDs, especially if you want lots of storage, but you have to keep in mind that while SSDs may suck for GB/$, they do have major advantages in other areas, such as MB/S/$ - That Intel X25-M is FAST, and if you are primarily interested in serving lots of small transactions rather than storing big files, it's the way to go.
For example, Slashdot is probably better off with an array of X25-Ms because it's only storing text and is getting LOTS of hits.
Many of the "content release teams" will make their official releases in multipart RAR format.
Apparently, Usenet is now for the "1337".
The end result is that even if you get such releases via BitTorrent, there's still a good chance they're distributed as multipart RARs. A video player that can play such files lets you view the video in its "seedable" form.
Of course, I just simply stop seeding such content much earlier than I normally would. If someone wants me to seed, they should make it EASY for me to seed by having the "seedable" form equal the "viewable" form.
I used to be a bigger fan of VLC, but on a lot of videos, I've recently had problems where after I hit pause, video will continue for 5-10 seconds before it finally pauses. Also, with a lot of videos I would get audio but no video for the first 5-10 seconds of playback.
It also gave some audio stuttering on some videos that played back fine in MPlayer.
MPlayer's biggest drawback is the fact that without some sort of frontend, it's UI stinks. SMPlayer solves that problem though. I've started to really like SMPlayer.
Except for a lot of people (even with some currently-sold systems like Intel Atom netbooks), it's: Open browser Go to hulu.com Attempt to watch show, decide that watching TV as a slideshow sucks Go to TPB or mininova Download show Watch show with smooth video instead of tearing and/or slideshowing.
I have a number of PCs in my house. My Aspire One is too slow for Hulu. My HTPC is too slow for Hulu (despite only needing 40-50% CPU for the exact same content played in a different player - I know this from before Hulu switched to encrypted RTMP, as "ripped" shows play fine in SMPlayer even though they slideshow when watched as intended). My desktop/gaming machine is the the only one fast enough for Hulu, and is subject to constant tearing during video playback because the player is a piece of junk.
The whole point of P2P is to use the bandwidth of each client as a server in addition. This relies on a network being distributed without a central bottleneck.
VPNing in to TPB will introduce just such a bottleneck, killing performance. Or have they figured out a way to do point-to-point VPNing between all registered users?
What VPN technology are they using? How does it work?
As others have said: 1) Municipalities started tweaking yellow light timers WAY down to increase red light camera revenue. This wound up reducing T-bone accidents (intended) but significantly increased rearend accidents (not intended) due to people slamming on their brakes to make sure they not only didn't catch the red due to a short yellow, but to make sure they weren't unfairly ticketed because their vehicle was stationary 6 inches over the line. 2) Yes, an additional problem was that the cameras would snap pictures of those who were stopped 6 inches over the line at an intersection. Not by any means "running a red light" but according to the cameras they were doing so.
Back in the early days of military spending, it was easy for unscrupulous contractors to cheat the government. The end result, of course, is that contractors DID cheat the government.
So the government clamped down with lots of red tape, rules, and regulations.
Upside: It's next to impossible to cheat the government. Downside: All that paperwork makes any government program extremely expensive compared to a commercial project that has similar scope and work quality, even if the contractor is 100% ethical and honest. Everyone pays for the sins of a few, and because of the historical reason WHY that paperwork is there, everyone not familiar with the defense industry assumes that someone's up to no good. One of the reasons there are a small number of large government contractors is that companies got tired of the paperwork and either stopped doing government contracts or sold off their divisions that did.
The article title is clearly misleading. They say Windows and Linux aren't ready, but the article spends all of its time talking about the applications not being ready.
In fact, after RTFAing, I can't even find any mention of the OS in the linked article. Nothing about Windows or Linux deficiencies whatsoever.
Yup. I don't know about the iPhone's architecture, but the Qualcomm MSM7200 used in the AT&T Tilt uses a separate ARM core to handle radio functions. (Leading to a misconception that it was "dual core" even though the second core is best thought of as a "radio coprocessor" and is not only a different speed from the main applications core but I believe a slightly different architecture - there are multiple slight variants of the ARM architecture).
Sounds from the comments on that article that the iPhone's CPU just isn't fast enough to take advantage of 3G data rates even with a 3G radio present.
Based on those that commented on the linked article that their laptop data card was fast and my own experience with an AT&T Tilt in 3G coverage areas, it's *not* the network. The only time I have 3G speed problems is when I'm in a fringe area with only one bar of signal strength.
That's because for wrench/socket sets, the situation is just the opposite. Metric's unit (mm) is "just right" and doesn't need fractions or decimals, imperial's unit (inch) is way too big and nearly everything is less than one unit.
It goes the other way for Celsius vs Fahrenheit. Celsius units are "too big" and require dealing with fractional units, while most Fahrenheit-based systems can use single-full-unit increments.
Only valid if the system uses TCP to stream. Many realtime streaming protocols use a custom/semi-custom transport protocol layered over UDP, such as RTP.
Don't explicitly throttle any given protocol. Taking a protocol and saying, "this protocol only gets X kilobytes per second" is a good way to get you strangled by the FCC. (See Comcast.) It's also a good way to start a war you cannot win with your users and the P2P community, a war which is already being fought and is leading to custom transport protocols with custom congestion control. YOU DO NOT WANT TO ENCOURAGE THIS. Custom congestion control is a potentially dangerous thing for the Internet - if someone screws it up, Bad Things will happen. Sadly, Comcast's abuse of the TCP congestion control mechanism (bogus RST packets) is already leading down this slope.
Prioritizing protocols, on the other hand, is OK. Drop BitTorrent and other P2P into the "bulk" category - Anything else will preempt it. Maybe give it a small bit of bandwidth at all times to keep P2P users (and/or misclassified users) from getting too angry and taking strange countermeasures. Of course, there will be little from the "anything else" category between midnight and 8 AM, so that's when the P2P will get its bandwidth.
If it is difficult to explicitly identify BitTorrent and other P2P due to encryption, then choose a set of protocols that are to get "normal" priority and explicitly put them into "normal" (HTTP, FTP, SMTP, POP/IMAP) categories or possibly "realtime" categories (VoIP protocols).
I disagree on your last con - If you get an SSD netbook this is the case, but you can store quite a few movies on a 160GB hard drive if you get one of the $300-400 HD versions. (As opposed to the $200-300 SSD ones)
An Acer Aspire One with a 6-cell can do 5.5-6 hours with general use. General use and totally idle doesn't make too much difference. Supposedly the latest Eees can reach 8-9 with the same battery (but likely at practically idle use) due to more aggressive power management.
It will only get better too - while the Atom sips power, the chipset is not nearly as power efficient. IIRC even at full CPU usage the chipset uses more power than the CPU.
I have a real laptop (17") but there are a lot of places where I just take the AAO - It's just so incredibly portable.
In which case, the optimum time is not necessarily "when the most people are actively watching TV", but now is "when you're least likely to trigger a DVR recording conflict but still get some live viewers". Guess what - FRIDAY!
As others have said, many of the most successful sci-fi TV series in history have spent most of their lives on Friday nights.
Also many of those series (SG1, Atlantis, BSG) had long midseason breaks. In their case it was probably due to UK syndication - A season (called a series over there, sometimes leading to "series finale" confusion) in the UK is typically 12-13 episodes instead of the 25-26 in the U.S. So many shows are designed to allow for a U.S. midseason break that coincides with the split between two UK seasons.
In the era of DVRs, midseason breaks are now the exception and not the norm. Fringe is not by any means unusual in its use of a midseason break. I'm pretty sure LOST has had some pretty hefty midseason breaks and unusual scheduling, despite that it's still successful. Networks are shuffling shows around such that the rerun season is getting shorter and shorter as shows trade places within a timeslot for a while.
Slashdot Mirror
Nice vaporware.
The Tesla Roadster is in production now, which while it isn't the "big news" Model S, it proves that Tesla CAN get an all-electric vehicle into production as a street legal car.
Aptera has yet to prove that. Their oh-so-great vehicle has yet to enter production.
They're not the only ones pulling numbers out of their ass. You also seem to be too, unless you're finding the absolutely most expensive drive in any given capacity class.
For example, the 80GB Intel X25-M runs around $380, so is better than any of the prices you pulled up.
Obviously, it doesn't make sense to replace every drive in a server farm with SSDs, especially if you want lots of storage, but you have to keep in mind that while SSDs may suck for GB/$, they do have major advantages in other areas, such as MB/S/$ - That Intel X25-M is FAST, and if you are primarily interested in serving lots of small transactions rather than storing big files, it's the way to go.
For example, Slashdot is probably better off with an array of X25-Ms because it's only storing text and is getting LOTS of hits.
Many of the "content release teams" will make their official releases in multipart RAR format.
Apparently, Usenet is now for the "1337".
The end result is that even if you get such releases via BitTorrent, there's still a good chance they're distributed as multipart RARs. A video player that can play such files lets you view the video in its "seedable" form.
Of course, I just simply stop seeding such content much earlier than I normally would. If someone wants me to seed, they should make it EASY for me to seed by having the "seedable" form equal the "viewable" form.
Do you mean wxWorks?
VxWorks is an embedded operating system, not a graphical toolkit...
I used to be a bigger fan of VLC, but on a lot of videos, I've recently had problems where after I hit pause, video will continue for 5-10 seconds before it finally pauses. Also, with a lot of videos I would get audio but no video for the first 5-10 seconds of playback.
It also gave some audio stuttering on some videos that played back fine in MPlayer.
MPlayer's biggest drawback is the fact that without some sort of frontend, it's UI stinks. SMPlayer solves that problem though. I've started to really like SMPlayer.
No, they will not dig that kind of technical inferiority.
Except for a lot of people (even with some currently-sold systems like Intel Atom netbooks), it's:
Open browser
Go to hulu.com
Attempt to watch show, decide that watching TV as a slideshow sucks
Go to TPB or mininova
Download show
Watch show with smooth video instead of tearing and/or slideshowing.
I have a number of PCs in my house. My Aspire One is too slow for Hulu. My HTPC is too slow for Hulu (despite only needing 40-50% CPU for the exact same content played in a different player - I know this from before Hulu switched to encrypted RTMP, as "ripped" shows play fine in SMPlayer even though they slideshow when watched as intended). My desktop/gaming machine is the the only one fast enough for Hulu, and is subject to constant tearing during video playback because the player is a piece of junk.
It is. Just point and click.
Remember, while Apple ripped off Xerox, Xerox ripped off Smith and Wesson.
Note: This approach, while easy, may have undesired side effects, such as something called "prison".
The whole point of P2P is to use the bandwidth of each client as a server in addition. This relies on a network being distributed without a central bottleneck.
VPNing in to TPB will introduce just such a bottleneck, killing performance. Or have they figured out a way to do point-to-point VPNing between all registered users?
What VPN technology are they using? How does it work?
At one point I was at a summer program for gifted high school students.
Despite this, somehow one of the students missed the dorm toilet by:
1 stall door
1 large bathroom
1 bathroom door
To this day the identity of said student is not known, only the identity of the student unfortunate enough to discover the incident barefoot.
I never got the recall feature.
"This user would like to recall this message". Usually seen after I had already read the message in general.
And as you say - The recalled message goes nowhere.
As others have said:
1) Municipalities started tweaking yellow light timers WAY down to increase red light camera revenue. This wound up reducing T-bone accidents (intended) but significantly increased rearend accidents (not intended) due to people slamming on their brakes to make sure they not only didn't catch the red due to a short yellow, but to make sure they weren't unfairly ticketed because their vehicle was stationary 6 inches over the line.
2) Yes, an additional problem was that the cameras would snap pictures of those who were stopped 6 inches over the line at an intersection. Not by any means "running a red light" but according to the cameras they were doing so.
My opinion on the red tape:
Back in the early days of military spending, it was easy for unscrupulous contractors to cheat the government. The end result, of course, is that contractors DID cheat the government.
So the government clamped down with lots of red tape, rules, and regulations.
Upside: It's next to impossible to cheat the government.
Downside: All that paperwork makes any government program extremely expensive compared to a commercial project that has similar scope and work quality, even if the contractor is 100% ethical and honest. Everyone pays for the sins of a few, and because of the historical reason WHY that paperwork is there, everyone not familiar with the defense industry assumes that someone's up to no good. One of the reasons there are a small number of large government contractors is that companies got tired of the paperwork and either stopped doing government contracts or sold off their divisions that did.
Yeah, but in that case you'd have a downwards blow to the top of the sail. This appears to have been a sideways blow from the pictures.
The article title is clearly misleading. They say Windows and Linux aren't ready, but the article spends all of its time talking about the applications not being ready.
In fact, after RTFAing, I can't even find any mention of the OS in the linked article. Nothing about Windows or Linux deficiencies whatsoever.
Yup. I don't know about the iPhone's architecture, but the Qualcomm MSM7200 used in the AT&T Tilt uses a separate ARM core to handle radio functions. (Leading to a misconception that it was "dual core" even though the second core is best thought of as a "radio coprocessor" and is not only a different speed from the main applications core but I believe a slightly different architecture - there are multiple slight variants of the ARM architecture).
Sounds from the comments on that article that the iPhone's CPU just isn't fast enough to take advantage of 3G data rates even with a 3G radio present.
Based on those that commented on the linked article that their laptop data card was fast and my own experience with an AT&T Tilt in 3G coverage areas, it's *not* the network. The only time I have 3G speed problems is when I'm in a fringe area with only one bar of signal strength.
You typically don't need access to SMM to write to the BIOS.
On the other hand, BIOS attacks aren't very portable. Something that compromises one machine will brick another.
That's because for wrench/socket sets, the situation is just the opposite. Metric's unit (mm) is "just right" and doesn't need fractions or decimals, imperial's unit (inch) is way too big and nearly everything is less than one unit.
It goes the other way for Celsius vs Fahrenheit. Celsius units are "too big" and require dealing with fractional units, while most Fahrenheit-based systems can use single-full-unit increments.
Only valid if the system uses TCP to stream. Many realtime streaming protocols use a custom/semi-custom transport protocol layered over UDP, such as RTP.
Even simpler.
Don't explicitly throttle any given protocol. Taking a protocol and saying, "this protocol only gets X kilobytes per second" is a good way to get you strangled by the FCC. (See Comcast.) It's also a good way to start a war you cannot win with your users and the P2P community, a war which is already being fought and is leading to custom transport protocols with custom congestion control. YOU DO NOT WANT TO ENCOURAGE THIS. Custom congestion control is a potentially dangerous thing for the Internet - if someone screws it up, Bad Things will happen. Sadly, Comcast's abuse of the TCP congestion control mechanism (bogus RST packets) is already leading down this slope.
Prioritizing protocols, on the other hand, is OK. Drop BitTorrent and other P2P into the "bulk" category - Anything else will preempt it. Maybe give it a small bit of bandwidth at all times to keep P2P users (and/or misclassified users) from getting too angry and taking strange countermeasures. Of course, there will be little from the "anything else" category between midnight and 8 AM, so that's when the P2P will get its bandwidth.
If it is difficult to explicitly identify BitTorrent and other P2P due to encryption, then choose a set of protocols that are to get "normal" priority and explicitly put them into "normal" (HTTP, FTP, SMTP, POP/IMAP) categories or possibly "realtime" categories (VoIP protocols).
I miss DAoC's RvR too, which is why I was initially looking forward to WAR.
Sadly, DAoC's biggest problem with RvR (realm balance) was completely botched in WAR.
I disagree on your last con - If you get an SSD netbook this is the case, but you can store quite a few movies on a 160GB hard drive if you get one of the $300-400 HD versions. (As opposed to the $200-300 SSD ones)
An Acer Aspire One with a 6-cell can do 5.5-6 hours with general use. General use and totally idle doesn't make too much difference. Supposedly the latest Eees can reach 8-9 with the same battery (but likely at practically idle use) due to more aggressive power management.
It will only get better too - while the Atom sips power, the chipset is not nearly as power efficient. IIRC even at full CPU usage the chipset uses more power than the CPU.
I have a real laptop (17") but there are a lot of places where I just take the AAO - It's just so incredibly portable.
In which case, the optimum time is not necessarily "when the most people are actively watching TV", but now is "when you're least likely to trigger a DVR recording conflict but still get some live viewers". Guess what - FRIDAY!
As others have said, many of the most successful sci-fi TV series in history have spent most of their lives on Friday nights.
Also many of those series (SG1, Atlantis, BSG) had long midseason breaks. In their case it was probably due to UK syndication - A season (called a series over there, sometimes leading to "series finale" confusion) in the UK is typically 12-13 episodes instead of the 25-26 in the U.S. So many shows are designed to allow for a U.S. midseason break that coincides with the split between two UK seasons.
In the era of DVRs, midseason breaks are now the exception and not the norm. Fringe is not by any means unusual in its use of a midseason break. I'm pretty sure LOST has had some pretty hefty midseason breaks and unusual scheduling, despite that it's still successful. Networks are shuffling shows around such that the rerun season is getting shorter and shorter as shows trade places within a timeslot for a while.