I find this implausible. At what point in the development of the AI would we cut the cord beween the AI level and the storage level?
That's a good question, and I'm not sure of the answer. It depends on how we develop the AI. For example, if we use genetic algorithms, we might not have any choice in the matter. Similarly, if we take some approach that mimics the human brain, it might be impossible to re-wire direct storage access into that model.
Developing AI is probably (unless we're missing something stupid!) going to be way hard, and insisting that we can't cut that cord might be (is probably, IMO) infeasible. Well, as another poster said, read GEB if you haven't.
I don't see how this is possible, since (theoretically) any electronic
lifeform would have perfect memory. If you have a perfect, electronic memory
then how would the government or MPAA/RIAA know that you're not "pirating"
some music/movies/books in there?
This is a misconception about AI. Just because an AI implementation has a
mass digital storage, doesn't mean the AI "being" has mass digital storage in
any significant sense. The AI level is so far above the storage level, that
the AI would probably not interface to the storage any differently from how you
or I would. In other words, it would be little different from a person with
an MP3/DVD player.
Similarly, an AI would not necessarily be a lightning calculator, even
though it's built of of the same chips that can do a billion additions per
second. In the AI's "mind", as in ours, numbers are high-level symbols, not
RAM words. The AI has no more access to its RAM than we have to our
neurons.
Of course, I can't prove this, but I'm quite persuaded.
This was a fairly reasonable (if unexceptional, being a rehash of a
rehash) article, until the author got to his recommendations:
However, all of these issues can and are solved in projects with a
disciplined software development process, clearly defined roles for the
contributers and a semi-structured leadership hierarchy.
This is almost certainly not the path to better free software. Mass
movements in the free software community develop bottom-up, not top-down.
If the community rises to the challenge of creating secure software, it will
happen for the same reason as any other of our successes: because
individual contributors see it as worthwhile.
So if you want it to happen, don't focus on rules and leadership. Focus
on ways to increase the visibility of good security work and to credit its
practitioners. Make people care.
Microsoft is sitting on a $38 billion pile of cash. $6 million is 0.15 cents on the dollar.
It's actually less by an order of magnitude.
Re:The kicker's in the tail
on
SuSE 7.3 vs XP
·
· Score: 4, Interesting
I realised that I was suffering Linux cognitive dissonance (overvaluing
the utility of it simply because it was hard to learn), and resolved to come
to XP with an open mind. [And then XP sucks.]
That was a really nice revelation. However, I often develop the opposite
illusion. When using Linux, and having to do some tedious, unintuitive
tweaking, I can't avoid thinking, "It would be so easy to take care of this
with a sane config system. I'm sure I wouldn't have to do this in
Windows.". But on the occasions I use Windows, I invariably find myself
wasting just as much time tweaking, and further getting frustrated at the
many things I can't tweak, and the arrogance of a UI that supposes to know
better than I. Sure, the baby stuff is easier and more polished, but every
foray into Windows reminds me that providing an enjoyable user experince is
still a difficult and unsolved problem. This gives me some hope that the
race is just getting started.
I'm not sure about the dig on TellMe; I've always found their services (both
their direct public system, and their use in part of American Airlines's
phone tree) quite well executed. The voice reconition has generally been
good, even with background noise (the one failing I experienced was asking
for the movie "Amelie", when "Ali" was also playing). I never got an ad
when it didn't understand--what kind of brain-damaged company would
intentionally aggravate an already annoyed customer? Moreover, I found the
flow of the "conversation"--timing, appropriateness of response, integration
of voice samples--to be excellent, which I think is key to making a system
like this palatable. And I know first-hand that they have quality people in
engineering.
By contrast, I once called SprintPCS and ended up on a similar system, but
it was terrible. The VR was flakey, and it did not degrade gracefully when
it didn't understand, leaving me disoriented. I confirmed from a friend at
TellMe that SprintPCS used someone else.
I don't know anything about Tuvox, but I question whether they will have
success against TellMe, which not only has good tech, but is very well
backed. If they're betting on their "AI", they're probably dead as soon as
people find out it sucks. If they're just trying to be a better TellMe,
they have a challenge--but I hope they come out with a competing public
service to get publicity!
Re:They actually did something, unlike most compan
on
AvantGo Gets a Patent
·
· Score: 2
If you've ever used AvantGo, you know that it's an incredible system. They deserve this patent!
I've never used AvantGo, so I may be off base here....
But, keep in mind the distinction between a novel technical idea, and able execution. Strong marketing, engineering, and usability are all admirable, but they're not patentable. Reading other comments, I gather that the technology is uninspired (if competent), so I suspect that other factors are responsible for the success of AvantGo.
we didn't want people buggering with it if they didn't understand it.
Damn right! I'm disgusted with the common argument that, "in three years, when you're gone, the 'Learn VB in 24 hours' intern is going to have to debug/extend it". That is not a rational approach to code maintenance. You wouldn't have the intern write the code; why would you have him maintain it?
Keeping a codebase clean and correct long-term is not simple. In some ways, it is fundamentally more difficult than writing new code: You don't get to pick your concepts from scratch, instead you have to discover sensible ways to alter and reuse existing ones. If you just do the first thing that works, you will turn a beautiful design into an abject mess alarmingly fast.
Of course, your application had special demands, but I believe most organizations would benefit from a similar attitude. Using "obscure" languages to discourage unconsidered changes may seem elitist, but I agree that it is probably effective. (You might compare Linus's argument about debuggers.) I like your warning, as well.:-)
As for where they go, the obvious answer is not the general swap area, because that's already full. However, that doesn't preclude the existence of a secondary (actually tertiary) swap area that exists only for this purpose.
If you have enough swap space (whether you call it "tertiary" or not) for all writable memory, you're not overcommitting. By definition.
PS. It's funny that you accuse Rik of NIH, because his VM is strongly influenced by FreeBSD's, and receives praise from that camp. Indeed Rik is usually the one making NIH accusations.
Very nicely stated! I was going to publish my own response to "Large
Limits", but I honestly decided that the paper was too "academic" (in the
sense of, "interesting but irrelevant to the practical world") to be worth
critiquing. But this is slashdot, and what better place for worthless
thoughts, so here goes...
The glaring flaw of the paper is that the main argument can be applied
equally to any human endeavor, not just to programming. The argument is
essetially a rigorous version of the statement, "You can't (in general) know
how hard (complex) it's going to be, until you do it". The author supports
this by pointing out that the purpose of any program is equivalent to
generating a string that is a complete, precise description of the problem.
Complexity theory tells us you can't predict the length of that program
(without a formal system bigger than the program).
But it's not hard to cast any problem into this form. Take baking a cake.
The problem can be thought of as generating a precise description of how to
turn some inputs into an output within the range of what we consider a cake.
In a reductionist sense, that process is incredibly complex (much more than
any computer program), involving gazillions of elementary parcticles and
their interactions. But nonetheless it's pretty easy to estimate how long
it will take to bake a cake.
Complexity theory shows us that complexity is indeed pervasive in general;
but everyday experience shows us that it is usually encapsulated within
simple abstractions. Most things we plan and do have relatively simple
descriptions in terms of objects with those properties we are familiar, and
things we have done countless times before. So while estimating complexity
may not be possible in general, it is usually not very hard for the things
we care about.
In order for the paper to be persuasive, Lewis must show that computer
programming is, in practice, more complex than most other activities--that
new problems can't be easy stated in terms of already solved problems. (He
does begin to address this, but only as a side-note.) I think most
practitioners would essentially agree (and I'm not going to argue this,
unless someone challenges it). What does this mean for the relevance of
complexity theory? It's a deep and difficult question, but I suspect that
some insights can be drawn. In particular, I do believe that there are
problems that can't be estimated without effectively solving them.
Regardless, there are more obvious, intuitive reasons that complex
activities are difficult to estimate. One is that that humans vary wildly
in their efficiency at complex tasks. We all know the experience of
cracking nut after nut one day, and being stumped the next. Sometimes, to
be sure, this is due to misestimation of difficulty, but just as surely it
is often purely psychological. Another is that teams working on complex
problems are prone to miscommunication and other group disfunctions. A
third is simply that the flesh is weak--we often lack the discipline and
concentation to plan our projects in sufficient detail.
And this list only considers the difficulties that derive from complexity.
Software development faces a host of additional "accidental" challenges,
such as bugs in third-party software, clients (and marketers) that change
their minds, changing fashions in tools and methodologies, etc. In short,
you don't need a fancy theory to conclude that predicting development time
is quite hard!
Granted, I am assuming there is not an excessive amount of direct copy-n-paste. Even if the code is closely modeled off existing software and designs, 5000 lines/week is prodigious. Typing is obviously not a bottleneck, but simply thinking that many thoughts so quickly is. For unless it's truly copy-n-paste, you do have to think at least briefly about every few lines.
The reality is that the programmer needs to be highly skilled, highly motivated, and have a very good understanding of what he/she is trying to achieve.
I agree, though I would probably say "extraordinarily skilled" instead of "highly".
I mean almost any programmer can crank out 5000 lines of crap a week
Actually, no, any programmer can't. Seriously. Most programmers simply can't conceive the number of coherent, interrelated thoughts necessary to produce 5000 lines/week of reasonably functional code. Even without knowing anything about the quality of this code, the sheer quantity bespeaks an extraordinary programmer.
I can't quite figure out why I would want to use QMTest.
I haven't looked at QMTest, so I'm going by what $parent says. I have written a whole lotta tests, as well as designed and coded testing frameworks.
In my opinion, the number one criteria for judging a testing system is: it must be dead simple to write and maintain test cases. Because writing tests (for your obviously immaculate code) is annoying enough, and if the tool gets in your way, forget it--it just won't happen. This is probably especially true for volunteer projects, although it applies in no small measure to closed shops.
So, you can invent a fancy aparatus and even a "theory of testing". But your system had better not require learning much aparatus, or any theory. Keep in mind when tempted to create or use a fancy system, that most of the value of a test run is in the first bit of information: did it work, or not? Anything after that is gravy.
So if QMTest requires a lot of infrastructure and tools and web UI's, I'd guess it's probably too heavy. Correctness testing is something that should stay out of your way. Assuming you keep your codebase working--right?:-)
All of the entries after the first (I'm going by what the poster wrote; I
haven't run 0.9.7 myself) can be read as if prefixed with "Scripts are
allowed to...". So make that the heading! "Scripts and Windows" makes
little sense, since most of the entries are unrelated to windows. This
change would require that "Enable Javascript" be moved to its own section,
which seems appropriate anyway.
(I guess someone wanted "windows" in the heading so that people looking to
disable ad windows would see it; but this is "advanced" configuration, and I
think anyone going here would know that it's really a script preference.)
On to the original matter: "Open windows by themselves" is gratuitously
ambiguous. "by themselves" seems to go with "windows", which could either
mean that windows open in a separate part of the screen ("by" as in
location"); or that windows spontaneously open without external cause ("by"
as in agent). Neither one is really right.
If you change the heading as I suggest, it reads, "Scripts are allowed to
open windows by themselves". This is an improvement, because "by" as in
agent clearly refers to "scripts". But the "by" as in location
interpretation is still possible, so it remains confusing.
"Scripts are allowed to open windows automatically" reads with no ambiguity
to me, and seems no worse in any way. So I would suggest "Open windows
automatically" as the text for the checkbox. "Open windows without user
input" isn't bad if you want to be more explicit.
Good god, people, if you couldn't read that one, the terrorists have already won! It was not interesting or insightful or overrated or any of the less polite things suggested by other posters. It was FUNNY.
Please, restore my faith in humanity by reading it again and at least pretending to laugh if you still don't get it.
Ok, this is a development kernel, so you shouldn't just jump in as if it
were a stable release. But keep in mind that this is only 2.5.1, where
2.5.0 == 2.4.15, a stable kernel. Since it's only been one revision, it
can't have destabilized that much.
A quick primer on kernel engineering might help. You know how the 2.4.x
series solidified release by excruciating release? Well, the 2.5.x series
is the same, only in reverse. It takes as much work to destabilize a kernel
as it did to stabilize it, so don't expect crashes and corruption right
away. In fact, just as a few 2.4.x releases were regressions, 2.5.1 might
even be stabler than 2.5.0. That would be an accident, though, and the
developers try to prevent it.
To the Slashdot editors: You can dispense only so much over-caution before
the readers decide you're crying wolf. As a community, we need to save up
our restraint for the real hour of need, when the siren song of exotic new
features lures even the most stolid administrator from the doldrums of
predictable stability, into the roiling churn of highly evolved breakage. I would
recommend toning down the warnings for now, and becoming progressively more
shrill as the kernel hits its maximal instability.
The facts did not change a whit. This is just another in a long train of gaping holes in critical software, which you must have been aware of. Either you never thought to ask yourself, "What if this bug affected a service that I rely upon?" (in which case you were intellectually lazy), or you failed to appreciate the impact it would have (in which case you erred in judgement). It happens, I know, but don't make excuses.
I can't get to the article, but according to michael, a theme is that "all
licensing... is an expression of power". ESR based his rebuttal on the same premise: "Stallman and Kuhn want to be able to
make decisions that affect other developers more than themselves.... [T]hey
want power."
While strictly true, this is a blatantly unfair claim. If we accept that
actions are expressions of either freedom or power (as per Kuhn and
Stallman's definition), we must also accept that expressions of power
either limit others' freedom, or limit others' power. Using power to limit
freedom, we can all agree is evil. Using power to limit power, however,
must be allowed in some form, unless you feel that no-one may stop thieves
and murderers.
If you acknowledge that software licensing is a form of power (and it is RMS's primary contension that proprietary licensing is an exercise of power that deprives users of essential freedoms), then it
follows that GPL licensing uses power to limit power. It becomes a question
of whether it's acceptible for individuals to limit others' power in this
way. But you can't simply vilify all forms of power.
Credit card numbers follow a known format (mod10). It should be simple, but somewhat intensive as far as search engines go, to scan content, look for 16 digit numeric strings, and run a mod10 on them. If it comes back true, don't put it into the index.
Among other things, this would have the amusing effect of blacklisting most web pages about credit card number validation.
McAfee calculates the signature from the code. Presumably, the way it works around Magic Lantern is by some code that looks like this:
if virusSignature == magicLantern then return(1);
Sure. But after a Magic Lantern impersonator is discovered and analyzed, McAfee adjusts the signatures to distinguish the impostor from the original. So the situation is the same as for any other virus: undetected at first, but stopped after McAfee analyzes it and issues a signature update. Really, all McAfee would be doing is ensuring that none of their "bad" signatures matches Magic Lantern.
That said, McAfee has always sucked donkey donuts.
- Modify c:\windows\hosts, point fbi.gov to the ip of haxor.org
- Mail all passwords to me@fbi.org
This particular example is silly: any software smart enough to detect and stop outgoing mail would probably 1) use the IP address of fbi.gov to allow Magic Lantern and 2) flag the modification of the hosts file as suspicious. However,...
Virus writers are smart. Very smart some times... keep this in mind please;-)
... you are right in the same sense that I already mentioned: it's an arms race. There will always be ways to evade scanners, and perhaps the Magic Lantern features will make it a little easier. But it's hardly a red carpet for viruses.
(Heck, if Magic Lantern does send mail to spooks@fbi.gov, and you can subvert the router on the victim's network, you can just infect him with the real Magic Lantern and you win!)
Unless McAfee has drastically changed the operating model of their software since I last used it (which would be 8 days ago, since I'm on vacation), you are completely wrong about what they do or do not detect.
It's still based on signatures, not operating patterns.
Ok, I admit I haven't used a virus scanner since I last ran Windows, which was over 4 years ago. If McAfee is operates only on signatures, then obviously there is no need to impersonate Magic Lantern to evade it: any original code (that doesn't match existing signatures) will do. And since any code that does something more than Magic Lantern must necessarily be different from Magic Lantern, McAfee can write a signature for it after it's discovered. So, against signature-based defenses, impersonating Magic Lantern buys you exactly nothing. Is there anything I'm missing here?
In my original post, please replace "McAfee" with "a hypothetical clever anti-malware product".
(From memory, though, I thought that McAfee did guard against things like suspicious file modifications. Maybe that was a different product.)
Slashdot Mirror
That's a good question, and I'm not sure of the answer. It depends on how we develop the AI. For example, if we use genetic algorithms, we might not have any choice in the matter. Similarly, if we take some approach that mimics the human brain, it might be impossible to re-wire direct storage access into that model.
Developing AI is probably (unless we're missing something stupid!) going to be way hard, and insisting that we can't cut that cord might be (is probably, IMO) infeasible. Well, as another poster said, read GEB if you haven't.
This is a misconception about AI. Just because an AI implementation has a mass digital storage, doesn't mean the AI "being" has mass digital storage in any significant sense. The AI level is so far above the storage level, that the AI would probably not interface to the storage any differently from how you or I would. In other words, it would be little different from a person with an MP3/DVD player.
Similarly, an AI would not necessarily be a lightning calculator, even though it's built of of the same chips that can do a billion additions per second. In the AI's "mind", as in ours, numbers are high-level symbols, not RAM words. The AI has no more access to its RAM than we have to our neurons.
Of course, I can't prove this, but I'm quite persuaded.
This was a fairly reasonable (if unexceptional, being a rehash of a rehash) article, until the author got to his recommendations:
However, all of these issues can and are solved in projects with a disciplined software development process, clearly defined roles for the contributers and a semi-structured leadership hierarchy.
This is almost certainly not the path to better free software. Mass movements in the free software community develop bottom-up, not top-down. If the community rises to the challenge of creating secure software, it will happen for the same reason as any other of our successes: because individual contributors see it as worthwhile.
So if you want it to happen, don't focus on rules and leadership. Focus on ways to increase the visibility of good security work and to credit its practitioners. Make people care.
It's actually less by an order of magnitude.
That was a really nice revelation. However, I often develop the opposite illusion. When using Linux, and having to do some tedious, unintuitive tweaking, I can't avoid thinking, "It would be so easy to take care of this with a sane config system. I'm sure I wouldn't have to do this in Windows.". But on the occasions I use Windows, I invariably find myself wasting just as much time tweaking, and further getting frustrated at the many things I can't tweak, and the arrogance of a UI that supposes to know better than I. Sure, the baby stuff is easier and more polished, but every foray into Windows reminds me that providing an enjoyable user experince is still a difficult and unsolved problem. This gives me some hope that the race is just getting started.
By contrast, I once called SprintPCS and ended up on a similar system, but it was terrible. The VR was flakey, and it did not degrade gracefully when it didn't understand, leaving me disoriented. I confirmed from a friend at TellMe that SprintPCS used someone else.
I don't know anything about Tuvox, but I question whether they will have success against TellMe, which not only has good tech, but is very well backed. If they're betting on their "AI", they're probably dead as soon as people find out it sucks. If they're just trying to be a better TellMe, they have a challenge--but I hope they come out with a competing public service to get publicity!
I've never used AvantGo, so I may be off base here....
But, keep in mind the distinction between a novel technical idea, and able execution. Strong marketing, engineering, and usability are all admirable, but they're not patentable. Reading other comments, I gather that the technology is uninspired (if competent), so I suspect that other factors are responsible for the success of AvantGo.
Damn right! I'm disgusted with the common argument that, "in three years, when you're gone, the 'Learn VB in 24 hours' intern is going to have to debug/extend it". That is not a rational approach to code maintenance. You wouldn't have the intern write the code; why would you have him maintain it?
Keeping a codebase clean and correct long-term is not simple. In some ways, it is fundamentally more difficult than writing new code: You don't get to pick your concepts from scratch, instead you have to discover sensible ways to alter and reuse existing ones. If you just do the first thing that works, you will turn a beautiful design into an abject mess alarmingly fast.
Of course, your application had special demands, but I believe most organizations would benefit from a similar attitude. Using "obscure" languages to discourage unconsidered changes may seem elitist, but I agree that it is probably effective. (You might compare Linus's argument about debuggers.) I like your warning, as well. :-)
If you have enough swap space (whether you call it "tertiary" or not) for all writable memory, you're not overcommitting. By definition.
PS. It's funny that you accuse Rik of NIH, because his VM is strongly influenced by FreeBSD's, and receives praise from that camp. Indeed Rik is usually the one making NIH accusations.
The glaring flaw of the paper is that the main argument can be applied equally to any human endeavor, not just to programming. The argument is essetially a rigorous version of the statement, "You can't (in general) know how hard (complex) it's going to be, until you do it". The author supports this by pointing out that the purpose of any program is equivalent to generating a string that is a complete, precise description of the problem. Complexity theory tells us you can't predict the length of that program (without a formal system bigger than the program).
But it's not hard to cast any problem into this form. Take baking a cake. The problem can be thought of as generating a precise description of how to turn some inputs into an output within the range of what we consider a cake. In a reductionist sense, that process is incredibly complex (much more than any computer program), involving gazillions of elementary parcticles and their interactions. But nonetheless it's pretty easy to estimate how long it will take to bake a cake.
Complexity theory shows us that complexity is indeed pervasive in general; but everyday experience shows us that it is usually encapsulated within simple abstractions. Most things we plan and do have relatively simple descriptions in terms of objects with those properties we are familiar, and things we have done countless times before. So while estimating complexity may not be possible in general, it is usually not very hard for the things we care about.
In order for the paper to be persuasive, Lewis must show that computer programming is, in practice, more complex than most other activities--that new problems can't be easy stated in terms of already solved problems. (He does begin to address this, but only as a side-note.) I think most practitioners would essentially agree (and I'm not going to argue this, unless someone challenges it). What does this mean for the relevance of complexity theory? It's a deep and difficult question, but I suspect that some insights can be drawn. In particular, I do believe that there are problems that can't be estimated without effectively solving them.
Regardless, there are more obvious, intuitive reasons that complex activities are difficult to estimate. One is that that humans vary wildly in their efficiency at complex tasks. We all know the experience of cracking nut after nut one day, and being stumped the next. Sometimes, to be sure, this is due to misestimation of difficulty, but just as surely it is often purely psychological. Another is that teams working on complex problems are prone to miscommunication and other group disfunctions. A third is simply that the flesh is weak--we often lack the discipline and concentation to plan our projects in sufficient detail.
And this list only considers the difficulties that derive from complexity. Software development faces a host of additional "accidental" challenges, such as bugs in third-party software, clients (and marketers) that change their minds, changing fashions in tools and methodologies, etc. In short, you don't need a fancy theory to conclude that predicting development time is quite hard!
Why do worm writers stay free? Maybe they've accumulated enough hotel points on their credit cards.
Granted, I am assuming there is not an excessive amount of direct copy-n-paste. Even if the code is closely modeled off existing software and designs, 5000 lines/week is prodigious. Typing is obviously not a bottleneck, but simply thinking that many thoughts so quickly is. For unless it's truly copy-n-paste, you do have to think at least briefly about every few lines.
The reality is that the programmer needs to be highly skilled, highly motivated, and have a very good understanding of what he/she is trying to achieve.
I agree, though I would probably say "extraordinarily skilled" instead of "highly".
Actually, no, any programmer can't. Seriously. Most programmers simply can't conceive the number of coherent, interrelated thoughts necessary to produce 5000 lines/week of reasonably functional code. Even without knowing anything about the quality of this code, the sheer quantity bespeaks an extraordinary programmer.
I haven't looked at QMTest, so I'm going by what $parent says. I have written a whole lotta tests, as well as designed and coded testing frameworks.
In my opinion, the number one criteria for judging a testing system is: it must be dead simple to write and maintain test cases. Because writing tests (for your obviously immaculate code) is annoying enough, and if the tool gets in your way, forget it--it just won't happen. This is probably especially true for volunteer projects, although it applies in no small measure to closed shops.
So, you can invent a fancy aparatus and even a "theory of testing". But your system had better not require learning much aparatus, or any theory. Keep in mind when tempted to create or use a fancy system, that most of the value of a test run is in the first bit of information: did it work, or not? Anything after that is gravy.
So if QMTest requires a lot of infrastructure and tools and web UI's, I'd guess it's probably too heavy. Correctness testing is something that should stay out of your way. Assuming you keep your codebase working--right? :-)
All of the entries after the first (I'm going by what the poster wrote; I haven't run 0.9.7 myself) can be read as if prefixed with "Scripts are allowed to ...". So make that the heading! "Scripts and Windows" makes
little sense, since most of the entries are unrelated to windows. This
change would require that "Enable Javascript" be moved to its own section,
which seems appropriate anyway.
(I guess someone wanted "windows" in the heading so that people looking to disable ad windows would see it; but this is "advanced" configuration, and I think anyone going here would know that it's really a script preference.)
On to the original matter: "Open windows by themselves" is gratuitously ambiguous. "by themselves" seems to go with "windows", which could either mean that windows open in a separate part of the screen ("by" as in location"); or that windows spontaneously open without external cause ("by" as in agent). Neither one is really right.
If you change the heading as I suggest, it reads, "Scripts are allowed to open windows by themselves". This is an improvement, because "by" as in agent clearly refers to "scripts". But the "by" as in location interpretation is still possible, so it remains confusing.
"Scripts are allowed to open windows automatically" reads with no ambiguity to me, and seems no worse in any way. So I would suggest "Open windows automatically" as the text for the checkbox. "Open windows without user input" isn't bad if you want to be more explicit.
One word: EBay. :-)
Please, restore my faith in humanity by reading it again and at least pretending to laugh if you still don't get it.
Ok, this is a development kernel, so you shouldn't just jump in as if it were a stable release. But keep in mind that this is only 2.5.1, where 2.5.0 == 2.4.15, a stable kernel. Since it's only been one revision, it can't have destabilized that much.
A quick primer on kernel engineering might help. You know how the 2.4.x series solidified release by excruciating release? Well, the 2.5.x series is the same, only in reverse. It takes as much work to destabilize a kernel as it did to stabilize it, so don't expect crashes and corruption right away. In fact, just as a few 2.4.x releases were regressions, 2.5.1 might even be stabler than 2.5.0. That would be an accident, though, and the developers try to prevent it.
To the Slashdot editors: You can dispense only so much over-caution before the readers decide you're crying wolf. As a community, we need to save up our restraint for the real hour of need, when the siren song of exotic new features lures even the most stolid administrator from the doldrums of predictable stability, into the roiling churn of highly evolved breakage. I would recommend toning down the warnings for now, and becoming progressively more shrill as the kernel hits its maximal instability.
The facts did not change a whit. This is just another in a long train of gaping holes in critical software, which you must have been aware of. Either you never thought to ask yourself, "What if this bug affected a service that I rely upon?" (in which case you were intellectually lazy), or you failed to appreciate the impact it would have (in which case you erred in judgement). It happens, I know, but don't make excuses.
While strictly true, this is a blatantly unfair claim. If we accept that actions are expressions of either freedom or power (as per Kuhn and Stallman's definition), we must also accept that expressions of power either limit others' freedom, or limit others' power. Using power to limit freedom, we can all agree is evil. Using power to limit power, however, must be allowed in some form, unless you feel that no-one may stop thieves and murderers.
If you acknowledge that software licensing is a form of power (and it is RMS's primary contension that proprietary licensing is an exercise of power that deprives users of essential freedoms), then it follows that GPL licensing uses power to limit power. It becomes a question of whether it's acceptible for individuals to limit others' power in this way. But you can't simply vilify all forms of power.
Among other things, this would have the amusing effect of blacklisting most web pages about credit card number validation.
if virusSignature == magicLantern then return(1);
Sure. But after a Magic Lantern impersonator is discovered and analyzed, McAfee adjusts the signatures to distinguish the impostor from the original. So the situation is the same as for any other virus: undetected at first, but stopped after McAfee analyzes it and issues a signature update. Really, all McAfee would be doing is ensuring that none of their "bad" signatures matches Magic Lantern.
That said, McAfee has always sucked donkey donuts.
Yes, I do seem to remember that....
- Mail all passwords to me@fbi.org
This particular example is silly: any software smart enough to detect and stop outgoing mail would probably 1) use the IP address of fbi.gov to allow Magic Lantern and 2) flag the modification of the hosts file as suspicious. However, ...
Virus writers are smart. Very smart some times... keep this in mind please ;-)
(Heck, if Magic Lantern does send mail to spooks@fbi.gov, and you can subvert the router on the victim's network, you can just infect him with the real Magic Lantern and you win!)
It's still based on signatures, not operating patterns.
Ok, I admit I haven't used a virus scanner since I last ran Windows, which was over 4 years ago. If McAfee is operates only on signatures, then obviously there is no need to impersonate Magic Lantern to evade it: any original code (that doesn't match existing signatures) will do. And since any code that does something more than Magic Lantern must necessarily be different from Magic Lantern, McAfee can write a signature for it after it's discovered. So, against signature-based defenses, impersonating Magic Lantern buys you exactly nothing. Is there anything I'm missing here?
In my original post, please replace "McAfee" with "a hypothetical clever anti-malware product".
(From memory, though, I thought that McAfee did guard against things like suspicious file modifications. Maybe that was a different product.)