This is a rating system for games, to which many publishers subscribe voluntarily, and it is referred to by the IDSA lawyer. Few people have a problem with labelling of in this manner.
So I, like many people, support labelling, responsible parenting, and having the State keep its nose out of the issue of morality. These are not mutually exclusive viewpoints.
I would support a system (voluntary or otherwise) that sees all entertainment material (movies, books, music, games) accompanied by a rating (that is reviewed for every item by some independant body), and places an onus on vendors to not sell such material to a minor under the recommended age. However, a parent or guardian should have the right to purchase any good or service on behalf of that minor, irrespective of the recommendations given on the label.
Havok! cry the mommies. Daddy will be taking junior to the next SLVN movie that comes out. And that is the way it should be. If the parent is being responsible they will not take such an action until they are happy that the child / young adult is mature enough; if the parent is not responsible there are many other applicable laws that can be invoked (in this case, child abuse).
But an outright ban on access to certain material by minors, as is effective in many countries, especially a preemptive one, is damaging to society.
To begin with, you are imposing artificial limitations on human activity and development. Children are naturally curious; an aspect that adults seem to forget. Banning access to material creates or inflames a curiousity about that material. While the material itself could be harmful, the behaviour that may result (including deceit, theft, etc) in an effort to satisfy that curiousity is often more harmful. Worse still many parents sympathise with this activity and do not sufficiently punish it, leaving the message that its okay to break the rules.
Then we have the question that we started with: is this material actually harmful? There is evidence to suggest that graphic pornography and violence is bad for young children, but most of that evidence suggests that the response is trauma, not mimicry. Psychology is a field notorious for claims that appear to be supported by evidence, but are merely one way of reading the statistics (and yes, I have a major in Psychology).
In times gone by children had far more direct access to REAL violence and pornography. Parents weren't so careful not to be "caught in the act". We have lives through many wars and revolutions, much bloodshed, in the past centuaries. And now we believe our children can't handle it?
Maybe we should also be asking ourselves: how much do we damage children by "protecting" them against this material? Growing up is a process of learning, not only knowledge, but coping skills and emotional control. If you have never been subjected to a crisis before you were an adult (legally), how can you be expected to behave responsibly when you are an adult? Experience is a vital component of development, and something we are increasingly removing from our childrens' lives in the quest to "protect" them.
Great point about client certs! Users and admins seem to forget that the client computer itself may not be secure, in which case you can't trust SSL.
There are also many other features you lose without a full client application; especially the ability to have your entire mail folder on your own computer (so that you only have to retrieve new mails).
Its the "you need an external lib to access it from Tcl itself" that I'm referring to. I have seen many comments on how great the threading in the core is, and even when using to/from C/C++ ; but as an application developer its pretty useless to me if I can start a thread from within my (Tcl) program.
incrTcl is on of several object systems for Tcl. The primary problem with an object system being an add-in is that Tk cannot then rely on having an object system available, which means you can't create generic encapsulations of Tk widgets as objects, short of using an entirely new widget set (such as incr Tk).
incr Tk has its own problems: it is very large, and provides its own look and feel that is very weird on most platforms.
Now that we have Tclkit, I would also support having sockets and regexp as modules; but an object system shouldn't be an add-on to a language anymore than security should be an add-on to an application.
I have a love-hate relationship with TCL. In the past I have been part of a large development effort where the basis was TCL (read: the rapid prototype looked good, worked, and the chaps upstairs didn't see a need to rewrite in a different language) and was amazed by its power, extensibility and simplicity.
On the other hand I have found it the second most difficult language I've had to learn, its constructs for complex operations (such as callbacks) can be very confusing, and it lacks several important features than mean a lot of workarounds.
To get into specfics:
Tcl does not have threading support. I am aware of a threads library that exists now, but its still not part of the core, and poorly documented. I haven't even found a starkit that has it. With Tcl 7.x and even 8.0 we were forced to use extensions and/or script/batch files to invoke multiple interpretters, and introduce nasty platform-specific hacks.
Tcl's support for reusable code (especially GUI code) is either rotton, or simple doesn't fit into modern design idioms. A simple reusable dialog that can attach to one of several sets of back-end data (and with the possibility to display several such dialogs simultaneously) is incredibly hard to do "right" in Tcl (e.g. getting a button to call back to the right function, which is easy in an OO paradigm). incrTcl/Tk doesn't help much either: without rewriting the megawidgets you're stuck with a very strange look and feel that doesn't really fit in with ANY platform. This is all, of course, related to...
Tcl doesn't have native object support. And it sorely needs it.
On the up side, Tclkit and starkits have brought Tcl a LONG way, and I think we can look forward to Tcl being used a lot more on the client end as client-server applications increase their support for multiple platforms.
There are two parts to DLL Hell. The first is well known: a DLL is replaced with a different version, causing software to break. The second is more subtle: a program is uninstalled causing a DLL to be removed or rolled back, and software breaks.
The more structured a system in terms of storing shared libraries centrally, the worse problem #2 becomes, and the better the tracking required (i.e. registry entries to indicate software using that DLL) to prevent the problem.
This is why a lot of modern software opts to have DLLs in its own directory structure, rather than to use the shared DLLs. Bypassing lots of hell.
Of course, there are a number of interesting ways to combat this problem. One of the best is to use hard links (which are supported on NTFS) to link a DLL from a shared location into an application's directory structure. This only works successfully if there is a mechanism for versioning DLLs where the versions are stored in different files (a la Unix). It prevents removal (and with the correct permissions overwriting) of a DLL that is required by installed software.
Of course, if you write "smarter" installer programs that follow the behaviour expected from the MS OS (write shared DLLs to the registry, identify programs that share them, store in \SYSTEM32), you end up with more upset users because (1) DllHell means you break programs that rely on the bugs in older versions of the shared library; (2) DllHell means your program breaks because you rely on the bugs in a version of the shared library but the system already has a newer version; (3) You have to reboot after installing because a system library needs to be replaced (and was most likely in use during the install, say by Explorer).
The problem here is smart developers, who will insist on a DLL-version-specific workaround to do whatever it is they have their minds set on doing. Simple rule: if you think a library function isn't behaving correctly, don't use it like that, or your code won't work when they fix it! An often better solution is to distribute the shared libraries your program uses with it, but not install them as shared libraries, neatly bypassing the DLL problem, but irritating people like you, who find this a hack solution.
I usually appreciate Joel's views, but this article is way off base. He would do well to study group psychology and collaboration before making comments like this.
In one breath he wails about the lack of "community", and in the next distinguished between "newbies" and "old timers" on a usenet group. These categories emerge strictly as a result of the community building process, whereby it is difficult for a newcomer to enter a (social) group on an equal footing to existing members.
The idea that quoting is a "disease" is misguided at best. Because a single e-mail or post represents several parts of a conversation, indicating the context to which you are referring is essential. This is even more true in the case of online systems that will be used in the future as archive and/or reference material, where it will be difficult and time-consuming to follow the entire conversation from the beginning to the point of interest. While quoting of entire posts is indeed a curse, selective quoting to indicate context is necessary for meaningful communication.
When it comes to e-mail notification, Joel is even more far gone. All literature on the relatively new field of active collaboration indicates that people have less time to do more things, and the best way to achieve collaboration is to tell them what they need when they need it. I used to spend plenty of time and bandwidth browsing to Slashdot to find out if someone had replied to my comments; now I know when this happens, and can follow up in a reasonable period of time. Conversations that may have taken days and stagnated can now be more meaningful.
Branching? Let's thing about this for a moment -- there is a lecture theatre with (say) 100 people in the audience; after a short speech (the "initial post") there is a break for discussion. Does each person insist on an opportunity to stand at the podium and give their 5c, or do they go and huddle with other people and discuss their views and interpretation. And which system is better suited to communicating and increasing group knowledge, assuming all conversations are recorded and archived?
While Joel's commented on Slashdot may be warranted, it (Slashdot) is nevertheless the closest thing on the public Internet to Active Collaborative Filtering (ACF). The idea of ACF is that there is too much content for you to process (filter) on your own. Instead you can leverage the processing (filtering) of others (experts in the field and/or people you trust to be like-minded). Slashdot's moderation system is a simple implementation of ACF, assuming you trust all geekdom to be like-minded. The ability to assign additional moderation to particular users progresses the system more towards true ACF. In any event it is a more reliable system than moderation by a number of pre-selected moderators.
While not a scientific method for discrimination, I think the pool o' geeks method works quite well.
Dude: "Amazon has come up with this idea of making a purchase with just one click."
Geeks: That's silly. Its impossible unless you pre-store information, so its not really one click.
Dude: "Google has come up with this idea of ranking pages according to the number of other pages that link to them, rather than the occurance of keywords in the page"
Geeks: Hey, that's pretty neat! Good way to filter out the lousy stuff.
And yes, this is the response I get from most people that I tell about Amazon and Google (techie and otherwise).
Maybe Google's technique was around in some form or another before, but Google applied it and made it work and as a result we've seen progress in the field (Google isn't the world's favourite search engine for nothing). Amazon didn't do anything more complex than create a shortcut that starts with "buy" command in non-interactive mode.
To add a spanner to my own comment: if you want to attack Google's position on trademarks, ask yourself if they can trademark "google" at all. This is, after all, an English word, and in Lindows v Microsoft we saw the judge question the validity of the Windows trademark on the same basis.
Aside: Since in this context "google" is not being used in the same sense as the word, or even a related sense, the trademark would most probably hold.
I'm not interested in the why. While I would prefer to take the naive view you are taking, the courts have found that trademarks are diluted by generic use, and that unless active steps are taken to protect a trademark it can be diluted and eventually lost. The accepted legal term is genericide.
I must apologise that Xerox(R) is not a case in point - it managed to keep its trademark, as did Kleenex(R). Aspirin and thermos weren't so lucky. This is discussed in an article and reinforced by TSANet(R)'s trademark policy
(since they have been in past danger of trademark dilution... goodness knows why).
I don't like the way the world works... especially in this regard. But this is how things go. If Google did not take steps to protect its trademark (especially in a lexicon or dictionary) it may see the trademark diluted, and in future we could see an "MSN google service".
You may find that CVS (and friends) is not a source versioning system. It is a document versioning system. Revision control is a well-studied topic, and can be provided for by a number of products. Revision contorl in a hierarchy and/or file system is similarly nothing new: older Unix systems had versioned file systems, and there are dozens of commercial document management and revision control products on the market.
Content management is distinct from revision control. It is possible (although stupid) to have content management without revision control.
but also includes a system to quickly and directly retrieve content for a web site/application and other such ammenities described in the patent. You would never do such a thing with CVS, unless you're insane
Most people find that tags/labels work just fine. There are many docs and books on how to do exactly that with CVS.
The idea of adding workflow to SCM is not new; in fact its a best practice in many organisations (just not necessarily integrated into a product, unless you're using Rational's suite).
The patent was filed on 3 Feb 1999. Depending on how you read the legalese of the claims, use of CVS (for web development) may or may not be covered by this patent.
Prior art with regard to CVS is easy to prove. Back in 1997 cyclic.com already had a CVS and the Web page. That page references amongst others L.D.Stein's book How to set up and maintain a web site, that makes mention of the use of CVS for version control.
By 1998 the same page on cyclic included a link to Sean Dreilinger's
CVS Version Control for Web Site Projects (link to current version). archive.org does not appear to have the original document, but the link is on cyclic.com circa Dec 1998, and Sean's Copyright is dated back to 1997.
And just in case anyone didn't get the message, WebDAV (RFC) has a history (and more) going back to 1996. The RFC was published in (surprise surprise) Feb 1999.
Hoover and Xerox. Both brands became so pervasive that they became verbs and subsequently lost control over their trademark. The courts found that they hadn't taken adequate steps to protect their respective trademarks. Implicitly this means that a trademark holder has a right (and in fact a responsibility) to protect their trademark from falling into common use in this manner.
In this specific case, however, I would contend that the interpretation of the word is significant. Everyone I know uses the verb "google" to indicate "search the web using Google", which is NOT a dilution of their trademark. If a dictionary/lexicon upholds that definition (rather than the generic "web searching") there is unlikely to be legal issue here.
For about one (or maybe two) days, before the bank or cardholder noticed and cancelled the card.
To start with you're right: the attack described by the Cambridge paper requires access to a PIN verification device;... but the attack the parent comment described was recently and successfully used in Australia.
An ATM maintenance company is suspected of sniffing magstripes and PINs and according to reports I've heard managed to remain in operation for several months (possibly longer) before being caught, by moving the equipment between ATMs on a very regular basis. The best news reference I could find on this in a short time was here.
This comment is a little off base. To begin with, banking networks do not use "on the spot verification". There are a limited number of hardware cryptography modules in a banking system that have the capability and correct keys to perform PIN verification.
When you enter a PIN at an ATM, it is encrypted using a key that is specific to that ATM. The PIN is transmitted through various networks to reach the back-end verification system; at each change point between networks the PIN is reencrypted under a different key.
The use of an account number in PIN creation binds the PIN to the account number, so that you cannot take an encrypted PIN for one account (say, yours) and use it to access another account by fiddling with the magstripe.
In fact it is your account number that is encrypted to produce the PIN (as the first four digits); while the verification process sees the PIN encrypted under a DIFFERENT key and transmitted to the verification system where it can be checked. The ATM does not verify your PIN!
The paper describes an approach that, if you have API-level access to a verification hardware module AND an encrypted PIN corresponding to a known account number, will establish the PIN in on average 15 guesses.
To reword the last paragraph: if you are a bank employee with access to the most trusted parts of their network, and can sniff that network as well as submit requests, you may be able to perform this attack. Even then, many banks use serial-attached hardware modules, which means you will have to hack the bank's "mainframe" to stage this attack.
In other words, you cannot perform this attack with access to old ATM hardware or most hardware on the financial network. And banks have very strict procedures for disposing of old security hardware. And very strict procedures for gaining access to their most secure systems.
ATMs would not have to be replaced. The decimalisation table is not used by the ATMs... only the verification system. Locking these tables down in the hardware would prevent this attack (specifically), but there are others than can still be used.
Aside: some people don't believe that ATMs don't verify PINs. They do; it seems really quick because they often allow you to get on with your business while the verification is performed in the background. Simple proof that this is the case: (1) an offline ATM won't allow you to perform a transaction; (2) in order to verify a PIN you need the same DES key that was used to generate the PIN... so either all banks and PINs in the world use the same key, or an ATM that was deployed before some new bank started operating wouldn't be able to accept cards/PINs from that bank (as it wouldn't have the bank's secret PIN key). Ummm... no.
Since there are a limited number of verification systems for each bank, a solution would be to have an out-of-band mechanism to permit only specific, approved decimalisation tables to be used in each system. This limits or prevents the attach by preventing unfetered modification of the table, but does not involve any changes to hardware "in the field" or to customer PINs. In effect, a change to the hardware used in the verification process to lock the decimalisation table(s) to predefined values on a per-installation basis would be sufficient (from the paper: "To regain full security, the decimalisation table input
must be cryptographically protected so that only authorised tables can be used." [my emphasis]).
Perfect security is perfectly unusable. The weakest point in the security of the global financial system is the end user.
A trivial PIN attack takes on average 5000 guesses, and can be conducted by inserting a stolen card into the same or different ATMs 2500 times. An even more simple attack obtains the PIN in one attempt with 80% certainty, and involves nothing more than a gun.
Newer systems will (in the future) employ Smart Cards for security. Unfortunately it is possible to retrieve secret data from most Smart Cards with $30,000 of equipment, and even duplicate them for a little more.
Biometrics are esaily fooled and, as most security conscious people should know, serve as identification rather than authentication mechanisms. As usual, a Smith & Weston beats a Smart Card, retinal scan, DNA fingerprint and 357 digit PIN. Bummer.
Which of course, if you think about it, means that it is in the consumers interest that the banking system has weaknesses. Case in point: car alarms and immobilisers have increased the incidence of hijacking; later anti-hijack devices increased the incidence of kidnapping and murder in association with hijacks. Leaving your keys in the ignition involves significantly less trauma and threat to life.
At some point, security becomes so inconvenient that no-one wants to use the system anymore. i.e. a self-destruct.
Why does (anyone) have a system that is vulnerable if people know it's workings?
Because the system has been in place for years, since before many aspects of security were well researched, and is in the process of being replaced; a process which is taking 8 to 12 years, as a result of the huge global dependancy on existing financial networks.
Why isn't all security nicely compartmented into specific keys that don't have to be revealed?
It is. Read the paper. This is an attack that exploits vulnerabilities in the use of the cryptography and keys.
Why is anyone cooperating with any attempt to force people to pay for a withdrawal done half a world away ?
Because the financial institution in question is accusing the person of committing fraud against the bank by exploiting weaknesses in the system.
Banks have known for some time that weaknesses exist. The problem is that changing financial standards involves global coordination and huge cost. Most banks are still using single DES to protect transactions because of this inertia.
The intent in keeping quiet about these vulnerabilities is not to cause mass histeria and to limit the abuse of the vulnerabilities. As seen in many recent security reports (e.g. "hacking" a master key for locks) secrecy/obscurity does not guarantee security, but it does limit damage, at least in the short term.
Banks are actively working on improving security, a process which will see EMV being supported from next year (in most nations), and which will drag through until 2012 before magstripe cards are completely replaced. In the mean time, one can hardly expect them to publish exploits for all weaknesses that they cannot fix without breaking the global financial network!
Languages and locales are two subtly different things. There is also liver pudding, where is something else again.
For those interested enough to care, language is a medium of communication. Locale indicates language as well as many other socioeconomic and geographic differences, including curreny, date/time representation and timezone.
Then again, you clearly know what you're talking about already, so this is mostly for the benefit of everyone else;) Thanks for the clarification.
By the way, do you know what they call a quarter pounder with cheese in Paris...?
Shared code should be carefully mangaged and should not be altered without prior coordination with all its users
This is true, and usually means use of procedures external to source control. Of course there are some revision control and/or configuration management products that have workflow support, to gain prior approval for a change, or to perform a "trial" checkin so that the change can be approved before actually becoming part of the development branch.
Quite often though you will find that shared code is in development by multiple teams simultaneously, and there is no other option. In my experience this is far more common than sharing of fully developed code.
The reason is that it is usually prudent and beneficial to reuse fully developed code as a library, whereas closely linked products (such as firmware and associated software) need to share definitions and often have the same or mirror-effect routines.
In an iterative/incremental process, there is no chance for one group to fully develop a particular shared file. Obviously the groups need to work closely and communicate regularly, but the problems of sharing can be managed if they are identified up front and procedures put in place.
but for closed source development you should rarely need to edit the same file unless your team is poorly organized or system poorly designed
...or if you happen to have a high level of code reuse; or if you have doing firmware, software and driver development in parallel; or if you have a small but busy team; or if you have a large but busy team; or... or... or.
This is a ridiculous statement. There are any number of reasons that multiple developers will work on a single file at once, especially in a well structure organisation or development. Development, code inspection, fixes in response to testing and maintenance fixes (bringing a patch from a release into current) can ALL happen simultaneously in a development tree, and can ALL happen simultaneously in one file. They just shouldn't often happen simultaneously in one method/function.
Where's my moderator points when I need them sigh. One of the reasons good information is becoming hard to find on the 'Net is that everyone wants to invent their own name for something, often because they haven't bothered to research the topic first.
Internationalization, i18n, and occasionally localization are the accepted terms. Globalization is used in economics, not CS. Mod this guy up!
As everyone is well aware, a gravaton pulse has a 78.2% probability of overloading the power conduits leading to microfractures in the dilithium chamber and a chain reaction that causes a rift in the space-time continuum.
Basically, Seven of Nine appeared briefly, bad mouthed someone about something they may do one day in an alternate future, recalibrated the sensors not to detect her, and never appeared in the first place.
Scientists analysing the situation need only to look for a slight seemingly-random deviation in the operational parameters and one operator who feels insulted for no particular reason, in order to prove this theory.
Slashdot Mirror
This is a rating system for games, to which many publishers subscribe voluntarily, and it is referred to by the IDSA lawyer. Few people have a problem with labelling of in this manner.
So I, like many people, support labelling, responsible parenting, and having the State keep its nose out of the issue of morality. These are not mutually exclusive viewpoints.
I would support a system (voluntary or otherwise) that sees all entertainment material (movies, books, music, games) accompanied by a rating (that is reviewed for every item by some independant body), and places an onus on vendors to not sell such material to a minor under the recommended age. However, a parent or guardian should have the right to purchase any good or service on behalf of that minor, irrespective of the recommendations given on the label.
Havok! cry the mommies. Daddy will be taking junior to the next SLVN movie that comes out. And that is the way it should be. If the parent is being responsible they will not take such an action until they are happy that the child / young adult is mature enough; if the parent is not responsible there are many other applicable laws that can be invoked (in this case, child abuse).
But an outright ban on access to certain material by minors, as is effective in many countries, especially a preemptive one, is damaging to society.
To begin with, you are imposing artificial limitations on human activity and development. Children are naturally curious; an aspect that adults seem to forget. Banning access to material creates or inflames a curiousity about that material. While the material itself could be harmful, the behaviour that may result (including deceit, theft, etc) in an effort to satisfy that curiousity is often more harmful. Worse still many parents sympathise with this activity and do not sufficiently punish it, leaving the message that its okay to break the rules.
Then we have the question that we started with: is this material actually harmful? There is evidence to suggest that graphic pornography and violence is bad for young children, but most of that evidence suggests that the response is trauma, not mimicry. Psychology is a field notorious for claims that appear to be supported by evidence, but are merely one way of reading the statistics (and yes, I have a major in Psychology).
In times gone by children had far more direct access to REAL violence and pornography. Parents weren't so careful not to be "caught in the act". We have lives through many wars and revolutions, much bloodshed, in the past centuaries. And now we believe our children can't handle it?
Maybe we should also be asking ourselves: how much do we damage children by "protecting" them against this material? Growing up is a process of learning, not only knowledge, but coping skills and emotional control. If you have never been subjected to a crisis before you were an adult (legally), how can you be expected to behave responsibly when you are an adult? Experience is a vital component of development, and something we are increasingly removing from our childrens' lives in the quest to "protect" them.
Great point about client certs! Users and admins seem to forget that the client computer itself may not be secure, in which case you can't trust SSL.
There are also many other features you lose without a full client application; especially the ability to have your entire mail folder on your own computer (so that you only have to retrieve new mails).
Its the "you need an external lib to access it from Tcl itself" that I'm referring to. I have seen many comments on how great the threading in the core is, and even when using to/from C/C++ ; but as an application developer its pretty useless to me if I can start a thread from within my (Tcl) program.
incrTcl is on of several object systems for Tcl. The primary problem with an object system being an add-in is that Tk cannot then rely on having an object system available, which means you can't create generic encapsulations of Tk widgets as objects, short of using an entirely new widget set (such as incr Tk).
incr Tk has its own problems: it is very large, and provides its own look and feel that is very weird on most platforms.
Now that we have Tclkit, I would also support having sockets and regexp as modules; but an object system shouldn't be an add-on to a language anymore than security should be an add-on to an application.
I have a love-hate relationship with TCL. In the past I have been part of a large development effort where the basis was TCL (read: the rapid prototype looked good, worked, and the chaps upstairs didn't see a need to rewrite in a different language) and was amazed by its power, extensibility and simplicity.
On the other hand I have found it the second most difficult language I've had to learn, its constructs for complex operations (such as callbacks) can be very confusing, and it lacks several important features than mean a lot of workarounds.
To get into specfics:
Well, that's my 2c.
There are two parts to DLL Hell. The first is well known: a DLL is replaced with a different version, causing software to break. The second is more subtle: a program is uninstalled causing a DLL to be removed or rolled back, and software breaks.
The more structured a system in terms of storing shared libraries centrally, the worse problem #2 becomes, and the better the tracking required (i.e. registry entries to indicate software using that DLL) to prevent the problem.
This is why a lot of modern software opts to have DLLs in its own directory structure, rather than to use the shared DLLs. Bypassing lots of hell.
Of course, there are a number of interesting ways to combat this problem. One of the best is to use hard links (which are supported on NTFS) to link a DLL from a shared location into an application's directory structure. This only works successfully if there is a mechanism for versioning DLLs where the versions are stored in different files (a la Unix). It prevents removal (and with the correct permissions overwriting) of a DLL that is required by installed software.
Of course, if you write "smarter" installer programs that follow the behaviour expected from the MS OS (write shared DLLs to the registry, identify programs that share them, store in \SYSTEM32), you end up with more upset users because (1) DllHell means you break programs that rely on the bugs in older versions of the shared library; (2) DllHell means your program breaks because you rely on the bugs in a version of the shared library but the system already has a newer version; (3) You have to reboot after installing because a system library needs to be replaced (and was most likely in use during the install, say by Explorer).
The problem here is smart developers, who will insist on a DLL-version-specific workaround to do whatever it is they have their minds set on doing. Simple rule: if you think a library function isn't behaving correctly, don't use it like that, or your code won't work when they fix it! An often better solution is to distribute the shared libraries your program uses with it, but not install them as shared libraries, neatly bypassing the DLL problem, but irritating people like you, who find this a hack solution.
Strange as it may seem, this is not a troll.
I usually appreciate Joel's views, but this article is way off base. He would do well to study group psychology and collaboration before making comments like this.
In one breath he wails about the lack of "community", and in the next distinguished between "newbies" and "old timers" on a usenet group. These categories emerge strictly as a result of the community building process, whereby it is difficult for a newcomer to enter a (social) group on an equal footing to existing members.
The idea that quoting is a "disease" is misguided at best. Because a single e-mail or post represents several parts of a conversation, indicating the context to which you are referring is essential. This is even more true in the case of online systems that will be used in the future as archive and/or reference material, where it will be difficult and time-consuming to follow the entire conversation from the beginning to the point of interest. While quoting of entire posts is indeed a curse, selective quoting to indicate context is necessary for meaningful communication.
When it comes to e-mail notification, Joel is even more far gone. All literature on the relatively new field of active collaboration indicates that people have less time to do more things, and the best way to achieve collaboration is to tell them what they need when they need it. I used to spend plenty of time and bandwidth browsing to Slashdot to find out if someone had replied to my comments; now I know when this happens, and can follow up in a reasonable period of time. Conversations that may have taken days and stagnated can now be more meaningful.
Branching? Let's thing about this for a moment -- there is a lecture theatre with (say) 100 people in the audience; after a short speech (the "initial post") there is a break for discussion. Does each person insist on an opportunity to stand at the podium and give their 5c, or do they go and huddle with other people and discuss their views and interpretation. And which system is better suited to communicating and increasing group knowledge, assuming all conversations are recorded and archived?
While Joel's commented on Slashdot may be warranted, it (Slashdot) is nevertheless the closest thing on the public Internet to Active Collaborative Filtering (ACF). The idea of ACF is that there is too much content for you to process (filter) on your own. Instead you can leverage the processing (filtering) of others (experts in the field and/or people you trust to be like-minded). Slashdot's moderation system is a simple implementation of ACF, assuming you trust all geekdom to be like-minded. The ability to assign additional moderation to particular users progresses the system more towards true ACF. In any event it is a more reliable system than moderation by a number of pre-selected moderators.
While not a scientific method for discrimination, I think the pool o' geeks method works quite well.
Dude: "Amazon has come up with this idea of making a purchase with just one click."
Geeks: That's silly. Its impossible unless you pre-store information, so its not really one click.
Dude: "Google has come up with this idea of ranking pages according to the number of other pages that link to them, rather than the occurance of keywords in the page"
Geeks: Hey, that's pretty neat! Good way to filter out the lousy stuff.
And yes, this is the response I get from most people that I tell about Amazon and Google (techie and otherwise).
Maybe Google's technique was around in some form or another before, but Google applied it and made it work and as a result we've seen progress in the field (Google isn't the world's favourite search engine for nothing). Amazon didn't do anything more complex than create a shortcut that starts with "buy" command in non-interactive mode.
To add a spanner to my own comment: if you want to attack Google's position on trademarks, ask yourself if they can trademark "google" at all. This is, after all, an English word, and in Lindows v Microsoft we saw the judge question the validity of the Windows trademark on the same basis.
Aside: Since in this context "google" is not being used in the same sense as the word, or even a related sense, the trademark would most probably hold.
I'm not interested in the why. While I would prefer to take the naive view you are taking, the courts have found that trademarks are diluted by generic use, and that unless active steps are taken to protect a trademark it can be diluted and eventually lost. The accepted legal term is genericide.
I must apologise that Xerox(R) is not a case in point - it managed to keep its trademark, as did Kleenex(R). Aspirin and thermos weren't so lucky. This is discussed in an article and reinforced by TSANet(R)'s trademark policy
(since they have been in past danger of trademark dilutionI don't like the way the world works ... especially in this regard. But this is how things go. If Google did not take steps to protect its trademark (especially in a lexicon or dictionary) it may see the trademark diluted, and in future we could see an "MSN google service".
When someone can say they are going to "xerox" a document, and walk off to the Minolta copier, you know your trademark is diluted.
You may find that CVS (and friends) is not a source versioning system. It is a document versioning system. Revision control is a well-studied topic, and can be provided for by a number of products. Revision contorl in a hierarchy and/or file system is similarly nothing new: older Unix systems had versioned file systems, and there are dozens of commercial document management and revision control products on the market.
Content management is distinct from revision control. It is possible (although stupid) to have content management without revision control.
Most people find that tags/labels work just fine. There are many docs and books on how to do exactly that with CVS.
The idea of adding workflow to SCM is not new; in fact its a best practice in many organisations (just not necessarily integrated into a product, unless you're using Rational's suite).
The patent was filed on 3 Feb 1999. Depending on how you read the legalese of the claims, use of CVS (for web development) may or may not be covered by this patent.
Prior art with regard to CVS is easy to prove. Back in 1997 cyclic.com already had a CVS and the Web page. That page references amongst others L.D.Stein's book How to set up and maintain a web site, that makes mention of the use of CVS for version control.
By 1998 the same page on cyclic included a link to Sean Dreilinger's CVS Version Control for Web Site Projects (link to current version). archive.org does not appear to have the original document, but the link is on cyclic.com circa Dec 1998, and Sean's Copyright is dated back to 1997.
Cyclic.com also had a page listing sites using CVS (for web development, 1998).
And just in case anyone didn't get the message, WebDAV (RFC) has a history (and more) going back to 1996. The RFC was published in (surprise surprise) Feb 1999.
Hoover and Xerox. Both brands became so pervasive that they became verbs and subsequently lost control over their trademark. The courts found that they hadn't taken adequate steps to protect their respective trademarks. Implicitly this means that a trademark holder has a right (and in fact a responsibility) to protect their trademark from falling into common use in this manner.
In this specific case, however, I would contend that the interpretation of the word is significant. Everyone I know uses the verb "google" to indicate "search the web using Google", which is NOT a dilution of their trademark. If a dictionary/lexicon upholds that definition (rather than the generic "web searching") there is unlikely to be legal issue here.
To start with you're right: the attack described by the Cambridge paper requires access to a PIN verification device; ... but the attack the parent comment described was recently and successfully used in Australia.
An ATM maintenance company is suspected of sniffing magstripes and PINs and according to reports I've heard managed to remain in operation for several months (possibly longer) before being caught, by moving the equipment between ATMs on a very regular basis. The best news reference I could find on this in a short time was here.
This comment is a little off base. To begin with, banking networks do not use "on the spot verification". There are a limited number of hardware cryptography modules in a banking system that have the capability and correct keys to perform PIN verification.
When you enter a PIN at an ATM, it is encrypted using a key that is specific to that ATM. The PIN is transmitted through various networks to reach the back-end verification system; at each change point between networks the PIN is reencrypted under a different key.
The use of an account number in PIN creation binds the PIN to the account number, so that you cannot take an encrypted PIN for one account (say, yours) and use it to access another account by fiddling with the magstripe.
In fact it is your account number that is encrypted to produce the PIN (as the first four digits); while the verification process sees the PIN encrypted under a DIFFERENT key and transmitted to the verification system where it can be checked. The ATM does not verify your PIN!
The paper describes an approach that, if you have API-level access to a verification hardware module AND an encrypted PIN corresponding to a known account number, will establish the PIN in on average 15 guesses.
To reword the last paragraph: if you are a bank employee with access to the most trusted parts of their network, and can sniff that network as well as submit requests, you may be able to perform this attack. Even then, many banks use serial-attached hardware modules, which means you will have to hack the bank's "mainframe" to stage this attack.
In other words, you cannot perform this attack with access to old ATM hardware or most hardware on the financial network. And banks have very strict procedures for disposing of old security hardware. And very strict procedures for gaining access to their most secure systems.
ATMs would not have to be replaced. The decimalisation table is not used by the ATMs ... only the verification system. Locking these tables down in the hardware would prevent this attack (specifically), but there are others than can still be used.
Aside: some people don't believe that ATMs don't verify PINs. They do; it seems really quick because they often allow you to get on with your business while the verification is performed in the background. Simple proof that this is the case: (1) an offline ATM won't allow you to perform a transaction; (2) in order to verify a PIN you need the same DES key that was used to generate the PIN ... so either all banks and PINs in the world use the same key, or an ATM that was deployed before some new bank started operating wouldn't be able to accept cards/PINs from that bank (as it wouldn't have the bank's secret PIN key). Ummm ... no.
Since there are a limited number of verification systems for each bank, a solution would be to have an out-of-band mechanism to permit only specific, approved decimalisation tables to be used in each system. This limits or prevents the attach by preventing unfetered modification of the table, but does not involve any changes to hardware "in the field" or to customer PINs. In effect, a change to the hardware used in the verification process to lock the decimalisation table(s) to predefined values on a per-installation basis would be sufficient (from the paper: "To regain full security, the decimalisation table input must be cryptographically protected so that only authorised tables can be used." [my emphasis]).
Perfect security is perfectly unusable. The weakest point in the security of the global financial system is the end user.
A trivial PIN attack takes on average 5000 guesses, and can be conducted by inserting a stolen card into the same or different ATMs 2500 times. An even more simple attack obtains the PIN in one attempt with 80% certainty, and involves nothing more than a gun.
Newer systems will (in the future) employ Smart Cards for security. Unfortunately it is possible to retrieve secret data from most Smart Cards with $30,000 of equipment, and even duplicate them for a little more.
Biometrics are esaily fooled and, as most security conscious people should know, serve as identification rather than authentication mechanisms. As usual, a Smith & Weston beats a Smart Card, retinal scan, DNA fingerprint and 357 digit PIN. Bummer.
Which of course, if you think about it, means that it is in the consumers interest that the banking system has weaknesses. Case in point: car alarms and immobilisers have increased the incidence of hijacking; later anti-hijack devices increased the incidence of kidnapping and murder in association with hijacks. Leaving your keys in the ignition involves significantly less trauma and threat to life.
At some point, security becomes so inconvenient that no-one wants to use the system anymore. i.e. a self-destruct.
Because the system has been in place for years, since before many aspects of security were well researched, and is in the process of being replaced; a process which is taking 8 to 12 years, as a result of the huge global dependancy on existing financial networks.
It is. Read the paper. This is an attack that exploits vulnerabilities in the use of the cryptography and keys.
Because the financial institution in question is accusing the person of committing fraud against the bank by exploiting weaknesses in the system.
Banks have known for some time that weaknesses exist. The problem is that changing financial standards involves global coordination and huge cost. Most banks are still using single DES to protect transactions because of this inertia.
The intent in keeping quiet about these vulnerabilities is not to cause mass histeria and to limit the abuse of the vulnerabilities. As seen in many recent security reports (e.g. "hacking" a master key for locks) secrecy/obscurity does not guarantee security, but it does limit damage, at least in the short term.
Banks are actively working on improving security, a process which will see EMV being supported from next year (in most nations), and which will drag through until 2012 before magstripe cards are completely replaced. In the mean time, one can hardly expect them to publish exploits for all weaknesses that they cannot fix without breaking the global financial network!
Languages and locales are two subtly different things. There is also liver pudding, where is something else again.
For those interested enough to care, language is a medium of communication. Locale indicates language as well as many other socioeconomic and geographic differences, including curreny, date/time representation and timezone.
Then again, you clearly know what you're talking about already, so this is mostly for the benefit of everyone else ;) Thanks for the clarification.
By the way, do you know what they call a quarter pounder with cheese in Paris...?
This is true, and usually means use of procedures external to source control. Of course there are some revision control and/or configuration management products that have workflow support, to gain prior approval for a change, or to perform a "trial" checkin so that the change can be approved before actually becoming part of the development branch.
Quite often though you will find that shared code is in development by multiple teams simultaneously, and there is no other option. In my experience this is far more common than sharing of fully developed code.
The reason is that it is usually prudent and beneficial to reuse fully developed code as a library, whereas closely linked products (such as firmware and associated software) need to share definitions and often have the same or mirror-effect routines.
In an iterative/incremental process, there is no chance for one group to fully develop a particular shared file. Obviously the groups need to work closely and communicate regularly, but the problems of sharing can be managed if they are identified up front and procedures put in place.
...or if you happen to have a high level of code reuse; or if you have doing firmware, software and driver development in parallel; or if you have a small but busy team; or if you have a large but busy team; or ... or ... or.
This is a ridiculous statement. There are any number of reasons that multiple developers will work on a single file at once, especially in a well structure organisation or development. Development, code inspection, fixes in response to testing and maintenance fixes (bringing a patch from a release into current) can ALL happen simultaneously in a development tree, and can ALL happen simultaneously in one file. They just shouldn't often happen simultaneously in one method/function.
Where's my moderator points when I need them sigh. One of the reasons good information is becoming hard to find on the 'Net is that everyone wants to invent their own name for something, often because they haven't bothered to research the topic first.
Internationalization, i18n, and occasionally localization are the accepted terms. Globalization is used in economics, not CS. Mod this guy up!
As everyone is well aware, a gravaton pulse has a 78.2% probability of overloading the power conduits leading to microfractures in the dilithium chamber and a chain reaction that causes a rift in the space-time continuum.
Basically, Seven of Nine appeared briefly, bad mouthed someone about something they may do one day in an alternate future, recalibrated the sensors not to detect her, and never appeared in the first place.
Scientists analysing the situation need only to look for a slight seemingly-random deviation in the operational parameters and one operator who feels insulted for no particular reason, in order to prove this theory.