No rights are absolute: all rights are restricted but the amount to which they infringe on other rights. My right to free speech is restricted by your right to your good name, hence the crime of defamation. A child's rights to freedom of association and freedom of religion are restricted by the parent's right to bring up their child as they see fit, which includes the protection of religious indoctrination.
All rights have reciprocal duties or responsibilities: the flip side of the right of parents to bring up their children as they see fit, is a responsibility of care. Which makes it clear why children's rights may be limited by their guardians: you cannot exercise your duty of care if you cannot prohibit your children from interacting with certain people, or engaging in certain behaviour.
when a government is stupid they affect millions of people.
When government is clever, it can protect millions of people against their own stupidity. That includes people who don't have the rights to protect themselves... like children.
In most nations with censorship boards, the board provides a rating/classification only. They cannot prohibit adult access to the material.
People are stupid. By extension, parents are stupid. There are very few parents out there that are sufficiently knowledgable or qualified to know what is appropriate for children at various ages, and what exposure to the wrong thing may do to that kid down the line. Content classification for games/books/movies provides parents with a guideline on what is typically (in)appropriate at a given age.
Classifications should have limited legal force for non-adults. In particular, only the legitimate parents/guardians of a child should be able to permit a "violation" of the classification (and the parents right to do this should be sacrosanct). But other adults (friend's parents, older siblings, relatives, teachers, care givers) should not be allowed to provide children with access to age inappropriate material without the parent's explicit permission.
Since you clearly don't understand the business concept of a mission, you can't understand how certain resources (like IT infrastructure) can be mission critical.
The Therac-25 controller was not mission critical. It was safety critical. The nature of the risk is completely different.
In a typical modern organisation, suffering a full days' downtime of business systems translates into a loss of about 0.3% of annual turnover, unless your company is not operating at capacity. For a company that has a net profit on turnover of 10% (which is pretty decent), that translates to a 3% reduction in net profit. Draw your own conclusions.
RTFW, or A Brief Introduction to Copyright for Fan Fiction Authors. By using identifiable creations (characters, places, plots) of another author you may be creating a derived work, which is an infringement. Just because you expressed an idea yourself doesn't mean you aren't infringing copyright. Why is this such a diccifult concept to understand?
Which brings up a very important point: we need some comprehensive and reliable market research that shows the demographics of game players. A lot of the push for game censorship seems to be in the name of the precious children... and we need to be able to show that the "games are for children" adage is wrong.
Kudos to the well-informed parent. Tcl/Tk is indeed an excellent solution. More below.
But first... Visual Basic is NOT the answer. The criteria were "fairly small" and "easy to install". For most Windows versions you'll have to distribute your VB application in an install package that includes the VB runtime DLLs or the.NET runtime (or get the end user to download them, which is a mission). If you're unlucky you'll have to distribute other MS DLLs like ComCtls as well. Find out more at http://msdn.microsoft.com/vbrun/ . Then there's accessing the serial port...
For a simpler solution, grab TclKit, a single-file Tcl/Tk distribution. Tcl is ridiculously easy to learn, serial port access is as easy as file access, and it uses Tk to provide a powerful GUI.
You can put your scripts into the TclKit EXE as a resource, creating a single-file EXE distribution of your application. With UPX compression the resulting file will be around 1.2Mb (depending on what extensions you choose to use).
Assuming that you're being serious, the first step is for her to recognise her addiction and voluntarily choose to address it. Encourage her to consider what the addiction is doing to her and people around her; but she must decide that something should be done.
Then seek professional help. Psychologists are trained to deal with addiction issues; not only treating the addiction, but also helping the person to integrate back into their family and social environment. A psychologist will also be able to help you understand what you should be doing to support her (in fact, you may even consider visiting one for advise on how to encourage her to seek help).
Process standards are essential. Make sure you have them and that you have developer buy-in. Avoid contentious issues that have little factual support.
Off-topic: the first process standard you should introduce (if you don't have it) is source control; it has one of the highest cost/benefit ratios of good development practices. The second is configuration management (that is, proper control and version management of releases -- binaries and source code). The third is design and source code documentation.
Typographic formatting (where to put brackets, etc) is of questionable benefit, and it's not worth pissing developers off unless they all agree on it. There are several research papers that show a small benefit in having a consistent style, but the majority of this benefit comes from a consistent style within one file, and to a lesser extent within one code base. Typographic differences across code bases have little or no implication for development and maintenance. On the other hand, most developers read all styles with similar effeciency, and write their preferred style with somewhat greater effeciency (that other styles).
Typographic style also becomes a problem when you have legacy code that doesn't conform. What do you do when you maintain it? Update the style for the whole file; for the function being modified; just for the code you are modifying? Hint: changing the entire file or function makes it dramatically more difficult to use source control to identify (meaningful) changes. I have worked with several teams in which we have applied the rule "use the existing style for the file", with great success.
Commenting is both a technical issue and a management issue:
Technically, it is essential to comment code. Every reusable section of code (files, classes, namespaces, functions) should have a comment that explains what it is and how to use it. Without this, maintainers must make assumptions about what functions do, and how they are used; to confirm the assumptions they must read and understand the implementation. This is extremely inefficient.
Aside: some people think that the use of a function can be implied from its prototype; this is often incorrect. It is seldom possible to assume parameter boundaries, object state (in the case of methods) or error responses given only a prototype.
Every paragraph (block) of code that is not immediately obvious is a candicate for a brief comment indicating what the code is intended to do conceptually. These comments assist maintainers in navigating the code, and (in the case of bugs) understanding what it's meant to do instead of what is is doing (presumable erroneously).
A documentation standard should prescribe what must be documented, the "syntax" of the documentation (e.g. you could use Doxygen), and what the documentation is intended to achieve (e.g. for functions, a developer should be able to understand and use the function without having to refer to its implementation).
From a management perspective, risk related to poor coding can be mitigated by means of reviews and shared ownership; but risk also comes from the fact that intellectual property resides in people's heads not in source code. Unless you are intending doing a thorough walk-through of every legacy codebase with every new developer who joins the company, you need to have as much information as possible in the code, to allow knowledge to be transferred to new developers and maintainers. That means explaining the design and the implementation within the code.
As for comments not being kept up to date, that is something which is trivially addressed by source control and oversight. Every check-in can be reviewed by a peer to ensure the correctness of the code, and that any relevant comments have been made or updated.
Remember that source code is communication with other developers, not just instructions to a machine, and that makes writing style important. Sometimes it helps to think of source code like a book (the Book Paradigm).
Please take the PHP runtime and regression test suite, and write a non-trivial application. You may NOT refer to any PHP function documentation; not even a list of functions. To make this more realistic, do it with a language you don't even know.
will that make religion then opposed to the realm of ethics as well?
Religion is already in opposition with secular ethics and morality. In general secular morality is more permissive than religious morality (for example in the area of relationships and in particular premarital sex), which causes such a conflict. Most religions require (or at least practice) that their laws are imposed on the population, rather than allowing members of the population to voluntarily accept them. Imposing dogma is unethical by secular standards, where ethics and morality are logically reasoned.
Sometimes the opposition is more blatent: many forms of evangalism require an active effort to change the attitudes of others, something with is an onus on all Christians (according to doctrine), yet which is generally unethical according to secular reasoning.
Obviously there are large areas where religious and secular morality agree; but that doesn't prevent them from being in opposition.
Not to mention the arrow keys in close proximity in the middle of the keyboard. So you have to hold either hand with your wrist at an awkward angle over them. Try holding you hand over the IJKM keys for a bit...
I did not mean for negation to mean "opposite"... You seem to think I mean opposites in the sense that one would claim "if something is not being destroyed then it is being created"
I think this because of your statement:
... if you don't believe something is so, you're assuming (though not as a matter of faith; just a tentative assumption) that it's not so...
If I don't believe that something exists, I am not asserting or assuming the negation (or opposite) that it does not exist. The only thing I am assuming is that I should proceed as if it may not exist. The important word here is "believe".
As an example, imagine you are blindfolded, spun around a few times, and told that it's okay to walk forward ten paces. You do not believe that a wall exists in your path (because you trust the person who told you to walk), but that doesn't necessarily stop you from being cautious and feeling out for a wall. You don't believe it's there, but neither do you assume that it's not.
Since an agnostic position is not to believe anything until there's good reason, an agnostic must necessarily assume that any claim about something's existence is false until they have reason to believe it true
That is not the agonistic position. Agostics hold that proof or emperical evidence of god is impossible; thus any belief in or against the existance of god is strictly a matter of faith, and cannot be justified by empericism. No true agnostic is waiting around for proof of god -- they believe wholeheartedly that such proof it impossible. They may believe in the existance or god or be skeptical about it; but in either case they do so knowing that there is no proof of that belief.
...you say that agnostics believe it is scientifically impossible to know whether or not God exists. While this may be the strict use of it in comparative religion, I have seen it used more broadly in a general epistemological sense to mean the reservation of judgement about negative claims (as in "x is not so") until reason directly dictates belief in such claims
Yes, people use a lot of words more broadly than their meaning implies. But this is a religious discussion in which terminology is important (as evidenced by the attempts to define "athiest" and "agnostic"). Furthermore, I have most often heard the words "athiest" and "agnostic" abused in Christian circles, where they mean "undecided heathens waiting to be converted" (another way of saying "reserving judgement until they have reason"...).
You also say it is possible to not make any assumptions, but the claim I am making here is that everyone is always making an implicit assumption about every possible claim
You must be confusing me with someone else... in fact, I didn't use any form of the word "assume" in my last post. Nonetheless, I happen to agree that every claim is an assumption.
You can assume all positive claims to be false (thus all negative claims true) and get nothing contrary... it is logically safe to assume "no claim is true" (the position of skepticism) until proven otherwise
Agreed.
To be truly agnostic you must also be skeptical. You do not *know* that x is not-so (e.g. God does not exist) but you've got to assume that until you have reason to think otherwise.
Incorrect. To be agnostic does not deny the option of faith. On the contrary, it says that if you choose to hold a belief on the existance or non-existance of god, you do so knowing that your belief is on faith alone, and no evidence or proof can exist to support that belief.
You have to be careful with "positive" and "negative" statements. Just because something contains a "not" doesn't make it negative. "God exists" and "God does not exist" are
Damnit people. Stop trying to define things in terms of opposites.
An athiest believes there is no god. That is a much strong statement that simply not believing in a god, or not believing that there are one or more gods. It is an unprovable statement of belief (also known as "faith") in the non-existance of any form of divinity.
An agnostic believes that scientific knowledge or proof of the existance or non-existance of god (or gods) is impossible. Note that this does not preclude an agnostic from being a theist or an athiest -- it just means that the agnostic is aware that there can be no scientific evidence to back his/her beliefs. Agnosticism itself is a belief -- currently there are no proofs that scientific knowledge of god is impossible, largely because there is no definition for "god".
Agnostics are not uncertain. They have a view and they hold it firmly. But that view does not concern whether or not they believe in gods, it concerns whether scientific knowledge of gods is possible. An agnostic could be uncertain about his/her beliefs in the supernatural, but that's not inherent to agnosticism.
Religion is a belief system concerning the supernatural. A religion is, by definition, organized (a belief system); and by extension contains various doctrines (such as rituals and moral codes). Without doctrine religion would not be organised, and unorganised belief in the supernatural is termed "spirituality", not "religion".
Because of the need for organization and doctrine, and because they do not concern belief in the supernatural so much as belief against the supernatural, neither athiesm nor agnosticism are considered to be religions. This is both by definition and by convention in comparative religious studies.
The default position is neither athiest nor agnostic. It is "non-believer". A non-believer is someone who does not have a determined viewpoint on the supernatural. (Wikipedia uses the term "weak athiest").
This is different to "secularism", which holds that religion and supernatural beliefs are not paramount in understanding life and the natural world. Secularism is another ideological standpoint with specific views, and does not necessarily describe someone who simply does not have a determined viewpoint on the supernatural.
It is also different to "irreligious", which is the absence of religious belief. An irrelgious person could be spiritual (belief in the supernatural) or a non-believer, or an athiest.
You have grossly misstated the principle of bivalence. From Wikipedia: "In logic, the principle of bivalence states that for any proposition P, either P is true or P is false." You said "if any claim is false, its negation is true" (and in your examples you demonstrate that you intend "negation" to mean "opposite") which is only true when P is boolean.
If P is "I believe jam tastes good", then bivalence says that either P is true (jam tastes good) or P is false (jam does not taste good). The latter does not mean that jam tastes bad (which is the opposite of P), merely that it does not taste good. There are a whole range of tastes in between "bad" and "good". It could taste "just, y'know, okay, i suppose".
Back on agnosticism: agnostics simply believe that claims regarding the existance of god (or gods) are inherently unknowable. There is no statement of whether the gods do or do not exist, only that we can't be sure either way. Thus you get athiest agnostics, theist agnostics, and agnostics who are non-believers.
Sounds like the wrong person is driving this. Non-technical people seem to think that a firewall is the Grand Ultimate Answer to Security Problems. When you phrase your requirements in terms of a specific solution (i.e. We need to protect our IT infrastructure with a firewall) then you've got trouble.
Start by getting an IT security expert to review your infrastructure and identify potential threats, and discuss what protection can be used to mitigate various threats.
You will almost certainly find that "a firewall" is not going to provide the protection currently envisaged. You will also find that ongoing maintenance of your security solution is essential -- security without maintenance is useless.
If a firewall makes up part of that solution, it would be sensible to go for an appliance or a custom firewall distribution. Cisco PIX or M0n0wall are good choices. When you put a software package on a generic OS you have to spend more time maintaining the OS (patches, etc) and admins have a tendency to put other software and services on the machine because its there (which, obviously, are bad for security).
Remember that the majority of threats to your infrastructure are internal, and a firewall won't protect you. "External" threats like viruses tend to penetrate firewalls easily via e-mail. Many organisations (large and small) adopt a DMZ configuration (two firewalls with a limited number of machines between them, that are the only machines that can accept connections from outside the outer firewall, e.g. mail and web servers) with an additional firewall protecting the application servers (by which I mean whatever servers your business needs to do its stuff) from the desktop PCs.
And so we live in a universe of new media with phenomenal opportunities for worldwide communications and research -- but populated by volunteer vandals with poison-pen intellects. Congress has enabled them and protects them.
Seigenthaler goes out of his way to deride Wikipedia and all its volunteers, and to cast congress in a poor light for upholding the First Amendment. His stated goal is to "[let] many people know that Wikipedia is a flawed and irresponsible research tool."
You don't get much more poison-pen that that.
One day they may stop asking "where were you when JDK was killed?" and ask "where were you when Seigenthaler tried to kill Wikipedia?"
Or possibly the rise of industrialization and the contraction of childhood? Children have always been expected to do chores, but in previous generations have had much more leisure time and far less expectations to be adults.
Children as young as 7 are having their day packed with 8 hours of school and homework. Leisure time makes way for structured leisure activities and sports. Chores stay much as they always have been. And the child is acutely aware that they must decide what to be when they grow up, and if the don't get good grades right now they'll never get to university and that's pretty much the end of existance as we know it.
Children just don't have time to be children anymore.
Oh, and the age of consent used to be a lot lower.
The required population size depends on what you're trying to test and how carefully you select your population. If you're trying to test the failure rate of moderately experienced Windows users performing tasks on a Linux system, and you can accurately identify and select moderately experienced Windows users with no prior Linux experience, then you only need a tiny population.
Testing the failure rate is important: 100% of 11 users succeeding at a task can give you at most ~ 90% confidence that all similar users will succeed. 1 of 11 users failing is a far stronger result, telling you that you can expect at least 9% of all users to fail.
Various usability experts suggest that as few as 5 or 10 individuals are required for usability testing, and the remaining usability issues are discovered and resolved via the bug reporting and maintenance processes.
So now, which language is more secure? I still say C, for no other reason than because it's easier to make the system protect itself from broken C programs than broken JVMs or Java applets.
Lots of FUD and hand-waving here as the author compares the JVM to a C application, and implies that (1) the C runtime is bug-free and/or any C application can avoid C runtime bugs; and (2) all programmers can make their C programs more bug-free than a JVM.
A better comparison would be the C compiler, runtime and automated protection extensions versus the JVM, as those are the components of C and Java respectively that define the boundaries of what code written in the language can accomplish. Note in particular that a buggy C compiler can generate exploitable code, whereas a Java compiler cannot (because the JVM restricts what the code can do).
It must also be said that ultimately the JVM is a C program, so the system can protect itself just as much from a JVM as from any other C program.
Re:This sort of thing...
on
RIAA Sues a Child
·
· Score: 3, Informative
Theft or stealing are the words used to describe the common law property tort of conversion, which involves infringing a person's right to a chattel (that is, personal property). The crime of theft involves unauthorised use and the intent to deprive.
In copyright infringement the copyright holder cannot be deprived. His positions before and after the instant of the infringing action are identical, as no damage (that is, real loss) has been suffered. In Dowling v United States the US Supreme Court found that "the rights of a copyright holder are 'different' from the rights of owners of other kinds of property". In other words, copyright infringement is not theft. This is one of the reasons that the phrase "intellectual property" is a misnomer.
Direct copyright infringement on the other hand is a strict liability tort. Liabilities that arise are the responsibility of the person who performed the act, irrespective of where the fault (culpability) lies. Strict liability does not necessarily make an action a crime.
So simply having an unlicensed copy of a work is sufficient to demonstrate the tort of strict liability, but possession of stolen property is insufficient to demonstrate theft.
The problem is determining what the liability is. In some countries the liability for copyright is determined by statute, and this is part of the problem behind the RIAA's actions.
First, there is a huge distinction between income and potential income. If person X copies a song, this is not evidence that person X would have bought the song in the absence of the option to copy it. Even if we assumed that it was, the actual damage to the copyright holder is limited to the net profit that would have been made off the purchase of one license (not the retail value of an album, as the RIAA would have you believe). Furthermore, noone other than the copyright holder has a claim -- retailers, wholesalers, manufacturers and publishers may not have benefitted from an album sale because of the infringement, but they are not entitled to a strict liability tort.
US law provides for statutory damages of "at least $750" per work. Compare that to the estimated $1 net profit the copyright holder will make per copy sold. It pays the RIAA enormously to claim the infringement of (say) 829 works with associated damages of either $30,000 or $150,000 (depending on how they make the claim)... compared to the $829 their members would make from legitimate sales of the same works.
Your crypto background doesn't matter. The banking industry has a massive investment in infrastructure that takes years to change, and cannot be changes any faster because of the huge cost involved.
By the beginning of 2006 most security in the retail banking industry will have moved off single DES and on to Triple DES. Those that haven't will foot the bill for fraud on their systems rather than passing it on to their banks or Visa/Mastercard.
The system is expected to be based on TDES until at least 2012. By then it will still not be advantageous to attack the system: the cost will exceed the gain. This is a factor not only of the current strength of Triple DES, but of monitoring systems that will detect fraud patterns in time to respond appropriately.
The algorithm is also of little concern because there are far weaker points to attack in a payment network -- ones that are inherent to the existing infrastructure and that are going to take some time to go away.
Because the entire payment network is based on TDES, there is no option but to use TDES at the moment. SHA1 is used in conjunction with RSA as part of the new EMV payment system, which I'm guessing Pay Pass uses (I haven't seen the specs).
Chances are also good that Pay Pass will only permit transactions up to a certain value unless a PIN is entered, providing a balance between security and convenience.
On the contrary, there is an extensive knowledge base in Software Engineering on how to make reliable estimates of software development time and cost. Most programmers simply don't have this knowledge, which is giving the entire profession a bad reputation.
The only "creative" part of SE that is difficult to estimate is design -- "solving the problem" if you will. Coding is methodical application of rules; it still requires the skills of the craft, but it is easily and reliably estimated in a mature environment.
As for design, there are several techniques (such as prototyping) to reduce uncertainty and arrive at an accurate answer sooner than the "brute force" method (i.e. doing the work and seeing how long it took).
Please note it says "can drag down", not "always drags down"
It also doesn't say "can drag up", which is more to the point.
The moment someone gets so defensive about Six Sigma, you know the person's career relies on it because they have no real skills.
I don't know whether to laugh or cry. Why is it that technically inclined people believe that "real skills" must be technical?
"Real skills" depend on the environment. In a commercial environment the only "real skills" that count are the ones that can lead to increased stakeholder wealth. That typically means more profits for the company (increased income and/or lower expenses) and better salary and working conditions for you. So you start by cutting secondary activities in the value chain (i.e. reduce unnecessary administration and overheads), and then further improvement must come from productivitiy gains in the primary activities.
Productivity gains don't have to come from the developers working faster. They can come from working smarter, from better allocation and utilisation of resources, from changing the product to be valuable to the customer, and from reducing wasted time.
Most of these changes can be effected by management and/or process experts with little or no technical knowledge... as long as they keep their fingers out of the development methodology.
e.g. Managers that keep customers and upper management our of the faces of developers increase productivity ; PMIs that force the Back Room Boy to delegate to the other developers that are sitting idle can increase productivity ; Six Sigma experts that insist on handover and quality checks between phases of activity (like requirements and design) can increase productivity.
The book talks specifically about how Six Sigma, Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI), and Project Management Institute (PMI) certification can drag down development productivity and quality
The moment a book claiming to be about software engineering trashes management processes like this, you know to call BS. It never ceases to amaze me how pretentious code-monkeys believe their immature approach to development is somehow hamstrung by proven management techniques that are able to deliver multi-million dollar projects ranging from constructing and mechanical/plant engineering, to the design and manufacture of electronics and automobiles.
Let's start with some basic facts. PMI doesn't dictate your development methodology. PMI doesn't assume your project is cast in stone from day 1. PMI is about ensure that a reliable process is in place, and that there are measurable goals and delivery points so that you can check your progress in terms of time and quality. And if that's not how it works in your company then you have a management-monkey who didn't learn shit from the certification.
CMMI worries about you having processes and procedures in place for various activities that are essential to the software process in a commercial environment, and capturing important information between steps in the process. It doesn't really care if you use the waterfall model or XP (although compliance is easier if you're using the waterfall model).
The problem with Software Engineering at the moment is that it is being approaches as a technical problem by ivory tower academics. They're floundering in baths of bullshit and fighting with management types because they're unable to contribute anything new, they wank about perfect quality/process and forget about real-world concerns (i.e. commercial environments), and they're making old mistakes. Management theory has addressed (in other areas) many of problems we are seeing in SE. Somehow, SE thinks it is unique. It's not. It's just another production / operations function.
And before you even think of bitching that "making software is not like a factory" - read a management textbook. Design (the creative, unique, once-off part... y'know, like software development) is a production function. And it has to consider all the same things as SE... oh, like user requirements, and a project plan, and quality, and maintainability, and testing, and...
Okay, I guess I'd better add some background on this one;)
A lot of businesses these days put a lot of money into building brand, expanding, diversifying, adding capacity... all the "planning for the future" things. And somewhere around 60% of those (for SMMEs) fail because of this. It's not the lack of profit that kills them, its the lack of cash flow.
A lot of businesses also make a profit without getting in more money than they spend, or make a loss despite getting in more money than they spend. Accounting is a wonderful thing.
I had a boss (Jewish) who made his comfortable living by buying up failing small businesses and turning them around. His philosophy was the "Jewish tailor principle" (and I have subsequently heard it called the Jewish accounting principle, lawyer principle, doctor principle, etc).
The Jewish tailor principle says that you don't spend money unless it is to make money. Not to possibly make money in the future, but to make money now. You spend $0.50 because its going to put $1 in your pocket tomorrow.
Also, money is cash and nothing else counts. A payment on credit is not money (unless you're the one paying;) ).
I don't know a huge number of Jews, but those that I know all seem to know about "the Jewish principle". Perhaps its some sort of in-joke in the local community.
Slashdot Mirror
The rights (and duties) of children are limited.
No rights are absolute: all rights are restricted but the amount to which they infringe on other rights. My right to free speech is restricted by your right to your good name, hence the crime of defamation. A child's rights to freedom of association and freedom of religion are restricted by the parent's right to bring up their child as they see fit, which includes the protection of religious indoctrination.
All rights have reciprocal duties or responsibilities: the flip side of the right of parents to bring up their children as they see fit, is a responsibility of care. Which makes it clear why children's rights may be limited by their guardians: you cannot exercise your duty of care if you cannot prohibit your children from interacting with certain people, or engaging in certain behaviour.
When government is clever, it can protect millions of people against their own stupidity. That includes people who don't have the rights to protect themselves ... like children.
Because:
Since you clearly don't understand the business concept of a mission, you can't understand how certain resources (like IT infrastructure) can be mission critical.
The Therac-25 controller was not mission critical. It was safety critical. The nature of the risk is completely different.
In a typical modern organisation, suffering a full days' downtime of business systems translates into a loss of about 0.3% of annual turnover, unless your company is not operating at capacity. For a company that has a net profit on turnover of 10% (which is pretty decent), that translates to a 3% reduction in net profit. Draw your own conclusions.
RTFW, or A Brief Introduction to Copyright for Fan Fiction Authors. By using identifiable creations (characters, places, plots) of another author you may be creating a derived work, which is an infringement. Just because you expressed an idea yourself doesn't mean you aren't infringing copyright. Why is this such a diccifult concept to understand?
Which brings up a very important point: we need some comprehensive and reliable market research that shows the demographics of game players. A lot of the push for game censorship seems to be in the name of the precious children ... and we need to be able to show that the "games are for children" adage is wrong.
Kudos to the well-informed parent. Tcl/Tk is indeed an excellent solution. More below.
But first ... Visual Basic is NOT the answer. The criteria were "fairly small" and "easy to install". For most Windows versions you'll have to distribute your VB application in an install package that includes the VB runtime DLLs or the .NET runtime (or get the end user to download them, which is a mission). If you're unlucky you'll have to distribute other MS DLLs like ComCtls as well. Find out more at http://msdn.microsoft.com/vbrun/ . Then there's accessing the serial port ...
For a simpler solution, grab TclKit, a single-file Tcl/Tk distribution. Tcl is ridiculously easy to learn, serial port access is as easy as file access, and it uses Tk to provide a powerful GUI.
You can put your scripts into the TclKit EXE as a resource, creating a single-file EXE distribution of your application. With UPX compression the resulting file will be around 1.2Mb (depending on what extensions you choose to use).
Assuming that you're being serious, the first step is for her to recognise her addiction and voluntarily choose to address it. Encourage her to consider what the addiction is doing to her and people around her; but she must decide that something should be done.
Then seek professional help. Psychologists are trained to deal with addiction issues; not only treating the addiction, but also helping the person to integrate back into their family and social environment. A psychologist will also be able to help you understand what you should be doing to support her (in fact, you may even consider visiting one for advise on how to encourage her to seek help).
Process standards are essential. Make sure you have them and that you have developer buy-in. Avoid contentious issues that have little factual support.
Off-topic: the first process standard you should introduce (if you don't have it) is source control; it has one of the highest cost/benefit ratios of good development practices. The second is configuration management (that is, proper control and version management of releases -- binaries and source code). The third is design and source code documentation.
Typographic formatting (where to put brackets, etc) is of questionable benefit, and it's not worth pissing developers off unless they all agree on it. There are several research papers that show a small benefit in having a consistent style, but the majority of this benefit comes from a consistent style within one file, and to a lesser extent within one code base. Typographic differences across code bases have little or no implication for development and maintenance. On the other hand, most developers read all styles with similar effeciency, and write their preferred style with somewhat greater effeciency (that other styles).
Typographic style also becomes a problem when you have legacy code that doesn't conform. What do you do when you maintain it? Update the style for the whole file; for the function being modified; just for the code you are modifying? Hint: changing the entire file or function makes it dramatically more difficult to use source control to identify (meaningful) changes. I have worked with several teams in which we have applied the rule "use the existing style for the file", with great success.
Commenting is both a technical issue and a management issue:
Technically, it is essential to comment code. Every reusable section of code (files, classes, namespaces, functions) should have a comment that explains what it is and how to use it. Without this, maintainers must make assumptions about what functions do, and how they are used; to confirm the assumptions they must read and understand the implementation. This is extremely inefficient.
Aside: some people think that the use of a function can be implied from its prototype; this is often incorrect. It is seldom possible to assume parameter boundaries, object state (in the case of methods) or error responses given only a prototype.
Every paragraph (block) of code that is not immediately obvious is a candicate for a brief comment indicating what the code is intended to do conceptually. These comments assist maintainers in navigating the code, and (in the case of bugs) understanding what it's meant to do instead of what is is doing (presumable erroneously).
A documentation standard should prescribe what must be documented, the "syntax" of the documentation (e.g. you could use Doxygen), and what the documentation is intended to achieve (e.g. for functions, a developer should be able to understand and use the function without having to refer to its implementation).
From a management perspective, risk related to poor coding can be mitigated by means of reviews and shared ownership; but risk also comes from the fact that intellectual property resides in people's heads not in source code. Unless you are intending doing a thorough walk-through of every legacy codebase with every new developer who joins the company, you need to have as much information as possible in the code, to allow knowledge to be transferred to new developers and maintainers. That means explaining the design and the implementation within the code.
As for comments not being kept up to date, that is something which is trivially addressed by source control and oversight. Every check-in can be reviewed by a peer to ensure the correctness of the code, and that any relevant comments have been made or updated.
Remember that source code is communication with other developers, not just instructions to a machine, and that makes writing style important. Sometimes it helps to think of source code like a book (the Book Paradigm).
Please take the PHP runtime and regression test suite, and write a non-trivial application. You may NOT refer to any PHP function documentation; not even a list of functions. To make this more realistic, do it with a language you don't even know.
Got a Clue yet?
Religion is already in opposition with secular ethics and morality. In general secular morality is more permissive than religious morality (for example in the area of relationships and in particular premarital sex), which causes such a conflict. Most religions require (or at least practice) that their laws are imposed on the population, rather than allowing members of the population to voluntarily accept them. Imposing dogma is unethical by secular standards, where ethics and morality are logically reasoned.
Sometimes the opposition is more blatent: many forms of evangalism require an active effort to change the attitudes of others, something with is an onus on all Christians (according to doctrine), yet which is generally unethical according to secular reasoning.
Obviously there are large areas where religious and secular morality agree; but that doesn't prevent them from being in opposition.
I'm left handed, you insensitive clod!
Not to mention the arrow keys in close proximity in the middle of the keyboard. So you have to hold either hand with your wrist at an awkward angle over them. Try holding you hand over the IJKM keys for a bit ...
I think this because of your statement:
If I don't believe that something exists, I am not asserting or assuming the negation (or opposite) that it does not exist. The only thing I am assuming is that I should proceed as if it may not exist. The important word here is "believe".
As an example, imagine you are blindfolded, spun around a few times, and told that it's okay to walk forward ten paces. You do not believe that a wall exists in your path (because you trust the person who told you to walk), but that doesn't necessarily stop you from being cautious and feeling out for a wall. You don't believe it's there, but neither do you assume that it's not.
That is not the agonistic position. Agostics hold that proof or emperical evidence of god is impossible; thus any belief in or against the existance of god is strictly a matter of faith, and cannot be justified by empericism. No true agnostic is waiting around for proof of god -- they believe wholeheartedly that such proof it impossible. They may believe in the existance or god or be skeptical about it; but in either case they do so knowing that there is no proof of that belief.
Yes, people use a lot of words more broadly than their meaning implies. But this is a religious discussion in which terminology is important (as evidenced by the attempts to define "athiest" and "agnostic"). Furthermore, I have most often heard the words "athiest" and "agnostic" abused in Christian circles, where they mean "undecided heathens waiting to be converted" (another way of saying "reserving judgement until they have reason"...).
You must be confusing me with someone else ... in fact, I didn't use any form of the word "assume" in my last post. Nonetheless, I happen to agree that every claim is an assumption.
Agreed.
Incorrect. To be agnostic does not deny the option of faith. On the contrary, it says that if you choose to hold a belief on the existance or non-existance of god, you do so knowing that your belief is on faith alone, and no evidence or proof can exist to support that belief.
You have to be careful with "positive" and "negative" statements. Just because something contains a "not" doesn't make it negative. "God exists" and "God does not exist" are
Damnit people. Stop trying to define things in terms of opposites.
An athiest believes there is no god. That is a much strong statement that simply not believing in a god, or not believing that there are one or more gods. It is an unprovable statement of belief (also known as "faith") in the non-existance of any form of divinity.
An agnostic believes that scientific knowledge or proof of the existance or non-existance of god (or gods) is impossible. Note that this does not preclude an agnostic from being a theist or an athiest -- it just means that the agnostic is aware that there can be no scientific evidence to back his/her beliefs. Agnosticism itself is a belief -- currently there are no proofs that scientific knowledge of god is impossible, largely because there is no definition for "god".
Agnostics are not uncertain. They have a view and they hold it firmly. But that view does not concern whether or not they believe in gods, it concerns whether scientific knowledge of gods is possible. An agnostic could be uncertain about his/her beliefs in the supernatural, but that's not inherent to agnosticism.
Religion is a belief system concerning the supernatural. A religion is, by definition, organized (a belief system); and by extension contains various doctrines (such as rituals and moral codes). Without doctrine religion would not be organised, and unorganised belief in the supernatural is termed "spirituality", not "religion".
Because of the need for organization and doctrine, and because they do not concern belief in the supernatural so much as belief against the supernatural, neither athiesm nor agnosticism are considered to be religions. This is both by definition and by convention in comparative religious studies.
The default position is neither athiest nor agnostic. It is "non-believer". A non-believer is someone who does not have a determined viewpoint on the supernatural. (Wikipedia uses the term "weak athiest").
This is different to "secularism", which holds that religion and supernatural beliefs are not paramount in understanding life and the natural world. Secularism is another ideological standpoint with specific views, and does not necessarily describe someone who simply does not have a determined viewpoint on the supernatural.
It is also different to "irreligious", which is the absence of religious belief. An irrelgious person could be spiritual (belief in the supernatural) or a non-believer, or an athiest.
You have grossly misstated the principle of bivalence. From Wikipedia: "In logic, the principle of bivalence states that for any proposition P, either P is true or P is false." You said "if any claim is false, its negation is true" (and in your examples you demonstrate that you intend "negation" to mean "opposite") which is only true when P is boolean.
If P is "I believe jam tastes good", then bivalence says that either P is true (jam tastes good) or P is false (jam does not taste good). The latter does not mean that jam tastes bad (which is the opposite of P), merely that it does not taste good. There are a whole range of tastes in between "bad" and "good". It could taste "just, y'know, okay, i suppose".
Back on agnosticism: agnostics simply believe that claims regarding the existance of god (or gods) are inherently unknowable. There is no statement of whether the gods do or do not exist, only that we can't be sure either way. Thus you get athiest agnostics, theist agnostics, and agnostics who are non-believers.
Sounds like the wrong person is driving this. Non-technical people seem to think that a firewall is the Grand Ultimate Answer to Security Problems. When you phrase your requirements in terms of a specific solution (i.e. We need to protect our IT infrastructure with a firewall) then you've got trouble.
Start by getting an IT security expert to review your infrastructure and identify potential threats, and discuss what protection can be used to mitigate various threats.
You will almost certainly find that "a firewall" is not going to provide the protection currently envisaged. You will also find that ongoing maintenance of your security solution is essential -- security without maintenance is useless.
If a firewall makes up part of that solution, it would be sensible to go for an appliance or a custom firewall distribution. Cisco PIX or M0n0wall are good choices. When you put a software package on a generic OS you have to spend more time maintaining the OS (patches, etc) and admins have a tendency to put other software and services on the machine because its there (which, obviously, are bad for security).
Remember that the majority of threats to your infrastructure are internal, and a firewall won't protect you. "External" threats like viruses tend to penetrate firewalls easily via e-mail. Many organisations (large and small) adopt a DMZ configuration (two firewalls with a limited number of machines between them, that are the only machines that can accept connections from outside the outer firewall, e.g. mail and web servers) with an additional firewall protecting the application servers (by which I mean whatever servers your business needs to do its stuff) from the desktop PCs.
More irony:
Seigenthaler goes out of his way to deride Wikipedia and all its volunteers, and to cast congress in a poor light for upholding the First Amendment. His stated goal is to "[let] many people know that Wikipedia is a flawed and irresponsible research tool."
You don't get much more poison-pen that that.
One day they may stop asking "where were you when JDK was killed?" and ask "where were you when Seigenthaler tried to kill Wikipedia?"
Or possibly the rise of industrialization and the contraction of childhood? Children have always been expected to do chores, but in previous generations have had much more leisure time and far less expectations to be adults.
Children as young as 7 are having their day packed with 8 hours of school and homework. Leisure time makes way for structured leisure activities and sports. Chores stay much as they always have been. And the child is acutely aware that they must decide what to be when they grow up, and if the don't get good grades right now they'll never get to university and that's pretty much the end of existance as we know it.
Children just don't have time to be children anymore.
Oh, and the age of consent used to be a lot lower.
The required population size depends on what you're trying to test and how carefully you select your population. If you're trying to test the failure rate of moderately experienced Windows users performing tasks on a Linux system, and you can accurately identify and select moderately experienced Windows users with no prior Linux experience, then you only need a tiny population.
Testing the failure rate is important: 100% of 11 users succeeding at a task can give you at most ~ 90% confidence that all similar users will succeed. 1 of 11 users failing is a far stronger result, telling you that you can expect at least 9% of all users to fail.
Various usability experts suggest that as few as 5 or 10 individuals are required for usability testing, and the remaining usability issues are discovered and resolved via the bug reporting and maintenance processes.
Lots of FUD and hand-waving here as the author compares the JVM to a C application, and implies that (1) the C runtime is bug-free and/or any C application can avoid C runtime bugs; and (2) all programmers can make their C programs more bug-free than a JVM.
A better comparison would be the C compiler, runtime and automated protection extensions versus the JVM, as those are the components of C and Java respectively that define the boundaries of what code written in the language can accomplish. Note in particular that a buggy C compiler can generate exploitable code, whereas a Java compiler cannot (because the JVM restricts what the code can do).
It must also be said that ultimately the JVM is a C program, so the system can protect itself just as much from a JVM as from any other C program.
Theft or stealing are the words used to describe the common law property tort of conversion, which involves infringing a person's right to a chattel (that is, personal property). The crime of theft involves unauthorised use and the intent to deprive.
In copyright infringement the copyright holder cannot be deprived. His positions before and after the instant of the infringing action are identical, as no damage (that is, real loss) has been suffered. In Dowling v United States the US Supreme Court found that "the rights of a copyright holder are 'different' from the rights of owners of other kinds of property". In other words, copyright infringement is not theft. This is one of the reasons that the phrase "intellectual property" is a misnomer.
Direct copyright infringement on the other hand is a strict liability tort. Liabilities that arise are the responsibility of the person who performed the act, irrespective of where the fault (culpability) lies. Strict liability does not necessarily make an action a crime.
So simply having an unlicensed copy of a work is sufficient to demonstrate the tort of strict liability, but possession of stolen property is insufficient to demonstrate theft.
The problem is determining what the liability is. In some countries the liability for copyright is determined by statute, and this is part of the problem behind the RIAA's actions.
First, there is a huge distinction between income and potential income. If person X copies a song, this is not evidence that person X would have bought the song in the absence of the option to copy it. Even if we assumed that it was, the actual damage to the copyright holder is limited to the net profit that would have been made off the purchase of one license (not the retail value of an album, as the RIAA would have you believe). Furthermore, noone other than the copyright holder has a claim -- retailers, wholesalers, manufacturers and publishers may not have benefitted from an album sale because of the infringement, but they are not entitled to a strict liability tort.
US law provides for statutory damages of "at least $750" per work. Compare that to the estimated $1 net profit the copyright holder will make per copy sold. It pays the RIAA enormously to claim the infringement of (say) 829 works with associated damages of either $30,000 or $150,000 (depending on how they make the claim) ... compared to the $829 their members would make from legitimate sales of the same works.
Your crypto background doesn't matter. The banking industry has a massive investment in infrastructure that takes years to change, and cannot be changes any faster because of the huge cost involved.
By the beginning of 2006 most security in the retail banking industry will have moved off single DES and on to Triple DES. Those that haven't will foot the bill for fraud on their systems rather than passing it on to their banks or Visa/Mastercard.
The system is expected to be based on TDES until at least 2012. By then it will still not be advantageous to attack the system: the cost will exceed the gain. This is a factor not only of the current strength of Triple DES, but of monitoring systems that will detect fraud patterns in time to respond appropriately.
The algorithm is also of little concern because there are far weaker points to attack in a payment network -- ones that are inherent to the existing infrastructure and that are going to take some time to go away.
Because the entire payment network is based on TDES, there is no option but to use TDES at the moment. SHA1 is used in conjunction with RSA as part of the new EMV payment system, which I'm guessing Pay Pass uses (I haven't seen the specs).
Chances are also good that Pay Pass will only permit transactions up to a certain value unless a PIN is entered, providing a balance between security and convenience.
On the contrary, there is an extensive knowledge base in Software Engineering on how to make reliable estimates of software development time and cost. Most programmers simply don't have this knowledge, which is giving the entire profession a bad reputation.
The only "creative" part of SE that is difficult to estimate is design -- "solving the problem" if you will. Coding is methodical application of rules; it still requires the skills of the craft, but it is easily and reliably estimated in a mature environment.
As for design, there are several techniques (such as prototyping) to reduce uncertainty and arrive at an accurate answer sooner than the "brute force" method (i.e. doing the work and seeing how long it took).
It also doesn't say "can drag up", which is more to the point.
I don't know whether to laugh or cry. Why is it that technically inclined people believe that "real skills" must be technical?
"Real skills" depend on the environment. In a commercial environment the only "real skills" that count are the ones that can lead to increased stakeholder wealth. That typically means more profits for the company (increased income and/or lower expenses) and better salary and working conditions for you. So you start by cutting secondary activities in the value chain (i.e. reduce unnecessary administration and overheads), and then further improvement must come from productivitiy gains in the primary activities.
Productivity gains don't have to come from the developers working faster. They can come from working smarter, from better allocation and utilisation of resources, from changing the product to be valuable to the customer, and from reducing wasted time.
Most of these changes can be effected by management and/or process experts with little or no technical knowledge ... as long as they keep their fingers out of the development methodology.
e.g. Managers that keep customers and upper management our of the faces of developers increase productivity ; PMIs that force the Back Room Boy to delegate to the other developers that are sitting idle can increase productivity ; Six Sigma experts that insist on handover and quality checks between phases of activity (like requirements and design) can increase productivity.
The moment a book claiming to be about software engineering trashes management processes like this, you know to call BS. It never ceases to amaze me how pretentious code-monkeys believe their immature approach to development is somehow hamstrung by proven management techniques that are able to deliver multi-million dollar projects ranging from constructing and mechanical/plant engineering, to the design and manufacture of electronics and automobiles.
Let's start with some basic facts. PMI doesn't dictate your development methodology. PMI doesn't assume your project is cast in stone from day 1. PMI is about ensure that a reliable process is in place, and that there are measurable goals and delivery points so that you can check your progress in terms of time and quality. And if that's not how it works in your company then you have a management-monkey who didn't learn shit from the certification.
CMMI worries about you having processes and procedures in place for various activities that are essential to the software process in a commercial environment, and capturing important information between steps in the process. It doesn't really care if you use the waterfall model or XP (although compliance is easier if you're using the waterfall model).
The problem with Software Engineering at the moment is that it is being approaches as a technical problem by ivory tower academics. They're floundering in baths of bullshit and fighting with management types because they're unable to contribute anything new, they wank about perfect quality/process and forget about real-world concerns (i.e. commercial environments), and they're making old mistakes. Management theory has addressed (in other areas) many of problems we are seeing in SE. Somehow, SE thinks it is unique. It's not. It's just another production / operations function.
And before you even think of bitching that "making software is not like a factory" - read a management textbook. Design (the creative, unique, once-off part ... y'know, like software development) is a production function. And it has to consider all the same things as SE ... oh, like user requirements, and a project plan, and quality, and maintainability, and testing, and ...
Okay, I guess I'd better add some background on this one ;)
A lot of businesses these days put a lot of money into building brand, expanding, diversifying, adding capacity ... all the "planning for the future" things. And somewhere around 60% of those (for SMMEs) fail because of this. It's not the lack of profit that kills them, its the lack of cash flow.
A lot of businesses also make a profit without getting in more money than they spend, or make a loss despite getting in more money than they spend. Accounting is a wonderful thing.
I had a boss (Jewish) who made his comfortable living by buying up failing small businesses and turning them around. His philosophy was the "Jewish tailor principle" (and I have subsequently heard it called the Jewish accounting principle, lawyer principle, doctor principle, etc).
The Jewish tailor principle says that you don't spend money unless it is to make money. Not to possibly make money in the future, but to make money now. You spend $0.50 because its going to put $1 in your pocket tomorrow. Also, money is cash and nothing else counts. A payment on credit is not money (unless you're the one paying ;) ).
I don't know a huge number of Jews, but those that I know all seem to know about "the Jewish principle". Perhaps its some sort of in-joke in the local community.