He couldn't have created the OS on the computer on which he began creating C in C because he hadn't created it yet
Not at all. OS and language grew up together. The first, simplest implementations of both had to be written in assembler, but they quickly became self-hosting.
Actually, that message is ambiguous -- it doesn't specify whether it's master.kernel.org or github that will be "just a mirror".
Is there a difference? I suppose if Linus runs "git push kernel.org master" before doing "git push github master" then people grabbing from kernel.org might get the latest version a few seconds sooner.
Or maybe Linus will get tired of having to do both and add a "multiple remote alias" feature so that he can push to both simultaneously.
Yes, it is. Because by the time students get to real life, the tools have changed.
Keeping students engaged isn't important.
It's important iff lack of engagement reduces learning. Learning should be reflected on test scores, so if computers don't increase test scores, then either computers don't increase engagement, or lack of engagement wasn't a problem.
They cut down the amount of geeky stuff like work-on-your-own-projects
I'm a software engineer at Google, and this isn't true. There has been no pushback on 20% projects; and lots of people still have them (I do). Nor, from what I can see, is there any significant limitation on employees' ability to choose what kinds of things they want to spend their 20% time on.
Rather, I think actions like this are a natural consequence of the freedom given to Googlers to work on what they want to. That freedom means that Google ends up doing a lot of random things. The things that look somewhat promising get more investment and get rolled out to the public. Some work, most don't, and the result is that eventually the projects that aren't panning out get axed. That doesn't mean Googlers can't continue working on them in 20% time if the wish, though it's doubtful that many will want to.
they use every evil marketing tactic in the book
I think this is simply untrue, but it's not possible to debate such broad generalizations.
There's another option: Go to a cheaper school and exploit the other financial assistance options. A cheaper school will give you an education that is 90% as good, for 10% of the cost, and if you take advantage of grants, scholarships and part-time jobs it's perfectly feasible to get a four-year degree and walk away with no debt whatsoever. Of course, you'll have to spend your evenings working, rather than drinking with your friends.
If you truly can't find another decent-paying job because your experience sucks, perhaps you need to take a lesser-paying job working on mainstream stuff, to build up the experience you need for decent-paying jobs working on mainstream stuff. I'm assuming that the problem is that your "business software" is written in some lesser-used language and toolset. If you're writing "business software" in something like Java or C# and potential employers are telling you they aren't hiring you because of the type of software you've been writing, they're lying to you.
I also recommend that, rather than drinking, you do some side projects at home. Try to recover the joy you found in writing software when you first started, and take the opportunity to learn some other languages and tools, and perhaps even to build yourself a portfolio of open source software to use as a proof of experience. Good employers will give that sort of thing as much weight as work experience. Plus it's fun!
If, on the other hand, you see writing code as drudgery never found any joy in doing it for its own sake, then you really need to think about changing careers because software development isn't for you. If you're not passionate about it, you'll hate it wherever you're doing it -- and, honestly, you'll suck at it, which will mean that you'll never get a chance to work at the places you wouldn't hate.
Their freedom to lie isn't quite that broad. If they make claims that they're giving you lawful orders which they do not in fact have the authority to give, then the results of those orders are tainted. If they step far enough over the line, they can even be prosecuted for civil rights violations. It doesn't happen often, but it does happen.
In this case, if the officers told her they had a search warrant, then they were telling her that she was required to submit to the search. That means the search was not voluntary, because she believed she was obligated to comply with a court order. And an involuntary, warrantless search is unconstitutional and the results of any such search can and should be inadmissible in court.
I agree, with the caveat that I think browsers should do ssh-style key history tracking. For all certs, not just self-signed, but it's especially important for self-signed certs. If I visit a site every day for a year and it always has the same certificate, that is actually a much stronger statement of trust than a signature by some random CA, but if that certificate suddenly changes there should be big red warnings. Further, I like the ssh model wherein the user is recommended to do some additional verification the first time they see a particular cert. It needn't be scary, and most users won't bother, but the offer should definitely be made and the user should have to make a deliberate choice to bypass it without verification.
It might also be good to allow the user to confirm if they have actually validated the fingerprint. If so, then the lock icon can be displayed. This might add too much UI complexity for most people, however.
Such an approach would play very nicely with Marlinspike's distributed notary system, BTW. A newly-seen cert (self-signed or not) should definitely be checked against all the notaries, but one that the browser has seen before, especially many times before, doesn't need the same level of checking. In fact, if a cert has been seen before, the browser should probably go ahead and display the site and then check with some notaries in the background.
Another reason to take a good, long look at Moxie Marlinspike's Convergence system. Basically, it does away with CAs in favor of a trusted and anonymous notary-based system.
I think the best thing about Marlinspike's system is that it doesn't do away with the CAs. Rather, it provides a stand-beside certificate validation mechanism; there's no reason a site can't use both, and using both actually increases the security over using either one alone.
There must be something I don't understand about this system...
The whole idea is to compare a certificate served by a website to a client with one received from the same destination by a notary. If the client is surfing from a compromised network and gets served a fake certificate, it won't match with the one from the notary, triggering an alert.
How does it prevent a man in the middle attack from simply forging the certificate and all of the notary responses?
Wrong question.
The notary responses can't be forged; they're signed, and you have their public keys. This is essentially the same as having the public keys of a bunch of CAs, and you'd probably get those keys in the same way: with your browser (though it's more likely that you'd edit them, or replace them with a set from some reputable site, etc.).
The right question is: How does it prevent a man in the middle attack from simply fooling all of the notaries?
The idea is that it's difficult for an attacker to get between the targeted server and all of the notaries, and even if he can, it's impossible for him to hide the fact that he's done so from the targeted server, which can (and should) also make periodic queries to the notaries, asking them what certificate they're seeing from it (note: this last bit is my assumption about how Marlinspike assures the notaries aren't serving up the attacker's cert; I haven't actually seen any explanation of it from Marlinspike).
As long as some notary has a network path to the server that the attacker can't compromise, that notary will report the true site certificate, rather than the attacker's substitution. This means, effectively, that the attacker must compromise all network paths between the server and the rest of the world. And if any notary is being fooled about the site's certificate, the site can find that out by querying the notary.
It's also important to realize that Marlinspike's system is an additional verification mechanism that can stand beside the existing PKI infrastructure, not a pure replacement. You can easily have both the decentralized notary system plus the centralized certificate authority system and, in fact, if Marlinspike's system were deployed I would expect high-value sites to have CA-issued certificates, and multiple network connections from independent providers, and to work with major notary service providers through a second channel to ensure that only their correct certificate is verified by the notary.
The result would be nearly impossible to subvert.
As a bonus, Marlinspike's system would allow self-signed certificates to operate with a fairly high degree of assurance.
If youre worried about encrypting the contents of RAM, youre trying to protect against an attack which needs far more physical access than booting off of a CD and loading a malicious MBR onto the drive.
Right, you have to take the laptop. So? In many contexts this is significantly easier than getting control of it twice, with the owner none the wiser in between.
theyre simply going to modify your bios or bootloader or insert a keylogger inbetween the keyboard and motherboard, and find out your passphrase.
That's a significantly different threat model. It presumes that the attacker can gain access to your hardware, modify it, then return it to you without you noticing it was gone or that it was modified, and then take your machine again.
Not that this is impossible, but it raises the stakes and the difficulty significantly.
Many minorities pursue careers in sports and music because their other opportunities for social and economic advancement are more limited. It's not genetics. It's culture. Specifically, it's a culture recovering from long-term, widespread racism.
True, but you've got to admit there's a significant genetic factor in which sports they choose. Witness the huge number of latin american basketball and football players, and the prevalence of blacks and pacific islanders in baseball.
In any case it is generally considered to be morally wrong to write people off based on a visible characteristic that they can't change or choose
But the OP isn't doing that. What he's doing is avoiding doctors who have been held to lower standards in entering and completing medical school. That's not a characteristic they can change or choose, but it's a real and valid one. "Held to a lower standard in medical school" isn't generally a "visible" characteristic, but in this case he is able to identify at lease some such doctors by their skin color, because that's how the medical schools identify them. Of course, many of these doctors didn't need to be given a lower bar, and could have done fine with the standard requirements, but there's no reasonable way to identify which only made it because of the lower requirements and which would have succeeded regardless.
At bottom, this is exactly the same as judging a professional's ability by the school they graduated from. Do I think that a CS graduate of Stanford, MIT, CMU, etc., is likely to be smarter and a more talented programmer than a CS graduate from Podunk U? Yes, I do, but the reason has much less to do with the quality of education offered than it does the filtering performed. It's possible for both idiots and geniuses to graduate from Podunk U, but idiots have a very difficult time getting into and through, say, Stanford's CS program.
Also, I have to point out that you're trying to subtly redefine the term "racist", to say that anyone making any decisions based on racial indicators is racist. But that's not what the term means. The correct definition of "racist" is a person who believes that certain races of people are inherently better or worse, and that's not what the OP is saying at all. He doesn't believe black doctors are inherently inferior, either individually or as a group. He says they are inferior because the medical schools have chosen to make them inferior, by doing a less effective job of filtering.
He's not saying black doctors are inferior because of their race, but that their race is an indicator that they're inferior. It's a subtle distinction, between a direct cause (which is fallacious) and an indirect cause (which may be real).
Of course, in an ideal world we would all judge each person on their own personal, individual merits, but unfortunately that's impossible. I have some ability to judge programmers by their individual ability, by asking them to solve hard problems and implement the solutions, but I don't have the knowledge needed to do the same for doctors. So, I have to go by the school they graduated from, their apparent success in the field, etc. But if they're a minority who "benefits" from AA, then I have to downgrade my school-related expectations -- because the school did.
America fixed this with the, less than ideal, 2 party system, all or nothing, and if less than 50%, you have a run off.
No, most of America does not require a run-off if no candidate gets 50%. There are a few jurisdictions that do, for some elections, but in general winners with less than 50% of the vote are common.
You have to trust _someone_ ultimately or you wouldn't vote at all.
No you don't. Well, I suppose you're stuck with trusting that the people you elect will do a good job, but you don't have to trust the election committee to correctly collect and count the ballots, thanks to some very cool work by some of the world's foremost cryptographic protocol designers. Check out the Scantegrity system. It provides end-to-end verifiability, including allowing individual voters to verify that their vote was counted as they intended, but without compromising voter anonymity.
It would be great to have SSL fixed but it won't happen. The reasons are (same as Flash, HTML5 and Java, IPV6):
1) has a monetary interest in the technology
2) The public/private sectors have adopted this as defacto standard
3) Haters hate change in the name of "secure"
The only way to change this is to implement a work-around which excludes the current 'key masters' and makes the previous technology obsolete (like HTML5.. ok, mostly obsolete).
Marlinspike's proposed replacement avoids that issue by making the change something that can be implemented on the user side without any action on the part of standards bodies or site owners. Really, the only players who have to implement the technology in order for it to work are the browser makers, and they can even make it optional.
Another aspect of it that I like is that it facilitates the use of self-signed certificates. Also, it's worth pointing out that his suggestion isn't so much a "replacement" for the CA system, but a stand-beside additional validation method. So for sites that use a CA you can get both checks. For sites with self-signed certs, you only get the Convergence validation.
Supposedly.
One problem I see is that the information provided on the Convergence web site is completely insufficient to understand how it works. The "Details" page doesn't really provide much. Here's my guess as to how it works:
There are a set of servers scattered around the net which can be queried to validate a certificate. These can be run by anyone.
The way one of these validation servers checks a certificate is (I think) by making a request to the site and looking at the certificate they receive from it. Perhaps they also check it against the certificate they've received from that site in the past, and perhaps the servers talk amongst themselves.
Your browser has a list of such servers, and whenever you visit a site for the first time, it queries several (all?) of them to see if they got the same certificate from the site that you did.
Assuming my guesses are right, I think the core idea is clever and potentially very useful, but I see some flaws (which Marlinspike may well have completely addressed with his design -- but it's not clear how based on the minimal information I've seen).
The approach defends against man-in-the-middle attacks unless the attacker has also compromised the link between the site being validated and the validation servers. This means that MITM attacks mounted "close" (in terms of network topology) to the user will be basically impossible (modulo the next point), but attacks mounted close to the site will be very likely to succeed. To make the security good, you also need to ensure that the client is using a well-distributed set of validation servers.
The approach assumes that the client can trust its communications with the validation servers. This seems simple enough, though; when you configure a list of validation servers you also configure their certificates, much the same way you add a CA to your browser configuration. Then when the browser talks to the validation server it uses SSL and checks that the server cert matches the configured value.
Another issue that comes up is how to know what set of validation servers to use. Obviously users aren't going to configure this, any more than they configure their list of SSL CAs. The clear solution is the same one used for the CA list -- let the browser makers vet the validation servers and provide a default list, pre-configured. The user can alter it, but generally won't. If a validation server proves untrustworthy or unreliable, it can simply be removed in an update. Given the use of multiple validation servers, removing an untrustworthy one would be an important but not particularly urgent change. This is the "Trust Agility" Marlinspike speaks of... you can stop trusting someone who proves th
Exactly. Smart pointers do better than garbage collection since they allow one to i) control reclamation much more flexibly (especially if using custom allocators and deleters), and ii) handle many types of resources other than memory; smart pointers is just the ligical completion of the RAII principle, really. Java GC is like an automatic transmission--you move the lever to select D and press the gas. And D is for "Dummy".
Yes and no.
The ability to use a consistent methodology for handling all scarce resources is very nice, but there are some significant downsides to semi-automated memory management via smart pointers and the like as well. One obvious problem is memory leaks due to circular references. GC can clean up circular structures while smart pointers can't (efficiently). The biggest issue, though, is one of developer effort. Even with good smart pointers, it requires effort and discipline to plan and implement a memory management strategy with manual or semi-automated techniques. Developer time is much more valuable in most cases than machine time, so it makes sense to let the machine figure out when to deallocate stuff -- and in practice GC often consumes fewer processor cycles than manual deallocation. Lacking RAII, Java/Ruby/Python/etc. developers have to put more effort into management of non-memory resources than C++ developers do, but those other sorts of resources are used much less often than heap space, so the end result is less effort.
The flip side is that sometimes the effort put into thinking about resource lifetime in order to manage it in C++ pays dividends in terms of better design. I've often seen that while thinking hard about what objects should live and die together, in order to figure out what sorts of pointers to use, I notice other elements of the solution structure and make choices that result in clearer and more maintainable code. But that's not really an argument for manual memory management, because it's absolutely possible to put in that same effort and reap the same rewards in a garbage-collected language.
I think manual memory management is also contra-indicated for heavy parallel programming, which is going to become more and more the norm as core count rises. My opinion is that we're going to see a shift towards functional programming paradigms because from the developer's perspective they eliminate mutable data. In functional styles you "modify" data by making a copy with the changes incorporated into it, which largely eliminates race conditions and the need for locking. Of course, never modifying data in-place is hugely wasteful of memory, but it's the compiler and run-time that have to worry about that. They can figure out when it's safe to modify data in-place, and when it must actually be copied and the result is very efficient in programmer time and reasonably time and space-efficient as well. But that approach absolutely demands GC.
In summary, there are pros and cons to both, but overall I think GC makes more sense for most software. Software that needs very precise control of memory consumption benefits from C++-style memory management, as does software whose primary task is managing non-memory resources, and there are probably some other categories that aren't coming to mind right now. Note that I don't think GC should be added to C++, though. The language would have to be changed too dramatically to make that feasible, in ways that would break it for software that needs manual memory management.
Then you're going to have to nab an employee, take their card and "motivate" them to give you the password.
Find lowest-paid employee and pay them double their yearly salary for the password. If you don't have the budget for that, you're not really involved in industrial espionage.
Yep, that should do the trick very neatly.
I don't think that qualifies as "easier than gaining access to an RJ-45 port", though.
The fact is that gaining physical access to active Ethernet RJ45 port is significantly more difficult than sitting outside an office and hacking into a WiFi network.
Easier than breaking WPA2? Nonsense.
Barring some newly-discovered weakness in the protocol (very unlikely at this point), breaking WPA2 essentially requires breaking AES or the public-key algorithm you're using for your 802.1x EAP-TLS certificates (no business would use PSK, right?). The only practical way to get in is to get hold of a client certificate by compromising a machine with access (e.g. a laptop). Unless of course your target keeps their client keys on password-protected smart cards. Then you're going to have to nab an employee, take their card and "motivate" them to give you the password.
Of course, if you really care about security, you should be using EAP-TLS authentication on your wired network as well.
Slashdot Mirror
Compilers are not chickens.
He couldn't have created the OS on the computer on which he began creating C in C because he hadn't created it yet
Not at all. OS and language grew up together. The first, simplest implementations of both had to be written in assembler, but they quickly became self-hosting.
Actually, that message is ambiguous -- it doesn't specify whether it's master.kernel.org or github that will be "just a mirror".
Is there a difference? I suppose if Linus runs "git push kernel.org master" before doing "git push github master" then people grabbing from kernel.org might get the latest version a few seconds sooner.
Or maybe Linus will get tired of having to do both and add a "multiple remote alias" feature so that he can push to both simultaneously.
Experience with real life tools are irrelevant.
Yes, it is. Because by the time students get to real life, the tools have changed.
Keeping students engaged isn't important.
It's important iff lack of engagement reduces learning. Learning should be reflected on test scores, so if computers don't increase test scores, then either computers don't increase engagement, or lack of engagement wasn't a problem.
They cut down the amount of geeky stuff like work-on-your-own-projects
I'm a software engineer at Google, and this isn't true. There has been no pushback on 20% projects; and lots of people still have them (I do). Nor, from what I can see, is there any significant limitation on employees' ability to choose what kinds of things they want to spend their 20% time on.
Rather, I think actions like this are a natural consequence of the freedom given to Googlers to work on what they want to. That freedom means that Google ends up doing a lot of random things. The things that look somewhat promising get more investment and get rolled out to the public. Some work, most don't, and the result is that eventually the projects that aren't panning out get axed. That doesn't mean Googlers can't continue working on them in 20% time if the wish, though it's doubtful that many will want to.
they use every evil marketing tactic in the book
I think this is simply untrue, but it's not possible to debate such broad generalizations.
There's another option: Go to a cheaper school and exploit the other financial assistance options. A cheaper school will give you an education that is 90% as good, for 10% of the cost, and if you take advantage of grants, scholarships and part-time jobs it's perfectly feasible to get a four-year degree and walk away with no debt whatsoever. Of course, you'll have to spend your evenings working, rather than drinking with your friends.
If you truly can't find another decent-paying job because your experience sucks, perhaps you need to take a lesser-paying job working on mainstream stuff, to build up the experience you need for decent-paying jobs working on mainstream stuff. I'm assuming that the problem is that your "business software" is written in some lesser-used language and toolset. If you're writing "business software" in something like Java or C# and potential employers are telling you they aren't hiring you because of the type of software you've been writing, they're lying to you.
I also recommend that, rather than drinking, you do some side projects at home. Try to recover the joy you found in writing software when you first started, and take the opportunity to learn some other languages and tools, and perhaps even to build yourself a portfolio of open source software to use as a proof of experience. Good employers will give that sort of thing as much weight as work experience. Plus it's fun!
If, on the other hand, you see writing code as drudgery never found any joy in doing it for its own sake, then you really need to think about changing careers because software development isn't for you. If you're not passionate about it, you'll hate it wherever you're doing it -- and, honestly, you'll suck at it, which will mean that you'll never get a chance to work at the places you wouldn't hate.
I'm thinking a box that looks like a CRT monitor on your head and maybe a shirt with a keyboard drawn on it.
Not sure the CRT look is ideal... many six and seven year-olds may never have seen a CRT. They're familiar with flat panel monitors and TVs.
Their freedom to lie isn't quite that broad. If they make claims that they're giving you lawful orders which they do not in fact have the authority to give, then the results of those orders are tainted. If they step far enough over the line, they can even be prosecuted for civil rights violations. It doesn't happen often, but it does happen.
In this case, if the officers told her they had a search warrant, then they were telling her that she was required to submit to the search. That means the search was not voluntary, because she believed she was obligated to comply with a court order. And an involuntary, warrantless search is unconstitutional and the results of any such search can and should be inadmissible in court.
I agree, with the caveat that I think browsers should do ssh-style key history tracking. For all certs, not just self-signed, but it's especially important for self-signed certs. If I visit a site every day for a year and it always has the same certificate, that is actually a much stronger statement of trust than a signature by some random CA, but if that certificate suddenly changes there should be big red warnings. Further, I like the ssh model wherein the user is recommended to do some additional verification the first time they see a particular cert. It needn't be scary, and most users won't bother, but the offer should definitely be made and the user should have to make a deliberate choice to bypass it without verification.
It might also be good to allow the user to confirm if they have actually validated the fingerprint. If so, then the lock icon can be displayed. This might add too much UI complexity for most people, however.
Such an approach would play very nicely with Marlinspike's distributed notary system, BTW. A newly-seen cert (self-signed or not) should definitely be checked against all the notaries, but one that the browser has seen before, especially many times before, doesn't need the same level of checking. In fact, if a cert has been seen before, the browser should probably go ahead and display the site and then check with some notaries in the background.
Another reason to take a good, long look at Moxie Marlinspike's Convergence system. Basically, it does away with CAs in favor of a trusted and anonymous notary-based system.
I think the best thing about Marlinspike's system is that it doesn't do away with the CAs. Rather, it provides a stand-beside certificate validation mechanism; there's no reason a site can't use both, and using both actually increases the security over using either one alone.
There must be something I don't understand about this system...
The whole idea is to compare a certificate served by a website to a client with one received from the same destination by a notary. If the client is surfing from a compromised network and gets served a fake certificate, it won't match with the one from the notary, triggering an alert.
How does it prevent a man in the middle attack from simply forging the certificate and all of the notary responses?
Wrong question.
The notary responses can't be forged; they're signed, and you have their public keys. This is essentially the same as having the public keys of a bunch of CAs, and you'd probably get those keys in the same way: with your browser (though it's more likely that you'd edit them, or replace them with a set from some reputable site, etc.).
The right question is: How does it prevent a man in the middle attack from simply fooling all of the notaries?
The idea is that it's difficult for an attacker to get between the targeted server and all of the notaries, and even if he can, it's impossible for him to hide the fact that he's done so from the targeted server, which can (and should) also make periodic queries to the notaries, asking them what certificate they're seeing from it (note: this last bit is my assumption about how Marlinspike assures the notaries aren't serving up the attacker's cert; I haven't actually seen any explanation of it from Marlinspike).
As long as some notary has a network path to the server that the attacker can't compromise, that notary will report the true site certificate, rather than the attacker's substitution. This means, effectively, that the attacker must compromise all network paths between the server and the rest of the world. And if any notary is being fooled about the site's certificate, the site can find that out by querying the notary.
It's also important to realize that Marlinspike's system is an additional verification mechanism that can stand beside the existing PKI infrastructure, not a pure replacement. You can easily have both the decentralized notary system plus the centralized certificate authority system and, in fact, if Marlinspike's system were deployed I would expect high-value sites to have CA-issued certificates, and multiple network connections from independent providers, and to work with major notary service providers through a second channel to ensure that only their correct certificate is verified by the notary.
The result would be nearly impossible to subvert.
As a bonus, Marlinspike's system would allow self-signed certificates to operate with a fairly high degree of assurance.
I really like it.
If your Google Profile is disabled, a shit load of other services are impacted.
Cite?
Yeah, I know the summary says that, but the article says the opposite.
If youre worried about encrypting the contents of RAM, youre trying to protect against an attack which needs far more physical access than booting off of a CD and loading a malicious MBR onto the drive.
Right, you have to take the laptop. So? In many contexts this is significantly easier than getting control of it twice, with the owner none the wiser in between.
theyre simply going to modify your bios or bootloader or insert a keylogger inbetween the keyboard and motherboard, and find out your passphrase.
That's a significantly different threat model. It presumes that the attacker can gain access to your hardware, modify it, then return it to you without you noticing it was gone or that it was modified, and then take your machine again.
Not that this is impossible, but it raises the stakes and the difficulty significantly.
Many minorities pursue careers in sports and music because their other opportunities for social and economic advancement are more limited. It's not genetics. It's culture. Specifically, it's a culture recovering from long-term, widespread racism.
True, but you've got to admit there's a significant genetic factor in which sports they choose. Witness the huge number of latin american basketball and football players, and the prevalence of blacks and pacific islanders in baseball.
In any case it is generally considered to be morally wrong to write people off based on a visible characteristic that they can't change or choose
But the OP isn't doing that. What he's doing is avoiding doctors who have been held to lower standards in entering and completing medical school. That's not a characteristic they can change or choose, but it's a real and valid one. "Held to a lower standard in medical school" isn't generally a "visible" characteristic, but in this case he is able to identify at lease some such doctors by their skin color, because that's how the medical schools identify them. Of course, many of these doctors didn't need to be given a lower bar, and could have done fine with the standard requirements, but there's no reasonable way to identify which only made it because of the lower requirements and which would have succeeded regardless.
At bottom, this is exactly the same as judging a professional's ability by the school they graduated from. Do I think that a CS graduate of Stanford, MIT, CMU, etc., is likely to be smarter and a more talented programmer than a CS graduate from Podunk U? Yes, I do, but the reason has much less to do with the quality of education offered than it does the filtering performed. It's possible for both idiots and geniuses to graduate from Podunk U, but idiots have a very difficult time getting into and through, say, Stanford's CS program.
Also, I have to point out that you're trying to subtly redefine the term "racist", to say that anyone making any decisions based on racial indicators is racist. But that's not what the term means. The correct definition of "racist" is a person who believes that certain races of people are inherently better or worse, and that's not what the OP is saying at all. He doesn't believe black doctors are inherently inferior, either individually or as a group. He says they are inferior because the medical schools have chosen to make them inferior, by doing a less effective job of filtering.
He's not saying black doctors are inferior because of their race, but that their race is an indicator that they're inferior. It's a subtle distinction, between a direct cause (which is fallacious) and an indirect cause (which may be real).
Of course, in an ideal world we would all judge each person on their own personal, individual merits, but unfortunately that's impossible. I have some ability to judge programmers by their individual ability, by asking them to solve hard problems and implement the solutions, but I don't have the knowledge needed to do the same for doctors. So, I have to go by the school they graduated from, their apparent success in the field, etc. But if they're a minority who "benefits" from AA, then I have to downgrade my school-related expectations -- because the school did.
When I hear the name Kim, I think of a white girl named Kimberly....not an Asian.
And Wilfong is a European surname, though I suppose the "fong" part might sound vaguely Asian.
America fixed this with the, less than ideal, 2 party system, all or nothing, and if less than 50%, you have a run off.
No, most of America does not require a run-off if no candidate gets 50%. There are a few jurisdictions that do, for some elections, but in general winners with less than 50% of the vote are common.
You have to trust _someone_ ultimately or you wouldn't vote at all.
No you don't. Well, I suppose you're stuck with trusting that the people you elect will do a good job, but you don't have to trust the election committee to correctly collect and count the ballots, thanks to some very cool work by some of the world's foremost cryptographic protocol designers. Check out the Scantegrity system. It provides end-to-end verifiability, including allowing individual voters to verify that their vote was counted as they intended, but without compromising voter anonymity.
Ugh. When did slashdot's formatting of lists get broken?
It would be great to have SSL fixed but it won't happen. The reasons are (same as Flash, HTML5 and Java, IPV6): 1) has a monetary interest in the technology 2) The public/private sectors have adopted this as defacto standard 3) Haters hate change in the name of "secure"
The only way to change this is to implement a work-around which excludes the current 'key masters' and makes the previous technology obsolete (like HTML5.. ok, mostly obsolete).
Marlinspike's proposed replacement avoids that issue by making the change something that can be implemented on the user side without any action on the part of standards bodies or site owners. Really, the only players who have to implement the technology in order for it to work are the browser makers, and they can even make it optional.
Another aspect of it that I like is that it facilitates the use of self-signed certificates. Also, it's worth pointing out that his suggestion isn't so much a "replacement" for the CA system, but a stand-beside additional validation method. So for sites that use a CA you can get both checks. For sites with self-signed certs, you only get the Convergence validation.
Supposedly.
One problem I see is that the information provided on the Convergence web site is completely insufficient to understand how it works. The "Details" page doesn't really provide much. Here's my guess as to how it works:
Assuming my guesses are right, I think the core idea is clever and potentially very useful, but I see some flaws (which Marlinspike may well have completely addressed with his design -- but it's not clear how based on the minimal information I've seen).
Another issue that comes up is how to know what set of validation servers to use. Obviously users aren't going to configure this, any more than they configure their list of SSL CAs. The clear solution is the same one used for the CA list -- let the browser makers vet the validation servers and provide a default list, pre-configured. The user can alter it, but generally won't. If a validation server proves untrustworthy or unreliable, it can simply be removed in an update. Given the use of multiple validation servers, removing an untrustworthy one would be an important but not particularly urgent change. This is the "Trust Agility" Marlinspike speaks of... you can stop trusting someone who proves th
Exactly. Smart pointers do better than garbage collection since they allow one to i) control reclamation much more flexibly (especially if using custom allocators and deleters), and ii) handle many types of resources other than memory; smart pointers is just the ligical completion of the RAII principle, really. Java GC is like an automatic transmission--you move the lever to select D and press the gas. And D is for "Dummy".
Yes and no.
The ability to use a consistent methodology for handling all scarce resources is very nice, but there are some significant downsides to semi-automated memory management via smart pointers and the like as well. One obvious problem is memory leaks due to circular references. GC can clean up circular structures while smart pointers can't (efficiently). The biggest issue, though, is one of developer effort. Even with good smart pointers, it requires effort and discipline to plan and implement a memory management strategy with manual or semi-automated techniques. Developer time is much more valuable in most cases than machine time, so it makes sense to let the machine figure out when to deallocate stuff -- and in practice GC often consumes fewer processor cycles than manual deallocation. Lacking RAII, Java/Ruby/Python/etc. developers have to put more effort into management of non-memory resources than C++ developers do, but those other sorts of resources are used much less often than heap space, so the end result is less effort.
The flip side is that sometimes the effort put into thinking about resource lifetime in order to manage it in C++ pays dividends in terms of better design. I've often seen that while thinking hard about what objects should live and die together, in order to figure out what sorts of pointers to use, I notice other elements of the solution structure and make choices that result in clearer and more maintainable code. But that's not really an argument for manual memory management, because it's absolutely possible to put in that same effort and reap the same rewards in a garbage-collected language.
I think manual memory management is also contra-indicated for heavy parallel programming, which is going to become more and more the norm as core count rises. My opinion is that we're going to see a shift towards functional programming paradigms because from the developer's perspective they eliminate mutable data. In functional styles you "modify" data by making a copy with the changes incorporated into it, which largely eliminates race conditions and the need for locking. Of course, never modifying data in-place is hugely wasteful of memory, but it's the compiler and run-time that have to worry about that. They can figure out when it's safe to modify data in-place, and when it must actually be copied and the result is very efficient in programmer time and reasonably time and space-efficient as well. But that approach absolutely demands GC.
In summary, there are pros and cons to both, but overall I think GC makes more sense for most software. Software that needs very precise control of memory consumption benefits from C++-style memory management, as does software whose primary task is managing non-memory resources, and there are probably some other categories that aren't coming to mind right now. Note that I don't think GC should be added to C++, though. The language would have to be changed too dramatically to make that feasible, in ways that would break it for software that needs manual memory management.
Then you're going to have to nab an employee, take their card and "motivate" them to give you the password.
Find lowest-paid employee and pay them double their yearly salary for the password. If you don't have the budget for that, you're not really involved in industrial espionage.
Yep, that should do the trick very neatly.
I don't think that qualifies as "easier than gaining access to an RJ-45 port", though.
The fact is that gaining physical access to active Ethernet RJ45 port is significantly more difficult than sitting outside an office and hacking into a WiFi network.
Easier than breaking WPA2? Nonsense.
Barring some newly-discovered weakness in the protocol (very unlikely at this point), breaking WPA2 essentially requires breaking AES or the public-key algorithm you're using for your 802.1x EAP-TLS certificates (no business would use PSK, right?). The only practical way to get in is to get hold of a client certificate by compromising a machine with access (e.g. a laptop). Unless of course your target keeps their client keys on password-protected smart cards. Then you're going to have to nab an employee, take their card and "motivate" them to give you the password.
Of course, if you really care about security, you should be using EAP-TLS authentication on your wired network as well.