Remember when virtualization was only something for companies with highly specialized needs? And RAID? And cooled CPUs? And hard drives? and computers?
When a solution like this comes along, it generally starts out being used only by a few people (nerds and people who REALLY need it) Then it filters down into the rest of the market as a nice solution to a common problem. Then it becomes something which nobody can imagine living without. Then it becomes unthinkable to design a system which doesn't have this ability.
Not true of every technology, surely, but "allow an arbitrary system to fail without stopping" is one of those "how did we ever live without it?" things. People will laugh at "three nines" as something absurd, like advertising that your web servers connect to the Internet or are powered by Electricity.
Sudo let's you say "I know I need more privileges to run this program. Here is the user I would like to run it as instead."
this patent let's you say "Run this program" and have the OS respond "That won't work, you probably want to run as Steve or Administrator. Shall I run it as one of them?"
This is very, very different, no matter how little you notice since behind-the-scenes, a program is calling "sudo" when it guesses it needs to. This is another thing, like one-click-shopping, which was probably "obvious" to everybody, but discarded as poor UI ("I'd rather the user need to explicitly ask for privileges, to prevent mistakes.")
sounds like every other service in the world which requires relatively-specialized hardware... and none of those have this problem. If TiVo just lets anyone anywhere dial in, send a "can I have TV listings?" request, and it responds to those requests with "ok, sure", they don't get to complain about people "stealing" their listings any more than a website can complain about someone adding/tomorrow.html to the end of a URL.
It's not stealing if the server says "you can have it" without you saying "I am bill gates, really"
And if you do need to say "I am bill gates, then the process involves more than flipping a bit.
I'd need to actively work to "not change my diet" when exercising. That's part of the deal: When you exercise, the food you want and the amount you eat changes, because your body requires different things.
Re:Sorry, what you're asking for is too easy to ab
on
Reusing Old TiVo Hardware?
·
· Score: 5, Insightful
Okay, I admit right off that I am unfamiliar with TiVo aside from what I've heard mentioned on TV. I don't have a tivo, I don't plan on getting a tivo, I've never actually looked into it.
However, I was under the strong impression that TiVo was a DVR. How can one "crack" or "rip off" a DVR? What does a TiVo provide which would be something that, if one were able to re-flash a TiVo, "crackers" would be able to use to some disadvantage to TiVo? Is TiVo cracking something which is actually done? What benefits does it have? What makes it "bad" as opposed to just "bad for the company that wants you to keep using its software"?
And what do most package managers do? Utterly lazy dependency management. "Well, you need this package... so you should have the latest version of it. If you want another version, you should rename the package and depend on something else instead."
I've never used a package manager that forced you to upgrade all dependencies to the latest version to install a package. All of them allow not just required packages but required versions of packages, and only force upgrades of dependencies when you don't have a sufficiently recent version.
And anyone who has ever wanted to upgrade just one package can tell you that this is clearly insufficient, because every package ever made lazily specifies all they know: "this package works with the version I have, therefore it requires the version I have." If this lazy way is the easiest method of specifying requirements, it is what will be used- you can tell, because it is what is used. If you are dealing with what is considered to be a non-trivial requirement by package managers, you will have run into this problem. "I know this requires version N. I have read the source, I know where Foo is being called, I know that this works in all versions since A. But the package maintainer didn't say "requires this feature" they said "requires version Q of package Foo", so I can't use the dependency management for this package". Blame the maintainer, not the system? Not bloody likely. Sometimes you see ugly hacks like "virtual packages" and "meta packages" which attempt to abuse the limits of the package manager and act as if a real providesrequires system is in place.
And that would be almost-excusable, except for the brain-dead "open source is king" approach for updates: "The whole-thing's free anyway, why not just re-send the whole thing?" binary patches are pretty-much unheard of. Of course, sending the whole thing is really just a work-around because-
Some can do patches. I think RPM can. But unless you're using dialup, they're not really that much of advantage. And you also have the problem of having to provide patches from lots of versions to lots of versions. Or you can provide only patches from the last version to the current one, in which case they're useless for anyone who misses an upgrade.
This is a solved problem. Some package managers actually/do/ send binary patches, as does every software company on the planet. If there were a valid excuse for not doing it, it wouldn't be a problem.
Package managers generally do NOT bother to detect when they are about to clobber or alter "the wrong file". When they do, they don't bother to keep a record of what they/would/ consider to be "the right file", making "merging" impossible and difference examination a guessing game.
I don't know any package manager that does this. For example, Pacman, the package manager of Arch (my current distro of choice), installs new versions of files with the suffix '.pacnew' if the old version was modified and doesn't clobber.
The "not clobbering" part is/usually/ true of configuration files, though it really all depends on what you consider to be "configuration", which you'll find yourself disagreeing with often enough to wonder why the hell the rule isn't applied universally. And yes, the second-half of that applies even to configuration files: Putting "oh, I didn't clobber this file, here's the one I wanted to stick somewhere" in a random tree, sometimes with no notification, and rarely with/useful/ notification ("speak now or forever hold your peace" notification is the bane of any upgrade, especially when combined with the point above about too-many-things-upgrading just because you wanted _one_ change), does nothing to help you find out what has changed between versions. If the only thi
point-by-point:
- it's not "you died, and are dead" it's "you never existed because activation destroyed the universe". As in: nobody ever activated it, so universes where activation is possible do not exist. No one exists to comment on their survival "so-far", the universe is all-encompassing.
- The universe doesn't actively prevent anything. In an infinity of universes, there are universes where X is physically impossible, and there are universes where X never happens despite being possible. If something never happens despite being possible, and has humans in it, some pretty unlikely events would need to happen. Yes, I do believe that physical impossibility is much more likely and so we are probably in a universe which is simply impossible to destroy, but that doesn't mean option B cannot be, especially if the technology to destroy oneself in easier ways comes along before the technology to destroy the whole universe.
- I did not mention the Higgs boson, so detection of it is unrelated.
- If activation of the LHC destroys the universe and its past, we must exist in a universe in which the universe which does not activate the LHC. The same can be said of Britney Spears releasing another hit, and I think it's no less valid.
I don't know how you got "the universe can't tolerate a paradox" from "universes which create higgs bosons don't exist because they are destroyed by that creation". Can you please describe something more paradoxical? Really I tend to think the whole idea is generally absurd because it requires a paradox - though personally I don't shy away from such things, at least for thought experiments.
All joking about the LHC aside, I do assume that it's impossible to lower entropy in a closed system because all universes in which this is possible have been destroyed by some member of the first intelligent species playing around with their toaster- I figure this would make it much more likely (even if it is infinity vs N*infinity) to exist in a universe which doesn't allow such things.
this theory has actually been proposed: That activating the LHC would actually destroy the universe, that is, the whole universe, even reaching back into the past. That would mean that the only possible universes are ones in which the LHC is never activated, which means that if we keep trying, implausible events will continue to occur, preventing the LHC from activating- after all, we're here now, right. That's _proof_ that the LHC will never be activated!
The state of package management is atrocious, and so should not be looked to for solutions? I'd call that a pretty big one.
MOST packages need only the functionality of a dependency manager, everything else being a nice-to-have-when-you-need-it feature. This is why dependency management can be considered to be the central feature of a package manager- if you don't have dependency management, you'd be hard-pressed to find anyone who claims you have a working package manager.
And what do most package managers do? Utterly lazy dependency management. "Well, you need this package... so you should have the latest version of it. If you want another version, you should rename the package and depend on something else instead."
And that would be almost-excusable, except for the brain-dead "open source is king" approach for updates: "The whole-thing's free anyway, why not just re-send the whole thing?" binary patches are pretty-much unheard of. Of course, sending the whole thing is really just a work-around because-
Package managers generally do NOT bother to detect when they are about to clobber or alter "the wrong file". When they do, they don't bother to keep a record of what they/would/ consider to be "the right file", making "merging" impossible and difference examination a guessing game. That doesn't even matter, because the first step in an "Upgrade" is usually to just completely remove the existing package, which means...
Multiple versions of a single package co-existing on the same base install is generally impossible. Which really makes you wonder what the hell a package manager/does/ manage.
It's not third-party software, that's for sure. You want the bleeding-edge version of something? You just want to patch a broken package? That means you're not using the package manager, and that means you're on your own for everything. Either you build a/package/ for what you're doing on the side, or you don't get access to any of the supposed features. And anything that depends on what you're doing, you may as well just compile and track yourself- 'cause that's what you like doing, right?
The short of it is: Package managers seem so fundamentally broken that giving them another task seems like a waste of time. They'll just be replaced by a better system eventually anyway, right? And then you'll need to do it all again.
And you can do all of that from different/directories/ without worrying about what partition something is on (you know, that's one of those things about unix: it pretty much _never_ cares how a directory is stored, unless you tell it to)
I suppose if you have an abysmally broken installer which clobbers things without asking, and only installs to the root of a mountpoint(seriously?), and deletes random files it doesn't even know about, then it might matter.
Otherwise, you probably just read a guide from 1970 about how to partition your hard drives, or something copied from a copy of a copy of one, and never actually thought about it or tried it.
How does partitioning have any effect on your ability to upgrade/downgrade, unless your distribution's installer is utterly, beyond-all-hope, broken-as-fuck?
He died forty years after they were written. If copyright law were at all sane, there would be no need for "authorization", and there would already be 500 sequels, some of which might be good. A dead guy's intentions regarding old books should not be the concern of anyone other than someone studying literature.
The example in the article would not have happened. Various other things would be much better. It completely, 100%, solves the problem for this situation. Even if a group of technically-minded people couldn't be bothered to configure their mail clients to sign their own messages, I bet they could be convinced to send google-groups messages through google.
- These are technical people. All of them should be able to configure their mail clients to send signed e-mails.
Solves the problem for them; what about everyone else?
Who cares about everyone else? It solves the problem for them. That is who matters to them.
- The example from TFS highlights an important fact: Google Itself doesn't check against gmail address spoofing
Due to the way SMTP works, the only way to verify that the messages really came from Gmail would be to check the IP of the SMTP server which connected to deliver the message. They could whitelist Gmail's SMTP server, but as I said, non-Gmail users can still participate in a Google Group. Their e-mail addresses could still be spoofed by a spammer. Even if you did a reverse-DNS lookup, you have no guarantee that their e-mail service wouldn't allow someone else to register an account and then spoof their username. Gmail won't, but they can't control other e-mail service providers.
completely false. If google signed their own messages, they could very well verify that they came from their own servers. Though, technically, they could just determine when a mail was being sent from a google server to a google server, and work out any number of secure message transfer mechanisms, rejecting anything from "outside" which claims to be a gmail message. You are just completely and utterly wrong here.
- Google _is_ a central authority over google groups. It would be completely painless for all subscribers of google groups, not just gmail users, since google groups could easily reject all unsigned emails which claim to be from google.
And what about unsigned e-mails which claim to be from non-Gmail users who are members of the group?
I'm not saying your solution wouldn't help, but it wouldn't solve the problem. It seems that spammers could trivially shift gears and bypass your security as long as there were non-Gmail users in the Google Group.
If they are members of the group in question, they are technical people, so they should be able to configure their e-mail client to behave properly.
The real problem is we're talking about two different things:
1) A group of technical people should all be able to sign their e-mails, so why don't they do that instead of complaining about spam?
2) Google should sign all emails which originate from its servers, since SMTP by itself has no way of verifying that "account foo" really sent "message from account foo". This wouldn't verify identity itself, but it would sure-as-hell verify "this particular google account sent this message", which among other things, solves the specific problem mentioned in the summary.
The example in the summary was of a group of people which tried only allowing known users, but that didn't work because of spoofing. Whitelisting doesn't work because google doesn't sign its own messages.
No, you don't _need_ a gmail account to post, yes you can easily get a gmail account, but the example was of a spoofed gmail account. Google should be smart enough to detect such things on its own servers, and nice enough to provide an easy way for others to detect it. (the simple addition of signing emails to validate their origin would at least somewhat legitimize a presently completely-broken system)
Hi! You ignored the majority of my post, drew wild and random conclusions about what I was implying, and responded with a lame copy&paste! Perhaps I can highlight a few key points:
- These are technical people. All of them should be able to configure their mail clients to send signed e-mails.
- The example from TFS highlights an important fact: Google Itself doesn't check against gmail address spoofing
- Google _is_ a central authority over google groups. It would be completely painless for all subscribers of google groups, not just gmail users, since google groups could easily reject all unsigned emails which claim to be from google.
- I never mentioned that this would solve all spam problems for all people everywhere, but wouldn't it be oh-so-useful if a huge and supposedly-tech-savvy company started automatically signing all its mail? This wouldn't do anything to end spam, but it would end spoofing of gmail accounts among gmail services (with absolutely no pain on the part of the users themselves). As a bonus, it would end spoofing of gmail accounts among literate e-mail users.
So, point-by-point: I propose a technical solution to some spam. It requires no cooperation from anyone involved, , though the people in question who would want side-benefits are all literate enough that cooperation would not be a problem, it involves a real-life central authority on the email addresses involved for the services involved, and you should trust google's servers to identify google's users because they are google's servers and google's users- I really wouldn't trust anyone else (note that I'm not saying it establishes identity, only that it establishes "yes, this e-mail went through google") furthermore, if you have a question of "why should I trust server X?" I would suggest you shouldn't be using server X for your group management (ie: you already _DO_ trust the server, no further trust is necessary. In fact, you already trust the server more than you should, because it/doesn't/ already sign its own messages)
You're a group of technologically literate people. Why don't you just sign your messages and verify based on signature, rather than something completely meaningless like email-address?
And once again: Why the hell does google not sign all messages which pass through gmail as "really did come from this address"?
times like this, I just want to be able to say:
sandbox $whatever_command and have it run in a completely safe environment. We have usermode linux, how hard would it be to have such a thing self-contained and operating in a read-from-real-filesystem,write-to-virtual-filesystem,--disable-all,--enable-fake-internet, manner?
Or does such a thing exist? Security for examining someone else's arbitrary commands doesn't seem like it should be an unsolved problem
This has nothing to do with corporation vs company, "rights as an individual", etc. In the U.S.: The group of people is standing over there. In the U.K.: The group of people are standing over there.
Collective nouns are plural in the U.K. (a collection of things) Collective nouns are singular in the U.S. (a collection of things)
Apparently you have done what most people do: You "try adding some topspin" in order to see if it seems to do the same thing you wanted it to. This doesn't actually let you see what is happening, only "I tried this, Hey look! I win now!"
If you actually break down the individual motions and look at how it effects the timing of when different events would be detected, you will realize pretty quickly that every supposedly-captured event can be "faked" through careful timing and a downward flick.
This isn't some vast conspiracy, it's just the limits of the system. The way the inputs were programmed in was: repeatedly performing the desired actions, then letting an automated system build up some heuristics which matched those motions. WiiMotion+, apparently (that is, I have heard) has a much better system for determining what is actually going on, and so has much better heuristics. However, the the original Wii controller is so primitive that it winds up pretty much always being nothing other than "when did this happen?" (basically, it was so horrible that in order to get it to work at all, they needed to turn up the thresholds until they were practically meaningless).
If you think how you swing it doesn't have an effect, you are absolutely, 100% wrong. But if you think it "added topspin" because you moved your wrist in a certain way while swinging, you are 100% wrong. If there are seventy-seven different directions, twists, etc, you can put on the controller while swinging, to produce the same result (animation-wise and ball-direction wise) then it's not motion capture. If delaying or speeding up those actions produces more direction change than actually changing direction, twisting, etc, then it's not motion capture which determines the way the game behaves.
I didn't say that I am unable to get the ball to do what I want it to. I said that I have determined what I need to do in order to get the ball to do what I want- and it's not what you claim it is. Try delaying your swings sometimes, see how realistic the reaction seems.
find me a term which is more-general than "button" but less-general than "input" and I will use it. Pong had two ways to tell the thing to go, Wii tennis has one.
No, it doesn't matter how you swing the thing. Even if someone who was bullshitted by Nintendo's marketing ploy wouldn't notice that. Here's an experiment: Try swinging in various different ways, at various different times, and watch what moves the character on the screen performs, how the ball moves, etc. Don't worry about points, just keep track of what you are doing and what happens. Next, try swinging at various different times, with the same motion each time. Notice the exact same things as before happening on the screen.
Wii Tennis fakes motion-capture by providing you with different motions which tip over the sensor at different times. It's all the same sensor, noticing the same motion, from the same action. It's just noticing at different times. Wii bowling is another good example of this. Wii baseball/would/ be, but it doesn't have the pretense of being anything else.
Slashdot Mirror
Remember when virtualization was only something for companies with highly specialized needs? And RAID? And cooled CPUs? And hard drives? and computers?
When a solution like this comes along, it generally starts out being used only by a few people (nerds and people who REALLY need it)
Then it filters down into the rest of the market as a nice solution to a common problem.
Then it becomes something which nobody can imagine living without.
Then it becomes unthinkable to design a system which doesn't have this ability.
Not true of every technology, surely, but "allow an arbitrary system to fail without stopping" is one of those "how did we ever live without it?" things. People will laugh at "three nines" as something absurd, like advertising that your web servers connect to the Internet or are powered by Electricity.
And here I thought sudo did the opposite of that.
Sudo let's you say "I know I need more privileges to run this program. Here is the user I would like to run it as instead."
this patent let's you say "Run this program" and have the OS respond "That won't work, you probably want to run as Steve or Administrator. Shall I run it as one of them?"
This is very, very different, no matter how little you notice since behind-the-scenes, a program is calling "sudo" when it guesses it needs to. This is another thing, like one-click-shopping, which was probably "obvious" to everybody, but discarded as poor UI ("I'd rather the user need to explicitly ask for privileges, to prevent mistakes.")
But this is not what sudo does.
sounds like every other service in the world which requires relatively-specialized hardware... and none of those have this problem. /tomorrow.html to the end of a URL.
If TiVo just lets anyone anywhere dial in, send a "can I have TV listings?" request, and it responds to those requests with "ok, sure", they don't get to complain about people "stealing" their listings any more than a website can complain about someone adding
It's not stealing if the server says "you can have it" without you saying "I am bill gates, really"
And if you do need to say "I am bill gates, then the process involves more than flipping a bit.
I'd need to actively work to "not change my diet" when exercising. That's part of the deal: When you exercise, the food you want and the amount you eat changes, because your body requires different things.
Okay, I admit right off that I am unfamiliar with TiVo aside from what I've heard mentioned on TV. I don't have a tivo, I don't plan on getting a tivo, I've never actually looked into it.
However, I was under the strong impression that TiVo was a DVR. How can one "crack" or "rip off" a DVR? What does a TiVo provide which would be something that, if one were able to re-flash a TiVo, "crackers" would be able to use to some disadvantage to TiVo? Is TiVo cracking something which is actually done? What benefits does it have? What makes it "bad" as opposed to just "bad for the company that wants you to keep using its software"?
I've never used a package manager that forced you to upgrade all dependencies to the latest version to install a package. All of them allow not just required packages but required versions of packages, and only force upgrades of dependencies when you don't have a sufficiently recent version.
And anyone who has ever wanted to upgrade just one package can tell you that this is clearly insufficient, because every package ever made lazily specifies all they know: "this package works with the version I have, therefore it requires the version I have." If this lazy way is the easiest method of specifying requirements, it is what will be used- you can tell, because it is what is used. If you are dealing with what is considered to be a non-trivial requirement by package managers, you will have run into this problem. "I know this requires version N. I have read the source, I know where Foo is being called, I know that this works in all versions since A. But the package maintainer didn't say "requires this feature" they said "requires version Q of package Foo", so I can't use the dependency management for this package". Blame the maintainer, not the system? Not bloody likely. Sometimes you see ugly hacks like "virtual packages" and "meta packages" which attempt to abuse the limits of the package manager and act as if a real providesrequires system is in place.
Some can do patches. I think RPM can. But unless you're using dialup, they're not really that much of advantage. And you also have the problem of having to provide patches from lots of versions to lots of versions. Or you can provide only patches from the last version to the current one, in which case they're useless for anyone who misses an upgrade.
This is a solved problem. Some package managers actually /do/ send binary patches, as does every software company on the planet. If there were a valid excuse for not doing it, it wouldn't be a problem.
I don't know any package manager that does this. For example, Pacman, the package manager of Arch (my current distro of choice), installs new versions of files with the suffix '.pacnew' if the old version was modified and doesn't clobber.
The "not clobbering" part is /usually/ true of configuration files, though it really all depends on what you consider to be "configuration", which you'll find yourself disagreeing with often enough to wonder why the hell the rule isn't applied universally. And yes, the second-half of that applies even to configuration files: Putting "oh, I didn't clobber this file, here's the one I wanted to stick somewhere" in a random tree, sometimes with no notification, and rarely with /useful/ notification ("speak now or forever hold your peace" notification is the bane of any upgrade, especially when combined with the point above about too-many-things-upgrading just because you wanted _one_ change), does nothing to help you find out what has changed between versions. If the only thi
you can mount a loopback device, this is pretty much the only sane way to try out another filesystem
point-by-point:
- it's not "you died, and are dead" it's "you never existed because activation destroyed the universe". As in: nobody ever activated it, so universes where activation is possible do not exist. No one exists to comment on their survival "so-far", the universe is all-encompassing.
- The universe doesn't actively prevent anything. In an infinity of universes, there are universes where X is physically impossible, and there are universes where X never happens despite being possible. If something never happens despite being possible, and has humans in it, some pretty unlikely events would need to happen. Yes, I do believe that physical impossibility is much more likely and so we are probably in a universe which is simply impossible to destroy, but that doesn't mean option B cannot be, especially if the technology to destroy oneself in easier ways comes along before the technology to destroy the whole universe.
- I did not mention the Higgs boson, so detection of it is unrelated.
- If activation of the LHC destroys the universe and its past, we must exist in a universe in which the universe which does not activate the LHC. The same can be said of Britney Spears releasing another hit, and I think it's no less valid.
I don't know how you got "the universe can't tolerate a paradox" from "universes which create higgs bosons don't exist because they are destroyed by that creation". Can you please describe something more paradoxical? Really I tend to think the whole idea is generally absurd because it requires a paradox - though personally I don't shy away from such things, at least for thought experiments.
All joking about the LHC aside, I do assume that it's impossible to lower entropy in a closed system because all universes in which this is possible have been destroyed by some member of the first intelligent species playing around with their toaster- I figure this would make it much more likely (even if it is infinity vs N*infinity) to exist in a universe which doesn't allow such things.
this theory has actually been proposed: That activating the LHC would actually destroy the universe, that is, the whole universe, even reaching back into the past. That would mean that the only possible universes are ones in which the LHC is never activated, which means that if we keep trying, implausible events will continue to occur, preventing the LHC from activating- after all, we're here now, right. That's _proof_ that the LHC will never be activated!
The state of package management is atrocious, and so should not be looked to for solutions? I'd call that a pretty big one.
MOST packages need only the functionality of a dependency manager, everything else being a nice-to-have-when-you-need-it feature. This is why dependency management can be considered to be the central feature of a package manager- if you don't have dependency management, you'd be hard-pressed to find anyone who claims you have a working package manager.
And what do most package managers do? Utterly lazy dependency management. "Well, you need this package... so you should have the latest version of it. If you want another version, you should rename the package and depend on something else instead."
And that would be almost-excusable, except for the brain-dead "open source is king" approach for updates: "The whole-thing's free anyway, why not just re-send the whole thing?" binary patches are pretty-much unheard of. Of course, sending the whole thing is really just a work-around because-
Package managers generally do NOT bother to detect when they are about to clobber or alter "the wrong file". When they do, they don't bother to keep a record of what they /would/ consider to be "the right file", making "merging" impossible and difference examination a guessing game. That doesn't even matter, because the first step in an "Upgrade" is usually to just completely remove the existing package, which means...
Multiple versions of a single package co-existing on the same base install is generally impossible. Which really makes you wonder what the hell a package manager /does/ manage.
It's not third-party software, that's for sure. You want the bleeding-edge version of something? You just want to patch a broken package? That means you're not using the package manager, and that means you're on your own for everything. Either you build a /package/ for what you're doing on the side, or you don't get access to any of the supposed features. And anything that depends on what you're doing, you may as well just compile and track yourself- 'cause that's what you like doing, right?
The short of it is: Package managers seem so fundamentally broken that giving them another task seems like a waste of time. They'll just be replaced by a better system eventually anyway, right? And then you'll need to do it all again.
The closest to "right" I've seen is GoboLinux.
And you can do all of that from different /directories/ without worrying about what partition something is on (you know, that's one of those things about unix: it pretty much _never_ cares how a directory is stored, unless you tell it to)
I suppose if you have an abysmally broken installer which clobbers things without asking, and only installs to the root of a mountpoint(seriously?), and deletes random files it doesn't even know about, then it might matter.
Otherwise, you probably just read a guide from 1970 about how to partition your hard drives, or something copied from a copy of a copy of one, and never actually thought about it or tried it.
How does partitioning have any effect on your ability to upgrade/downgrade, unless your distribution's installer is utterly, beyond-all-hope, broken-as-fuck?
He died forty years after they were written. If copyright law were at all sane, there would be no need for "authorization", and there would already be 500 sequels, some of which might be good. A dead guy's intentions regarding old books should not be the concern of anyone other than someone studying literature.
The example in the article would not have happened.
Various other things would be much better.
It completely, 100%, solves the problem for this situation.
Even if a group of technically-minded people couldn't be bothered to configure their mail clients to sign their own messages, I bet they could be convinced to send google-groups messages through google.
And finally, there are many, many side-benefits.
- These are technical people. All of them should be able to configure their mail clients to send signed e-mails.
Solves the problem for them; what about everyone else?
Who cares about everyone else? It solves the problem for them. That is who matters to them.
- The example from TFS highlights an important fact: Google Itself doesn't check against gmail address spoofing
Due to the way SMTP works, the only way to verify that the messages really came from Gmail would be to check the IP of the SMTP server which connected to deliver the message. They could whitelist Gmail's SMTP server, but as I said, non-Gmail users can still participate in a Google Group. Their e-mail addresses could still be spoofed by a spammer. Even if you did a reverse-DNS lookup, you have no guarantee that their e-mail service wouldn't allow someone else to register an account and then spoof their username. Gmail won't, but they can't control other e-mail service providers.
completely false. If google signed their own messages, they could very well verify that they came from their own servers. Though, technically, they could just determine when a mail was being sent from a google server to a google server, and work out any number of secure message transfer mechanisms, rejecting anything from "outside" which claims to be a gmail message. You are just completely and utterly wrong here.
- Google _is_ a central authority over google groups. It would be completely painless for all subscribers of google groups, not just gmail users, since google groups could easily reject all unsigned emails which claim to be from google.
And what about unsigned e-mails which claim to be from non-Gmail users who are members of the group?
I'm not saying your solution wouldn't help, but it wouldn't solve the problem. It seems that spammers could trivially shift gears and bypass your security as long as there were non-Gmail users in the Google Group.
If they are members of the group in question, they are technical people, so they should be able to configure their e-mail client to behave properly.
The real problem is we're talking about two different things:
1) A group of technical people should all be able to sign their e-mails, so why don't they do that instead of complaining about spam?
2) Google should sign all emails which originate from its servers, since SMTP by itself has no way of verifying that "account foo" really sent "message from account foo". This wouldn't verify identity itself, but it would sure-as-hell verify "this particular google account sent this message", which among other things, solves the specific problem mentioned in the summary.
The example in the summary was of a group of people which tried only allowing known users, but that didn't work because of spoofing. Whitelisting doesn't work because google doesn't sign its own messages.
No, you don't _need_ a gmail account to post, yes you can easily get a gmail account, but the example was of a spoofed gmail account. Google should be smart enough to detect such things on its own servers, and nice enough to provide an easy way for others to detect it. (the simple addition of signing emails to validate their origin would at least somewhat legitimize a presently completely-broken system)
Hi! You ignored the majority of my post, drew wild and random conclusions about what I was implying, and responded with a lame copy&paste! Perhaps I can highlight a few key points:
- These are technical people. All of them should be able to configure their mail clients to send signed e-mails.
- The example from TFS highlights an important fact: Google Itself doesn't check against gmail address spoofing
- Google _is_ a central authority over google groups. It would be completely painless for all subscribers of google groups, not just gmail users, since google groups could easily reject all unsigned emails which claim to be from google.
- I never mentioned that this would solve all spam problems for all people everywhere, but wouldn't it be oh-so-useful if a huge and supposedly-tech-savvy company started automatically signing all its mail? This wouldn't do anything to end spam, but it would end spoofing of gmail accounts among gmail services (with absolutely no pain on the part of the users themselves). As a bonus, it would end spoofing of gmail accounts among literate e-mail users.
So, point-by-point: /doesn't/ already sign its own messages)
I propose a technical solution to some spam. It requires no cooperation from anyone involved, , though the people in question who would want side-benefits are all literate enough that cooperation would not be a problem, it involves a real-life central authority on the email addresses involved for the services involved, and you should trust google's servers to identify google's users because they are google's servers and google's users- I really wouldn't trust anyone else (note that I'm not saying it establishes identity, only that it establishes "yes, this e-mail went through google") furthermore, if you have a question of "why should I trust server X?" I would suggest you shouldn't be using server X for your group management (ie: you already _DO_ trust the server, no further trust is necessary. In fact, you already trust the server more than you should, because it
You're a group of technologically literate people. Why don't you just sign your messages and verify based on signature, rather than something completely meaningless like email-address?
And once again: Why the hell does google not sign all messages which pass through gmail as "really did come from this address"?
times like this, I just want to be able to say:
sandbox $whatever_command
and have it run in a completely safe environment.
We have usermode linux, how hard would it be to have such a thing self-contained and operating in a read-from-real-filesystem,write-to-virtual-filesystem,--disable-all,--enable-fake-internet, manner?
Or does such a thing exist? Security for examining someone else's arbitrary commands doesn't seem like it should be an unsolved problem
"beyond a certain point, high resolution is most useful for something really really useful, therefore is completely useless"
This has nothing to do with corporation vs company, "rights as an individual", etc.
In the U.S.: The group of people is standing over there.
In the U.K.: The group of people are standing over there.
Collective nouns are plural in the U.K. (a collection of things)
Collective nouns are singular in the U.S. (a collection of things)
Apparently you have done what most people do: You "try adding some topspin" in order to see if it seems to do the same thing you wanted it to. This doesn't actually let you see what is happening, only "I tried this, Hey look! I win now!"
If you actually break down the individual motions and look at how it effects the timing of when different events would be detected, you will realize pretty quickly that every supposedly-captured event can be "faked" through careful timing and a downward flick.
This isn't some vast conspiracy, it's just the limits of the system. The way the inputs were programmed in was: repeatedly performing the desired actions, then letting an automated system build up some heuristics which matched those motions. WiiMotion+, apparently (that is, I have heard) has a much better system for determining what is actually going on, and so has much better heuristics. However, the the original Wii controller is so primitive that it winds up pretty much always being nothing other than "when did this happen?" (basically, it was so horrible that in order to get it to work at all, they needed to turn up the thresholds until they were practically meaningless).
If you think how you swing it doesn't have an effect, you are absolutely, 100% wrong. But if you think it "added topspin" because you moved your wrist in a certain way while swinging, you are 100% wrong. If there are seventy-seven different directions, twists, etc, you can put on the controller while swinging, to produce the same result (animation-wise and ball-direction wise) then it's not motion capture. If delaying or speeding up those actions produces more direction change than actually changing direction, twisting, etc, then it's not motion capture which determines the way the game behaves.
I didn't say that I am unable to get the ball to do what I want it to. I said that I have determined what I need to do in order to get the ball to do what I want- and it's not what you claim it is. Try delaying your swings sometimes, see how realistic the reaction seems.
find me a term which is more-general than "button" but less-general than "input" and I will use it. Pong had two ways to tell the thing to go, Wii tennis has one.
No, it doesn't matter how you swing the thing. Even if someone who was bullshitted by Nintendo's marketing ploy wouldn't notice that. Here's an experiment: Try swinging in various different ways, at various different times, and watch what moves the character on the screen performs, how the ball moves, etc. Don't worry about points, just keep track of what you are doing and what happens.
Next, try swinging at various different times, with the same motion each time. Notice the exact same things as before happening on the screen.
Wii Tennis fakes motion-capture by providing you with different motions which tip over the sensor at different times. It's all the same sensor, noticing the same motion, from the same action. It's just noticing at different times. Wii bowling is another good example of this. Wii baseball /would/ be, but it doesn't have the pretense of being anything else.