We use a commercial configuration management tool which has no revision control capability.
Pre-release activities include labeling the source code in the various parts of the separate revision control tool and archiving it (.zip or.tar.gz), then putting the code archives, design documentation, hardware diagrams, Bill of Materials, installation programs, user manuals, and an image of the final (distributable) CD into the CM tool.
Every unit of data which is stored in this manner is assigned a unique identifier, which is propegated back to the source of the data (VSS trees are labeled with the source code UID, source code is updated to contain the UID so that it appears in DLL versioninfo, documents have their UIDs added into them, the CD has the UID in a file in root and printed on the label, etc).
Finally, the CM also tracks the development of systems as a whole (hardware, software, documentation in their entirity), as well as delivery to customers. Patches are also entered into the CM separately, and their delivery tracked.
In short, given any program or part thereof, or piece of hardware, documentation, CD, whatever, we can identify all the source code (main application, tools, firmware), design documents, hardware processes, material providers, previously discovered bugs (linked to a separate system), patches available and applied, and so on.
For a commercial environment which values engineering processes, the benefit of this sort of knowledge should be clear. It is also something which can't be done with most revision control tools (notably, it would be possible to do it with VSS because of the availability of linking and cross-project labeling, although still not an ideal solution).
Confusing, maybe, but certainly not stupid. OpenCM, like many other tools, is mistaken as a revision control tool, but isn't.
Revision control systems like RC and CVS are concerned with tracking revisions of files. The have some limited capability to track revisions of entire systems. But the lack the capability to properly track and manage the way a system is put together from its components.
Maybe the easiest way is to think of a system as one of those cool (well, they were then) transformer toys. In its airplain configuration is goes really fast, but change it to its robot configuration and it has laser weapons.
In a software system, configuration management is concerned with which revisions of which files make up a particular "distribution" (for lack of a clearer word). It can also track this information across what would normally be separate projects in revision control systems. In its simplest for, CM can be a text file which says "This is label 1.2.14 of the main system, and is built against label 2.7 of libraryA, which in turn is build against label 0.96 of libraryB". A proper CM system gives you far more flexibility (I am not familiar with OpenCM's capabilities).
What software geeks usually refer to as "configuration" should more often than not be called "preferences". A Linux distribution is a particular configuration of Linux and associated tools, but your installation of that distribution has been specialised with a number of your preferences.
#1. Many music companies hold the (sometimes exclusive) rights to distribute a musician's work... but not the Copyright itself.
#2. I believe a strong case can be made for one of these bogus or loop MP3s being a derivative work.
If #1 and #2 hold, then the music companies are illegally creating and distributing derivative works, which puts musicians in a position to claim Copyright infringement and possibly damages.
Running the same SLOC figures against the statistics from the Function Points methodology and you get a different picture. You are looking at 2500 person years of effort, with a cost optimum development time of 6.5 years. However, to deal with the complexity involved you will need approximately 3000 average and 1500 above average developers (at average development rate you could expect a 13 year delivery!). Total price tag: around $2 billion (that's 2e9, in case your definition of billion is different).
Of course, this is still a very skewed figure. There is no accounting for the quality of code (at the end of such a complex development cycle, you could expect as many as 7 million defects!), and both FP and COCOMO estimate development effort inclusive of design work and documentation, which in OpenSource typically don't match those in mature commercial development environments (from which the FP and COCOMO statistics are derived).
There is also a huge, and invalid, assumption made by the author, regarding the application of COCOMO (and my FP calculations suffer the same problem). The complexity of a system is MORE than the sum of its parts. This is because developer productivity declines as system complexity increases.
At 10,000 FP, as developer is often only 60% as productive compared to 1,000 FP. The situation is obviously far worse at 300,000 FP (the entire distribution), yet the kernel itself only weighs in at around 20,000 FP. And even then, clear modularisation reduces complexity for individual developers. So it is grossly unfair to base calculations on the system as a whole.
The kernel (around 2.5 MLOC) as a single system would be a task for 300 skilled developers over around 3 years, while the Gimp (around 500 KLOC, still near the top of the list in size) would be looking at 50 developers over 18 months. More complex projects need relatively more time and more developers. Doing all these projects in parallel (assuming it were possible - which is isn't because of dependancies, and that's another factor) would take less than the most complex task (kernel = 3 years) and relatively less developers than estimated based on the complexity of that task (30 MLOC / 2.5 MLOC * 300 developers = max 3600 for entire distribution). Max cost: 3600 * 3 * $55k = $594 million.
And you're STILL not accounting for the fact that employing someone costs a lot more than just paying a salary. Which puts all estimates (mine and the authors) up.
My point was that you alternate hands with both QWERTY and dvorak. Dvorak is designed to do this more, yes (assuming you are typing in English!). The viperlair author's implication was that hand alternation caused QWERTY to be slower, which is obviously nonsense.
QWERTY was not designed to slow down typing, but rather to speed it up, given the constraints of physical collisions of typewriter heads. Thus the most common letters are organised on the home row or in convenient positions above it, but in such a way as lessen the liklihood of consecutively typing letters which have adjacent heads.
dvorak by comparison is lousy at this - the concentration of common letters on the home row makes it very likely that, if there were physical heads present, there would be a jam. You would have to deliberately slow your typing to prevent this - something QWERTY was designed to avoid. On the other hand, dvorak is arguably better in a situation without physical heads, as you point out.
I have used dvorak layout before, for several weeks. I decided to stick with QWERTY because (1) it will take me several months to get my typing to the same speed with dvorak (based on my current typing speed and the testimonies of others who have taken the plunge); and (2) everyone else uses it, which makes it irritating to use other computers (where I am not the sole user, and which I have to do quite a bit).
Most particularly, I find it unreasonable difficult to type in password, because I tend to remember them as key patterns rather than character sequences;)
Thank you! This is absolutely true. The viperlair article even makes the accurate claim that consecutive letter have often been placed on opposite sides of the keyboard: this makes you alternate work between your hands, and reduces the possibility of hammers sticking, thereby increasing the rate of typing.
You will also note that this concept of hand alternative is one of the two reasons for dvorak being claimed to be a better layout (the other being that the most commonly used English letters and punctuation are on the home row in dvorak.
"Configuration management" is an industry term for precisely what this product does, which is product revision control, and not source file revision control. You will notice that other tools like AEgis and many commercial tools also refer to themselves as "configuration management" rather than "source control".
South Africa (where I come from). There is no need to, and in fact no WAY to, register a copyright (except for films). There is no copyright office or the like, only a patent office. Reference: Department of Trade and Industry (SA)
Collecting damages involves proving that you are in possession of the original copy of the work, which is most easily done by proving that you had the complete work before the first publication. I don't have a legal reference, but I have associations with two successful Copyright defendants.
WIPO's rules require that all signatory countries enact legislation to recognise only: the WORD "Copyright", the copyright symbol (and bracket-c-bracket is specifically excluded in recent WIPO commentaries, but can be recognised by individual countries if they choose to), AND THEY DO NOT REQUIRE COPYRIGHT TO BE REGISTERED.
I don't have a reference for the symbol vs. (C) commentary, but according to this article, this article, and in particular this article from the Library of Congress you haven't done your research. Or you can read from the Berne Convention itself. In particular take note of the line "Before an infringement suit may be filed in court, registration is necessary for works of U. S. origin", as well as references in all three articles to the registration requirement for claiming infringement being a purely US phenomenon, but that it may make it easy to claim damages in other jurisdictions. Registration can also take place at any time in a Copyright life!
Not only did you get it backwards, (the UCC only recognizes the (c) as a valid copyright notice) but all of the above is meaningless if you haven't registered the copyright.
When copyright is challanged, the onus is on the author to prove that their work predates any work the claimant can prove.
Wrong.
Rephase, your Honour. When copyright is challanged, the onus is on the challanged to prove that their work predates anything the defendant can prove.
Same effect. At long as I can prove I owned the work before you did, you can't possible own the Copyright. This is enough to get even a registration overturned in court (since you don't have to register a Copyright at the beginning of its life).
This is definately NOT a recommended method. The only recommended method is formal registration.
Only in the US, Canada and other countries where they HAVE registries.
Actually it only proves that you can mail yourself an empty(?) envelope.
No, this is why it specifically has to be registered mail, or the equivalent service, because they will not accept unsealed mail. Registered mail ensures that the mail is delivered and not tampered with. Or did you miss the bit about "containing the complete work"?
You might look here [copyright.gov] for some correct information on copyright in the US. There are also links to international copyright law.
Do I have to register with your office to be protected?
No. In general, registration is voluntary. Copyright exists from the moment the work is created. You will have to register, however, if you wish to bring a lawsuit for infringement of a U.S. work. See Circular 1, section Copyright Registration. Note: "U.S. work", a sentiment borne out by the LOC page and other legal articles.
Thank you for playing, consider yourself WRONG. Insert brain to continue...
In many countries there is no requirement to submit works to the national library unless they are "formally published"; that means they have been assigned a unique number (like a bar code or ISBN). There is also often no requirement to submit non-text works. This actually has nothing to do with copyright, but to do with archives for public access.
WIPO's rules call for the recognition of authorial copyright - if you are the author of a work, you automatically enjoy copyright protection. There is no need to register that copyright, it simply exists. If you publish the work, you need to put a valid copyright declaration on it (which must be either the word "Copyright" or the copyright symbol [ (C) isn't valid! ], followed by the date of publication OR a date range indicating the first publication and the most recent publication, followed by the identity of the copyright holder.
When copyright is challanged, the onus is on the author to prove that their work predates any work the claimant can prove. Copyright registries are primarily meant to solve this issue, but many countries don't have them. One recommended method is to post yourself a registered mail containing the copyright work, or significant parts thereof, and not to open that mail. Registered mail (in case you have a different term) is stamped, logged and tracked at every sorting office it passes through, and the fact that it is sealed is stamped and signed.
If there is every a contesting of Copyright, you can produce the unopened mail, which proves the date at which you had the full work (which should be before you publish it;) ). Once produced in court, the court records can achieve the same ends in terms of proving the date.
This article is a typical case of benchmark bullshit. The author has taken a deliberately Unix-centric view of comuputing, and ignored design and implementation concepts that are normal for Windows-based systems.
In the synchronisation article (the/. poster missed the link for that one) only Mutexes, Semaphores and Critical Sections are evaluated. It is well known that mutex performance on Windows is poor compared to *nix, but that is mitigated by a number of benefits in the Windows threading model.
Here's a brief intro, to show why they CAN'T be compared:
Windows has processes and threads as first class citizens, and they have fair (multi-level round-robin) scheduling. Mutexes, semaphores and critical sections are the primary locks, but there are also atomic check-and-increment functions as well as events/signals (long lasting flags). Every object (mutex, sem, section, event, thread, process, file, socket, etc) in Windows can be waited on, and you can wait on any number and combination of objects at once, in either an AND or OR configuration. e.g. wait for a mutex AND an async socket IO; or wait for a semaphore OR a thread to end OR an event
Linux's options are far more limited - to achieve the same results you have to use a different architecture (not that this is necessarily a bad thing); on the other hand Linux's primitives and context switching is faster than the Windows equivalents. Linux has kernel scheduled processes, userland threads (kernel threads are available), a fair but not deterministic scheduler, mutexes, semaphores and condition variables.
A condition variable is similar to an event, but is instantaneous - if no thread is waiting on the condition variable, nothing happens. An event stays set until it releases a thread (auto-reset events) or until explicitly reset (manual-reset events). A condition variable one of the few time-waitable objects in Linux (all objects are time-waitable in Windows; mutexes and semaphores are not time-waiting in Linux).
The comparitive power of the Windows' threading and synchronisation model may not be obvious to long-time Unix programmers, but consider the wider range of architectural possibility when you can wait (with a timeout) on any combination of any objects in the system.
In the socket article, the author compares the BSD socket API on Linux with the WSASocket API on Windows, which is meant primarily for asynchronous operation. Despite claiming techniques for "high performance" sockets, he fails to mention/dev/poll, POSIX AIO, or Window's IoCompletion Ports. POSIX AIO can be reasonably compared to Window's async socket/file support, but it is impossible to make a valid comparison between/dev/poll (or kqueue, etc) and IoCompletion Port because they require significantly different architectures to function at peak efficiency.
On to processes and threads. CreateProcess() has the combined functionality of fork() and exec(), so the article starts off on the wrong foot. It also supports security attributes, so the equivalent Linux example should have had a larger function starting with fork(), then dropping permissions in the child and exec()ing another binary.
The author incorrectly assets that Linux threads are scheduled by the CPU - he is using the pthreads library, which is userland threading. pthreads is also far from "fair"; Windows uses a multi-level round-robin algorithm, which makes thread scheduling very deterministic; pthreads is far more prone to thread starvation in a system where processing cascades between threads. e.g. an input thread, processing thread and output thread, which use mutex-protected queues to communicate; this is an excellent architecture for Windows, but performs poorly by comparison on *nix because a sudden heavy load will see the input thread scheduled more often that other threads, until it's load dies down, at which point the processing thread will get the load, and so on - throughput stays much the same as a Window system, but latency near-triples.
Benchmarking thread creation is a load of crap. Few seriously high-performance servers use a thread-per-connection architecture anymore; and at the very least they use thread pools.
The entire article is unfair to both sides: on Windows, threads are first-class citizens; on Linux you are more likely to use multiple processes for stability and performance.
I've already covered everything necessary to dispute the bullshit in the Scheduling article.
Conclusion: this is an excellent case of "don't believe the FUD". You can't compare apples and apples when some of the apples are growing on an orange tree. The only way to achieve a meaningful comparison of these platforms is to construct applications with equivalent functions, but designed and implemented for the target platform.
You're talking specifically about America. Most countries have a national library to which you need to submit any book which is published *with an ISBN*. "Home publishing", games, music, movies etc. are not submitted to some sort of central repository in most countries. In line with WIPO treaties, you don't HAVE to register copyright to enjoy its protection, not even in the US.
I believe there should be a distinction drawn between Copyright over published worked, and intrinsic Copyright on unpublished works. If (say) Disney publishes something, and 70 years later their Copyright expires but no copies can be found in the hands of the public, Disney should be forced to provide the work as published, at least to a couple of public institutions.
Sorry, I'm talking bullshit, and so is the laywer. DMCA doesn't cover this AT ALL, as the software in question does not have access control mechanisms that are being circumvented. Even if you would like to argue that it does,...
DMCA, Section 1201
(f) Reverse Engineering. -
(1) Notwithstanding the provisions of subsection (a)(1)(A), a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs, and that have not previously been readily available to the person engaging in the circumvention, to the extent any such acts of identification and analysis do not constitute infringement under this title.
(2) Notwithstanding the provisions of subsections (a)(2) and (b), a person may develop and employ technological means to circumvent a technological measure, or to circumvent protection afforded by a technological measure, in order to enable the identification and analysis under paragraph (1), or for the purpose of enabling interoperability of an independently created computer program with other programs, if such means are necessary to achieve such interoperability, to the extent that doing so does not constitute infringement under this title.
So even if it can be shown that the DMCA applies, there is a legitimate reason (interoperability) for the creation of this software.
My point was not that it does not become public domain, but that there is no explicit legal requirement for the release of the material to the public.
That is to say, when (if) Disney's Copyright on Micky Mouse expires, there is no legal requirement that they hand over their Micky Mouse archives (or a copy thereof) to some sort of public institution. If you happen to HAVE a copy - sure, go ahead and copy it. But getting your hands on it may not be such a simple matter.
Abandonware is a case in point. Many games available on Abandonware sites do not exist somewhere in corporate archives, because the game companies simply went under -- there was no sale of assets, not buy-out by a bigger company. Just a quite whimper. Even though there was a threat (to society) of that information being lost forever... there was no attempt or requirement to make it public.
Talking about software specifically, where is there any implication or requirement for (say) the source code to be made public? Simple, there isn't. No more than an author could be expected to make his/her notes public when Copyright expires (okay, this would be posthumous anyway).
So here you have the basis of the problem: Copyright is a LEGAL measure to prevent you from distributing something; but when Copyright expires you have no LEGAL resource to FORCE distribution. If the (elapsed) owner simply doesn't make a copy available, you can't force him to.
I was considering pointing out that everyone does not necessarily win. In particular, LucasArts.
A number of gaming companies (EA in particular) have percesuted AbandonWare sites precisely because they intend to improve and rerelease old classics for newer architectures - in effect doubling the life (and revenue) of the product.
On the Copyright side this is particularly sad: Copyright was never intended as a tool to allow owners to prevent access; it was intended to allow the owner to benefit (financially) from the work during its useful lifetime. But there are no provisions in Copyright law which force material to be placed in the public domain when it is no longer being used (or even when Copyright expires!).
An unfortunately oversight on the part of the ScummVM representative, was the failure to mention that to use ScummVM you still require the original (LucasArts) software!
Had this be pointed out, along with the fact that ScummVM extends the accessibility of the original software beyond its original platform, it may make it less likely that the lawyers will respond with tougher measures.
There are a number of papers on the application of GAs to the optimization of the timetabling problem, but all of the require an initial solution. This is a basic premise of GA - start with a working solution, modify it randomly, and test it, until you find something that works better.
The initial solution comes from solving a complex system of constraints. Typically a collage will require the modelling of Students, Teachers, Classes and Venues. A group of Students enrolled for a particular Class, plus the Teacher teaching the Class, must not have clashes with other Classes, and the Class must not have a Venue clash.
Venues are assigned to a class based on teacher locality and class size. Students are assigned to a class based on registration. Teachers are assigned to classes by a department.
A useful heuristic for getting the initial solution is to allocate class time in "streams": identify courses that cannot be taken simultaneously, and schedule them at the same time. e.g. CS 1, CS 2 and CS 3. If the same Teacher is required for different subjects in the stream, you have to take out all but one such subject.
You may also have to consider oversize classes - sometimes a class of (say) 900 students must be split into 2 venues; and sometimes one teacher must teach all 900, so instead of venues, there is a split into two classes. This is rather more complex than it sounds: some students will only be able to attend one of the classes, others could attend either. Those that can attend either need to be assigned to a particular class, to prevent the venue from being overfilled and "starving out" those who need to attend that class, because they have a clash with the other.
On the other hand, if it takes a single staff member "at least a day" to schedule all of this, then you are probably looking for a less complex solution. I was asked by a high school (1000 pupils, approx. 40 staff) to assist them by writing an timetabling program; they took up to a week between three planners to schedule their classes.
You seem to have two main issues here. The first is that a person with (assumedly) less technical competance than you is dictating technical policy; and the second is that the usage of this application is too dynamic to allow for what your boss wants to do.
You need to establish how technically competant you are compared to your boss. Can you resort to hard technical fact to prove your case? Can you show that the speed sacrifice is negligable? If it is not, can you justify it?
The last point is important: if speed is so important (and you have to conceed that your boss is more driven by customer requirements than you are) then maybe you need to compromise on some other aspect.
It is already clear that, although customers can enter any amount of data, they can't enter 6Mb, because there are no enough resources. What about 4 Mb? 2Mb? How much is too much. Decide on a reasonable upper limit for customer data, and work from there. On a system with the limitations you have, this should have been part of the design spec.
Once you have determined an upper limit for customer data, you can calculate how much memory you have permanently available. It may be possible (depending on your app) to use additional memory when the customer supplies less data.
Wrong, your website IS released to the public, unless you have taken steps to make it private (say, using password protection and having a limited set of permitted members). Publishing on the web is just that - publishing. That gives libraries the right to take your publication and make it available to the general public.
The issue is more accurate one of whether the archive site is simply making your publication accessible, or republishing (which is protected by Copyright). Copyright ownership does NOT give you carte blanche to decide how and who has access to your material; there are limitations and provisions, in particular that public libraries can provide access to that material on a loan basis irrespective of the licensing clause you try to apply.
It should also be pointed out that in most countries it is a legal requirement that a number of copies of all publications be lodged with the central/national library. Because of the ad hoc nature of Internet publication (which means ANY web site) this is largely overlooked or ignored.
Archive sites provide a facility which can be equated to a public library. Once you have published material publically, you have no right to demand that it cannot be presented in a public library.
This is excellent advise. In my experience, the most stable code comes from pragmatic design followed up by pragmatic coding.
Design your system thoroughly. Identify every component, and the minimum interface required for that component. Carefully document that interface (API) - use Design By Contract (preconditions, postconditions and invariants) if possible.
Moving targets mean that the API will almost certainly have to be extended - documentation on the design and intent of the component/API as a whole will reduce the pain of this process. The responsibility for this documentation is shared between the design and implementation phases. Pay careful attention to documenting assumptions made within the code, e.g. ownership of member/global variables.
When it comes to coding, start with a skeleton. Put in the API function/method as defined, then check/assert every pre/post condition. Think about how any parameter could be out of range, or violate the assumptions you make. Once you are happy you're checking for all illegal use, you can go on to code the internals.
When coding internals, remember that you cannot trust anything (with the possible exception of other code in the same component). Check/assert the return values (and in/out parameters) of all calls you make. Have a well-defined system-level design for error handling, that doesn't allow the real error (or its source, if possible) to get lost.
As for testing, I'm all for the XP method: write your test cases first. This helps you to think about what you API is doing, how you are going to actually use it, and what you can throw at it that may break it (helping you to lock down the pre/postconditions).
You must use regression tests! Testing is useless if its done one, but the code is modified afterwards. Have a library of test cases, and use all of them. Every time a bug is found, add a test case for that bug, and ensure it is regression tested every time.
Code audits can detect and solve a lot of common implementation bugs. Use them to look for unchecked pointer/buffer use, assuming return values or success/failure of functions, and that asserts are correctly and accurately used.
In my experience most bugs do NOT come from implementation errors, but from developer misunderstanding, especially late in a project or in maintenance, or even during bug fixing! A developer must fully understand the code (s)he is working on, and all the assumptions it makes. Never adjust a non-local variable without first checking all other functions that use or modify that variable, and understanding the implications. Never use a function or method without understanding all the side effects (on parameters and scope/global state). This is why all of this information should be documented, and audits performed to ensure that the documentation is accurate.
Slashdot Mirror
We use a commercial configuration management tool which has no revision control capability.
Pre-release activities include labeling the source code in the various parts of the separate revision control tool and archiving it (.zip or .tar.gz), then putting the code archives, design documentation, hardware diagrams, Bill of Materials, installation programs, user manuals, and an image of the final (distributable) CD into the CM tool.
Every unit of data which is stored in this manner is assigned a unique identifier, which is propegated back to the source of the data (VSS trees are labeled with the source code UID, source code is updated to contain the UID so that it appears in DLL versioninfo, documents have their UIDs added into them, the CD has the UID in a file in root and printed on the label, etc).
Finally, the CM also tracks the development of systems as a whole (hardware, software, documentation in their entirity), as well as delivery to customers. Patches are also entered into the CM separately, and their delivery tracked.
In short, given any program or part thereof, or piece of hardware, documentation, CD, whatever, we can identify all the source code (main application, tools, firmware), design documents, hardware processes, material providers, previously discovered bugs (linked to a separate system), patches available and applied, and so on.
For a commercial environment which values engineering processes, the benefit of this sort of knowledge should be clear. It is also something which can't be done with most revision control tools (notably, it would be possible to do it with VSS because of the availability of linking and cross-project labeling, although still not an ideal solution).
Confusing, maybe, but certainly not stupid. OpenCM, like many other tools, is mistaken as a revision control tool, but isn't.
Revision control systems like RC and CVS are concerned with tracking revisions of files. The have some limited capability to track revisions of entire systems. But the lack the capability to properly track and manage the way a system is put together from its components.
Maybe the easiest way is to think of a system as one of those cool (well, they were then) transformer toys. In its airplain configuration is goes really fast, but change it to its robot configuration and it has laser weapons.
In a software system, configuration management is concerned with which revisions of which files make up a particular "distribution" (for lack of a clearer word). It can also track this information across what would normally be separate projects in revision control systems. In its simplest for, CM can be a text file which says "This is label 1.2.14 of the main system, and is built against label 2.7 of libraryA, which in turn is build against label 0.96 of libraryB". A proper CM system gives you far more flexibility (I am not familiar with OpenCM's capabilities).
What software geeks usually refer to as "configuration" should more often than not be called "preferences". A Linux distribution is a particular configuration of Linux and associated tools, but your installation of that distribution has been specialised with a number of your preferences.
result superiot to both
Yes ... there are some issues with qwerty.
#1. Many music companies hold the (sometimes exclusive) rights to distribute a musician's work ... but not the Copyright itself.
#2. I believe a strong case can be made for one of these bogus or loop MP3s being a derivative work.
If #1 and #2 hold, then the music companies are illegally creating and distributing derivative works, which puts musicians in a position to claim Copyright infringement and possibly damages.
Running the same SLOC figures against the statistics from the Function Points methodology and you get a different picture. You are looking at 2500 person years of effort, with a cost optimum development time of 6.5 years. However, to deal with the complexity involved you will need approximately 3000 average and 1500 above average developers (at average development rate you could expect a 13 year delivery!). Total price tag: around $2 billion (that's 2e9, in case your definition of billion is different).
Of course, this is still a very skewed figure. There is no accounting for the quality of code (at the end of such a complex development cycle, you could expect as many as 7 million defects!), and both FP and COCOMO estimate development effort inclusive of design work and documentation, which in OpenSource typically don't match those in mature commercial development environments (from which the FP and COCOMO statistics are derived).
There is also a huge, and invalid, assumption made by the author, regarding the application of COCOMO (and my FP calculations suffer the same problem). The complexity of a system is MORE than the sum of its parts. This is because developer productivity declines as system complexity increases.
At 10,000 FP, as developer is often only 60% as productive compared to 1,000 FP. The situation is obviously far worse at 300,000 FP (the entire distribution), yet the kernel itself only weighs in at around 20,000 FP. And even then, clear modularisation reduces complexity for individual developers. So it is grossly unfair to base calculations on the system as a whole.
The kernel (around 2.5 MLOC) as a single system would be a task for 300 skilled developers over around 3 years, while the Gimp (around 500 KLOC, still near the top of the list in size) would be looking at 50 developers over 18 months. More complex projects need relatively more time and more developers. Doing all these projects in parallel (assuming it were possible - which is isn't because of dependancies, and that's another factor) would take less than the most complex task (kernel = 3 years) and relatively less developers than estimated based on the complexity of that task (30 MLOC / 2.5 MLOC * 300 developers = max 3600 for entire distribution). Max cost: 3600 * 3 * $55k = $594 million.
And you're STILL not accounting for the fact that employing someone costs a lot more than just paying a salary. Which puts all estimates (mine and the authors) up.
My point was that you alternate hands with both QWERTY and dvorak. Dvorak is designed to do this more, yes (assuming you are typing in English!). The viperlair author's implication was that hand alternation caused QWERTY to be slower, which is obviously nonsense.
QWERTY was not designed to slow down typing, but rather to speed it up, given the constraints of physical collisions of typewriter heads. Thus the most common letters are organised on the home row or in convenient positions above it, but in such a way as lessen the liklihood of consecutively typing letters which have adjacent heads.
dvorak by comparison is lousy at this - the concentration of common letters on the home row makes it very likely that, if there were physical heads present, there would be a jam. You would have to deliberately slow your typing to prevent this - something QWERTY was designed to avoid. On the other hand, dvorak is arguably better in a situation without physical heads, as you point out.
I have used dvorak layout before, for several weeks. I decided to stick with QWERTY because (1) it will take me several months to get my typing to the same speed with dvorak (based on my current typing speed and the testimonies of others who have taken the plunge); and (2) everyone else uses it, which makes it irritating to use other computers (where I am not the sole user, and which I have to do quite a bit).
Most particularly, I find it unreasonable difficult to type in password, because I tend to remember them as key patterns rather than character sequences ;)
Thank you! This is absolutely true. The viperlair article even makes the accurate claim that consecutive letter have often been placed on opposite sides of the keyboard: this makes you alternate work between your hands, and reduces the possibility of hammers sticking, thereby increasing the rate of typing.
You will also note that this concept of hand alternative is one of the two reasons for dvorak being claimed to be a better layout (the other being that the most commonly used English letters and punctuation are on the home row in dvorak.
"Configuration management" is an industry term for precisely what this product does, which is product revision control, and not source file revision control. You will notice that other tools like AEgis and many commercial tools also refer to themselves as "configuration management" rather than "source control".
South Africa (where I come from). There is no need to, and in fact no WAY to, register a copyright (except for films). There is no copyright office or the like, only a patent office. Reference: Department of Trade and Industry (SA)
Collecting damages involves proving that you are in possession of the original copy of the work, which is most easily done by proving that you had the complete work before the first publication. I don't have a legal reference, but I have associations with two successful Copyright defendants.
WIPO's rules require that all signatory countries enact legislation to recognise only: the WORD "Copyright", the copyright symbol (and bracket-c-bracket is specifically excluded in recent WIPO commentaries, but can be recognised by individual countries if they choose to), AND THEY DO NOT REQUIRE COPYRIGHT TO BE REGISTERED.
I don't have a reference for the symbol vs. (C) commentary, but according to this article, this article, and in particular this article from the Library of Congress you haven't done your research. Or you can read from the Berne Convention itself. In particular take note of the line "Before an infringement suit may be filed in court, registration is necessary for works of U. S. origin", as well as references in all three articles to the registration requirement for claiming infringement being a purely US phenomenon, but that it may make it easy to claim damages in other jurisdictions. Registration can also take place at any time in a Copyright life!
1. The symbol © (the letter C in a circle), or the word "Copyright," or the abbreviation "Copr."; and, from LOC.
Rephase, your Honour. When copyright is challanged, the onus is on the challanged to prove that their work predates anything the defendant can prove.
Same effect. At long as I can prove I owned the work before you did, you can't possible own the Copyright. This is enough to get even a registration overturned in court (since you don't have to register a Copyright at the beginning of its life).
Only in the US, Canada and other countries where they HAVE registries.
No, this is why it specifically has to be registered mail, or the equivalent service, because they will not accept unsealed mail. Registered mail ensures that the mail is delivered and not tampered with. Or did you miss the bit about "containing the complete work"?
Do I have to register with your office to be protected? No. In general, registration is voluntary. Copyright exists from the moment the work is created. You will have to register, however, if you wish to bring a lawsuit for infringement of a U.S. work. See Circular 1, section Copyright Registration. Note: "U.S. work", a sentiment borne out by the LOC page and other legal articles.
Thank you for playing, consider yourself WRONG. Insert brain to continue...
In many countries there is no requirement to submit works to the national library unless they are "formally published"; that means they have been assigned a unique number (like a bar code or ISBN). There is also often no requirement to submit non-text works. This actually has nothing to do with copyright, but to do with archives for public access.
WIPO's rules call for the recognition of authorial copyright - if you are the author of a work, you automatically enjoy copyright protection. There is no need to register that copyright, it simply exists. If you publish the work, you need to put a valid copyright declaration on it (which must be either the word "Copyright" or the copyright symbol [ (C) isn't valid! ], followed by the date of publication OR a date range indicating the first publication and the most recent publication, followed by the identity of the copyright holder.
When copyright is challanged, the onus is on the author to prove that their work predates any work the claimant can prove. Copyright registries are primarily meant to solve this issue, but many countries don't have them. One recommended method is to post yourself a registered mail containing the copyright work, or significant parts thereof, and not to open that mail. Registered mail (in case you have a different term) is stamped, logged and tracked at every sorting office it passes through, and the fact that it is sealed is stamped and signed.
If there is every a contesting of Copyright, you can produce the unopened mail, which proves the date at which you had the full work (which should be before you publish it ;) ). Once produced in court, the court records can achieve the same ends in terms of proving the date.
This article is a typical case of benchmark bullshit. The author has taken a deliberately Unix-centric view of comuputing, and ignored design and implementation concepts that are normal for Windows-based systems.
In the synchronisation article (the /. poster missed the link for that one) only Mutexes, Semaphores and Critical Sections are evaluated. It is well known that mutex performance on Windows is poor compared to *nix, but that is mitigated by a number of benefits in the Windows threading model.
Here's a brief intro, to show why they CAN'T be compared:
Windows has processes and threads as first class citizens, and they have fair (multi-level round-robin) scheduling. Mutexes, semaphores and critical sections are the primary locks, but there are also atomic check-and-increment functions as well as events/signals (long lasting flags). Every object (mutex, sem, section, event, thread, process, file, socket, etc) in Windows can be waited on, and you can wait on any number and combination of objects at once, in either an AND or OR configuration. e.g. wait for a mutex AND an async socket IO; or wait for a semaphore OR a thread to end OR an event
Linux's options are far more limited - to achieve the same results you have to use a different architecture (not that this is necessarily a bad thing); on the other hand Linux's primitives and context switching is faster than the Windows equivalents. Linux has kernel scheduled processes, userland threads (kernel threads are available), a fair but not deterministic scheduler, mutexes, semaphores and condition variables.
A condition variable is similar to an event, but is instantaneous - if no thread is waiting on the condition variable, nothing happens. An event stays set until it releases a thread (auto-reset events) or until explicitly reset (manual-reset events). A condition variable one of the few time-waitable objects in Linux (all objects are time-waitable in Windows; mutexes and semaphores are not time-waiting in Linux).
The comparitive power of the Windows' threading and synchronisation model may not be obvious to long-time Unix programmers, but consider the wider range of architectural possibility when you can wait (with a timeout) on any combination of any objects in the system.
In the socket article, the author compares the BSD socket API on Linux with the WSASocket API on Windows, which is meant primarily for asynchronous operation. Despite claiming techniques for "high performance" sockets, he fails to mention /dev/poll, POSIX AIO, or Window's IoCompletion Ports. POSIX AIO can be reasonably compared to Window's async socket/file support, but it is impossible to make a valid comparison between /dev/poll (or kqueue, etc) and IoCompletion Port because they require significantly different architectures to function at peak efficiency.
On to processes and threads. CreateProcess() has the combined functionality of fork() and exec(), so the article starts off on the wrong foot. It also supports security attributes, so the equivalent Linux example should have had a larger function starting with fork(), then dropping permissions in the child and exec()ing another binary.
The author incorrectly assets that Linux threads are scheduled by the CPU - he is using the pthreads library, which is userland threading. pthreads is also far from "fair"; Windows uses a multi-level round-robin algorithm, which makes thread scheduling very deterministic; pthreads is far more prone to thread starvation in a system where processing cascades between threads. e.g. an input thread, processing thread and output thread, which use mutex-protected queues to communicate; this is an excellent architecture for Windows, but performs poorly by comparison on *nix because a sudden heavy load will see the input thread scheduled more often that other threads, until it's load dies down, at which point the processing thread will get the load, and so on - throughput stays much the same as a Window system, but latency near-triples.
Benchmarking thread creation is a load of crap. Few seriously high-performance servers use a thread-per-connection architecture anymore; and at the very least they use thread pools.
The entire article is unfair to both sides: on Windows, threads are first-class citizens; on Linux you are more likely to use multiple processes for stability and performance.
I've already covered everything necessary to dispute the bullshit in the Scheduling article.
Conclusion: this is an excellent case of "don't believe the FUD". You can't compare apples and apples when some of the apples are growing on an orange tree. The only way to achieve a meaningful comparison of these platforms is to construct applications with equivalent functions, but designed and implemented for the target platform.
You're talking specifically about America. Most countries have a national library to which you need to submit any book which is published *with an ISBN*. "Home publishing", games, music, movies etc. are not submitted to some sort of central repository in most countries. In line with WIPO treaties, you don't HAVE to register copyright to enjoy its protection, not even in the US.
I believe there should be a distinction drawn between Copyright over published worked, and intrinsic Copyright on unpublished works. If (say) Disney publishes something, and 70 years later their Copyright expires but no copies can be found in the hands of the public, Disney should be forced to provide the work as published, at least to a couple of public institutions.
A valid point ... but does the LoC store computer games ...?
Sorry, I'm talking bullshit, and so is the laywer. DMCA doesn't cover this AT ALL, as the software in question does not have access control mechanisms that are being circumvented. Even if you would like to argue that it does, ...
So even if it can be shown that the DMCA applies, there is a legitimate reason (interoperability) for the creation of this software.
You don't have to argue (2) unless you are in the US ;) And unless I'm mistaken, the compatibility provision still applies.
My point was not that it does not become public domain, but that there is no explicit legal requirement for the release of the material to the public.
That is to say, when (if) Disney's Copyright on Micky Mouse expires, there is no legal requirement that they hand over their Micky Mouse archives (or a copy thereof) to some sort of public institution. If you happen to HAVE a copy - sure, go ahead and copy it. But getting your hands on it may not be such a simple matter.
Abandonware is a case in point. Many games available on Abandonware sites do not exist somewhere in corporate archives, because the game companies simply went under -- there was no sale of assets, not buy-out by a bigger company. Just a quite whimper. Even though there was a threat (to society) of that information being lost forever ... there was no attempt or requirement to make it public.
Talking about software specifically, where is there any implication or requirement for (say) the source code to be made public? Simple, there isn't. No more than an author could be expected to make his/her notes public when Copyright expires (okay, this would be posthumous anyway).
So here you have the basis of the problem: Copyright is a LEGAL measure to prevent you from distributing something; but when Copyright expires you have no LEGAL resource to FORCE distribution. If the (elapsed) owner simply doesn't make a copy available, you can't force him to.
I was considering pointing out that everyone does not necessarily win. In particular, LucasArts.
A number of gaming companies (EA in particular) have percesuted AbandonWare sites precisely because they intend to improve and rerelease old classics for newer architectures - in effect doubling the life (and revenue) of the product.
On the Copyright side this is particularly sad: Copyright was never intended as a tool to allow owners to prevent access; it was intended to allow the owner to benefit (financially) from the work during its useful lifetime. But there are no provisions in Copyright law which force material to be placed in the public domain when it is no longer being used (or even when Copyright expires!).
An unfortunately oversight on the part of the ScummVM representative, was the failure to mention that to use ScummVM you still require the original (LucasArts) software!
Had this be pointed out, along with the fact that ScummVM extends the accessibility of the original software beyond its original platform, it may make it less likely that the lawyers will respond with tougher measures.
Just to follow up on my previous post, here are some resources:
No, this is not a problem for the faint of heart.
There are a number of papers on the application of GAs to the optimization of the timetabling problem, but all of the require an initial solution. This is a basic premise of GA - start with a working solution, modify it randomly, and test it, until you find something that works better.
The initial solution comes from solving a complex system of constraints. Typically a collage will require the modelling of Students, Teachers, Classes and Venues. A group of Students enrolled for a particular Class, plus the Teacher teaching the Class, must not have clashes with other Classes, and the Class must not have a Venue clash.
Venues are assigned to a class based on teacher locality and class size. Students are assigned to a class based on registration. Teachers are assigned to classes by a department.
A useful heuristic for getting the initial solution is to allocate class time in "streams": identify courses that cannot be taken simultaneously, and schedule them at the same time. e.g. CS 1, CS 2 and CS 3. If the same Teacher is required for different subjects in the stream, you have to take out all but one such subject.
You may also have to consider oversize classes - sometimes a class of (say) 900 students must be split into 2 venues; and sometimes one teacher must teach all 900, so instead of venues, there is a split into two classes. This is rather more complex than it sounds: some students will only be able to attend one of the classes, others could attend either. Those that can attend either need to be assigned to a particular class, to prevent the venue from being overfilled and "starving out" those who need to attend that class, because they have a clash with the other.
On the other hand, if it takes a single staff member "at least a day" to schedule all of this, then you are probably looking for a less complex solution. I was asked by a high school (1000 pupils, approx. 40 staff) to assist them by writing an timetabling program; they took up to a week between three planners to schedule their classes.
You seem to have two main issues here. The first is that a person with (assumedly) less technical competance than you is dictating technical policy; and the second is that the usage of this application is too dynamic to allow for what your boss wants to do.
You need to establish how technically competant you are compared to your boss. Can you resort to hard technical fact to prove your case? Can you show that the speed sacrifice is negligable? If it is not, can you justify it?
The last point is important: if speed is so important (and you have to conceed that your boss is more driven by customer requirements than you are) then maybe you need to compromise on some other aspect.
It is already clear that, although customers can enter any amount of data, they can't enter 6Mb, because there are no enough resources. What about 4 Mb? 2Mb? How much is too much. Decide on a reasonable upper limit for customer data, and work from there. On a system with the limitations you have, this should have been part of the design spec.
Once you have determined an upper limit for customer data, you can calculate how much memory you have permanently available. It may be possible (depending on your app) to use additional memory when the customer supplies less data.
Wrong, your website IS released to the public, unless you have taken steps to make it private (say, using password protection and having a limited set of permitted members). Publishing on the web is just that - publishing. That gives libraries the right to take your publication and make it available to the general public.
The issue is more accurate one of whether the archive site is simply making your publication accessible, or republishing (which is protected by Copyright). Copyright ownership does NOT give you carte blanche to decide how and who has access to your material; there are limitations and provisions, in particular that public libraries can provide access to that material on a loan basis irrespective of the licensing clause you try to apply.
It should also be pointed out that in most countries it is a legal requirement that a number of copies of all publications be lodged with the central/national library. Because of the ad hoc nature of Internet publication (which means ANY web site) this is largely overlooked or ignored.
Archive sites provide a facility which can be equated to a public library. Once you have published material publically, you have no right to demand that it cannot be presented in a public library.
This is excellent advise. In my experience, the most stable code comes from pragmatic design followed up by pragmatic coding.
Design your system thoroughly. Identify every component, and the minimum interface required for that component. Carefully document that interface (API) - use Design By Contract (preconditions, postconditions and invariants) if possible.
Moving targets mean that the API will almost certainly have to be extended - documentation on the design and intent of the component/API as a whole will reduce the pain of this process. The responsibility for this documentation is shared between the design and implementation phases. Pay careful attention to documenting assumptions made within the code, e.g. ownership of member/global variables.
When it comes to coding, start with a skeleton. Put in the API function/method as defined, then check/assert every pre/post condition. Think about how any parameter could be out of range, or violate the assumptions you make. Once you are happy you're checking for all illegal use, you can go on to code the internals.
When coding internals, remember that you cannot trust anything (with the possible exception of other code in the same component). Check/assert the return values (and in/out parameters) of all calls you make. Have a well-defined system-level design for error handling, that doesn't allow the real error (or its source, if possible) to get lost.
As for testing, I'm all for the XP method: write your test cases first. This helps you to think about what you API is doing, how you are going to actually use it, and what you can throw at it that may break it (helping you to lock down the pre/postconditions).
You must use regression tests! Testing is useless if its done one, but the code is modified afterwards. Have a library of test cases, and use all of them. Every time a bug is found, add a test case for that bug, and ensure it is regression tested every time.
Code audits can detect and solve a lot of common implementation bugs. Use them to look for unchecked pointer/buffer use, assuming return values or success/failure of functions, and that asserts are correctly and accurately used.
In my experience most bugs do NOT come from implementation errors, but from developer misunderstanding, especially late in a project or in maintenance, or even during bug fixing! A developer must fully understand the code (s)he is working on, and all the assumptions it makes. Never adjust a non-local variable without first checking all other functions that use or modify that variable, and understanding the implications. Never use a function or method without understanding all the side effects (on parameters and scope/global state). This is why all of this information should be documented, and audits performed to ensure that the documentation is accurate.