I think it's mystro like "mysterious why anyone would want such a crippled service, which is why we're two years into design and 2 years from rolling it out."
The converstion to digital TV with the "broadcast flag" is what the content providers are dreaming about -- then this kind of system is viable, because
all the old Tivos and ReplayTVs and PVR card in people's PCs become obsolete, and the Mystro-like
order is enforced by the DMCA. In time, you will learn to love it.
wrong; the new software encrypts the streams, and crypto-protects the software. mucking with it is the
sort of thing hollywood would claim is a DMCA violation, and it does violate the ToS for the DTivo.
I'm a directTivo owner, and worked on VOD/"vcr" systems recently, and a long time ago was a cable lineman.
It -should- be cheaper to provision PVR service from a cable headend, only through redundant storage and memoery caching frequently accessed stuff. But there are real challenges there too, both technical, legal, and business model
technical: (1) bandwidh to house is limited, so you can't really get dedicated streams at sattelite quility, assuming each house has N distinct feeds at their own seek location; (2) latency for interaction of VCR controls (pause, fastforward, rewind, skip) is dificult to deal with. This is easy with local PVRs.
legal: it's not the napster case, it's the "mymp3" case that kills
centralized PVR use. MyMp3 -was- centralized PVR, for mp3 files. This is why they'd need changed licensing regimes for it to work. Home PVRs don't have this problem, because it is covered by fair use and formalized by the Betamax decision.
business model: nobody is really willing to pay extra for it. That's a common business problem for central PVRs and replay-tv/tivo/ultimate. Somehow, DirecTV is able to think $4.95/househole (not box!) is enough for the Tivo service in directivos. That's cheap enough, I can accept it.
In conclusion, except for the bandwidth problem, I think central PVR service -could- be cheaper than disks at home. But I don't think it works out that way in practice, because too many people are too greedy to pass the savings along.
I -really- like my direct tivo HDVR2. I want an
archiving solution, though.
switching to this, no.
But given Tivo's position on video extraction (unlike Sonic blue), I might very well build something that will take the analog output of my
new HDVR2 (directivo) and be capable of burning a divx CD or DVD for archiving and/or local net serving. I might even be happy to run Windows
on it if that simplified the setup and I could build it for about $400.
I looked hard at replaytvs and tivos, and standalones. Replay TV would win because of
net connection and ability to serve streams, but
loses because the HDVR2 is $199 at Good Guys,
and it has two DirecTV tuners built in so you
can record two things at once. I'm hoping the
tivo underground will figure out how to get in
sooner or later, but the "analog loophole" is
still there to be exploited.
"I remember back in 19 and 83 that my first VCR
set me back $400 when that was a big chunk of my
monthly pay, and that was after all the early
adopters were paying $1400 for 'em!"
The linked article is pretty reasonable. I'd quibble about the active thread count thing, though; I think at the limits it's bad to abstract into something that will establish scads of threads even if they aren't all active at the same time. For instance, say you did
do a thread-per-connection, but made it be the 'reading' thread only, so it could sit in read() or recv(). Whenever it got a message, it could queue it to a 'worker' thread that would consume cpu and send a response. For a zillion connections, this is a zillion stacks, which doesn't scale well. Probably better to i/o multiplex some fraction of connections into a smaller number of reader threads, and queue; or using the articles' suggestion, have N generic threads, which are either doing demux reading or
cpu intensive work. In either of these events, you are breaking the binding of connection/client state to a thread, which is the important state abstraction to do. Having broken clean, any number of possible implmenentations are easy to try. Without it, you are kind of stuck.
IMO, anyone who runs more than about 4*NCPUS threads in a program is an idiot; the benchmarks on 10^5 threads are absurd and irrelevant.
>>>>>>>>>
Typical *NIX developer.
Then why is Microsoft pushing Fibres/Fibers instead of their kernel threads if you want to do lots of things fast? Why are they saying, "don't have too many more threads than you have cpus?"
The alcove system of libraries was -very- common historically; it's hard to say the the dublin one was more of a particular model than any other pre-Carnegie institution. The one in Harry Potter is in the same line too.
If you're not designing for the cases where the system CPU is being heavily utilized, it doesn't make much difference what you do. It's a multitasking world-- you don't know how much is being chewed up by the mpeg decoders playing/scaling streams to the little windows underneath your gui application.
Yes, I'm overstating the position, but in my experience, using scads of threads is usually seen to be a mistake by those who have gone far down the road. If you have a thousand connections, are you
better off with 1000 threads, or one/a few in select, and ~4*NCPU workers?
This isssue is thinking through the scalability implications of using lots of threads. What the application ends up doing is relying on the thread scheduler to make proper policy decisions. If the appliation maintains it's own work queue(s) internally, it is in far better position to make correct decisions. Yes it's more work, but it works better.
I'm perfectly happy devoting a whole thread to UI events to get responsiveness. I shouldn't need 100 of them behind the scenes doing the real work if I only have 1 or 4 cpus.
If your application design calls for 100 concurrently operating threads, there is something broken about the decomposition.
For a long time, Sun used M:N threading, and many people thought this was a good idea. They have recently changed their minds, and been moving towards 1:1.
If one believes the Sun guys have a clue, you can take this as a vote in favor of 1:1.
IMO, anyone who runs more than about 4*NCPUS threads in a program is an idiot; the benchmarks on 10^5 threads are absurd and irrelevant.
Once you run a reasonable number of threads, you can be quickly driven to internal queueing of work from thread to thread; and by the time you have done that, you may already have reached a point of state abstraction that lets you run event driven in a very small number of threads, approaching NCPUs as the lower useful limit. Putting all your state in per-thread storage or on the thread stack is a sign of weak state abstraction.
The golden gate is *really* deep. "Mean lower low water depth at this site is about 75 feet and increases to a maximum depth of 378 feet in the main channel."
There is plenty of depth in the channel; there may not be enough current to make it economically feasible though. Not to mention the inevitable EIR complications.
Elecric motors have largely flat torque curves vs rpm. You can convert rpm to more torque with gearing, with straight multiplation by ration. If you have more rpms available, you should also have shorter gears to take advantage of them. The 'rice' mistake is in not adjusting the gearing at the same time.
You've heard the argument that mammals get about the same number of beats out of their hearts, so animals with fast heartbeats live shorter? I figure it's the same thing for motors in toys. At 16,000 rpm, these puppies ain't gonna last until the first set of batteries runs down.
If you read the articles, you find it's not a total cancellation, but a scaleback from an big integration to one that will just replace the launch operations.
And to those who talk about emulation as the answer, that is only part of the problem. (1) They'd still have
the same address space limitations in an emulated platform. (2) they'd still have a hard time finding people to work on it, and a long training period to get them up to speed. They really need to migrate the platform, even if they only replace the current function..
[i was going to moderate, but there was nothing
worth anything in the discussion so far]
I don't see what is 'micro' about the distro. The default installation takes 160M. Back when I have my AT&T 3b1 running, the whole thing fit on a 10M disk with 3M left for my files. No tcp/ip tho, but
does that really take 150M?
but which proposal promises to kick back funding, er 'help defray expenses of' ICANN? That would be
Ability to comply with ICANN-developed policies in the criteria for selection.
Kodak hasn't got any particular advantage here over any of the world-wide semiconductor makers. TI, for instance, who owns DLP. Or any of the Japanese LCD makers.
Slashdot Mirror
The converstion to digital TV with the "broadcast flag" is what the content providers are dreaming about -- then this kind of system is viable, because all the old Tivos and ReplayTVs and PVR card in people's PCs become obsolete, and the Mystro-like order is enforced by the DMCA. In time, you will learn to love it.
-dB
Must be time to fire up the tivo and watch west wing instead of reading /.
-dB
-dB
-dB
It -should- be cheaper to provision PVR service from a cable headend, only through redundant storage and memoery caching frequently accessed stuff. But there are real challenges there too, both technical, legal, and business model
technical: (1) bandwidh to house is limited, so you can't really get dedicated streams at sattelite quility, assuming each house has N distinct feeds at their own seek location; (2) latency for interaction of VCR controls (pause, fastforward, rewind, skip) is dificult to deal with. This is easy with local PVRs.
legal: it's not the napster case, it's the "mymp3" case that kills centralized PVR use. MyMp3 -was- centralized PVR, for mp3 files. This is why they'd need changed licensing regimes for it to work. Home PVRs don't have this problem, because it is covered by fair use and formalized by the Betamax decision.
business model: nobody is really willing to pay extra for it. That's a common business problem for central PVRs and replay-tv/tivo/ultimate. Somehow, DirecTV is able to think $4.95/househole (not box!) is enough for the Tivo service in directivos. That's cheap enough, I can accept it.
In conclusion, except for the bandwidth problem, I think central PVR service -could- be cheaper than disks at home. But I don't think it works out that way in practice, because too many people are too greedy to pass the savings along.
I -really- like my direct tivo HDVR2. I want an archiving solution, though.
-dB
I looked hard at replaytvs and tivos, and standalones. Replay TV would win because of net connection and ability to serve streams, but loses because the HDVR2 is $199 at Good Guys, and it has two DirecTV tuners built in so you can record two things at once. I'm hoping the tivo underground will figure out how to get in sooner or later, but the "analog loophole" is still there to be exploited.
"I remember back in 19 and 83 that my first VCR set me back $400 when that was a big chunk of my monthly pay, and that was after all the early adopters were paying $1400 for 'em!"
-dB
-dB
-dB
-dB
-dB
This isssue is thinking through the scalability implications of using lots of threads. What the application ends up doing is relying on the thread scheduler to make proper policy decisions. If the appliation maintains it's own work queue(s) internally, it is in far better position to make correct decisions. Yes it's more work, but it works better.
-dB
If your application design calls for 100 concurrently operating threads, there is something broken about the decomposition.
-dB
The change in thinking for this is argued in this Sun Whitepaper , and this FAQ .
If one believes the Sun guys have a clue, you can take this as a vote in favor of 1:1.
IMO, anyone who runs more than about 4*NCPUS threads in a program is an idiot; the benchmarks on 10^5 threads are absurd and irrelevant.
Once you run a reasonable number of threads, you can be quickly driven to internal queueing of work from thread to thread; and by the time you have done that, you may already have reached a point of state abstraction that lets you run event driven in a very small number of threads, approaching NCPUs as the lower useful limit. Putting all your state in per-thread storage or on the thread stack is a sign of weak state abstraction.
-dB
There is plenty of depth in the channel; there may not be enough current to make it economically feasible though. Not to mention the inevitable EIR complications.
-dB
I've still got some data on those I'd like to get off... -dB
Depending on your set of religious tenets, it's either the same thing as BitKeeper, or completely different.
-dB
-dB
-dB
(running from the bricks)
-dB
-dB
And to those who talk about emulation as the answer, that is only part of the problem. (1) They'd still have the same address space limitations in an emulated platform. (2) they'd still have a hard time finding people to work on it, and a long training period to get them up to speed. They really need to migrate the platform, even if they only replace the current function..
-dB
I don't see what is 'micro' about the distro. The default installation takes 160M. Back when I have my AT&T 3b1 running, the whole thing fit on a 10M disk with 3M left for my files. No tcp/ip tho, but does that really take 150M?
-dB
-dB
-dB