I could not agree more with your post. There was another quote that went something along the lines of: a cool language is one that teaches you something by learning it. I thought learning and using Haskell and Lisp were very useful for a different and complementary mindset that they help create. I think my C++ programs are higher quality because of my functional programming experience.
Languages like Java or Basic are not cool for me personally because they did not teach me anything. These languages are primarily designed to protect the computer from the programmer. I think the proliferation of buggy programs is due to languages like Java or Basic that make it easy for a person without the proper training to program. Engineers need to go through very rigerous tests to certify their expertise before they are allow to design and build a bridge. Why should programming be different?
Extreme gravity would not heat the core. The heat is from the formation of the object when material loses its potential energy as it collapses into the object.
There is no central energy source left once that collapse is complete and the object will start to cool at a rate related to its mass.
The object you are describing is a brown dwarf. A brown dwarf is a star that did not have enough mass to trigger nuclear reactions. Because of this, they are sometimes called failed stars.
Re:The correct pricing structure for most software
on
Pricing a Software Product
·
· Score: 2, Informative
At the risk of feeding a troll, the programming language doesn't matter. Bad coders will write bad code no matter what language they use.
I think the relevant thing here is that IBM have previously made the argument that SCO has already certified the Linux code with respect to their own IP by continuing to redistribute under the GPL long after it was first pointed out that they were doing it. This will make it difficult for SCO to successfully argue that its own code is improperly in the kernal.
If someone elses code is improperly in the kernel then both SCO and IBM are equally liable so the point is moot in regard to this case.
So does this mean that it IS possible to hijack the airtunes stream?
No. The key thing (pardon the pun) is that there are separate public and private keys. What he has done is isolate the public key (the one iTunes has) which would allow a separate program to send a stream to the AE just as iTunes does.
But to decrypt the stream coming from iTunes you would need to know the private key that is embedded in the AE.
An important part of public key encryption is that knowing the public key does not allow you to determine the private key easily. This is a one-way hack.
The strong encryption was not cracked. The implementation was cracked. No software-only based encryption is secure, period.
The audio stream is encrypted with AES. AES is a symmetric key encryption sceme which means that both sides need the same key. The key needs to change over time or the encryption scheme can be cracked.
This leaves the problem of how iTunes can tell the Airport the new key without everyone else listening and knowing the key also. Apple use RSA to secure the key transfer. RSA is a public key encryption system. This means there are two keys one public and one private. The private key is only known by the Airport. The public key is embedded in the iTunes software.
When iTunes wants to send a new AES key to the Airport it uses the RSA public key to encrypt the AES key. This encrypted message can only be decryped with the private key that the Airport has which means the system is secure even though everyone hears the new key in encrypted form.
The problem is that the RSA public key is embedded in the iTunes code. But that code needs to read in the key in order to use it and someone can reverse engineer this process to read the key themselves. This isn't necessaryily an easy thing to do but in a software only solution there is no way to stop it.
Again, I will have to disagree. An example about corporations is not relevent to
the end user experience. The issue is whether a typical user will be able to
change something they don't like. The reality is that most users will not due to
lack of the necessary skills and therefore the fact that they have access to the
source is moot.
The argument that anyone can pickup the project and continue it is also moot.
There are a large number of OSS projects that are variations on the same
program. This is because programmers often have a "not invented here" mentality
combined with the fact that building something from the ground up is just more
fun. It is also ignoring the fact that programs grow out of date very quickly
necessitating major changes that amount to rewriting the program (starting from
scratch with a new architecture). This can be for internal reasons or simply to
maintain compatibility with the latest version of your external dependencies
(kernel version, shared libraries, GUI environment, etc.)
And place this within the context of the larger argument the author is making.
Right now the OSS community is driven by the needs of developers and is making
it first steps in the direction of the needs of non-technical end users. To be
relevant in that world you cannot fall back on the pat retorts that he has
listed.
I think you are missing the point that it is "hardly anybody" simply because you need to have some programming knowledge to be in a position to fix things, What about normal end users? If OSS takes over as the defacto software, then developer's will be a tiny fraction of the overall number of users.
TV series have a different pacing than movies. Movies have to be more compressed
in time and are able to do much more elaborate and detailed scenes due to much
higher budgets.
My guess is that the movie will jump right into the main plot and introduce the
characters by showing them doing their thing. Joss has a gift for dialogue so I
bet he can sneak a lot of exposition into the action as they go.
My worry with the movie is studio oversight and stupid changes due to clueless
executives. I can see it now. 'We want Nathan to be more hunky have him ride
horses with no shirts.' or 'Wash should have more control switches, he is always
flicking that switch to his upper right.'
If you want to use Swing, then use it. I have programmed using both and I prefer SWT.
1. SWT is noticeably faster than Swing. When I use an interface I don't want to see any lag, when my development machine is much more powerful than the typical user machine.
2. SWT looks native. Users probably couldn't tell that it was written in Java. I have a pet peeve about applications that don't look consistent with everything else. If I have chosen a UI theme I don't want some applications ignoring my choice.
3. SWT consumes less memory.
4. SWT has a easier programming model.
Java the language is suited to any OS. Java the environment is in competition with the OS. The Java environment provides the features for your program which makes it much less important which OS the Java environment happens to be running on.
Java does have its performance issues but I don't think looking at the GUI is completely fair.
Most apps are written using a combination of AWT and Swing and these have embaressing performance. However if you look at an app written in SWT (the classes behind Eclipse) you could easily forget you are running a Java app at all. So, conventional Java apps have bad GUI performance because Sun did a poor job two times (AWT then Swing) in a row writing GUI classes.
Unfortunately most new Java developers aren't aware that there are much better alternatives for most of the standard SUN implemented classes.
Java Advanced Imaging (JAI) was supposed to be a showcase for Java. And it is implemented with Java, but they also ship platform specific implementations written in C if performance is remotely important.
Although I think 3D performance would be easier for Java to achieve as long as a suitable graphics card is present to do the heavy lifting.
Isn't that the point though. Scott Adams has observed that people inside most companies act in very disfunctional ways because most people *are* disfunctional.
The real problem is that we expect people to be more rational and logical just because they are at work and that is not a valid assumption.
I remember a television program (Scientific American Frontiers I think) that was showing this technique in action. The demonstration was for electronic business cards. You shake hands which connects the ciruit and the card info is exchanged.
Something I causally throw out from time to time is: You should not be a programmer if you cannot handle assembly code. This usually gets a negative reaction.
As languages have become higher level and easier to use, the effective bar has been lowered on who is able to write code. I once worked at a company that hired french majors to be programmers. The reasoning was that you can pick up script programming pretty quickly. But these people without a basic education in computer science wrote some of the worst code I have ever seen.
I think one reason that you see a lot of bugs in modern code is that a lot of the programmers should not be programmers. Assembly code forces you to actually understand how the machine functions. How are you going to write good code if you don't understand what the high level code you are writing actually does.
Little benchmark programs like this do not look at the two weakest areas in Java.
A large program will have bad performance until the garbage collector is tuned very carefully. My experience is running java server programs and we can get much improvement from careful tuning which is a iterative and time consuming process. But in no way are these systems close to the speed of raw C++ code. We routinely move bottleneck code to external C++ to improve performance.
Also the lack of destructors is a fundamental language flaw. In C++ it is a common pattern to allocate a resource in the constructor and free it in the destructor. Java can't do this and consequently serious resource leaks are very common in Java systems. Seasoned teams end up writing code that tracks every reference to a resource in order to make sure they are cleaned up.
Its possible that sometime in the future Java will narrow the performance gap with C++ for general applications but it won't be anytime soon.
Actually I think Gnome looks better. It's somehow more clean and streamlined. But no question, KDE is more integrated and powerful. I cannot decide between them myself so I run KDE on FreeBSD and Gnome on Gentoo...
I think the likely license will be different than your examples. One likely provision is that any version based on the code must pass the compatibility tests.
As a Java developer myself, I would be much more interested in viewing/modifying the libraries. Most of the Java bugs/performance problems I run into are in the library code. Right now, I'm left to guess what the problem might be to figure out a work around. With access to the code, that diagnostic process would be easier.
When I work on Visual C++ MFC and/or ATL projects the library source code is available to look at. This is an often overlooked case of Microsoft having open source components long before that was fashionable. I have never needed to actually modify that library code, but having access to it has made my programming life easier.
The setiathome client is not open to prevent tampering. In the early days of the project, it became a game to try to get the highest user statistics. People were installing on the best hardware possible to get good timings. Some people decided it was easier to cheat by just returning a bogus result set making it seem like they were processing very quickly.
Also, what is to stop someone (with very good intentions) to break the calculations that are being done and flood the seti database with bad/corrupted data?
To express every digital artwork as a number, the system used must be extremely expressive. This is exactly the Godel trap. Any system that is sufficiently expressive will be incomplete. If it is not sufficiently expressive it can't be used for every case anyway.
The important thing is not the data representation that you use. What matters is the system you use to encode an artwork to a data representation. In simple terms, Godel has proved that is isn't possible for you to encode every possible artwork. The system would always be incomplete.
Sure you could devise a formal system that allowed you to represent every piece or artwork or whatever, but unfortunately Gödel's Incompleteness Theorem proves that your system will be incomplete. (ie. there will be pieces of artwork that the system cannot describe)
Slashdot Mirror
I could not agree more with your post. There was another quote that went something along the lines of: a cool language is one that teaches you something by learning it. I thought learning and using Haskell and Lisp were very useful for a different and complementary mindset that they help create. I think my C++ programs are higher quality because of my functional programming experience.
Languages like Java or Basic are not cool for me personally because they did not teach me anything. These languages are primarily designed to protect the computer from the programmer. I think the proliferation of buggy programs is due to languages like Java or Basic that make it easy for a person without the proper training to program. Engineers need to go through very rigerous tests to certify their expertise before they are allow to design and build a bridge. Why should programming be different?
Extreme gravity would not heat the core. The heat is from the formation of the object when material loses its potential energy as it collapses into the object.
There is no central energy source left once that collapse is complete and the object will start to cool at a rate related to its mass.
The object you are describing is a brown dwarf. A brown dwarf is a star that did not have enough mass to trigger nuclear reactions. Because of this, they are sometimes called failed stars.
At the risk of feeding a troll, the programming language doesn't matter. Bad coders will write bad code no matter what language they use.
Infinity + 1 is still Infinity... (hey, we are all geeks here)
This decision isn't directly about copyrights. They have no said it is legal to download you favorite musician's mp3.
What they are saying is that if you do, you are the one breaking the law and not the authors of the software program that you use to download the mp3.
I think the relevant thing here is that IBM have previously made the argument that SCO has already certified the Linux code with respect to their own IP by continuing to redistribute under the GPL long after it was first pointed out that they were doing it. This will make it difficult for SCO to successfully argue that its own code is improperly in the kernal. If someone elses code is improperly in the kernel then both SCO and IBM are equally liable so the point is moot in regard to this case.
No. The key thing (pardon the pun) is that there are separate public and private keys. What he has done is isolate the public key (the one iTunes has) which would allow a separate program to send a stream to the AE just as iTunes does. But to decrypt the stream coming from iTunes you would need to know the private key that is embedded in the AE.
An important part of public key encryption is that knowing the public key does not allow you to determine the private key easily. This is a one-way hack.
The strong encryption was not cracked. The implementation was cracked. No software-only based encryption is secure, period. The audio stream is encrypted with AES. AES is a symmetric key encryption sceme which means that both sides need the same key. The key needs to change over time or the encryption scheme can be cracked.
This leaves the problem of how iTunes can tell the Airport the new key without everyone else listening and knowing the key also. Apple use RSA to secure the key transfer. RSA is a public key encryption system. This means there are two keys one public and one private. The private key is only known by the Airport. The public key is embedded in the iTunes software.
When iTunes wants to send a new AES key to the Airport it uses the RSA public key to encrypt the AES key. This encrypted message can only be decryped with the private key that the Airport has which means the system is secure even though everyone hears the new key in encrypted form.
The problem is that the RSA public key is embedded in the iTunes code. But that code needs to read in the key in order to use it and someone can reverse engineer this process to read the key themselves. This isn't necessaryily an easy thing to do but in a software only solution there is no way to stop it.
Again, I will have to disagree. An example about corporations is not relevent to the end user experience. The issue is whether a typical user will be able to change something they don't like. The reality is that most users will not due to lack of the necessary skills and therefore the fact that they have access to the source is moot.
The argument that anyone can pickup the project and continue it is also moot. There are a large number of OSS projects that are variations on the same program. This is because programmers often have a "not invented here" mentality combined with the fact that building something from the ground up is just more fun. It is also ignoring the fact that programs grow out of date very quickly necessitating major changes that amount to rewriting the program (starting from scratch with a new architecture). This can be for internal reasons or simply to maintain compatibility with the latest version of your external dependencies (kernel version, shared libraries, GUI environment, etc.)
And place this within the context of the larger argument the author is making. Right now the OSS community is driven by the needs of developers and is making it first steps in the direction of the needs of non-technical end users. To be relevant in that world you cannot fall back on the pat retorts that he has listed.
I think you are missing the point that it is "hardly anybody" simply because you need to have some programming knowledge to be in a position to fix things, What about normal end users? If OSS takes over as the defacto software, then developer's will be a tiny fraction of the overall number of users.
TV series have a different pacing than movies. Movies have to be more compressed in time and are able to do much more elaborate and detailed scenes due to much higher budgets.
My guess is that the movie will jump right into the main plot and introduce the characters by showing them doing their thing. Joss has a gift for dialogue so I bet he can sneak a lot of exposition into the action as they go.
My worry with the movie is studio oversight and stupid changes due to clueless executives. I can see it now. 'We want Nathan to be more hunky have him ride horses with no shirts.' or 'Wash should have more control switches, he is always flicking that switch to his upper right.'
If you want to use Swing, then use it. I have programmed using both and I prefer SWT.
1. SWT is noticeably faster than Swing. When I use an interface I don't want to see any lag, when my development machine is much more powerful than the typical user machine.
2. SWT looks native. Users probably couldn't tell that it was written in Java. I have a pet peeve about applications that don't look consistent with everything else. If I have chosen a UI theme I don't want some applications ignoring my choice.
3. SWT consumes less memory.
4. SWT has a easier programming model.
Java the language is suited to any OS. Java the environment is in competition with the OS. The Java environment provides the features for your program which makes it much less important which OS the Java environment happens to be running on.
The early Dalek episodes touched on some nice themes (runaway technology, weapons of mass destruction, meglomania, Davros!!).
But, I always preferred the episodes with the CyberMen. I can still remember how shocked I was when Adric died.
Java does have its performance issues but I don't think looking at the GUI is completely fair.
Most apps are written using a combination of AWT and Swing and these have embaressing performance. However if you look at an app written in SWT (the classes behind Eclipse) you could easily forget you are running a Java app at all. So, conventional Java apps have bad GUI performance because Sun did a poor job two times (AWT then Swing) in a row writing GUI classes.
Unfortunately most new Java developers aren't aware that there are much better alternatives for most of the standard SUN implemented classes.
Does anyone remember the record that was released with songs for all the popular games like Pac Man and Defender?
I would love to hear them again.
Java Advanced Imaging (JAI) was supposed to be a showcase for Java. And it is implemented with Java, but they also ship platform specific implementations written in C if performance is remotely important.
Although I think 3D performance would be easier for Java to achieve as long as a suitable graphics card is present to do the heavy lifting.
Isn't that the point though. Scott Adams has observed that people inside most companies act in very disfunctional ways because most people *are* disfunctional.
The real problem is that we expect people to be more rational and logical just because they are at work and that is not a valid assumption.
I remember a television program (Scientific American Frontiers I think) that was showing this technique in action. The demonstration was for electronic business cards. You shake hands which connects the ciruit and the card info is exchanged.
Or just turn autoplay off...
Something I causally throw out from time to time is: You should not be a programmer if you cannot handle assembly code. This usually gets a negative reaction.
As languages have become higher level and easier to use, the effective bar has been lowered on who is able to write code. I once worked at a company that hired french majors to be programmers. The reasoning was that you can pick up script programming pretty quickly. But these people without a basic education in computer science wrote some of the worst code I have ever seen.
I think one reason that you see a lot of bugs in modern code is that a lot of the programmers should not be programmers. Assembly code forces you to actually understand how the machine functions. How are you going to write good code if you don't understand what the high level code you are writing actually does.
Little benchmark programs like this do not look at the two weakest areas in Java.
A large program will have bad performance until the garbage collector is tuned very carefully. My experience is running java server programs and we can get much improvement from careful tuning which is a iterative and time consuming process. But in no way are these systems close to the speed of raw C++ code. We routinely move bottleneck code to external C++ to improve performance.
Also the lack of destructors is a fundamental language flaw. In C++ it is a common pattern to allocate a resource in the constructor and free it in the destructor. Java can't do this and consequently serious resource leaks are very common in Java systems. Seasoned teams end up writing code that tracks every reference to a resource in order to make sure they are cleaned up.
Its possible that sometime in the future Java will narrow the performance gap with C++ for general applications but it won't be anytime soon.
Actually I think Gnome looks better. It's somehow more clean and streamlined. But no question, KDE is more integrated and powerful. I cannot decide between them myself so I run KDE on FreeBSD and Gnome on Gentoo...
I think the likely license will be different than your examples. One likely provision is that any version based on the code must pass the compatibility tests.
As a Java developer myself, I would be much more interested in viewing/modifying the libraries. Most of the Java bugs/performance problems I run into are in the library code. Right now, I'm left to guess what the problem might be to figure out a work around. With access to the code, that diagnostic process would be easier.
When I work on Visual C++ MFC and/or ATL projects the library source code is available to look at. This is an often overlooked case of Microsoft having open source components long before that was fashionable. I have never needed to actually modify that library code, but having access to it has made my programming life easier.
The setiathome client is not open to prevent tampering. In the early days of the project, it became a game to try to get the highest user statistics. People were installing on the best hardware possible to get good timings. Some people decided it was easier to cheat by just returning a bogus result set making it seem like they were processing very quickly.
Also, what is to stop someone (with very good intentions) to break the calculations that are being done and flood the seti database with bad/corrupted data?
To express every digital artwork as a number, the system used must be extremely expressive. This is exactly the Godel trap. Any system that is sufficiently expressive will be incomplete. If it is not sufficiently expressive it can't be used for every case anyway.
The important thing is not the data representation that you use. What matters is the system you use to encode an artwork to a data representation. In simple terms, Godel has proved that is isn't possible for you to encode every possible artwork. The system would always be incomplete.
Sure you could devise a formal system that allowed you to represent every piece or artwork or whatever, but unfortunately Gödel's Incompleteness Theorem proves that your system will be incomplete. (ie. there will be pieces of artwork that the system cannot describe)