I'm going to be a slight devil's advocate here, because I believe strongly in unit testing, but there is a significant amount of academic literature which demonstrates the falacies inherent in using tests to catch bugs.
Incidently, test driven design is concerned with demonstrating that the software can function as specified. It is not concerned with - and bad at picking up - software that performs those functions with side effects, or contains code which can be exploited in a security-sensitive context.
The simplest "proof" of the problem with testing is to consider a function with four arguments; let's say this is C, and two arguments are int while the others are char*. To rigerously exercise a single argument of this function, you need five to seven distinct tests: obviously good value, obviously bad value, inner- and outer-values for boundary conditions (may only apply to the int), and NULL. Unfortunately a black box function may have strange interactions between parameters which testing each individually cannot expose; a proper test set to ensure the function behaves correctly in all circumstances will require approximately 6 * 6 * 5 * 7 = 756 tests, being the permutation of all single-argument test cases.
No, I'm afraid this is not a suitable answer. Unit tests are best used for two purposes: testing that a function produces the correct and expected effect when used correctly; and testing that a function does not produce a bug that has already been discovered (i.e. regression testing).
For everything else, there's Mast^H^H^H^Hcode inspections. A code inspection (audit) will detect problems in the handling of parameters far more efficiently than building hundreds of tests. What is more, it will (when performed by an experienced developer) expose problems that tests cannot: tests are particularly bad at showing up race conditions, buffer overflows and other security risks.
I agree completely, although there should be no harm in having auditing available to new projects (project leaders just wouldn't consider it for the purposes of when to stablise and release).
Although I would like to contribute more to OSS development, I have very little time or opportunity. In a project of any maturity which has a well designed and documented code structure and is employing DBC (design by contract), it is very easy to audit a single function now and then. Coding the function is somewhat more time consuming - even with strict modularity it takes some time to understand the requirements and implement them.
I'm betting that there are many eyes out there willing to find the bugs, but not sufficient tools to track where the eyes are (and should be) looking.
I've made this suggestion several times before; what we really need in OpenSource development is a reliable and powerful code auditing controller.
While direction and design are problems experienced by a lot of OpenSource software, it is quality and security issues which are of more concern to mature projects, which have the highest visibility and widest use.
A code audit system would allow a project to be viewed as a graph of procedures/methods, and force every procedure to be marked as audited by a number (variable threshold) of auditers of a predetermined "skill level". i.e. the designers and core audit team together decide that certain procedures and modules are sensitive, and require an audit by three senior/trusted auditors; other less sensitive code requires only to junior auditors.
The system could track the auditing in conjunction with source code control, and use the software call graph to invalidate audits on procedures when dependancies are modified (and automatically marked as unaudited).
e.g. Procedure A calls procedures B and C. They are all marked as completely audited. Any change to Procedure C will necessarily invalidate the audit on C, and by relationship invalidate the audit on A. Once C is re-audited, the audit of A will still have to be performed again (unless, say, a special "interface not changed" flag is used on the re-audit of C).
In this way everyone can be happy that a project release is secure and reliable, based on the extent of the audited code.
I'm afraid I can't find the original source where I was reading about this, but the problem extends to the text, mainly because it is not the original text. Shakespeare is good example, because most modern publications are not true to the original works: oldde englishe wordes have been changed into modern equivalents, and phrases here and there have been updated to ones we can understand today.
You are correct in saying that the publishers copyright (in such cases) is over the modifications only; but it can be very difficult to determine which parts have or have not been modified. Typically, you need an old copy of the original work, which means you can't pick up a modern publication for your library or bookstore.
Copyright law is supposed to give incentive to create, for the betterment of society, and allow the creator to derive direct benefits as a reward. An artist who has created a work so successful that (s)he can live on it indefinitely has arguably provided a suitable level of betterment to society.
Saying that copyright law is an incentive to "work" is accepting mediocracy. Artists who produce works that society values more highly should (have the opportunity to) receive more benefits.
On the other hand, I don't necessarily agree that copyright should last the lifetime of the creator (although there are strong arguments for this in the case of a natural person). But what is a "fair" limit?
Is 5 years enough? Almost certainly not. Many authors only achieve popularity after 10 or more years, and then make a fair amount of money off increased sales of their older works. A good number accept this as a risk, and plan to use this phenomenon to their benefit - work up a good number of titles with varied content, and you'll pull more readers, who are then likely to try some of your other titles.
Is 20 years enough? Maybe. But some of our best-loved authors were 15-20 years ahead of their time in terms of what readers wanted.
Is life enough? Strangely, no. If an aging star has just completed his/her autobiography, concludes the publishing deal, and dies... well, the family could well be screwed.
Maybe the answer lies in a compromise, rather than an all-or-nothing approach. Copyright over a work lasts for the greater of 10 years or the creator's natural life (which gets very interesting when we get eternal life medications...). But some rights fall away after the LESSER of those two times, such as exclusivity over derivative works (but not translations).
This allows society to (culturally) enrich itself by building on a work after a shorter amount of time, while the creator (and/or family) can still derive value from the original work for a longer time.
In the case of books this is easily understood: author writes book; 10 years later other people can write preludes and sequals, extend the world and characters, etc; 30 years later author dies and original book falls into public domain.
Sorry, but this isn't strictly true. See my earlier post. Publishers tweak the text ("corrections" mostly) which give them copyright over their particular publication.
Re:Copyright is not an issue
on
Just One Page a Day
·
· Score: 3, Informative
Sadly, copyright is an issue in this sort of work. Just because Dickens' works are no longer copyright, doesn't mean you can go and pull a Dickens novel off the library/bookstore shelf and OCR it. Publishers tend to be careful to make slight alterations to the text here and there (formatting, spelling, come clarifications and corrections) which turns a copyright-expired work into a derived work over which they own the copyright. Shitty, isn't it?
The syntax characters are not the same in all encodings. This is made completely clear by one of the appendices to the XML specification, which explains how a parser can determine the character encoding in use by examining the first four bytes of the file.
Since an XML document must start with <?xml, in UTF-8 the first four bytes will be <?xm . In UTF-16, however, the fist four bytes will contain BE or LE 16-bit encodings for just the first two characters <?, because each character uses at least 16-bits to encode. You can also determine UTF-32 encodings and others.
Encoding determines how to interpret the bits and bytes of the document into characters, and the control characters are not the same in all encodings. A parser that naively parses a document as ASCII will get the completely wrong idea if it is UTF-8 encoded, where there may be multiple bytes per character. A UTF-16 encoded document parsed as UTF-8 will be completely garbled.
Actually, I do. Like most sane people I understand that one unicode character encoding (EITHER UTF-8 OR UTF-16LE OR UTF-16BE OR UTF-32 OR on of the many others) is adequate. UTF-8 gives you a nice advantage of compatibility with the ASCII-7 character set, which means widespread support for text editing.
On the surface XML looks very simple. Balanced parenthesis expressions, as you say. Just under the surface it doubles its complexity: attributes are functionality equivalent to sub-expressions which have the limitation that they themselves can't have sub-expressions. This gives you two equivalent ways to represent information, which complicates the data model. It also makes it slightly more difficult to parse.
But when you get to the actual syntax, all hell breaks loose. A parser must understand UTF-8 and UTF-16 encoding (the latter in big endian or little endian format).
A parser must also parse not only the simple embedded parenthesis we know as XML, but also a DTD. Even if it cannot validate, it must parse the DTD in order to get past it and parse the rest of the document, in order to substitute entities, and in order to handle whitespace correctly.
Beyond the DTD and "basic XML syntax", it must handle special cases for comments, CDATA sections and processing instructions. All of these are effectively subgrammars - once you enter the section it has its own completely different rules for how its content is (or is not) parsed.
The parser must also detect and substitute entities, as specified in the DTD. The DTD also determines where whitespace is and is not significant, and therefore whether the parser must or should ignore whitespace, or must report it to the application (which is using the parser).
XML looks simple, and simple non-compliant XML parsers that parse simple XML are easy to write and in abundance. But XML, complete, is complex and tricky.
Umm, no. Brute forcing 1024-bit RSA is not O(2^1024), its closer to brute forcing 64-bit DES, which is O(2^56). Brute forcing simply involves an exhaustive search through the keyspace. It does NOT mean you have to do a full calculation and comparison with every possible value that can fit into a key representation.
e.g. RSA keys can only be prime, so you search for prime numbers of length 1024 bits rather than trying a RSA operation will all 1024 bit numbers. In addition, some techniques allow you to detect that a key cannot possibly give the desired solution before the entire calculation is completed, so you can do only partial calculations on some values.
Brute force means trying every key in the keyspace in turn. Just because the key is 109 bit doesn't mean the keyspace is. DES uses a 64 bit key, but 8 of those bits are parity, so the keyspace is only 56 bits. RSA uses a 1024 bit modulus, but only prime numbers can be used and the top bit is always set to ensure that the length is 1024 bits; the keyspace is nowhere near 2^1024!
You also have to factor in who is going to crack your key, and what they are prepared to throw at the problem. Moore's law is for commodity hardware - someone serious about cracking a key in a short time will use dedicated hardware.
Simple DES FPGAs can way outperform a P4 on DES operations, even running at 1/50 the speed. If it takes 10,000 computers 18 months to crack a key, it could take 50000 dedicated chips (which would be a lot cheaper!) under a month - even less depending on how much hardware can accelerate the calculations.
Plus 85 other rules. Yes, really - check the specification. There mere fact that it has attributes AND every tag can contain tags gives you two orthogonal and redundant data models. There are two character encodings, three character/data representations, four syntactically distinct data models... and only about four parsers that can claim to be compliant or close to compliant with the specification. Yes, complex.
In BNF notation Java has 54 productions, C++ has 88, and XML has 89. Where Java and C++ only support a single character encoding according to their standards, XML requires support for at least 2, one of which must be supported in both endian encodings. Where LR(1) grammars define at design time the significance of whitespace, XML must parse a DTD at runtime to determine when whitespace is or is not significant. In XML arbitrary characters or data can be represented in at least two ways other than a raw character, and XML has built into it a substitution language - so its fair to compare its complexity to C++ and CPP.
XML is a complex and difficult to implement standard (as evidenced by the very few completed, compliant parsers that are available).
Using MP3 as an alternative media for the purposes of using content which you have licensed is acceptable. So if you buy a CD (and thereby license the content) you should be able to back it up, copy it to your HDD / portable player / car MP3 player, etc. MP3 trading is, on the whole, NOT acceptable use: a CD (or any licensed content) should be treated like a book - it can only be used in one place at one time.
P2P is a massively effective advertising/marketing mechanism. There are numerous studies showing that music trading increases music purchases. This is especially true for non-headline groups that don't make the Top 40 lists and whose record companies won't pay to have them on regular playlists. Wider exposure means more sales, and this benefits the artists and the record label. Of course, this doesn't make it legal. The question is: how do you draw the line? Perhaps we should have a DRM system that permits shareware-style evaluation?
IANAL, and since the DMCA doesn't directly effect me, I am not overly familiar with it. On the whole, however, I have not seen many negative comments about the DMCA beyond the non-circumvention aspects (and I'm probably forgetting some other critical bits;) ). The DMCA is a good example of modern day legislation: it is redundant, and attempts to legislate a new solution to insufficient policing of existing laws. Consumers and record companies are best protected by concentrating the force of the law on commercial (i.e. mass) piracy, which is where most losses accumulate.
The RIAA and MPAA are by their very nature opposed to consumers. They exist to protect the interests of the middle man, not the consumer nor the artist. They do not stand to gain anything from a better consumer image.
As for (1). You should be able to transfer the content into any media you choose. Providing you do not distribute/publish content, you can also alter it (for private use) any way you see fit. You can also broadcast privately (e.g. play a DVD for a group of friends) and lend the content on a private, non-commercial basis (e.g. to a friend, but you cannot trade as a video store) providing that you don't use another copy of the content while a copy is on loan. Remember that Copyright law (as originally contemplated) is concerned with publishing and distribution rights, and cannot be used to control how you use the content once you have licensed it.
A clarification: yes, I do refer to licensing content rather than purchasing it. There is a distinction, and that is becoming more clear. When you purchase a CD you receive, in that purchase, the physical media containing the content, plus a license to use the content. Copyright law does not allow you to own the content unless you are the copyright holder - you can only use it according to a license granted to you by the copyright holder. With physical media we seldom distinguish between the purchase of the media and the purchase of the license, because the license is implicit.
Ah good, someone got in before me:) It is definatly a good idea to separate out the GUI part when dealing with cross-platform applications, since a lot of portability problems reside there.
In all honesty, I don't recommand Qt or wxWindows - they are great toolkits, but you lose out heavily on productivity compared to visual development environments with GUI builders. While both of these have associated builder tools, I don't consider them very mature of capable compared to VB or Delphi/C Builder. There is also a write-once-debug-and-tweak-everywhere concern (just getting wxWindows looking good on Windows and Solaris takes some effort).
Java is a great choice as it is supported on many platforms, has powerful GUI classes, a couple of builder products, and has several means for client/server support, including CORBA. But for UI applications it isn't hugely productive (strangely enough).
I have grappled with exactly this question (legacy C/C++ needing to go cross platform with GUIs), and the best answer I've come up with so far is to keep your main code in C/C++ (since you have the legacy code AND the skills), define a clear UI abstraction layer, and create the UI in a scripting language such as Tcl or Python. Use SWIG to tie the script to native C functions.
I have more experience with Tcl/Tk, and believe it is more widely portable (especially the GUI consistency), but it is slower and arguably more difficult to program than Python. Still, this depends on what skills you can acquire, and what your UI requirements are.
Prechelt has an empirical comparison of some languages, including C/C++, Python, Tcl and Perl, and most importantly he has productivity figures! Keith Waclena has a Language Crisis page of comparisons, and Doug Bagley hosts the Great Computer Language Shootout. There are all invaluable resources for determining a balance between portability, functionality and productivity.
And this is precisely what I look for when I publish a document for public or customer consumption. I want the final image of the document locked down, unmodifiable, the way I intend it to be. No messing with the formatting, fonts, colours or anything else that I carefully put together to convey my message.
To too many people a document is just text. This is far from the truth. A document is a presentation, and says a lot about the person or organisation that prepared it. From technical notes to marketting, control over document format is a vital part of publishing.
And that is why PDF kicks the arse of other formats when it comes to this type of use.
Is there another service on offer to provide porn / windows service packs on demand, which cross-subsidises data traffic? No.
Voice calls subsidize data traffic. Decrease voice calls in favour of data traffic (i.e. VoIP) and you upset the balance; to rebalance the telco must increase the price of BOTH voice AND data traffic (or significantly increase only data traffic and reduce cross-subsidization).
An increase in the cost of data traffic hurts everyone. It is not just that some people are now using more data traffic than others, it is that the traffic costs more. Even voice users who have nothing to do with data traffic will be paying more.
You're right -- this ruling is protectionism. It protects the majority of consumers from a few who can abuse the system by getting services at a fraction of the cost, thereby increasing the cost to the majority.
Telecoms companies use a wide range of cross-subsidies to cover the costs of their international capacity. Fact: voice calls subsidize data. A telecom can reserve and sell a block of bandwidth for data at a fixed price with a higher return than it can reserve bandwidth for on-demand purposes, such as voice calls which are more common at particular hours of the day. During the rest of the time that bandwidth reservation is not realising its full value.
The more users move to VoIP, the more the telecom must rebalance the costs of its services, and data bandwidth will become more expensive. So now the ISPs are paying, and you are paying the ISP. But until your ISP starts charging you, specifically, the VoIP user, that price increase gets passed on to all data users.
A peering agreement is between peers. An ISP has a service agreement with a telco, and a peer agreement with other ISPs. Telcos have peering agreements with each other, sharing the costs of interconnecting equipment and negating some call costs in each direction.
Go and read up on freeloading, the tragedy of the commons and the Nash equilibrium, and the economics that pertain to it. Anything that can be used to bypass restrictions on a product or service to obtain another product or service which is usually more expensive can be treated as a partial form of freeloading. VoIP is no different.
All the comments I've seen about this are along the lines "this is bad for progress", "you can't step on my rights", or "there are easy technical workarounds". But noone has actually acknowledged that there is a sound economic reason for this action, which is being contemplated by many governments around the world.
Governments have a responsibility to provide basic services to their citizens. Communication is considered (by the UN and most governments) to be a basic service. Thus the sector needs regulation to prevent abuse by the providers and the consumers.
VoIP sounds like a wonderful idea: use more advanced technology to reduce the cost of calls, especially international calls, thereby improving value to the consumer.
Sadly, this is one side of the equation. Using/allowing VoIP means a select number of consumers who have access to VoIP equipment are able to make international calls at local call cost, while still using some (perhaps less than a conventional call) international bandwidth without really funding it.
In order to afford the international bandwidth, the telecom company must recoup the cost, and it can do this in one of three ways:
Charge more for international calls: This means that the man-in-the-street, who does not have VoIP access, is paying more to make international calls, on account of VoIP users. When one group of users must pay more because of the actions of another group, this is generally considered in business as service abuse.
Charge more for international data only: this gives similar resulsts to the above, except the inconvience is more limited. VoIP users are a small subset of data users, but an even smaller subset of all telephone users; so you're asking the data users to fund the VoIP's bandwidth.
Charge more for all calls and have local calls subsidise international bandwidth costs: This means higher costs for everyone in the system. Since communications is a basic service, this will be a driver for inflation.
No matter how you look at it, VoIP is a specialised service with a usage pattern such that non-users are expected to subsidise the cost. This is grossly unfair to those users, which is precisely why telecoms companies are keen to prohibit the use of VoIP on their networks.
Until such time as ALL international calls can be VoIP (which basically means making all phones VoIP equipment), the ecnonomic concerns are going to be the same.
SMTP is the IM counterpart to SMTP. See "SEND", "SOML" and "SAML". If someone bothered to implement these, we'd have had a standardised IM network years ago.
Herbert places the Jihad 10,000 years before the first Dune novel, on several occasions. I'm afraid I don't have references here, but I can probably find them if you really want;)
The Jihad was ancient history in the original Dune series, which led to the complacency of civilisation that necessitated Paul's terrible purpose. The stagnant empire needed to be forced to change again in order to survive the future.
While I agree that the Bene Gesserit could predate the Jihad, I don't believe the Guild does, for three reasons: (1) I'm fairly sure that Herbert places Holtzman at the time of the Jihad, and his theories led to the generators that can fold space; (2) Herbert's comments about the Jihad implied that several technologies, including fast space travel, occured subsequently to the Jihad; (3) There is no indication by Herbert that Dune played any part in the Jihad, so it was certainly not a focal point or critical resource, implying that there was no need to spice, i.e. no guild.
Herbert doesn't say this in as many words, but it is heavily implied in various places. The tripod that has dominated the political landscape of the empire arose out of the Butlerian Jihad. If I'm not mistaken the presence of Tio Holtzman during the Jihad was mentioned directly; which would mean space folding could not predate the Jihad.
Whether mentats came about before, during or after the Jihad is unclear - certainly they occured sometime after the machines took over. Herbert never hints that mentats had anything to do with the downfall of the machines though.
The only questionable parts (in my mind) are the simultaneous discovery of the spice and its effects; and the relationship of the zensunnis to the original takeover by the machines.
Interestingly, the settling of the zensunnis on Dune shortly before the Jihad would be consistent: assuming the Bene Gesserit largely gained political power during or after the Jihad, this would be the time when they started their missionaria protectiva, and we know that the fremen culture was in its infancy then (or those seeds could not have been implanted).
Slashdot Mirror
I'm going to be a slight devil's advocate here, because I believe strongly in unit testing, but there is a significant amount of academic literature which demonstrates the falacies inherent in using tests to catch bugs.
Incidently, test driven design is concerned with demonstrating that the software can function as specified. It is not concerned with - and bad at picking up - software that performs those functions with side effects, or contains code which can be exploited in a security-sensitive context.
The simplest "proof" of the problem with testing is to consider a function with four arguments; let's say this is C, and two arguments are int while the others are char*. To rigerously exercise a single argument of this function, you need five to seven distinct tests: obviously good value, obviously bad value, inner- and outer-values for boundary conditions (may only apply to the int), and NULL. Unfortunately a black box function may have strange interactions between parameters which testing each individually cannot expose; a proper test set to ensure the function behaves correctly in all circumstances will require approximately 6 * 6 * 5 * 7 = 756 tests, being the permutation of all single-argument test cases.
No, I'm afraid this is not a suitable answer. Unit tests are best used for two purposes: testing that a function produces the correct and expected effect when used correctly; and testing that a function does not produce a bug that has already been discovered (i.e. regression testing).
For everything else, there's Mast^H^H^H^Hcode inspections. A code inspection (audit) will detect problems in the handling of parameters far more efficiently than building hundreds of tests. What is more, it will (when performed by an experienced developer) expose problems that tests cannot: tests are particularly bad at showing up race conditions, buffer overflows and other security risks.
I agree completely, although there should be no harm in having auditing available to new projects (project leaders just wouldn't consider it for the purposes of when to stablise and release).
Although I would like to contribute more to OSS development, I have very little time or opportunity. In a project of any maturity which has a well designed and documented code structure and is employing DBC (design by contract), it is very easy to audit a single function now and then. Coding the function is somewhat more time consuming - even with strict modularity it takes some time to understand the requirements and implement them.
I'm betting that there are many eyes out there willing to find the bugs, but not sufficient tools to track where the eyes are (and should be) looking.
I've made this suggestion several times before; what we really need in OpenSource development is a reliable and powerful code auditing controller.
While direction and design are problems experienced by a lot of OpenSource software, it is quality and security issues which are of more concern to mature projects, which have the highest visibility and widest use.
A code audit system would allow a project to be viewed as a graph of procedures/methods, and force every procedure to be marked as audited by a number (variable threshold) of auditers of a predetermined "skill level". i.e. the designers and core audit team together decide that certain procedures and modules are sensitive, and require an audit by three senior/trusted auditors; other less sensitive code requires only to junior auditors.
The system could track the auditing in conjunction with source code control, and use the software call graph to invalidate audits on procedures when dependancies are modified (and automatically marked as unaudited).
e.g. Procedure A calls procedures B and C. They are all marked as completely audited. Any change to Procedure C will necessarily invalidate the audit on C, and by relationship invalidate the audit on A. Once C is re-audited, the audit of A will still have to be performed again (unless, say, a special "interface not changed" flag is used on the re-audit of C).
In this way everyone can be happy that a project release is secure and reliable, based on the extent of the audited code.
I'm afraid I can't find the original source where I was reading about this, but the problem extends to the text, mainly because it is not the original text. Shakespeare is good example, because most modern publications are not true to the original works: oldde englishe wordes have been changed into modern equivalents, and phrases here and there have been updated to ones we can understand today.
You are correct in saying that the publishers copyright (in such cases) is over the modifications only; but it can be very difficult to determine which parts have or have not been modified. Typically, you need an old copy of the original work, which means you can't pick up a modern publication for your library or bookstore.
Copyright law is supposed to give incentive to create, for the betterment of society, and allow the creator to derive direct benefits as a reward. An artist who has created a work so successful that (s)he can live on it indefinitely has arguably provided a suitable level of betterment to society.
Saying that copyright law is an incentive to "work" is accepting mediocracy. Artists who produce works that society values more highly should (have the opportunity to) receive more benefits.
On the other hand, I don't necessarily agree that copyright should last the lifetime of the creator (although there are strong arguments for this in the case of a natural person). But what is a "fair" limit?
Is 5 years enough? Almost certainly not. Many authors only achieve popularity after 10 or more years, and then make a fair amount of money off increased sales of their older works. A good number accept this as a risk, and plan to use this phenomenon to their benefit - work up a good number of titles with varied content, and you'll pull more readers, who are then likely to try some of your other titles.
Is 20 years enough? Maybe. But some of our best-loved authors were 15-20 years ahead of their time in terms of what readers wanted.
Is life enough? Strangely, no. If an aging star has just completed his/her autobiography, concludes the publishing deal, and dies ... well, the family could well be screwed.
Maybe the answer lies in a compromise, rather than an all-or-nothing approach. Copyright over a work lasts for the greater of 10 years or the creator's natural life (which gets very interesting when we get eternal life medications ...). But some rights fall away after the LESSER of those two times, such as exclusivity over derivative works (but not translations).
This allows society to (culturally) enrich itself by building on a work after a shorter amount of time, while the creator (and/or family) can still derive value from the original work for a longer time.
In the case of books this is easily understood: author writes book; 10 years later other people can write preludes and sequals, extend the world and characters, etc; 30 years later author dies and original book falls into public domain.
Sorry, but this isn't strictly true. See my earlier post. Publishers tweak the text ("corrections" mostly) which give them copyright over their particular publication.
Sadly, copyright is an issue in this sort of work. Just because Dickens' works are no longer copyright, doesn't mean you can go and pull a Dickens novel off the library/bookstore shelf and OCR it. Publishers tend to be careful to make slight alterations to the text here and there (formatting, spelling, come clarifications and corrections) which turns a copyright-expired work into a derived work over which they own the copyright. Shitty, isn't it?
The syntax characters are not the same in all encodings. This is made completely clear by one of the appendices to the XML specification, which explains how a parser can determine the character encoding in use by examining the first four bytes of the file.
Since an XML document must start with <?xml, in UTF-8 the first four bytes will be <?xm . In UTF-16, however, the fist four bytes will contain BE or LE 16-bit encodings for just the first two characters <?, because each character uses at least 16-bits to encode. You can also determine UTF-32 encodings and others.
Encoding determines how to interpret the bits and bytes of the document into characters, and the control characters are not the same in all encodings. A parser that naively parses a document as ASCII will get the completely wrong idea if it is UTF-8 encoded, where there may be multiple bytes per character. A UTF-16 encoded document parsed as UTF-8 will be completely garbled.
Actually, I do. Like most sane people I understand that one unicode character encoding (EITHER UTF-8 OR UTF-16LE OR UTF-16BE OR UTF-32 OR on of the many others) is adequate. UTF-8 gives you a nice advantage of compatibility with the ASCII-7 character set, which means widespread support for text editing.
On the surface XML looks very simple. Balanced parenthesis expressions, as you say. Just under the surface it doubles its complexity: attributes are functionality equivalent to sub-expressions which have the limitation that they themselves can't have sub-expressions. This gives you two equivalent ways to represent information, which complicates the data model. It also makes it slightly more difficult to parse.
But when you get to the actual syntax, all hell breaks loose. A parser must understand UTF-8 and UTF-16 encoding (the latter in big endian or little endian format).
A parser must also parse not only the simple embedded parenthesis we know as XML, but also a DTD. Even if it cannot validate, it must parse the DTD in order to get past it and parse the rest of the document, in order to substitute entities, and in order to handle whitespace correctly.
Beyond the DTD and "basic XML syntax", it must handle special cases for comments, CDATA sections and processing instructions. All of these are effectively subgrammars - once you enter the section it has its own completely different rules for how its content is (or is not) parsed.
The parser must also detect and substitute entities, as specified in the DTD. The DTD also determines where whitespace is and is not significant, and therefore whether the parser must or should ignore whitespace, or must report it to the application (which is using the parser).
XML looks simple, and simple non-compliant XML parsers that parse simple XML are easy to write and in abundance. But XML, complete, is complex and tricky.
Umm, no. Brute forcing 1024-bit RSA is not O(2^1024), its closer to brute forcing 64-bit DES, which is O(2^56). Brute forcing simply involves an exhaustive search through the keyspace. It does NOT mean you have to do a full calculation and comparison with every possible value that can fit into a key representation.
e.g. RSA keys can only be prime, so you search for prime numbers of length 1024 bits rather than trying a RSA operation will all 1024 bit numbers. In addition, some techniques allow you to detect that a key cannot possibly give the desired solution before the entire calculation is completed, so you can do only partial calculations on some values.
Brute force means trying every key in the keyspace in turn. Just because the key is 109 bit doesn't mean the keyspace is. DES uses a 64 bit key, but 8 of those bits are parity, so the keyspace is only 56 bits. RSA uses a 1024 bit modulus, but only prime numbers can be used and the top bit is always set to ensure that the length is 1024 bits; the keyspace is nowhere near 2^1024!
You also have to factor in who is going to crack your key, and what they are prepared to throw at the problem. Moore's law is for commodity hardware - someone serious about cracking a key in a short time will use dedicated hardware.
Simple DES FPGAs can way outperform a P4 on DES operations, even running at 1/50 the speed. If it takes 10,000 computers 18 months to crack a key, it could take 50000 dedicated chips (which would be a lot cheaper!) under a month - even less depending on how much hardware can accelerate the calculations.
Plus 85 other rules. Yes, really - check the specification. There mere fact that it has attributes AND every tag can contain tags gives you two orthogonal and redundant data models. There are two character encodings, three character/data representations, four syntactically distinct data models ... and only about four parsers that can claim to be compliant or close to compliant with the specification. Yes, complex.
In BNF notation Java has 54 productions, C++ has 88, and XML has 89. Where Java and C++ only support a single character encoding according to their standards, XML requires support for at least 2, one of which must be supported in both endian encodings. Where LR(1) grammars define at design time the significance of whitespace, XML must parse a DTD at runtime to determine when whitespace is or is not significant. In XML arbitrary characters or data can be represented in at least two ways other than a raw character, and XML has built into it a substitution language - so its fair to compare its complexity to C++ and CPP.
XML is a complex and difficult to implement standard (as evidenced by the very few completed, compliant parsers that are available).
A clarification: yes, I do refer to licensing content rather than purchasing it. There is a distinction, and that is becoming more clear. When you purchase a CD you receive, in that purchase, the physical media containing the content, plus a license to use the content. Copyright law does not allow you to own the content unless you are the copyright holder - you can only use it according to a license granted to you by the copyright holder. With physical media we seldom distinguish between the purchase of the media and the purchase of the license, because the license is implicit.
Ah good, someone got in before me :) It is definatly a good idea to separate out the GUI part when dealing with cross-platform applications, since a lot of portability problems reside there.
In all honesty, I don't recommand Qt or wxWindows - they are great toolkits, but you lose out heavily on productivity compared to visual development environments with GUI builders. While both of these have associated builder tools, I don't consider them very mature of capable compared to VB or Delphi/C Builder. There is also a write-once-debug-and-tweak-everywhere concern (just getting wxWindows looking good on Windows and Solaris takes some effort).
Java is a great choice as it is supported on many platforms, has powerful GUI classes, a couple of builder products, and has several means for client/server support, including CORBA. But for UI applications it isn't hugely productive (strangely enough).
Some of your other options include ParaGUI and SDL, gTk, GraphApp, V, Mozilla's XPToolkit and XUL, and WideStudio.
I have grappled with exactly this question (legacy C/C++ needing to go cross platform with GUIs), and the best answer I've come up with so far is to keep your main code in C/C++ (since you have the legacy code AND the skills), define a clear UI abstraction layer, and create the UI in a scripting language such as Tcl or Python. Use SWIG to tie the script to native C functions.
I have more experience with Tcl/Tk, and believe it is more widely portable (especially the GUI consistency), but it is slower and arguably more difficult to program than Python. Still, this depends on what skills you can acquire, and what your UI requirements are.
Prechelt has an empirical comparison of some languages, including C/C++, Python, Tcl and Perl, and most importantly he has productivity figures! Keith Waclena has a Language Crisis page of comparisons, and Doug Bagley hosts the Great Computer Language Shootout. There are all invaluable resources for determining a balance between portability, functionality and productivity.
And this is precisely what I look for when I publish a document for public or customer consumption. I want the final image of the document locked down, unmodifiable, the way I intend it to be. No messing with the formatting, fonts, colours or anything else that I carefully put together to convey my message.
To too many people a document is just text. This is far from the truth. A document is a presentation, and says a lot about the person or organisation that prepared it. From technical notes to marketting, control over document format is a vital part of publishing.
And that is why PDF kicks the arse of other formats when it comes to this type of use.
Is there another service on offer to provide porn / windows service packs on demand, which cross-subsidises data traffic? No.
Voice calls subsidize data traffic. Decrease voice calls in favour of data traffic (i.e. VoIP) and you upset the balance; to rebalance the telco must increase the price of BOTH voice AND data traffic (or significantly increase only data traffic and reduce cross-subsidization).
An increase in the cost of data traffic hurts everyone. It is not just that some people are now using more data traffic than others, it is that the traffic costs more. Even voice users who have nothing to do with data traffic will be paying more.
You're right -- this ruling is protectionism. It protects the majority of consumers from a few who can abuse the system by getting services at a fraction of the cost, thereby increasing the cost to the majority.
Telecoms companies use a wide range of cross-subsidies to cover the costs of their international capacity. Fact: voice calls subsidize data. A telecom can reserve and sell a block of bandwidth for data at a fixed price with a higher return than it can reserve bandwidth for on-demand purposes, such as voice calls which are more common at particular hours of the day. During the rest of the time that bandwidth reservation is not realising its full value.
The more users move to VoIP, the more the telecom must rebalance the costs of its services, and data bandwidth will become more expensive. So now the ISPs are paying, and you are paying the ISP. But until your ISP starts charging you, specifically, the VoIP user, that price increase gets passed on to all data users.
A peering agreement is between peers. An ISP has a service agreement with a telco, and a peer agreement with other ISPs. Telcos have peering agreements with each other, sharing the costs of interconnecting equipment and negating some call costs in each direction.
Go and read up on freeloading, the tragedy of the commons and the Nash equilibrium, and the economics that pertain to it. Anything that can be used to bypass restrictions on a product or service to obtain another product or service which is usually more expensive can be treated as a partial form of freeloading. VoIP is no different.
All the comments I've seen about this are along the lines "this is bad for progress", "you can't step on my rights", or "there are easy technical workarounds". But noone has actually acknowledged that there is a sound economic reason for this action, which is being contemplated by many governments around the world.
Governments have a responsibility to provide basic services to their citizens. Communication is considered (by the UN and most governments) to be a basic service. Thus the sector needs regulation to prevent abuse by the providers and the consumers.
VoIP sounds like a wonderful idea: use more advanced technology to reduce the cost of calls, especially international calls, thereby improving value to the consumer.
Sadly, this is one side of the equation. Using/allowing VoIP means a select number of consumers who have access to VoIP equipment are able to make international calls at local call cost, while still using some (perhaps less than a conventional call) international bandwidth without really funding it.
In order to afford the international bandwidth, the telecom company must recoup the cost, and it can do this in one of three ways:
No matter how you look at it, VoIP is a specialised service with a usage pattern such that non-users are expected to subsidise the cost. This is grossly unfair to those users, which is precisely why telecoms companies are keen to prohibit the use of VoIP on their networks.
Until such time as ALL international calls can be VoIP (which basically means making all phones VoIP equipment), the ecnonomic concerns are going to be the same.
SMTP is the IM counterpart to SMTP. See "SEND", "SOML" and "SAML". If someone bothered to implement these, we'd have had a standardised IM network years ago.
Herbert places the Jihad 10,000 years before the first Dune novel, on several occasions. I'm afraid I don't have references here, but I can probably find them if you really want ;)
The Jihad was ancient history in the original Dune series, which led to the complacency of civilisation that necessitated Paul's terrible purpose. The stagnant empire needed to be forced to change again in order to survive the future.
While I agree that the Bene Gesserit could predate the Jihad, I don't believe the Guild does, for three reasons: (1) I'm fairly sure that Herbert places Holtzman at the time of the Jihad, and his theories led to the generators that can fold space; (2) Herbert's comments about the Jihad implied that several technologies, including fast space travel, occured subsequently to the Jihad; (3) There is no indication by Herbert that Dune played any part in the Jihad, so it was certainly not a focal point or critical resource, implying that there was no need to spice, i.e. no guild.
Frank Herbert made it clear in his novels that the animosity between Atreides and Harkonnan dates back to the time of the Jihad.
In our history there are many family lines/names that can be traced back thousands of years.
In a universe that has returned to a feudal system, family names are likely to become even more entrenched with time.
Herbert doesn't say this in as many words, but it is heavily implied in various places. The tripod that has dominated the political landscape of the empire arose out of the Butlerian Jihad. If I'm not mistaken the presence of Tio Holtzman during the Jihad was mentioned directly; which would mean space folding could not predate the Jihad.
Whether mentats came about before, during or after the Jihad is unclear - certainly they occured sometime after the machines took over. Herbert never hints that mentats had anything to do with the downfall of the machines though.
The only questionable parts (in my mind) are the simultaneous discovery of the spice and its effects; and the relationship of the zensunnis to the original takeover by the machines.
Interestingly, the settling of the zensunnis on Dune shortly before the Jihad would be consistent: assuming the Bene Gesserit largely gained political power during or after the Jihad, this would be the time when they started their missionaria protectiva, and we know that the fremen culture was in its infancy then (or those seeds could not have been implanted).