I am only quoting TFA: "unwarranted analogies lead to medieval thinking".
And your analogy is bad, because algorithms are algoriths, and can be analyzed and created and proven without being embodied in a computer program. Fighting fire with fire, it is like trying to understand biology by butchering small furry animals, instead of analyzing the underpinnings of the many systems that make *all* animals tick.
Sure, somewhere along the line you should do field work and see examples of the variations of said systems in different animals. But that does not make understanding the basics any less necessary.
I think both approaches (top-down and bottom-up) make sense. You learn C very fast if you can think of it as a high-level assembler. And learning assembler teaches you a lot about what computers are all about and what they can and cannot do.
But learning algoriths on C or other low-level, manage-your-own-memory languages is unnecessarily painful and error-prone. The algorithm exists independently of a specific language incarnation. Learn the algorithms in a language that makes it easy to concentrate on the problem and not get lost in a thousand small implementation details.
You reach enlightenment when you can bridge the gap from very low level to the highest levels. But it is folly to try to do everything at once.
I was just making a point. I don't consider myself technologically illiterate, and would be very glad to have a whole-table, high-resolution, touch-and-pen enabled desktop; and why stop there - I want seamless computing all over my house, allowing me to interact with it with whatever is most convenient at the moment. For an on-fridge household-inventory management system, touch rocks.
Instead of dumb screens that you can only interact with through a pixel-at-a-time device that, by design, has to be on a different surface from that of the data you are working with.
Not that I have any interest in prying your mouse from your not-so-cold, not-yet-dead hands. Sorry about trampling on your lawn, too.
The only big drawback is "no software that takes advantage of it". From an interface standpoint, a large display with hands-on interaction can do miracles that are simply not possible with a single mouse pointer and a keyboard.
Explaining a computer-illiterate person how to use a mouse and when to left-click or right-click or double-click is much harder than saying 'all things on the screen can be grabbed like this or opened like that -- play around until you get the hang of it'. No, touchscreens are not there yet. But I am sure that, in a few years, they will be the norm.
And not damaging the screen is just a matter of learning how to clean it. It doesn't stop people from wearing glasses or using glass-ceramic cooktops.
I say let people deposit as much as they want, and count whatever comes out. If vote-buying is the way forward, we may as well make it a straight-forward, user-friendly competitive bid. On the other hand, I'm a bit worried about the turnout rates.
Yes, FOSS cannot, by itself, make things completely secure. But showing the audience that there's nothing up your sleeve is surely a good sign anyway. I say use voter-verifiable paper trails -- and, for good measure, release the software so that it is harder to monkey with the system.
A similar point can be made regarding transparent vs. opaque ballot boxes. A transparent box doesn't mean you can't stuff things if you are quick enough - but it does make things harder. Hacking logic gates is harder than writing evil high-level code...
I've got a better one. Don't trust the machine, trust the paper ballot - and let people bring in their own ballot-checking machines.
So, yes - build your linux-powered machine (no need for special USB connectors; just make sure there's good physical security). Don't use any electronic recording mechanism - just print a piece of paper with the vote on it. Optically and humanly readable.
And let there be as many machines as possible, from several providers (or even bring-your-own) that can read, display and issue paper ballots. So if the dems don't trust the republican's machine, just have them bring their own and recount the votes. All machines must conform to stringent standards regarding printed ballots and interface.
To vote: go to the voting place, print as many ballots as you want, with any machine you want, check them with other machines if you're paranoid enough (or you want to know the print-out is really readable), and then show your ID and have the election officials deposit your ballot into the transparent box. At the end of the day, all those ballots get scanned and tallied (using more than one machine to make sure everything adds up). Voila! No need to trust just one piece of code+hardware!
This system would require good, public standards for the paper ballot and for the race format (so that machines could read it and display it) - but precious little else.
<car analogy>Yes. But the fact that walking 'works' has not stopped us from inventing cars. And mind you, the first ones were not exactly 'secure', and could claim much more than your vote.</car analogy>
On the serious side, yes, don't substitute paper until you have an alternative that's superior on all counts. But keep in mind that there's a lot of drudgery and automatable effort behind voting, and that many simply can't vote because of physical problems.
Actually, Internet voting must not be allowed unless you can make a connection that can't be eavesdropped between your mind and the voting machine. If third parties can listen in (even if they need your consent to do so) - vote buying will again be possible.
Imagine you manage to get this part right. Now you would only have to trust the voting machine to accurately store your vote, without the benefit of a voter-verifiable paper trail or anything you can possibly show to third parties to demonstrate that you voted one way or another... can't be done.
Spot on, but I would take it a bit further. Good AI at both the individual and group NPC levels is the key to the content problem - without it, nobody can script or generate persistent, non-linear, per-NPC story-lines fast enough to meet a large user base.
From a designer's perspective, you only need to initialize NPCs to a set of stats and relationships with each other (like, dislike, do not know, would avenge, reminds me of,...), and a long list of (possibly randomized) behaviors (aggressive against aggressors, 'work' behavior, fight-or-flight, crowd-forming, gossip). When something happens, designers can let the NPCs work it out by themselves, or nudge them along a general direction ("villagers send out a scout to the next village requesting help", "leave town", "form a mob and try to defend town"). Designers become something like the agents in 'matrix' - their preferred mode of interaction is to take over control of NPCs temporarily to make them advance certain plots.
Even better - this can work for larger groups of NPCs, allowing entire communities to develop community relationships. Create an unpopulated world, and drop a number of 'seed communities' (with community-wide likes, dislikes, goals, and so on). Simulate their evolution for a while; let them fight or cooperate with each other, build an economy, watch as some spread and others drop back, tinker to produced desired master storyline arcs (but let details sort themselves out) -- and *then* drop in the PCs. Simplified models can work just great - see the examples in Phillip Ball's book. Or take some clues from biologists or economists - they've been modeling entire ecosystems (economists call them 'markets') for a while.
A nice after-effect of 'evolved' NPCs and NPC communities is that they would provide rich backgrounds for PCs. So you want to be a rogue? Great, pick among these rogue-like characters we've been evolving in the last year (you may know some of them 'cause they tried to rob you before when you played another PC), and you will get a background, a set of likes and dislikes, a couple of caring aunts and uncles you can help or flee from, and so on and so forth. Also, this would provide persistence during off-line hours - let PCs choose the goals that will drive their characters while they're not directly controlling them.
That is lots of fundamental research we are talking about. I am no expert in network monitoring, but 4.4M to solve the following problems seems like peanuts:
Probability of detection of malicious traffic greater than 99% per attack launched
While some types of traffic are obviously not ham (say, spoofed IPs or syn scans), assigning intent to raw data flows requires nothing less than strong AI. Think of spam - anybody can fool a spam filter, no matter what filter, given enough time and motivation. You can also fool the human reading the mail, for that matter...
A false alarm rate while monitoring traffic of not more than one false alarm per day.
This makes a whitelist approach a lot harder. My guess is that any decent system will flag many, many things, and prioritize some over others. That way it is up to the network operator to dig deeper or not into each individual incident, using the program's classification as a starting point. I have no idea why email programs don't allow you to rank messages on "perceived spamminess" - it would make digging for false positives and negatives a lot easier...
Support capabilities at conventional gateway line speeds of 1Gbps in Phase I of the contract, while Phase II will demonstrate the scalability of this capability at gateway line speeds of 100Gbps.
This part, together with the "very high scalability" requirement, is the icing on the cake. It is impossible to detect complex threats in real-time, so the best bet would be to layer defenses. Very fast reflexes for certain behavior (say, DDOS), longer mulling times for patterns that are more deeply hidden (say, a covert channel somewhere).
In any case, 4.4M is peanuts to meet these goals at full strength. The most probable outcome is some fundamental research, partial successes, and another grant in a few years (possibly to a different team) to try to get further along the track.
I think the biggest single usability problem is that our current coding tools and 'best practices' force interface design and low-level code to be merged together in a big monolithic box called 'the application'. This is a technological dead end.
Not according to the article, which states that OSS software usually insists in clearly separated and switchable interface and backends.
On a separate note, most users are not avid interface tweakers. True, nobody provides the tools. But such tools would be hard to build indeed. Problems include:
Most applications are not designed to be externally scripted, since this would require hard decisions on how to share the data with the caller (formatting, locks, callbacks), what minimal environment to load, and so on. Since there is little perceived demand in exchange for a very substantial effort, developers stay clear of providing such interfaces.
Externally-scriptable applications would need some kind of unified, machine-readable documentation standard. Think end-user-readable javadoc-autocomplete. It should be easy to learn what verbs and adjectives you can use.
For a graphical script builder, documentation would not be so important, as you would be capable of directly interacting with the application. This is no mean feat, since the relationship between 'things this app can provide or accept' and widgets is not one-to-one. How do you plan to fix that?
Complexity scales *fast*. The moment the magical scripting tool allows you to build truly complex things (and variables, some math, conditionals and loops are enough to go Turing-complete), it will no longer be capable of hand-holding a user that strides into deep water. Think of debugging infinite loops or poorly performing scripts...
If I were an evil fraudster at PCMark, paid for Intel to deliver worse scores to rivals, I would make sure that these rivals had no easy way of uncovering the fraud. Testing for an ID looks much more like bad code paths than like "sneaky fraud".
There is no shortage of alternative quirks that can be used to see whether a given processor belongs to one family or another. Should enough of these quirks be combined, it would be *very* hard to discover an evil-related cause.
Of course, choosing the 'bad' path given an ID may just be blatant enough to provide plausible deniability for the developers that "messed up". However, being a firm proponent of Hanlon's Razor, I would rather call it a bug than a "sponsored feature".
On the other hand, kudos to the guys at Ars who thought of changing the ID and, when the numbers did not add up, make further tests to nail down the argument. Instead of just forgetting about the problem and performing a "review as usual", which would have doubtlessly required less effort. Yay for inquisitive hacker - reviewers.
Adding the event handler *after* the page has loaded may be there for efficiency reasons. If the results can be shown 0.5s earlier by deferring some code execution, the results *will* seem more snappy.
As for creating a sensor grid, Google is in the business of gathering data and reselling it. Why would they offer free visitor tracking without getting anything in return?
As the other replies say -- if you don't want to be tracked, nobody is stopping you from erasing their cookies, blocking their scripts, and avoiding their ads. Many do. Yes, there should probably be an easier way to remain untracked -- but one thing is "not being evil" and another, very different thing is torpedoing their business model. I doubt Google will add an opt-in check-box that says "track any events I generate instead of giving me all your services for free".
Parent is right. As long as there is no way for the programs running on Google's hardware to grow past their original programming (beyond optimization and load-balancing), there will be no Skynet.
Yes, many computer programs work in a feedback loop, and so do all organisms. But as long as only the data entry part of the loop can change, and the system lacks the flexibility to change the type of processing that takes place (the 'program'), no spontaneous evolution will occur.
Several factors are needed to get us to the bleak, dark, machine-vs-human Sci-Fi universe slashdotters know and love.
The would-be AI programs must be free to rewrite portions of themselves. Self-modifying code is generally frowned upon as being very hard to write and debug, and outside academia (evolutionary programming?), nobody is pushing it. Also, current approaches need massive amounts of processing for meager results.
The programs should be free to replicate. While Google has a lot of machines, they probably don't want runaway programs hogging the CPU cycles (they are not in the heating business). Internet-roaming malware is a much more likely than Google-sponsored code to eat over the Internets. Partly because the cheapest way to replicate is not asking for permission, and evolutionary systems will take shortcuts whenever available.
There must be evolutionary constraints to help weed the "unsucessful" strains. If a viral, self-modifying program manages to get everywhere and "kill the host" (bog down the net completely), it will no longer evolve. Fortunately, there's lots of different systems hooked up to the 'net, and colonization would be hard enough.
The first point is the most difficult. It is *not* easy to take pieces out of two programs and build a third program that does things that both do. Whatever OO promises, code is not yet "easy as lego blocks" to assemble. You need very well though-out constraints to mix code in a meaningful way - any self-modifying program would need a small, hard-to-modify kernel that would take care of the mixing mechanism. Nobody knows how to design such a kernel correctly, or what exactly to include as 'genes' (mixable code modules). Computational biology (and biology itself) are hard at work on this problem.
But mixing blocks would not be enough. A successful system would need to build new, unseen blocks by modifying existing ones -- or starting from scratch. How many different things can you say in 20 words? How many of these things make any sort of sense? And how many of those require a very, very specific context to fit into?. The way that evolution can sort this out is by, very slowly, building things that sort-of, kind-of get the job done. However you look at it, there will be huge amounts of trial-and-error involved.
And another problem is that of intelligence "scale". Imagine a super-self-modifying internet worm. The ability to probe and infect does not automatically lead to self-consciousness. There are many, many evolutionary steps from bacteria (very good at self-modification and breeding) to humans. And the current installed base of Internet-connected computers and their "stability" (the time-frame during which a given system remains 'constant') is tiny in comparison to the resources that earths' organisms have had at their disposal for evolutionary purposes. Yes, computers are way fast and this can compensate for some parallelism issues. But I still think that emerging AI is still very, very far off.
And yet another example - Conway's Game of Life. Simple rules, very complex emerging behavior if you only look at certain outcomes. The fact that emerging complexity may be, duh, complex, does not prevent the mechanisms that bring it about to be very, very interesting.
I don't remember ever saying that I rejected quantum physics. Why the strawman?
Read your own blog, Mr. Troll. You *do* say that quantum physics is crackpottery. Please keep your ravings straight.
Do you people work for D-Waves? Or are you all ass kissers by nature?
I don't have any opinion on D-Waves. They are probably selling snake-oil. As for the personal attacks, you sure have an interesting blog and post history. Most trolls forget create a blog that advertises the fact (maybe they troll for kicks, but you seem to be after the page hits). From the blog's "about me", first item:
I am a crackpot and a crank. Those are my credentials.
You sir, are a troll if I ever read one. However, I'll feed you some just for the amusement value.
In your opinion, what exactly is it that *can* be known, given the fact that our senses are quite limited? Does ultraviolet light exist, even if you can't see it, touch it or smell it? Does magnetism exist, even if you can't explain how it works and we have no built-in senses to detect it? What's so difficult to believe about quantum physics, given the huge mass of experiments that sustain it?
Perhaps you would care to point out a different interpretation of the experimental results. I'm sure there's a nobel prize waiting for you -- should your explanation be more helpful than the current one (which has allowed the development of working products, such as quantum cryptography).
And of course, if you manage to find a way to peer into subatomic particles using your naked eyes -- hey, imagine the look on the face of those CERN guys, who are just finishing their 5 bn Euro collider.
Kernel debugger considered harmful by Linus
on
Linux 2.6.26 Out
·
· Score: 5, Informative
Reading on it, it seems that Linus never has been a great fan of kernel debuggers. From a famous post,
I happen to believe that not having a kernel debugger forces people to
think about their problem on a different level than with a debugger. I
think that without a debugger, you don't get into that mindset where you
know how it behaves, and then you fix it from there. Without a debugger,
you tend to think about problems another way. You want to understand
things on a different _level_. [...]
I agree that stepping with a debugger instead of thinking real hard about the code (and using abundant log statements) is generally a waste of time, and that expecting to catch rare occurrences of weird race conditions with a debugger is not worth the effort. Sloppy programmers don't take the time to think, and rely too much on fixing what they could have not broken. Unit tests, although more expensive to code, can be reused many times - debugging sessions are one-shot.
On the other hand, even good programmers can get stuck and benefit from a debugger every once and then. I guess this argument finally won the day.
Exactly. Given the choice between including a boilerplate NC clause at 0 cost (which may be useful in retaining employees) or not including it (maybe get a warm and fuzzy feeling), the warm and fuzzy feeling does not stand a chance.
Also, as a poster noted above, in an area where everybody uses NCAs there is even less of an incentive to choose otherwise. Even if everybody (employees and employers) would be better off if 0-cost NCAs were outlawed.
Generally contracts of the form "you can't do X because you willingly and knowingly signed an agreement not to do X" are a reasonable exchange of one thing of value for another
It depends heavily on 'X'. There's many things that you can not sign away. Slavery comes to mind. Since employers have much more leverage than would-be employees, it makes sense to protect employees from some of the most obnoxious clauses, or mandate well-defined boundaries and compensation.
There is a vast number of laws that attempt to avoid situations of undue leverage (especially when it seems of little to the society at large).
I disagree. Wealthy countries have only a fraction of the population found in developing countries; however, few innovations come from the developing ones.
You need manpower, sure, but unless a substantial portion of a country's citizens have access to education and can dedicate time to advancing the state of the art, and then communicate their results to others, only very, very rare innovations will trickle out.
Without education, the hurdle to contribute something is huge. Standing on shoulders of giants is way easier than becoming an even bigger giant yourself. And without communication, discoveries made by such giants may well be lost.
As many others have pointed out, this was very much to be expected. It requires exceptionally skilled teachers to be able to motivate a whole spectrum of students at the same time.
In a traditional classroom, communication has a star-shaped topology with the teacher in the center. The teacher is a very scarce resource, and although broadcasting is available, the broadcast can be tuned to either low-bandwidth or high-bandwidth students. If only low-bandwidth broadcasts are used, those which could go faster will get bored real quick.
There are all sorts of proposals out there to break the star-shaped topology and get students to collaborate and motivate each other; however, the teacher will still be a scarce resource, because all proposals require a level of coordination which will itself require time&effort.
Never attribute to malice that which can be adequately explained by stupidity. - Hanlon's Razor to the rescue.
Also, feeling that you could have been a Kwisatz Haderach were it not for stupifying schools is probably true. After all, we are physically indistinguishable from our ancestors 3000 years ago, but any engineer or doctor of today would seem to be a genius by classical Greek standards.
Nobody knows how 'best practices' education will look like in a few hundred years, or what miracles will be considered commonplace for teachers to teach. The government is only to blame for not implementing 'best practices' today, and listening to voters that seem to think that education is not a top priority. But blaming it for evil scheming to produce drones is giving them way too much credit. Hanlon's razor is correct here.
Slashdot Mirror
And your analogy is bad, because algorithms are algoriths, and can be analyzed and created and proven without being embodied in a computer program. Fighting fire with fire, it is like trying to understand biology by butchering small furry animals, instead of analyzing the underpinnings of the many systems that make *all* animals tick.
Sure, somewhere along the line you should do field work and see examples of the variations of said systems in different animals. But that does not make understanding the basics any less necessary.
I think both approaches (top-down and bottom-up) make sense. You learn C very fast if you can think of it as a high-level assembler. And learning assembler teaches you a lot about what computers are all about and what they can and cannot do.
But learning algoriths on C or other low-level, manage-your-own-memory languages is unnecessarily painful and error-prone. The algorithm exists independently of a specific language incarnation. Learn the algorithms in a language that makes it easy to concentrate on the problem and not get lost in a thousand small implementation details.
You reach enlightenment when you can bridge the gap from very low level to the highest levels. But it is folly to try to do everything at once.
I was just making a point. I don't consider myself technologically illiterate, and would be very glad to have a whole-table, high-resolution, touch-and-pen enabled desktop; and why stop there - I want seamless computing all over my house, allowing me to interact with it with whatever is most convenient at the moment. For an on-fridge household-inventory management system, touch rocks.
Instead of dumb screens that you can only interact with through a pixel-at-a-time device that, by design, has to be on a different surface from that of the data you are working with.
Not that I have any interest in prying your mouse from your not-so-cold, not-yet-dead hands. Sorry about trampling on your lawn, too.
The only big drawback is "no software that takes advantage of it". From an interface standpoint, a large display with hands-on interaction can do miracles that are simply not possible with a single mouse pointer and a keyboard.
Explaining a computer-illiterate person how to use a mouse and when to left-click or right-click or double-click is much harder than saying 'all things on the screen can be grabbed like this or opened like that -- play around until you get the hang of it'. No, touchscreens are not there yet. But I am sure that, in a few years, they will be the norm.
And not damaging the screen is just a matter of learning how to clean it. It doesn't stop people from wearing glasses or using glass-ceramic cooktops.
[yes, just joking]
Yes, FOSS cannot, by itself, make things completely secure. But showing the audience that there's nothing up your sleeve is surely a good sign anyway. I say use voter-verifiable paper trails -- and, for good measure, release the software so that it is harder to monkey with the system.
A similar point can be made regarding transparent vs. opaque ballot boxes. A transparent box doesn't mean you can't stuff things if you are quick enough - but it does make things harder. Hacking logic gates is harder than writing evil high-level code...
I've got a better one. Don't trust the machine, trust the paper ballot - and let people bring in their own ballot-checking machines.
So, yes - build your linux-powered machine (no need for special USB connectors; just make sure there's good physical security). Don't use any electronic recording mechanism - just print a piece of paper with the vote on it. Optically and humanly readable.
And let there be as many machines as possible, from several providers (or even bring-your-own) that can read, display and issue paper ballots. So if the dems don't trust the republican's machine, just have them bring their own and recount the votes. All machines must conform to stringent standards regarding printed ballots and interface.
To vote: go to the voting place, print as many ballots as you want, with any machine you want, check them with other machines if you're paranoid enough (or you want to know the print-out is really readable), and then show your ID and have the election officials deposit your ballot into the transparent box. At the end of the day, all those ballots get scanned and tallied (using more than one machine to make sure everything adds up). Voila! No need to trust just one piece of code+hardware!
This system would require good, public standards for the paper ballot and for the race format (so that machines could read it and display it) - but precious little else.
<car analogy>Yes. But the fact that walking 'works' has not stopped us from inventing cars. And mind you, the first ones were not exactly 'secure', and could claim much more than your vote.</car analogy>
On the serious side, yes, don't substitute paper until you have an alternative that's superior on all counts. But keep in mind that there's a lot of drudgery and automatable effort behind voting, and that many simply can't vote because of physical problems.
Actually, Internet voting must not be allowed unless you can make a connection that can't be eavesdropped between your mind and the voting machine. If third parties can listen in (even if they need your consent to do so) - vote buying will again be possible.
Imagine you manage to get this part right. Now you would only have to trust the voting machine to accurately store your vote, without the benefit of a voter-verifiable paper trail or anything you can possibly show to third parties to demonstrate that you voted one way or another... can't be done.
Spot on, but I would take it a bit further. Good AI at both the individual and group NPC levels is the key to the content problem - without it, nobody can script or generate persistent, non-linear, per-NPC story-lines fast enough to meet a large user base.
From a designer's perspective, you only need to initialize NPCs to a set of stats and relationships with each other (like, dislike, do not know, would avenge, reminds me of, ...), and a long list of (possibly randomized) behaviors (aggressive against aggressors, 'work' behavior, fight-or-flight, crowd-forming, gossip). When something happens, designers can let the NPCs work it out by themselves, or nudge them along a general direction ("villagers send out a scout to the next village requesting help", "leave town", "form a mob and try to defend town"). Designers become something like the agents in 'matrix' - their preferred mode of interaction is to take over control of NPCs temporarily to make them advance certain plots.
Even better - this can work for larger groups of NPCs, allowing entire communities to develop community relationships. Create an unpopulated world, and drop a number of 'seed communities' (with community-wide likes, dislikes, goals, and so on). Simulate their evolution for a while; let them fight or cooperate with each other, build an economy, watch as some spread and others drop back, tinker to produced desired master storyline arcs (but let details sort themselves out) -- and *then* drop in the PCs. Simplified models can work just great - see the examples in Phillip Ball's book. Or take some clues from biologists or economists - they've been modeling entire ecosystems (economists call them 'markets') for a while.
A nice after-effect of 'evolved' NPCs and NPC communities is that they would provide rich backgrounds for PCs. So you want to be a rogue? Great, pick among these rogue-like characters we've been evolving in the last year (you may know some of them 'cause they tried to rob you before when you played another PC), and you will get a background, a set of likes and dislikes, a couple of caring aunts and uncles you can help or flee from, and so on and so forth. Also, this would provide persistence during off-line hours - let PCs choose the goals that will drive their characters while they're not directly controlling them.
That is lots of fundamental research we are talking about. I am no expert in network monitoring, but 4.4M to solve the following problems seems like peanuts:
Probability of detection of malicious traffic greater than 99% per attack launched
While some types of traffic are obviously not ham (say, spoofed IPs or syn scans), assigning intent to raw data flows requires nothing less than strong AI. Think of spam - anybody can fool a spam filter, no matter what filter, given enough time and motivation. You can also fool the human reading the mail, for that matter...
A false alarm rate while monitoring traffic of not more than one false alarm per day.
This makes a whitelist approach a lot harder. My guess is that any decent system will flag many, many things, and prioritize some over others. That way it is up to the network operator to dig deeper or not into each individual incident, using the program's classification as a starting point. I have no idea why email programs don't allow you to rank messages on "perceived spamminess" - it would make digging for false positives and negatives a lot easier...
Support capabilities at conventional gateway line speeds of 1Gbps in Phase I of the contract, while Phase II will demonstrate the scalability of this capability at gateway line speeds of 100Gbps.
This part, together with the "very high scalability" requirement, is the icing on the cake. It is impossible to detect complex threats in real-time, so the best bet would be to layer defenses. Very fast reflexes for certain behavior (say, DDOS), longer mulling times for patterns that are more deeply hidden (say, a covert channel somewhere).
In any case, 4.4M is peanuts to meet these goals at full strength. The most probable outcome is some fundamental research, partial successes, and another grant in a few years (possibly to a different team) to try to get further along the track.
I think the biggest single usability problem is that our current coding tools and 'best practices' force interface design and low-level code to be merged together in a big monolithic box called 'the application'. This is a technological dead end.
Not according to the article, which states that OSS software usually insists in clearly separated and switchable interface and backends.
On a separate note, most users are not avid interface tweakers. True, nobody provides the tools. But such tools would be hard to build indeed. Problems include:
If I were an evil fraudster at PCMark, paid for Intel to deliver worse scores to rivals, I would make sure that these rivals had no easy way of uncovering the fraud. Testing for an ID looks much more like bad code paths than like "sneaky fraud".
There is no shortage of alternative quirks that can be used to see whether a given processor belongs to one family or another. Should enough of these quirks be combined, it would be *very* hard to discover an evil-related cause.
Of course, choosing the 'bad' path given an ID may just be blatant enough to provide plausible deniability for the developers that "messed up". However, being a firm proponent of Hanlon's Razor, I would rather call it a bug than a "sponsored feature".
On the other hand, kudos to the guys at Ars who thought of changing the ID and, when the numbers did not add up, make further tests to nail down the argument. Instead of just forgetting about the problem and performing a "review as usual", which would have doubtlessly required less effort. Yay for inquisitive hacker - reviewers.
Adding the event handler *after* the page has loaded may be there for efficiency reasons. If the results can be shown 0.5s earlier by deferring some code execution, the results *will* seem more snappy.
As for creating a sensor grid, Google is in the business of gathering data and reselling it. Why would they offer free visitor tracking without getting anything in return?
As the other replies say -- if you don't want to be tracked, nobody is stopping you from erasing their cookies, blocking their scripts, and avoiding their ads. Many do. Yes, there should probably be an easier way to remain untracked -- but one thing is "not being evil" and another, very different thing is torpedoing their business model. I doubt Google will add an opt-in check-box that says "track any events I generate instead of giving me all your services for free".
Parent is right. As long as there is no way for the programs running on Google's hardware to grow past their original programming (beyond optimization and load-balancing), there will be no Skynet.
Yes, many computer programs work in a feedback loop, and so do all organisms. But as long as only the data entry part of the loop can change, and the system lacks the flexibility to change the type of processing that takes place (the 'program'), no spontaneous evolution will occur.
Several factors are needed to get us to the bleak, dark, machine-vs-human Sci-Fi universe slashdotters know and love.
The first point is the most difficult. It is *not* easy to take pieces out of two programs and build a third program that does things that both do. Whatever OO promises, code is not yet "easy as lego blocks" to assemble. You need very well though-out constraints to mix code in a meaningful way - any self-modifying program would need a small, hard-to-modify kernel that would take care of the mixing mechanism. Nobody knows how to design such a kernel correctly, or what exactly to include as 'genes' (mixable code modules). Computational biology (and biology itself) are hard at work on this problem.
But mixing blocks would not be enough. A successful system would need to build new, unseen blocks by modifying existing ones -- or starting from scratch. How many different things can you say in 20 words? How many of these things make any sort of sense? And how many of those require a very, very specific context to fit into?. The way that evolution can sort this out is by, very slowly, building things that sort-of, kind-of get the job done. However you look at it, there will be huge amounts of trial-and-error involved.
And another problem is that of intelligence "scale". Imagine a super-self-modifying internet worm. The ability to probe and infect does not automatically lead to self-consciousness. There are many, many evolutionary steps from bacteria (very good at self-modification and breeding) to humans. And the current installed base of Internet-connected computers and their "stability" (the time-frame during which a given system remains 'constant') is tiny in comparison to the resources that earths' organisms have had at their disposal for evolutionary purposes. Yes, computers are way fast and this can compensate for some parallelism issues. But I still think that emerging AI is still very, very far off.
And yet another example - Conway's Game of Life. Simple rules, very complex emerging behavior if you only look at certain outcomes. The fact that emerging complexity may be, duh, complex, does not prevent the mechanisms that bring it about to be very, very interesting.
I don't remember ever saying that I rejected quantum physics. Why the strawman?
Read your own blog, Mr. Troll. You *do* say that quantum physics is crackpottery. Please keep your ravings straight.
Do you people work for D-Waves? Or are you all ass kissers by nature?
I don't have any opinion on D-Waves. They are probably selling snake-oil. As for the personal attacks, you sure have an interesting blog and post history. Most trolls forget create a blog that advertises the fact (maybe they troll for kicks, but you seem to be after the page hits). From the blog's "about me", first item:
I am a crackpot and a crank. Those are my credentials.
In your opinion, what exactly is it that *can* be known, given the fact that our senses are quite limited? Does ultraviolet light exist, even if you can't see it, touch it or smell it? Does magnetism exist, even if you can't explain how it works and we have no built-in senses to detect it? What's so difficult to believe about quantum physics, given the huge mass of experiments that sustain it?
Perhaps you would care to point out a different interpretation of the experimental results. I'm sure there's a nobel prize waiting for you -- should your explanation be more helpful than the current one (which has allowed the development of working products, such as quantum cryptography).
And of course, if you manage to find a way to peer into subatomic particles using your naked eyes -- hey, imagine the look on the face of those CERN guys, who are just finishing their 5 bn Euro collider.
Reading on it, it seems that Linus never has been a great fan of kernel debuggers. From a famous post,
I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. [...]
I agree that stepping with a debugger instead of thinking real hard about the code (and using abundant log statements) is generally a waste of time, and that expecting to catch rare occurrences of weird race conditions with a debugger is not worth the effort. Sloppy programmers don't take the time to think, and rely too much on fixing what they could have not broken. Unit tests, although more expensive to code, can be reused many times - debugging sessions are one-shot.
On the other hand, even good programmers can get stuck and benefit from a debugger every once and then. I guess this argument finally won the day.
Exactly. Given the choice between including a boilerplate NC clause at 0 cost (which may be useful in retaining employees) or not including it (maybe get a warm and fuzzy feeling), the warm and fuzzy feeling does not stand a chance.
Also, as a poster noted above, in an area where everybody uses NCAs there is even less of an incentive to choose otherwise. Even if everybody (employees and employers) would be better off if 0-cost NCAs were outlawed.
It depends heavily on 'X'. There's many things that you can not sign away. Slavery comes to mind. Since employers have much more leverage than would-be employees, it makes sense to protect employees from some of the most obnoxious clauses, or mandate well-defined boundaries and compensation.
There is a vast number of laws that attempt to avoid situations of undue leverage (especially when it seems of little to the society at large).
Stupid gits!
You need manpower, sure, but unless a substantial portion of a country's citizens have access to education and can dedicate time to advancing the state of the art, and then communicate their results to others, only very, very rare innovations will trickle out.
Without education, the hurdle to contribute something is huge. Standing on shoulders of giants is way easier than becoming an even bigger giant yourself. And without communication, discoveries made by such giants may well be lost.
As many others have pointed out, this was very much to be expected. It requires exceptionally skilled teachers to be able to motivate a whole spectrum of students at the same time.
In a traditional classroom, communication has a star-shaped topology with the teacher in the center. The teacher is a very scarce resource, and although broadcasting is available, the broadcast can be tuned to either low-bandwidth or high-bandwidth students. If only low-bandwidth broadcasts are used, those which could go faster will get bored real quick.
There are all sorts of proposals out there to break the star-shaped topology and get students to collaborate and motivate each other; however, the teacher will still be a scarce resource, because all proposals require a level of coordination which will itself require time&effort.
Proposed solutions (all of them well-known):
- More teachers = more time-per-student
- Better teachers = greater student motivation, broader spectrum
- External support (from parents, society to teacher's efforts) = motivated students and teachers
News at eleven...Never attribute to malice that which can be adequately explained by stupidity. - Hanlon's Razor to the rescue.
Also, feeling that you could have been a Kwisatz Haderach were it not for stupifying schools is probably true. After all, we are physically indistinguishable from our ancestors 3000 years ago, but any engineer or doctor of today would seem to be a genius by classical Greek standards.
Nobody knows how 'best practices' education will look like in a few hundred years, or what miracles will be considered commonplace for teachers to teach. The government is only to blame for not implementing 'best practices' today, and listening to voters that seem to think that education is not a top priority. But blaming it for evil scheming to produce drones is giving them way too much credit. Hanlon's razor is correct here.