That address almost assuredly -doesn't- work these days, but since that's Randal L. Schwartz of Perl fame and Intel-prosecution infamy, I'm guessing you can track him down pretty easily....
However, Feynman had a -correct- idea about what makes an experiment.
Strict scientific method has VERY VERY limiting ideas about what an experiment is, and just poking at something to see what happens isn't that.
So, unless you have removed all variables EXCEPT the Higgs boson, an experiment can't prove or disprove the existance of the Higgs boson. It can just be misinterpreted.
Insulin pumps are primarily used with Type I (formerly 'juvenile-onset') diabetes. Obesity is a correlative factor in Type II diabetes.
Extreme weight LOSS is actually one of the symptoms of badly-managed Type I diabetes because of the somewhat different nature / mechanism of the disease.
Although I'm being pedantic (being diabetic myself), because your point still stands -- exercise is one of the most important facets of care and maintenance for any type of diabetes (I, II, gestational), so this invention does seem rather counter-productive from the inventor of the insulin pump.
Then, since Microsoft themselves are documenting that Winsock is a superset of the BSD socket API, we can assume either they took the existing API and re-implemented it, or that they just took the existing BSD code (perfectly legally) and used it as a base for Winsock.
Since there are BSD copyright notices sprinkled throughout various of the internet utilites that ship with Windows, I think it's pretty clear that it's the latter. And why not? If you're going to include a socket/IP implementation, and there's freely-usable code out there, why reinvent the wheel?
Even if you want to go all out with the benefit of the doubt, and decide that they rewrote their own implementation of the API, it's still safe to say that MS' IP stack is based on BSD.
Or are you confusing Sound Forge, the actual professional mastering / batch-processing / microediting tool that's a complete DX and VST harness; with Sound Forge XP, the tiny little consumer / multimedia / web version of the same thing that ships with lots of cheapo sound cards?
Or maybe you're making the common leap of logic that 'pro audio' somehow doesn't include advertising production, audio for video, game development, and the thousands of other professional audio fields that aren't 128-track digital multitrack Peter Gabriel studios?
Umn, no, no books. A couple of magazine articles, but nothing substantive.
I came up into systems administration by way of helpdesk, so I learned a good knack for breaking down complicated issues into little two-sentence paragraphs, when documenting things for end-users.
Sure, you _could_ do that. Spread CD's out to your friends with a big monster one-time pad file on it, keep tabs on how much of the 700MB of randomness you've used, never reuse any of it, and then hand out a new CD when you get near the end.
You can quickly run into a scalability nightmare, though. You can't use the same CD for multiple friends, and here's why. If you give the CD to two friends, and you send a message to person A using up bytes 100-200 of the OTP, somehow person B has to get the message not ever to use bytes 100-200, or else it's no longer a OTP, it's a repeat key subject to cryptanalysis.
So, somehow friend B has to get the message not to use those bytes. You could cc B on the mail, or send out a separate notice that those bytes are used, but then you have a lagtime factor -- both you and A could be sending to B at the same time using the same byte range.
The only solution to this, if you actually want to use your OTP's in a one-time fashion, is to have a separate OTP CD for _each_ relationship you have. With you, A, and B, that's two CD's per person, three total unique pairs. Add in C, and that's three CD's per person, six pairs. Add in D, that's 4 CD's per person, ten pairs. E, 5 per person, fifteen pairs. And on and on.
That's the basic scaling nightmare of ANY symmetric key solution, whether it's OTP or simply static keys.
The thing that makes public-key more secure is that you can encrypt your private key such that even if it WERE stolen. it has to be brute-forced open just like your mail would. With a symmetric key scheme, you can encrypt your key, but then you have to pass that key AND the decryption method around, meaning your local key is only as safe as the weakest link of your web of trust. With public-key, your local key is as safe as you, yourself are.
Sense? Your idea COULD work, but you're basically reinventing the wheel and inheriting a lot of the problems that were ameliorated (not solved, mind you...) with the rise of cheap and easy public-key schemes.
One-time pads are unbreakable if used correctly, yes.
The problem is that since you use each one exactly once, each side has to have either the same list of pads or arrange a new pad for each message.
If you have a list of pads, that's subject to theft/social engineering/other compromises ahead of time.
If you arrange a pad for each message, you need to transmit the pad over a secure channel to avoid man-in-the-middle attacks. And if you have such a secure channel, you don't need one-time pads, you can just send the message itself securely. Note that this problem also applies to distributing lists of pads.
[Note that the idea of creating a public-key secure channel to send a symmetric one-time-pad-style session key is how almost all 'public-key' systems actually work, for performance reasons.]
Basically one time pads are perfect in very limited circumstances, but completely unusable for basic day-to-day end-to-end encryption.
That's what public-key crypto is all about -- the ability to publish a key far and wide whose encryption can ONLY be read by a different key.
First point I'm not going to argue, particularly. I'm going to stand by my assertion that the AVERAGE Tivo purchaser plans to buy the service, and saying that everyman actually takes a minute to make the choice whether to buy the service is silly.
Second point: Incorrect. The Tivo clock can be set via NTP from any server. Alleging that Tivo has some monopoly on NTP is silly. And again, I maintain that if you want to use the device in an unsupported way, Tivo has no obligation to be your NTP server. If you choose to connect to their network for NTP, you also should accept the consequences, the "AUP" of their network. If you don't understand the implications of dialing into Tivo's network to set your clock, you probably shouldn't be trying to use the Tivo device without a subscription. You can't have it both ways.
As to the lifetime subscription: I continue to say that if your Tivo unit and Tivo itself last more than two years -- a pretty good bet as best I can tell -- it's a good deal. YMMV. Caveat Tivor.
> Problem is, that doesn't do any good for a normal non-geek. The issue is that Tivo is
> breaking something that people bought after purchase. What about the technophobes of the
> world? Their big breakthrough this year was understanding what a digital recorder can do for
> them -- can't expect them to get right into hacking!
The average technophobe would never get the idea to try to run the thing without the subscription in the first place. For the most part, it's the hacker mentality that would ever say "what if I just didn't pay for the service?"
In any case, read the avsforum thread referenced above -- Tivo themselves have said that the record button change was not intentional and that it will be fixed in the 2.5 release. I, for one, accept that -- I wouldn't expect Tivo to do a lot of QA testing on how their software reacts on machines that are not subscribed and so shouldn't be dialing in anyway....
(*shrug) I'm not trying to be an apologist for Tivo, but I find it pretty amusing that someone would buy the device, use it in an unsupported way, and then complain when it doesn't work. That's what 'unsupported' means -- if it breaks, you get to keep both parts.
Nope, no privacy loophole. The only 'gotcha' is that the 'lifetime' refers to the lifetime of the recorder, not of the subscriber. If it goes up in flames the day it gets out of warranty, you're screwed. --
I really don't have much sympathy -- even if you don't want to pay for the guide data, plugging the thing into the wall to use Tivo's dialup to access Tivo's network to sync to Tivo's NTP servers means you're using their service and therefore are going to get the upgrades and other such things, and rightly so. If you don't want to take part in the Tivo process, don't plug it into the phone jack -- Tivo doesn't owe you a free clock sync if you're not paying them to use their network.
That aside, there's a couple of options. One is that Tivo offers a 'lifetime' subscription to the guide data for a flat fee of $200. Sounds expensive, but just think of it as a full-featured Tivo for a one-time cost of $600.
Failing that, you still have your old 1.3 version on there in a separate partition. Tivo upgrades load the new OS onto an alternate root partition, then when it's successful, resets the boot sector to boot from the upgraded partition. The old one is still there, as the new 'alternate,' waiting for the next upgrade.
There's a holy MESS of information in the Tivo Hack FAQ (start at www.tivocommunity.com) about how to get a serial console on your Tivo box and change around your boot partitions as well as a bunch of other stuff. Unplug your Tivo from the wall so you don't get any MORE upgrades (therefore blowing away your 1.3), and start reading. You can get your 1.3 back, although there are all SORTS of caveats and readme's about doing a revert like that. Stop complaining and start reading and learning.
--
Re:Last episode mirrored structure of STTNG
on
Voyager Eulogy
·
· Score: 2
Totally. I caught the same thing, but somehow couldn't explain to the people I was watching with that what SHOULD have happened is that the "future" ship would race up to it the first time, and shoot their little tachyon beam into it just as it disappeared into nothing. Which would, of course, make the plot resolution impossible, but would have made SENSE at least.
Of course, the whole time-travel premise of the show is moronic -- if the issue is that the evil growing-backwards thingie will have made it so humans never existed, then humans never existed to make the growing thingie appear in the first place and so therefore did exist and around and around and around.
Same with the Voyager bit. Since the future Janeway got Voyager back early, and therefore everything was happy and Tuvok didn't go nuts and so forth, suddenly the future Janeway had no reason to go back and change things and around and around and around.
Caveat Scriptor: time travel is a cheap and easy way to bamboozle your readers/viewers in place of actually entertaining them. --
Good thing the Slashdot editors are calling non-coders "l4m3" in the poll this week, since they're SO clear on the difference between assemblers and compilers....
No. The joke is LONG since over. The terrifying thing is that these things still tend to get moderated up anyway. Someone ought make a Sig-11 style experiment to see if they can hit the karma cap just using the 'priceless' joke.
Well, the LambdaMOO server is available on SourceForge, and has been for some time. Not wanting to start a mini-flame-war about M** stuff, but if you want your virtual text-worlds to have more complexity than "hit orc with sword," MOO with the JHCore database is really just about the bext way to go (although ColdC is also pretty cool these days, if a bit more arcane and undocumented).
Slashdot Mirror
Last time I checked there wasn't a windows port of tuxracer ;)
Check again.
Oh God. They have?!? Quick, somebody, TELL LINUS!
That address almost assuredly -doesn't- work these days, but since that's Randal L. Schwartz of Perl fame and Intel-prosecution infamy, I'm guessing you can track him down pretty easily....
However, Feynman had a -correct- idea about what makes an experiment.
Strict scientific method has VERY VERY limiting ideas about what an experiment is, and just poking at something to see what happens isn't that.
So, unless you have removed all variables EXCEPT the Higgs boson, an experiment can't prove or disprove the existance of the Higgs boson. It can just be misinterpreted.
Insulin pumps are primarily used with Type I (formerly 'juvenile-onset') diabetes. Obesity is a correlative factor in Type II diabetes.
Extreme weight LOSS is actually one of the symptoms of badly-managed Type I diabetes because of the somewhat different nature / mechanism of the disease.
Although I'm being pedantic (being diabetic myself), because your point still stands -- exercise is one of the most important facets of care and maintenance for any type of diabetes (I, II, gestational), so this invention does seem rather counter-productive from the inventor of the insulin pump.
Then, since Microsoft themselves are documenting that Winsock is a superset of the BSD socket API, we can assume either they took the existing API and re-implemented it, or that they just took the existing BSD code (perfectly legally) and used it as a base for Winsock.
Since there are BSD copyright notices sprinkled throughout various of the internet utilites that ship with Windows, I think it's pretty clear that it's the latter. And why not? If you're going to include a socket/IP implementation, and there's freely-usable code out there, why reinvent the wheel?
Even if you want to go all out with the benefit of the doubt, and decide that they rewrote their own implementation of the API, it's still safe to say that MS' IP stack is based on BSD.
Then you need to check again.
Or are you confusing Sound Forge, the actual professional mastering / batch-processing / microediting tool that's a complete DX and VST harness; with Sound Forge XP, the tiny little consumer / multimedia / web version of the same thing that ships with lots of cheapo sound cards?
Or maybe you're making the common leap of logic that 'pro audio' somehow doesn't include advertising production, audio for video, game development, and the thousands of other professional audio fields that aren't 128-track digital multitrack Peter Gabriel studios?
Digital cameras make car accidents and naked girlfriends redundant?
I'm not sure what kind of parties you're going to, but invite me next time.
Nope, that's 61 Ursae Majoris. Closer to there than here, but not the same place at all.
Yes. That's the one.
--
Your "low" SlashID is for ponces.
(*grin)
--
Umn, no, no books. A couple of magazine articles, but nothing substantive.
I came up into systems administration by way of helpdesk, so I learned a good knack for breaking down complicated issues into little two-sentence paragraphs, when documenting things for end-users.
--
Sure, you _could_ do that. Spread CD's out to your friends with a big monster one-time pad file on it, keep tabs on how much of the 700MB of randomness you've used, never reuse any of it, and then hand out a new CD when you get near the end.
You can quickly run into a scalability nightmare, though. You can't use the same CD for multiple friends, and here's why. If you give the CD to two friends, and you send a message to person A using up bytes 100-200 of the OTP, somehow person B has to get the message not ever to use bytes 100-200, or else it's no longer a OTP, it's a repeat key subject to cryptanalysis.
So, somehow friend B has to get the message not to use those bytes. You could cc B on the mail, or send out a separate notice that those bytes are used, but then you have a lagtime factor -- both you and A could be sending to B at the same time using the same byte range.
The only solution to this, if you actually want to use your OTP's in a one-time fashion, is to have a separate OTP CD for _each_ relationship you have. With you, A, and B, that's two CD's per person, three total unique pairs. Add in C, and that's three CD's per person, six pairs. Add in D, that's 4 CD's per person, ten pairs. E, 5 per person, fifteen pairs. And on and on.
That's the basic scaling nightmare of ANY symmetric key solution, whether it's OTP or simply static keys.
The thing that makes public-key more secure is that you can encrypt your private key such that even if it WERE stolen. it has to be brute-forced open just like your mail would. With a symmetric key scheme, you can encrypt your key, but then you have to pass that key AND the decryption method around, meaning your local key is only as safe as the weakest link of your web of trust. With public-key, your local key is as safe as you, yourself are.
Sense? Your idea COULD work, but you're basically reinventing the wheel and inheriting a lot of the problems that were ameliorated (not solved, mind you...) with the rise of cheap and easy public-key schemes.
--
One-time pads are unbreakable if used correctly, yes.
The problem is that since you use each one exactly once, each side has to have either the same list of pads or arrange a new pad for each message.
If you have a list of pads, that's subject to theft/social engineering/other compromises ahead of time.
If you arrange a pad for each message, you need to transmit the pad over a secure channel to avoid man-in-the-middle attacks. And if you have such a secure channel, you don't need one-time pads, you can just send the message itself securely. Note that this problem also applies to distributing lists of pads.
[Note that the idea of creating a public-key secure channel to send a symmetric one-time-pad-style session key is how almost all 'public-key' systems actually work, for performance reasons.]
Basically one time pads are perfect in very limited circumstances, but completely unusable for basic day-to-day end-to-end encryption.
That's what public-key crypto is all about -- the ability to publish a key far and wide whose encryption can ONLY be read by a different key.
--
First point I'm not going to argue, particularly. I'm going to stand by my assertion that the AVERAGE Tivo purchaser plans to buy the service, and saying that everyman actually takes a minute to make the choice whether to buy the service is silly.
Second point: Incorrect. The Tivo clock can be set via NTP from any server. Alleging that Tivo has some monopoly on NTP is silly. And again, I maintain that if you want to use the device in an unsupported way, Tivo has no obligation to be your NTP server. If you choose to connect to their network for NTP, you also should accept the consequences, the "AUP" of their network. If you don't understand the implications of dialing into Tivo's network to set your clock, you probably shouldn't be trying to use the Tivo device without a subscription. You can't have it both ways.
As to the lifetime subscription: I continue to say that if your Tivo unit and Tivo itself last more than two years -- a pretty good bet as best I can tell -- it's a good deal. YMMV. Caveat Tivor.
--
Preach it, brother....
--
> Problem is, that doesn't do any good for a normal non-geek. The issue is that Tivo is
> breaking something that people bought after purchase. What about the technophobes of the
> world? Their big breakthrough this year was understanding what a digital recorder can do for
> them -- can't expect them to get right into hacking!
The average technophobe would never get the idea to try to run the thing without the subscription in the first place. For the most part, it's the hacker mentality that would ever say "what if I just didn't pay for the service?"
In any case, read the avsforum thread referenced above -- Tivo themselves have said that the record button change was not intentional and that it will be fixed in the 2.5 release. I, for one, accept that -- I wouldn't expect Tivo to do a lot of QA testing on how their software reacts on machines that are not subscribed and so shouldn't be dialing in anyway....
(*shrug) I'm not trying to be an apologist for Tivo, but I find it pretty amusing that someone would buy the device, use it in an unsupported way, and then complain when it doesn't work. That's what 'unsupported' means -- if it breaks, you get to keep both parts.
--
Nope, no privacy loophole. The only 'gotcha' is that the 'lifetime' refers to the lifetime of the recorder, not of the subscriber. If it goes up in flames the day it gets out of warranty, you're screwed.
--
(*nod) Ah yes. Forgot about that. Still, if you expect to use your Tivo for more than two years, this is still a bargain.
--
I really don't have much sympathy -- even if you don't want to pay for the guide data, plugging the thing into the wall to use Tivo's dialup to access Tivo's network to sync to Tivo's NTP servers means you're using their service and therefore are going to get the upgrades and other such things, and rightly so. If you don't want to take part in the Tivo process, don't plug it into the phone jack -- Tivo doesn't owe you a free clock sync if you're not paying them to use their network.
That aside, there's a couple of options. One is that Tivo offers a 'lifetime' subscription to the guide data for a flat fee of $200. Sounds expensive, but just think of it as a full-featured Tivo for a one-time cost of $600.
Failing that, you still have your old 1.3 version on there in a separate partition. Tivo upgrades load the new OS onto an alternate root partition, then when it's successful, resets the boot sector to boot from the upgraded partition. The old one is still there, as the new 'alternate,' waiting for the next upgrade.
There's a holy MESS of information in the Tivo Hack FAQ (start at www.tivocommunity.com) about how to get a serial console on your Tivo box and change around your boot partitions as well as a bunch of other stuff. Unplug your Tivo from the wall so you don't get any MORE upgrades (therefore blowing away your 1.3), and start reading. You can get your 1.3 back, although there are all SORTS of caveats and readme's about doing a revert like that. Stop complaining and start reading and learning.
--
Totally. I caught the same thing, but somehow couldn't explain to the people I was watching with that what SHOULD have happened is that the "future" ship would race up to it the first time, and shoot their little tachyon beam into it just as it disappeared into nothing. Which would, of course, make the plot resolution impossible, but would have made SENSE at least.
Of course, the whole time-travel premise of the show is moronic -- if the issue is that the evil growing-backwards thingie will have made it so humans never existed, then humans never existed to make the growing thingie appear in the first place and so therefore did exist and around and around and around.
Same with the Voyager bit. Since the future Janeway got Voyager back early, and therefore everything was happy and Tuvok didn't go nuts and so forth, suddenly the future Janeway had no reason to go back and change things and around and around and around.
Caveat Scriptor: time travel is a cheap and easy way to bamboozle your readers/viewers in place of actually entertaining them.
--
Good thing the Slashdot editors are calling non-coders "l4m3" in the poll this week, since they're SO clear on the difference between assemblers and compilers....
--
No. The joke is LONG since over. The terrifying thing is that these things still tend to get moderated up anyway. Someone ought make a Sig-11 style experiment to see if they can hit the karma cap just using the 'priceless' joke.
--
"I am the great Cornholio! Are you threatening meeee?!? I need TP for my bunghole!"
--
Well, the LambdaMOO server is available on SourceForge, and has been for some time. Not wanting to start a mini-flame-war about M** stuff, but if you want your virtual text-worlds to have more complexity than "hit orc with sword," MOO with the JHCore database is really just about the bext way to go (although ColdC is also pretty cool these days, if a bit more arcane and undocumented).
--