That...depends. Wearing one of the T-shirts could, depending on context, be easily construed as "use...in advertising of...services...in connection of which the use is likely to cause confusion" (15 USC Sect. 1114(1)(a)), especially since the logo is one (prior to seizure) of a voluntary association, where the wearing of the logo by members is a pretty standard way of advertising the association and its "services".
This would be a great precedent. And the next time Microsoft is charged with something, part of the punishment would be losing "Windows" or maybe even the copyright on Office 2003 or something.
This would only be "precedent" for that if what Microsoft was convicted of (not merely "charged with") was a RICO violation; of course, if Microsoft was charged with being a criminal enterprise under RICO, seizing a few bits of IP would be pretty low on the scale of what the government could seek as a remedy.
What I called bullshit on was the claim that by seizing the gang's trademark they would somehow be able to prevent the gang members from wearing jackets with the logo on it.
I think you missed the point of my response. I'm not saying that seizing the trademark would allow that. I'm saying that it seems most likely that, to acheive what they are describing, they are seeking a forfeiture order under Sect. 1963(a) against the trademark and the tangible property incorporating the trademark.
That is, the ability to seize the items would not come about as an application of trademark law following the forfeiture of the trademark, but as a part of the order under RICO along with the seizure of the trademark. So, what trademark law would empower the trademark holder to do is essentially irrelevant to the issue.
I'm not aware of any law that can prevent a particular logo from appearing on a jacket.
It seems only tangentially related to trademark law; the reference in TFA to a racketeering indictment makes it seem pretty likely that they are looking for, an order under the Racketeer Influenced and Corrupt Organization (RICO) Act, specifically, 18 USC Sect. 1963(a), declaring that the trademarked logo, and the tangible items created using the trademarked logo, are "property constituting, or derived from, any proceeds which the person obtained, directly or indirectly, from racketeering activity [...] in violation of section 1962 [of Title 18]", and therefore subject to forfeiture under RICO.
If you actually look for where the performance bottlenecks are and remove them, you get better efficiency. Who would ever have guessed?
Re:There's only ONE way to get security: JESUS CHR
on
Schneier on Security
·
· Score: 1
The point is that you do not get to decide whether someone else is a Christian any more than you get to decide whether they are a Scotsman, they get to decide if they are a Christian.
I would say that's not the point at all. The "no true Scotsman" fallacy isn't really a distinct fallacy, its either a case of circular argument or equivocation. If there is an agreed upon definition of "Scotsman" that applies to the given discussion, its perfectly legitimate to point out that an trait asserted to be associated with at least some Scotsmen is, in fact, inconsistent with that definition and thus, no true Scotsman has that feature.
Where it becomes problematic is: 1) Where no such definition exists, and the proposition being debated is precisely whether or not the trait involved is a trait of at least some "Scotsmen". In this case, its something of a circular argument, but it also can reveal that a fundamental problem in the discussion is the ambiguous definition of terms. 2) Where such a definition does exist (or at least, where a different definition of "Scotsman" is being used in the discussion), but the definition which excludes the trait from any "true Scotsman" is a different definition of Scotsmen. In this case, the fallacy is one of equivocation.
The principle problem that usually arises with "no true Scotsman" style arguments is where the person using them is making an argument that is trivially true for some definition of "Scotsman", but where the real interest in the discussion is in a different definition (or where, simply, the difference in definitions isn't that one is the "more interesting" one for the discussion, but instead just reveals that the participants are talking past each other about two or more completely different things.) It is not that one definition is necessarily objectively correct; there are many different, legitimate definitions of many terms ("Christian", for instance, can usefully defined by self-identification, by adherence to particular belief sets, or by participation in particular groups, and for each of those there are places where those are interesting and useful definitions), the key is that in a discussion, to be productive, people have to be applying the same definitions to the same terms.
Moreover, what does Security stand to gain by detaining and berating someone who isn't fooled by their faux security?
They stand to gain by, e.g., motivating GPs post, in which he suggests that people who notice this kind of security theater should keep their mouth shut and not reveal it. Developing this kind of attitude, of course, supports the goal of security theater, since it reduces the probability that its shortfalls as actual security will be noted.
Of course the compiler "carefully constructs" the loops to have the properties they are supposed to have!
The compiler can't carefully construct loops to be provably finite or infinite, unless the original programmer did, assuming its a compiler for a Turing-complete langauge. Moving the provably impossible task to a different component doesn't change the facts.
The bytecode verifier is there to make sure that the compiler isn't lying
A bytecode verifier doesn't get you any advantage here; what you are really checking is that the programmer isn't lying. In the case where the source language is expressive enough for the programmer to make claims about the provable properties of the code, it is exactly as difficult to analyze the source code as to do so for any compiled form that expresses the same program. The ability to make and to verify the claims is a feature of the source language, to which whether or not you compile to bytecode or run it one a virtual machine is entirely irrelevant. It doesn't even affect the practicality of having a separate pass (what you seem to be attributing to the compiler) where the programmer doesn't make any claims, but the first pass attempts to infer properties (such as provable termination) about code units and incorporate those claims along with the associated proofs into the code, and then a separate process verifies them. Assuming you have a suitably expressive source language, you can do that with a preprocessor in the source language that adds in the claims as annotations; compiling to bytecode is entirely irrelevant to the ability to add that additional information.
The only time compilation to bytecode has any relevance to any of this is if you do the two step process, using a source language without the expressiveness to express the provable properties and asserted proofs, but a bytecode that has that expressiveness. But the fact that that the second language is "bytecode" isn't really important to that, its just a matter of language expressiveness.
Is there? The closest thing I've heard of is HotRuby, which is a VM implemented in JavaScript that runs (currently, a subset of) the same bytecode as the Ruby 1.9 VM. This is not a "Ruby-to-JavaScript" compiler, or even a compiler at all.
IOW, it can't show that there are no infinite loops, unless all the actual loops are carefully constructed to be provably finite, in which case you don't need it to do that in the first place.
I saw this all the time at schools, jobs and like. People dont like smart people. People who intentionally find broken ideas and mechanisms will be dealt with, not glorified and congratulated.
This has nothing to do with smart people, it has to do with people who undermine the purpose of the system. In the case of "security" systems, many of them are not intended (from the point of view of at least some of the responsible parties: often there is a conflict) to provide security, they are intended to provide the appearance of security, which means that, contrary to what the "smart" people assume, those "smart" people are not pointing out failures to meet the actual design goal and thereby helping the system work better, they are directly undermining the actual design goal.
If you're really smart, you won't assume that people whose vested interest is in the appearance of security are concerned with the reality of security, or vice versa. And if people are concerned with the latter and you see a problem with the latter, you will make sure that, if you raise it at all, you do it in the context of how it is an inevitable problem with the former because someone hostile will inevitably discover it, and how the best way to fix it is the way that happens to provide actual security.
Its easier to get the response you want by showing people how that advances the intersts that they actually have, rather than the interests you think they should have. (You can work on changing priorities, too, but that's generally a longer term project, and even that can't work unless you are conscious of where people are coming from to start with.)
Ask a language theorist, and they will say, sure, but bytecode verification can check things like:
there are no infinite loops
Well, no, it can't, at least not comprehensively. It can identify provably finite and provably infinite loops, but there are large classes of loops that can be written in any Turing-complete language that don't fall into either category.
If your product works, or at least appears to, and you have a sound plan for getting it to market, where it will be purchased, then SOMEONE will loan you the money.
The credit crunch has hit carmakers (the big ones, too, not just niche guys like Tesla) because its much harder for people to get loans to buy cars. Also, a lot of the capital that would fund promising growing companies has simply ceased to exist. On top of that, Tesla is trying to build a market for a fairly high-end luxury product, and the present credit crisis is widely expected by economists to lead to a deep and fairly long recession (and the "D" word has been batted about), so even if the product is good, the market conditions for it have suddenly become quite bad, and what investment capital still exists is most likely going to be devoted to products that have better prospects given the economic conditions investors expect to prevail over the next few years.
ANYTHING that Windows wants to do to improve sucks and linux has already done it, done it better
No, anything Windows wants to do to improve either sucks or Linux (or OS X, or both) has done it first. Very few things, at the level of the general concept for "improvement", fall into both categories, though some things Windows seeks to do to improve have already been done fairly well first by Linux (etc.), and when Windows finally does them, the Windows implementation also manages to suck (Vista UAC seems to fall into this category).
Seriously is there anyone on/. that isn't a "me too, me too" Microsoft sucks, Linux is good person?
Aside from the licensing structure, and monopolistic corporate behavior, I don't think Microsoft sucks. I Microsoft Office is a fine office suite (note, I'm not talking about Office Open XML format and the manipulations around that, just the software itself), and I think Visio's a great product (not the best cost:benefit ratio, as is typical of MS software).
OTOH, I think, but for the available application base, Windows sucks compared to other OS's (I still use it, mostly, because of the available application base). (Actually, from what I hear, it seems like Windows Server doesn't seem to suck as bad as the various desktop editions, and could even be respun into a non-sucky desktop OS.)
Yet amazingly enough planes crash. They crash quite often in fact. In fact from what I remember the chance to die per hour of travel is roughly the same between airplanes and cars.
Looking at the same data in another (and for more relevant to any useful comparison) way (and assuming it is completely accurate), the chance of dying per mile in a plane is a small fraction of that in a car. Rarely does anyone face a decision of the form, "Given that I need to spend N hours traveling, should I take a car, bus, train, or airplane." Rather, they are more likely to decide "Given taht I want to get from Point A to Point B, should I take a car, etc." So, really, the risk of death per hour of travel is pretty much irrelevant.
Most human wars throughout the ages are based on religion. Scary, isn't it?
Scary, perhaps, but not at all true. Almost every war is entered into for economic reasons by the decision makers; religion, nationalism, and other forms of identity appeals are often used in appeals to keep the masses behind the war, but they generally aren't the main reasons, and often not reasons at all, for the war.
The problem is that at the time of search, the warrant was not false. It was a real warrant, it just had not been removed yet.
No, it was not a real warrant. The real warrant no long was valid. The electronic record of the warrant still existed, but the existence of the electronic record is not the same as the existence of a valid warrant; that's rather the whole point here. The argument that the evidence is admissible is based on the officer's good faith belief that they were operating under a valid warrant. The justification of a good faith exception is that the exclusionary rule, applied then, would not encourage better police behavior and adherence with the Constitutional limits on their power, because they had no reasonable way of knowing that what they were doing are wrong.
An argument against the application of the good faith exception to cases like this is that applying it encourages departments to selectively adopt practices that encourage that, e.g., records of warrants that become invalid are not removed promptly, because this increases the power of the department to search people in the field, with no consequences due to the good faith exception.
They seriously need to be taken down a notch legally so they don't lawyer up at every opportunity.
Uh. Being taken down a notch legally makes a company (or person) generally more prone to "lawyering up", in any reasonable sense of the phrase, early and pre-emptively in any future circumstances where legal action might potentially occur. So I don't follow the logic, here.
These kind of compatibility switches are make-or-break. I'm glad there's Python 2.6 to try to ease the problem, but Py3k means that everybody who publishes python software will all of a sudden have to maintain 2 branches, for Python 2.X line and Python 3.X line.
No, they don't "have to" maintain two branches. They can choose to, or they can maintain one (which depends on their particular circumstance); if necessary (if it is an app and not a library) they can just distribute the right interpreter with the app.
This isn't the same as one software package having "legacy" and "bleeding edge" branches, because that's their own choice.
Yeah, actually, it is exactly the same as that, at least as long as bug-fixes and maintenance continues on Python 2.x: the "one software package" being the Python interpreter.
And, yeah, if those maintaining python-based projects choose to maintain Python-2.x and Python-3.x based versions, that will also be an instance of exactly what you say it wouldn't be, as it will still be their own choice.
The developers were laid off? How is that even possible on an open source project?
The fact that a product is released under an open source license does not mean that the project does not have a regular, paid development staff employed by the copyright holder. It may or may not also accept community contributions (but accepting community contributions, while typical of open source projects, is not a necessary feature of open source project: you can develop in a completely closed shop with no community involvement and still release under, say, the GPL and thus be an open source project.)
An appeals court has erased most of the doubt around Open Source licensing, permanently
Bull. Even Supreme Court decisions can rarely reasonably be interpreted, without some historical perspective, as doing anything permanently, but describing a mere intermediate appellate court decision this way is sheer spin and hyperbole.
I often wonder why Toyota pulled the plugin capabilities from the Prius, the hardware is there in the first generation models, my friend has a kit to convert his once the battery warranty is up and there's not a lot to it, just a plug that attaches to some internal terminals and a chip mod to delay the engine warm-up until the battery is much further drained.
The second part of that, IIRC, only requires a mod of any kind in US models, its activated by an "EV mode" (often called "stealth mode") button that's standard in Asian and European Prius models (both in the current and first-gen models).
Slashdot Mirror
That...depends. Wearing one of the T-shirts could, depending on context, be easily construed as "use...in advertising of...services...in connection of which the use is likely to cause confusion" (15 USC Sect. 1114(1)(a)), especially since the logo is one (prior to seizure) of a voluntary association, where the wearing of the logo by members is a pretty standard way of advertising the association and its "services".
This would only be "precedent" for that if what Microsoft was convicted of (not merely "charged with") was a RICO violation; of course, if Microsoft was charged with being a criminal enterprise under RICO, seizing a few bits of IP would be pretty low on the scale of what the government could seek as a remedy.
I think you missed the point of my response. I'm not saying that seizing the trademark would allow that. I'm saying that it seems most likely that, to acheive what they are describing, they are seeking a forfeiture order under Sect. 1963(a) against the trademark and the tangible property incorporating the trademark.
That is, the ability to seize the items would not come about as an application of trademark law following the forfeiture of the trademark, but as a part of the order under RICO along with the seizure of the trademark. So, what trademark law would empower the trademark holder to do is essentially irrelevant to the issue.
It seems only tangentially related to trademark law; the reference in TFA to a racketeering indictment makes it seem pretty likely that they are looking for, an order under the Racketeer Influenced and Corrupt Organization (RICO) Act, specifically, 18 USC Sect. 1963(a), declaring that the trademarked logo, and the tangible items created using the trademarked logo, are "property constituting, or derived from, any proceeds which the person obtained, directly or indirectly, from racketeering activity [...] in violation of section 1962 [of Title 18]", and therefore subject to forfeiture under RICO.
If you actually look for where the performance bottlenecks are and remove them, you get better efficiency. Who would ever have guessed?
I would say that's not the point at all. The "no true Scotsman" fallacy isn't really a distinct fallacy, its either a case of circular argument or equivocation. If there is an agreed upon definition of "Scotsman" that applies to the given discussion, its perfectly legitimate to point out that an trait asserted to be associated with at least some Scotsmen is, in fact, inconsistent with that definition and thus, no true Scotsman has that feature.
Where it becomes problematic is:
1) Where no such definition exists, and the proposition being debated is precisely whether or not the trait involved is a trait of at least some "Scotsmen". In this case, its something of a circular argument, but it also can reveal that a fundamental problem in the discussion is the ambiguous definition of terms.
2) Where such a definition does exist (or at least, where a different definition of "Scotsman" is being used in the discussion), but the definition which excludes the trait from any "true Scotsman" is a different definition of Scotsmen. In this case, the fallacy is one of equivocation.
The principle problem that usually arises with "no true Scotsman" style arguments is where the person using them is making an argument that is trivially true for some definition of "Scotsman", but where the real interest in the discussion is in a different definition (or where, simply, the difference in definitions isn't that one is the "more interesting" one for the discussion, but instead just reveals that the participants are talking past each other about two or more completely different things.) It is not that one definition is necessarily objectively correct; there are many different, legitimate definitions of many terms ("Christian", for instance, can usefully defined by self-identification, by adherence to particular belief sets, or by participation in particular groups, and for each of those there are places where those are interesting and useful definitions), the key is that in a discussion, to be productive, people have to be applying the same definitions to the same terms.
They stand to gain by, e.g., motivating GPs post, in which he suggests that people who notice this kind of security theater should keep their mouth shut and not reveal it. Developing this kind of attitude, of course, supports the goal of security theater, since it reduces the probability that its shortfalls as actual security will be noted.
The compiler can't carefully construct loops to be provably finite or infinite, unless the original programmer did, assuming its a compiler for a Turing-complete langauge. Moving the provably impossible task to a different component doesn't change the facts.
A bytecode verifier doesn't get you any advantage here; what you are really checking is that the programmer isn't lying. In the case where the source language is expressive enough for the programmer to make claims about the provable properties of the code, it is exactly as difficult to analyze the source code as to do so for any compiled form that expresses the same program. The ability to make and to verify the claims is a feature of the source language, to which whether or not you compile to bytecode or run it one a virtual machine is entirely irrelevant. It doesn't even affect the practicality of having a separate pass (what you seem to be attributing to the compiler) where the programmer doesn't make any claims, but the first pass attempts to infer properties (such as provable termination) about code units and incorporate those claims along with the associated proofs into the code, and then a separate process verifies them. Assuming you have a suitably expressive source language, you can do that with a preprocessor in the source language that adds in the claims as annotations; compiling to bytecode is entirely irrelevant to the ability to add that additional information.
The only time compilation to bytecode has any relevance to any of this is if you do the two step process, using a source language without the expressiveness to express the provable properties and asserted proofs, but a bytecode that has that expressiveness. But the fact that that the second language is "bytecode" isn't really important to that, its just a matter of language expressiveness.
Is there? The closest thing I've heard of is HotRuby, which is a VM implemented in JavaScript that runs (currently, a subset of) the same bytecode as the Ruby 1.9 VM. This is not a "Ruby-to-JavaScript" compiler, or even a compiler at all.
IOW, it can't show that there are no infinite loops, unless all the actual loops are carefully constructed to be provably finite, in which case you don't need it to do that in the first place.
This has nothing to do with smart people, it has to do with people who undermine the purpose of the system. In the case of "security" systems, many of them are not intended (from the point of view of at least some of the responsible parties: often there is a conflict) to provide security, they are intended to provide the appearance of security, which means that, contrary to what the "smart" people assume, those "smart" people are not pointing out failures to meet the actual design goal and thereby helping the system work better, they are directly undermining the actual design goal.
If you're really smart, you won't assume that people whose vested interest is in the appearance of security are concerned with the reality of security, or vice versa. And if people are concerned with the latter and you see a problem with the latter, you will make sure that, if you raise it at all, you do it in the context of how it is an inevitable problem with the former because someone hostile will inevitably discover it, and how the best way to fix it is the way that happens to provide actual security.
Its easier to get the response you want by showing people how that advances the intersts that they actually have, rather than the interests you think they should have. (You can work on changing priorities, too, but that's generally a longer term project, and even that can't work unless you are conscious of where people are coming from to start with.)
Well, no, it can't, at least not comprehensively. It can identify provably finite and provably infinite loops, but there are large classes of loops that can be written in any Turing-complete language that don't fall into either category.
The credit crunch has hit carmakers (the big ones, too, not just niche guys like Tesla) because its much harder for people to get loans to buy cars. Also, a lot of the capital that would fund promising growing companies has simply ceased to exist. On top of that, Tesla is trying to build a market for a fairly high-end luxury product, and the present credit crisis is widely expected by economists to lead to a deep and fairly long recession (and the "D" word has been batted about), so even if the product is good, the market conditions for it have suddenly become quite bad, and what investment capital still exists is most likely going to be devoted to products that have better prospects given the economic conditions investors expect to prevail over the next few years.
No, anything Windows wants to do to improve either sucks or Linux (or OS X, or both) has done it first. Very few things, at the level of the general concept for "improvement", fall into both categories, though some things Windows seeks to do to improve have already been done fairly well first by Linux (etc.), and when Windows finally does them, the Windows implementation also manages to suck (Vista UAC seems to fall into this category).
Aside from the licensing structure, and monopolistic corporate behavior, I don't think Microsoft sucks. I Microsoft Office is a fine office suite (note, I'm not talking about Office Open XML format and the manipulations around that, just the software itself), and I think Visio's a great product (not the best cost:benefit ratio, as is typical of MS software).
OTOH, I think, but for the available application base, Windows sucks compared to other OS's (I still use it, mostly, because of the available application base). (Actually, from what I hear, it seems like Windows Server doesn't seem to suck as bad as the various desktop editions, and could even be respun into a non-sucky desktop OS.)
Since the comparison was being driving and flying, only the former choice is even remotely relevant.
The absolute risk of the best method available is relevant to the latter choice, of course.
Uh, an SLA for free customers? So, the people who aren't paying anything could get a refund if Google's uptime in a month is below some floor.
What good would that do?
Looking at the same data in another (and for more relevant to any useful comparison) way (and assuming it is completely accurate), the chance of dying per mile in a plane is a small fraction of that in a car. Rarely does anyone face a decision of the form, "Given that I need to spend N hours traveling, should I take a car, bus, train, or airplane." Rather, they are more likely to decide "Given taht I want to get from Point A to Point B, should I take a car, etc." So, really, the risk of death per hour of travel is pretty much irrelevant.
Scary, perhaps, but not at all true. Almost every war is entered into for economic reasons by the decision makers; religion, nationalism, and other forms of identity appeals are often used in appeals to keep the masses behind the war, but they generally aren't the main reasons, and often not reasons at all, for the war.
Having a "Lisp without the macro facility" is like having a Porsche 911 Turbo without the engine.
No, it was not a real warrant. The real warrant no long was valid. The electronic record of the warrant still existed, but the existence of the electronic record is not the same as the existence of a valid warrant; that's rather the whole point here. The argument that the evidence is admissible is based on the officer's good faith belief that they were operating under a valid warrant. The justification of a good faith exception is that the exclusionary rule, applied then, would not encourage better police behavior and adherence with the Constitutional limits on their power, because they had no reasonable way of knowing that what they were doing are wrong.
An argument against the application of the good faith exception to cases like this is that applying it encourages departments to selectively adopt practices that encourage that, e.g., records of warrants that become invalid are not removed promptly, because this increases the power of the department to search people in the field, with no consequences due to the good faith exception.
Uh. Being taken down a notch legally makes a company (or person) generally more prone to "lawyering up", in any reasonable sense of the phrase, early and pre-emptively in any future circumstances where legal action might potentially occur. So I don't follow the logic, here.
No, they don't "have to" maintain two branches. They can choose to, or they can maintain one (which depends on their particular circumstance); if necessary (if it is an app and not a library) they can just distribute the right interpreter with the app.
Yeah, actually, it is exactly the same as that, at least as long as bug-fixes and maintenance continues on Python 2.x: the "one software package" being the Python interpreter.
And, yeah, if those maintaining python-based projects choose to maintain Python-2.x and Python-3.x based versions, that will also be an instance of exactly what you say it wouldn't be, as it will still be their own choice.
The fact that a product is released under an open source license does not mean that the project does not have a regular, paid development staff employed by the copyright holder. It may or may not also accept community contributions (but accepting community contributions, while typical of open source projects, is not a necessary feature of open source project: you can develop in a completely closed shop with no community involvement and still release under, say, the GPL and thus be an open source project.)
Bull. Even Supreme Court decisions can rarely reasonably be interpreted, without some historical perspective, as doing anything permanently, but describing a mere intermediate appellate court decision this way is sheer spin and hyperbole.
The second part of that, IIRC, only requires a mod of any kind in US models, its activated by an "EV mode" (often called "stealth mode") button that's standard in Asian and European Prius models (both in the current and first-gen models).