This is weak typing. A strongly typed language does not allow treating objects as instances of types if they aren't actually. C and C++ are of course statically typed, i.e. you have to declare types of variables, but that is something different.
Sorry, but I can't agree with that without further qualification.
The language I use most of the time is Common Lisp, which started as a compromise between several Lisp dialects that have evolved since the late 50ies, together with new functionality designed in the 90ies. This lead to standard function names ranging from cdr and rplacd to update-instance-for-redefined-class. While there are more or less consistent rules explaining either of these, I think they are all bad. The trick is to come up with names that are both unambigous and short. This is very hard (and the fact that ANSI CL defines nearly 1000 names, all on one package, doesn't help). In fact, I often have the feeling that coming up with good names for my functions, classes etc. is harder than their actual implementation. But it is also more important, because that is what others will have to use and understand, and communication between humans is a more serious issue in programming than communication with the computer.
Besides, any sensible IDE would allow you to search for an exact name or at least a regular expression, so that a search for "i" would not find all mentions of "update-instance-for-redefined-class".
Oh, interesting. I admit that I always took that a as a given, without actually knowing the details of either language. Do you happen to have a pointer to such research? Did it come up with other relationships, or does it just state that finnish and/or hungarian are weird in their very own way, different to all other languages known today?
If you need a tamper-resitant binary, don't use anything that can be executed natively by any known processor architecture either. Compiled code for the JVM might be slightly easier to understand than code compiled for the x86 arch, but there are good decompilers for both.
If a CPU can understand your code, so can a human. The solution to this problem are licenses, not obfuscators.
You are aware that hungarian and finnish are closely related languages, right? And that basically no other language is closely related to either of them? (IIRC, basque is, but its chances to become an official UNO language are pretty slim either)
Writing code and/or comments in finnish or hungarian would be the ultimate obfuscation technique. People who know english have a bigger chance to guess what words could mean if they were written in persian.
i is always an integer with local scope, used as a counter in a loop and/or an index into an array or a similar collection. j, k and l are the same, if you need more than one variable that would qualify for being "i". This convention is perfectly clear and has been used for more than 40 years; calling "i" "index", "count" or "currentEmployeeIndex" does not carry any interesting surplus information. The same could be said for "n", which always is an integral number denoting the number of elements in some collection to operate on.
tmp is less clear, but it certainly would have local scope, and only exists because of shortcomings in the implementation language (like not having a primitive operation for swapping the values of two variables without introducing a temporary variable), but no real significance in the problem domain.
These variable names are perfectly acceptable and clear - unless you abuse them, of course, but you can abuse all nameing schemes. Nothing stops you from calling a global integer m_pszHelloKitty.
Hungarian notation on the other hand is problematic because a) it is just a non-functional workaround for the weak typing in C and C++ (and their habit to make type errors crash your program in random unrelated places, or just corrupt your data) and b) there aren't actually enough rules, and if there were, nobody could remember them all. "iSomeInteger" and "sSomeString" are pretty common, but if you happen to use more interesting types, or even a whole C++ class hierarchy, it just doesn't work anymore. The only use of Hungarian Notation is to make clueless middle managers happy, similar to a long-winded format for mandatory comments preceding any trivial function or multi-page e-mail disclaimers. Source code is readable when you can actually read it out loud and people would understand whats going on, not if you encrypt redundant information in variable names.
Another relatively painless way to install lots of free software on Solaris is the NetBSD pkgsrc collection (what the other BSDs call "ports"). Like NetBSD itself, an important goal is portability, and in its case the result is that it is not actually NetBSD-specific and works on many other OSes, including Solaris.
The only drawback is that it doesn't integrate with the Solaris-native package management scheme, it uses its own database and utilities. It is also not a good idea to use it with the Sunfreeware GCC, one should use the pkgsrc version (after bootstrapping it with the one from sunfreeware)..
The current version of Solaris 9 already installs Gnome by default - it is not the "default desktop", but only because users have to choose it from a dropdown list in the login screen. I doubt that Sun will drop it again, after all the work they put in it.
IMHO, the Solaris Gnome is not too pretty. Some stuff doesn't work right, and integration with Solaris tools is not as good as it is in CDE. Of course, CDE is not the perfect desktop either, so the main advantage is that now you can choose the way in which you are annoyed. Then again, nobody expects Solaris to be OS X.
There are rumors that Sun might join forces with Fujitsu Siemens, i.e. closer collaboration of the UltraSparc and SPARC64 design teams. This would seem like a pretty smart move - if you make your processor arch publicly available, you might as well try to benefit from it. Two independent groups developing 64bit sparcs for servers is a little wastefull, and maintaining an alternative architecture is hard enough.
There is no privacy in todays internet. Even networks designed to protect privacy like freenet might miss something, making all you activities visible to everyone who cares enough, and normal P2P networks do not even bother. It is just not the way networking, and TCP/IP in particular, works
So that means you agree that the social problem of child molesters cannot be solved by the technical measure of regulation and censorship?
I think neither that censorship will solve it, nor do I think that it is a technical measure. A technical measure would be a filtering proxy using image recognition to block child porn for example; censorship as such is a legal term.
Well, this is actually a hard problem. If you want to technically guarantee anonymity to prevent censorship and violations of the right to free speech by technical means, there is no way to distinguish legitimate users from assholes. The software cannot do this, by definition.
The solution is, of course, easy. Accept that you cannot solve social problems by technical measures. Censorship and political oppresion are political problems, they will be solved by political changes or not at all. A P2P network might be a tool usefull for those working on these change, but it is neither sufficient on its own, nor is it really neccessary.
A single line would be too insignificant to be copyrightable at all. And if you would have contibuted more, you'd have to have signed the contributor license agreement, which is another thing worked into the ASL proper with version 2.0.
If you had contributed to a GNU project instead, you would have had to assign copyright to them in a written, dead-tree, snailmail letter (no other way to get a patch of more then 10 lines into Emacs, for example).
I think that the Open Source movement is approaching a crossroads where the failure to have reached a viable consensus over what a proper license should be will seriously impede the future of software synergy and integration that the OS world so desparately needs.
There are detailed descriptions, which are not too far apart from each other, of what it means to be Open Source or FreeSoftware.
While there are certainly more free/open source licenses than would be neccessary (and the OSI is at least trying to prevent this from getting worse, by not accepting new licenses if there isn't a convincing reason why no existing license can be used), there is that one big schism that cannot be resolved by license consolidation: Copyleft or not copyleft.
You will never make a GPL-user switch to a non-copyleft license, because he simply does not want proprietary software vendors to use his code. Likewise, you will never make a BSD-user switch to a copyleft license because they want anyone to be able touse their code for every purpose whatsoever, including proprietary software vendors. The fundamental reasons to hack on open-source code are just very different, and I think talking of both as one community is just plain wrong more often than not. (Of course, both camps are not a homogenous community of their own either.)
Because one of the reasons for developing the ASL 2.0 was to make it GPL compatible.
You are right, the situation has not become worse than it was. But it hasn't become as good as was expected either. The GNU project and the Apache Foundation are arguably the two most important FLOSS projects, and that interoperability between them keeps being hampered by incompatible licenses is just annoying, especially when it is only due to stupid legal details that are in principle non-critical to either party.
The obvious solution is to modify the GNU GPL, but the eyes of some this would amount to heresy of the highest order.
The FSF is actively working on GPL V.3, and issues like this one are among the reasons for it.
On the other hand, they really don't seem to be in a hurry with that. On one hand this is a good thing, because the GPL is important enough that it should rather be well thought out (remember that most GPL software is licensed under the GPL version 2 "or any later version"). Let's just hope that they don't take the Hurd as an inspiration for release scheduling.
Except for, as I pointed out elsewhere, the C libraries. (which seems to have a special exemption?)
They have. First of all, there is this sentence in clause 3 of the GPL:
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs
(The effects of this sentence are broader than it sounds)
Second, the C library is standardized and the API itself if obviously not under the GPL, only implementations like glibc can be. Any program using it (on most platforms, that is any program, period) would work just as well with any other implementation. This obviously means that source code using libc APIs is not to be considered a derived work of the glibc, and even dynamically linked binaries aren't. With statically linked executables it is more tricky, and nobody can tell for sure until a judge decides, but they are generally not considered derivative works in such cases by most people (and the GPL clause mentioned above would kick in anyway, there aren't many OSes that don't normally include a libc).
I just don't like the thought of someone taking my hard work and making money off of it- I want to reserve that privilege for myself, thank you.
In that case, no free software license will help you.
The GPL gives you more ways to restrict others from profiting from your work than permissive licenses (which is why it is preferred by most companies using a dual-license scheme), but then again, all commercial Linux distributors do exactly what you want to be done - they make money off of the hard work of the Linux, GNU and other GPL-using developers.
the apache licence will probably be compatable with the next version of the GPL
Probably, but it should be mentioned that GPL Version 3 is not likely to be released any time soon. There isn't even a draft or something, and you bet that the FSF will take the time it takes to develop it until all potential issues are resolved. There probably won't be a new version of the GPL this year, and I woundn't bet on next year either.
Exactly. Do a trivial change to make it a dervied work, problem solved. In the same way you can take a BSD program, do something to it, and release it as GPL (good) or closed source (very bad...).
Trivial changes are not copyrightable, so you have to spend a little more effort...:-)
I think this one will be resolved amicably, if not, Apache will be forked, which will upset more people than it should.
I can't see any reason why anyone would fork apache because of this. Nobody did before, and the new license is not in any way "worse" (from a GPL point of view), it is just not as much better in comparison with the old Apache licenses as was hoped.
Both version 2.0 and 1.1 of the Apache license are free software licenses according to the FSF, are (probably, not officially confirmed yet, but nobody raised any concern either) Open Source licenses in the OSI sense, are DFSG-free, etc.
Slashdot Mirror
The language I use most of the time is Common Lisp, which started as a compromise between several Lisp dialects that have evolved since the late 50ies, together with new functionality designed in the 90ies. This lead to standard function names ranging from cdr and rplacd to update-instance-for-redefined-class. While there are more or less consistent rules explaining either of these, I think they are all bad. The trick is to come up with names that are both unambigous and short. This is very hard (and the fact that ANSI CL defines nearly 1000 names, all on one package, doesn't help). In fact, I often have the feeling that coming up with good names for my functions, classes etc. is harder than their actual implementation. But it is also more important, because that is what others will have to use and understand, and communication between humans is a more serious issue in programming than communication with the computer.
Besides, any sensible IDE would allow you to search for an exact name or at least a regular expression, so that a search for "i" would not find all mentions of "update-instance-for-redefined-class".
Oh, interesting. I admit that I always took that a as a given, without actually knowing the details of either language. Do you happen to have a pointer to such research? Did it come up with other relationships, or does it just state that finnish and/or hungarian are weird in their very own way, different to all other languages known today?
If a CPU can understand your code, so can a human. The solution to this problem are licenses, not obfuscators.
Writing code and/or comments in finnish or hungarian would be the ultimate obfuscation technique. People who know english have a bigger chance to guess what words could mean if they were written in persian.
tmp is less clear, but it certainly would have local scope, and only exists because of shortcomings in the implementation language (like not having a primitive operation for swapping the values of two variables without introducing a temporary variable), but no real significance in the problem domain.
These variable names are perfectly acceptable and clear - unless you abuse them, of course, but you can abuse all nameing schemes. Nothing stops you from calling a global integer m_pszHelloKitty.
Hungarian notation on the other hand is problematic because a) it is just a non-functional workaround for the weak typing in C and C++ (and their habit to make type errors crash your program in random unrelated places, or just corrupt your data) and b) there aren't actually enough rules, and if there were, nobody could remember them all. "iSomeInteger" and "sSomeString" are pretty common, but if you happen to use more interesting types, or even a whole C++ class hierarchy, it just doesn't work anymore. The only use of Hungarian Notation is to make clueless middle managers happy, similar to a long-winded format for mandatory comments preceding any trivial function or multi-page e-mail disclaimers. Source code is readable when you can actually read it out loud and people would understand whats going on, not if you encrypt redundant information in variable names.
The only drawback is that it doesn't integrate with the Solaris-native package management scheme, it uses its own database and utilities. It is also not a good idea to use it with the Sunfreeware GCC, one should use the pkgsrc version (after bootstrapping it with the one from sunfreeware)..
IMHO, the Solaris Gnome is not too pretty. Some stuff doesn't work right, and integration with Solaris tools is not as good as it is in CDE. Of course, CDE is not the perfect desktop either, so the main advantage is that now you can choose the way in which you are annoyed. Then again, nobody expects Solaris to be OS X.
There are rumors that Sun might join forces with Fujitsu Siemens, i.e. closer collaboration of the UltraSparc and SPARC64 design teams. This would seem like a pretty smart move - if you make your processor arch publicly available, you might as well try to benefit from it. Two independent groups developing 64bit sparcs for servers is a little wastefull, and maintaining an alternative architecture is hard enough.
The internet is a public place. Act accordingly.
It is actually called "Y Windows", so we won't have pointless arguments about it really being called either "Y" or "The Y Window System".
The solution is, of course, easy. Accept that you cannot solve social problems by technical measures. Censorship and political oppresion are political problems, they will be solved by political changes or not at all. A P2P network might be a tool usefull for those working on these change, but it is neither sufficient on its own, nor is it really neccessary.
It is also about as fast as the web was with Netscape Gold and a 14.4 modem.
If you had contributed to a GNU project instead, you would have had to assign copyright to them in a written, dead-tree, snailmail letter (no other way to get a patch of more then 10 lines into Emacs, for example).
While there are certainly more free/open source licenses than would be neccessary (and the OSI is at least trying to prevent this from getting worse, by not accepting new licenses if there isn't a convincing reason why no existing license can be used), there is that one big schism that cannot be resolved by license consolidation: Copyleft or not copyleft.
You will never make a GPL-user switch to a non-copyleft license, because he simply does not want proprietary software vendors to use his code. Likewise, you will never make a BSD-user switch to a copyleft license because they want anyone to be able touse their code for every purpose whatsoever, including proprietary software vendors. The fundamental reasons to hack on open-source code are just very different, and I think talking of both as one community is just plain wrong more often than not. (Of course, both camps are not a homogenous community of their own either.)
You are right, the situation has not become worse than it was. But it hasn't become as good as was expected either. The GNU project and the Apache Foundation are arguably the two most important FLOSS projects, and that interoperability between them keeps being hampered by incompatible licenses is just annoying, especially when it is only due to stupid legal details that are in principle non-critical to either party.
On the other hand, they really don't seem to be in a hurry with that. On one hand this is a good thing, because the GPL is important enough that it should rather be well thought out (remember that most GPL software is licensed under the GPL version 2 "or any later version"). Let's just hope that they don't take the Hurd as an inspiration for release scheduling.
Second, the C library is standardized and the API itself if obviously not under the GPL, only implementations like glibc can be. Any program using it (on most platforms, that is any program, period) would work just as well with any other implementation. This obviously means that source code using libc APIs is not to be considered a derived work of the glibc, and even dynamically linked binaries aren't. With statically linked executables it is more tricky, and nobody can tell for sure until a judge decides, but they are generally not considered derivative works in such cases by most people (and the GPL clause mentioned above would kick in anyway, there aren't many OSes that don't normally include a libc).
The GPL gives you more ways to restrict others from profiting from your work than permissive licenses (which is why it is preferred by most companies using a dual-license scheme), but then again, all commercial Linux distributors do exactly what you want to be done - they make money off of the hard work of the Linux, GNU and other GPL-using developers.
Both version 2.0 and 1.1 of the Apache license are free software licenses according to the FSF, are (probably, not officially confirmed yet, but nobody raised any concern either) Open Source licenses in the OSI sense, are DFSG-free, etc.