Well, while that may be an urban legend, I personally have had very good experience with the practicallity of people from the former Soviet Union. Two specific example stand out.
When I dropped my Pentax ZX-50, a modern all electronic SLR, it stopped working. The first couple of places I took it to told me not to bother fixing it and just buy a new one. Finally, I took it to a camera store owned and operated by people from Russia. They not only fixed the specific thing that broke, they also cleaned it up and got it working as good as new.
And on a more day to day issue, the pull tabs on the zippers of my leather jacket fall off after a while. Most of the tailors I took it to wanted to replace the entire zipper and a hefty cost and keeping the jacket for at least two weeks. I know a Russian tailor who just replaces the pull tab at 1/10th the cost and in a day or two (one time when I was in a rush, he even fixed it on the spot).
I don't have a problem with secret investigations provided the law is not broken in order to carry it out. For example, if they wish to purchase the advertised service to check whether the claims about it are correct, I see no problem in doing that without informing the person who they are looking into. On the other hand, if they start doing phone or data taps, they had better get a warrant first.
And another question is what happens once the investigation is done. If punishment can be handed down with due process, then that is seriously troubling. But if after the investigation, an open court proceeding is still required, then I don't see this taking us down an Orwellian path.
One of my biggest problem with "reusable" code is that it truly isn't reusable. A lot of libraries out there were obviously ripped straight out of a some other project and the interface reflects that. You end up spending as much time jumping through hoops to call the library as you would to rewrite it. And plus in that case, the places where the code meets is hard to maintain.
If engineers really want their code to be reusable, they really need to spend some time thinking about the interface. What are the exact semantics of each call. When an error occurs, who is the caller or the library responsible for cleaning up any partially finished events. How will the caller provide data; if the caller has data in a different format, how hard is to convert.
Until people start really thinking about interface/API design, reusability will never come to be.
"In dollar terms, patching is the most expensive security measure and keeping your antivirus descriptions up to date is the least."
"If customers could do both it would eliminate the bulk of security problems."
That second sentence seems very oddly phrased. It makes is sound like they can't do both which is definitely not true. I get the feeling that this may be the beginning of some MS campaign to somehow tie Virus updates and patching into a single system. I'm not sure what the ramifications of such a system are, but my guess is that it will continue to tie people to MS products.
One thought that I have been bouncing around my head for quite some while is what differentiates scripting from programming. It seems like many people use whether the language is interpreted at runtime or executed by the hardware/VM to differentiate. I feel that this is not a good way to make the distinction.
My thought is that the issue isn't the language, but the "process model." The idea is that a program that does most of its work by invoking external executables is a script while a program that does most of its work by internals is not.
So, code that directly reads the underlying directory is a program while one that invokes "ls" is a script.
One of the things I like about this definition is that it fits the non-technical use of script as well. A script is a description of what the actors should do. If you consider the external excutables as actors, then this fits nicely.
An interesting side-effect of this is that a language itself is no longer a scripting or programming language. For example, if you have a C program that looks like:
then this is a script even though it is written in C.
That said, some languages will definitely promote scripting by automatically taking an unrecognized word and trying to invoke it as an external process (sh, csh, bash and sometimes tcl). But just because a language might be designed for one style or not, it is the program that matters.
OS X is no more a single OS than Linux is a single OS. Linux interoperates just fine with other Linux machines. Don't confuse the operating system with the applications.
And don't confuse the kernel with the operating system. All Linux systems share the same kernel but can vary quite a bit when it comes to the full operating system.
Where are files kept? How does init work? These issues are definitely part of the OS but are not defined by the kernel itself.
Yes, many computer products are hard to use, but in our corporate society, I don't understand why it is the developers who are getting the blame for that. Most software corporations strive to save money by doubling up on jobs and having people design the UI who are not skilled at it. Often it is the developers or marketing people, neither of who are trained in human interface skills.
Once senior management realize that they need skilled UI designers so that the end users don't get frustrated, then we will make progress. But as long as we live in a bottom-line society, we will continue to put out poortly designed software.
So, Microsoft only scans the files they expect to be part of the install but they ship all the files anyway. While there is no way from the outside to prove or disprove this statement, I think it's odd they aren't consistent in which files they choose to scan and which they choose to ship. A decent process would use a consistent way to manage it.
At a minimum, I find this an example of the sloppy techniques I see all over the industry. Of course, sloppiness is one of the reasons that all these viruses keep finding new ways to infect software so I think it's a pretty big slap in the face for MS's Trustworthy Computing program.
The problem with trying to pipe both input and output to an arbitrary slave process is that deadlock can occur, if both processes are waiting for not-yet-generated input at the same time. Deadlock can be avoided only by having BOTH sides follow a strict deadlock-free protocol, but since that requires cooperation from the processes it is inappropriate for a popen()-like library function.
This is not true if you are using a *nix that implements non-blocking I/O. If the master process makes sure to never block when communicating with the slave process, there is no reason that deadlock should occur.
One of my personal mantras when commenting is to make sure I am commenting on why I'm doing something instead of what I'm doing. The code will already show the what, so add something to that.
To illustrate this point, consider the following snippet of code:
// Add 7 to the line count
line += 7;
Yes, the comment told exactly what the code does, but what are we adding the number 7. Why is this value special? Is it somehow related to the number being prime?
So, if the comments are just reiteratring exactly what the code is saying, don't bother. Give the reason about why something is being done.
Is how they are trying to redefine the generic term "operating system." My guess is that Microsoft recently changed their OEM agreement to do exactly this, make you contractually obliged to to provide the MS OS you purchased with the computer to anyone you donate the computer to. Given my (admittedly limited) knowledge of contract law, that is well within there legal power to do.
But what I find so amusing is that they have worded their guide to imply that this contractual obligation is something that applies to all operating systems. I doubt that Linux or any of the BSDs have put such wording in there license.
So lets use this to our advantage. Burn a CD with your favorite free OS. Tell the school that this was the OS preinstalled on it (and cross your fingers behind your back so you have an out in court if they can prove you weren't telling the truth:-) and that not only can they use it on the computer you gave them, but they can legally use it on any x86 hardward they have.
Didn't they say this about Java and C++
on
Trouble Ahead for Java
·
· Score: 2, Insightful
It seems like we here this a lot. Now that we have language X, no one will program in language Y anymore. Time after time, this proves to be incorrect. There are many reasons to stay with an old language, even if a better one has come along. This includes finding programmers who have the requisite years of experience, the added development cost of doing multi-language development, programmer preference, etc.
C# will definitely become a major player in the field. Both due to the fact that it is a well reasonably well designed language (Anders Hejlsberg did a good job) and that Microsoft is going to put its weight behind it. But just because C# becomes big, doesn't mean that Java will disappear.
is find the code that implements the expiration system and remove or disable it.
Anyway, even if you could do that, how long do you make the current version last. There have been way too many times when code is released and within the next couple of days and major bug is found. Using a time based expiration system would simply not work.
There has been quite a bit of work into doing process migration. The idea is transmit the entire state of a process to another computer to continue execution there. If you instead of transmitting the state to another machine, you wrote it to a file, this would do exactly what you are interested in.
One bad experience I had with Logitech split keyboards was the placement of the 6 key. The last time I needed to buy a new keyboard, Logitech had two split keyboards on the market. One of them had the 6 on the left hand side while the other had the 6 on the right hand side. Unfortunately, I am used to 6 on the left hand side and the keyboard with the better tactile feeling had the 6 on the right hand side. I tried it for a week and it drove me crazy and I eventually returned it for something else.
Forking also gets a bad reputation because it leads to upfront confusion and worries about choosing the wrong version. If I choose to run a BSD system, which one should I choose, OpenBSD, NetBSD, FreeBSD, BSDi, etc. Perhaps at this point my requirements are flexible enough that any of them will do. Perhaps I get it down to two that fit my current needs, how do I choose? Do I flip a coin?
Then there is the worry about future use. I choose OpenBSD now because it best fits my needs. But six months down the line FreeBSD comes out with a feature that will help me but the OpenBSD people don't like it enough to incorporate it. I could switch but perhaps I still find that I need a feature of OpenBSD that FreeBSD doesn't support.
In my experience, this is a major reason that forking frustrates people so bad.
Slashdot Mirror
Well, while that may be an urban legend, I personally have had very good experience with the practicallity of people from the former Soviet Union. Two specific example stand out.
When I dropped my Pentax ZX-50, a modern all electronic SLR, it stopped working. The first couple of places I took it to told me not to bother fixing it and just buy a new one. Finally, I took it to a camera store owned and operated by people from Russia. They not only fixed the specific thing that broke, they also cleaned it up and got it working as good as new.
And on a more day to day issue, the pull tabs on the zippers of my leather jacket fall off after a while. Most of the tailors I took it to wanted to replace the entire zipper and a hefty cost and keeping the jacket for at least two weeks. I know a Russian tailor who just replaces the pull tab at 1/10th the cost and in a day or two (one time when I was in a rush, he even fixed it on the spot).
I don't have a problem with secret investigations provided the law is not broken in order to carry it out. For example, if they wish to purchase the advertised service to check whether the claims about it are correct, I see no problem in doing that without informing the person who they are looking into. On the other hand, if they start doing phone or data taps, they had better get a warrant first.
And another question is what happens once the investigation is done. If punishment can be handed down with due process, then that is seriously troubling. But if after the investigation, an open court proceeding is still required, then I don't see this taking us down an Orwellian path.
One of my biggest problem with "reusable" code is that it truly isn't reusable. A lot of libraries out there were obviously ripped straight out of a some other project and the interface reflects that. You end up spending as much time jumping through hoops to call the library as you would to rewrite it. And plus in that case, the places where the code meets is hard to maintain.
If engineers really want their code to be reusable, they really need to spend some time thinking about the interface. What are the exact semantics of each call. When an error occurs, who is the caller or the library responsible for cleaning up any partially finished events. How will the caller provide data; if the caller has data in a different format, how hard is to convert.
Until people start really thinking about interface/API design, reusability will never come to be.
"In dollar terms, patching is the most expensive security measure and keeping your antivirus descriptions up to date is the least."
"If customers could do both it would eliminate the bulk of security problems."
That second sentence seems very oddly phrased. It makes is sound like they can't do both which is definitely not true. I get the feeling that this may be the beginning of some MS campaign to somehow tie Virus updates and patching into a single system. I'm not sure what the ramifications of such a system are, but my guess is that it will continue to tie people to MS products.
One thought that I have been bouncing around my head for quite some while is what differentiates scripting from programming. It seems like many people use whether the language is interpreted at runtime or executed by the hardware/VM to differentiate. I feel that this is not a good way to make the distinction.
My thought is that the issue isn't the language, but the "process model." The idea is that a program that does most of its work by invoking external executables is a script while a program that does most of its work by internals is not.
So, code that directly reads the underlying directory is a program while one that invokes "ls" is a script.
One of the things I like about this definition is that it fits the non-technical use of script as well. A script is a description of what the actors should do. If you consider the external excutables as actors, then this fits nicely.
An interesting side-effect of this is that a language itself is no longer a scripting or programming language. For example, if you have a
C program that looks like:
main()
{
system("...");
system("...");
system("...");
return 0;
}
then this is a script even though it is written in C.
That said, some languages will definitely promote scripting by automatically taking an unrecognized word and trying to invoke it as an external process (sh, csh, bash and sometimes tcl). But just because a language might be designed for one style or not, it is the program that matters.
OS X is no more a single OS than Linux is a single OS. Linux interoperates just fine with other Linux machines. Don't confuse the operating system with the applications.
And don't confuse the kernel with the operating system. All Linux systems share the same kernel but can vary quite a bit when it comes to the full operating system.
Where are files kept? How does init work? These issues are definitely part of the OS but are not defined by the kernel itself.
Yes, many computer products are hard to use, but in our corporate society, I don't understand why it is the developers who are getting the blame for that. Most software corporations strive to save money by doubling up on jobs and having people design the UI who are not skilled at it. Often it is the developers or marketing people, neither of who are trained in human interface skills.
Once senior management realize that they need skilled UI designers so that the end users don't get frustrated, then we will make progress. But as long as we live in a bottom-line society, we will continue to put out poortly designed software.
So, Microsoft only scans the files they expect to be part of the install but they ship all the files anyway. While there is no way from the outside to prove or disprove this statement, I think it's odd they aren't consistent in which files they choose to scan and which they choose to ship. A decent process would use a consistent way to manage it.
At a minimum, I find this an example of the sloppy techniques I see all over the industry. Of course, sloppiness is one of the reasons that all these viruses keep finding new ways to infect software so I think it's a pretty big slap in the face for MS's Trustworthy Computing program.
The problem with trying to pipe both input and output to an arbitrary slave process is that deadlock can occur, if both processes are waiting for not-yet-generated input at the same time. Deadlock can be avoided only by having BOTH sides follow a strict deadlock-free protocol, but since that requires cooperation from the processes it is inappropriate for a popen()-like library function.
This is not true if you are using a *nix that implements non-blocking I/O. If the master process makes sure to never block when communicating with the slave process, there is no reason that deadlock should occur.
One of my personal mantras when commenting is to make sure I am commenting on why I'm doing something instead of what I'm doing. The code will already show the what, so add something to that.
To illustrate this point, consider the following snippet of code:
line += 7;
Yes, the comment told exactly what the code does, but what are we adding the number 7. Why is this value special? Is it somehow related to the number being prime?
So, if the comments are just reiteratring exactly what the code is saying, don't bother. Give the reason about why something is being done.
Is how they are trying to redefine the generic term "operating system." My guess is that Microsoft recently changed their OEM agreement to do exactly this, make you contractually obliged to to provide the MS OS you purchased with the computer to anyone you donate the computer to. Given my (admittedly limited) knowledge of contract law, that is well within there legal power to do.
:-) and that not only can they use it on the computer you gave them, but they can legally use it on any x86 hardward they have.
But what I find so amusing is that they have worded their guide to imply that this contractual obligation is something that applies to all operating systems. I doubt that Linux or any of the BSDs have put such wording in there license.
So lets use this to our advantage. Burn a CD with your favorite free OS. Tell the school that this was the OS preinstalled on it (and cross your fingers behind your back so you have an out in court if they can prove you weren't telling the truth
It seems like we here this a lot. Now that we have language X, no one will program in language Y anymore. Time after time, this proves to be incorrect. There are many reasons to stay with an old language, even if a better one has come along. This includes finding programmers who have the requisite years of experience, the added development cost of doing multi-language development, programmer preference, etc.
C# will definitely become a major player in the field. Both due to the fact that it is a well reasonably well designed language (Anders Hejlsberg did a good job) and that Microsoft is going to put its weight behind it. But just because C# becomes big, doesn't mean that Java will disappear.
is find the code that implements the expiration system and remove or disable it.
Anyway, even if you could do that, how long do you make the current version last. There have been way too many times when code is released and within the next couple of days and major bug is found. Using a time based expiration system would simply not work.
There has been quite a bit of work into doing process migration. The idea is transmit the entire state of a process to another computer to continue execution there. If you instead of transmitting the state to another machine, you wrote it to a file, this would do exactly what you are interested in.
One bad experience I had with Logitech split keyboards was the placement of the 6 key. The last time I needed to buy a new keyboard, Logitech had two split keyboards on the market. One of them had the 6 on the left hand side while the other had the 6 on the right hand side. Unfortunately, I am used to 6 on the left hand side and the keyboard with the better tactile feeling had the 6 on the right hand side. I tried it for a week and it drove me crazy and I eventually returned it for something else.
Forking also gets a bad reputation because it leads to upfront confusion and worries about choosing the wrong version. If I choose to run a BSD system, which one should I choose, OpenBSD, NetBSD, FreeBSD, BSDi, etc. Perhaps at this point my requirements are flexible enough that any of them will do. Perhaps I get it down to two that fit my current needs, how do I choose? Do I flip a coin? Then there is the worry about future use. I choose OpenBSD now because it best fits my needs. But six months down the line FreeBSD comes out with a feature that will help me but the OpenBSD people don't like it enough to incorporate it. I could switch but perhaps I still find that I need a feature of OpenBSD that FreeBSD doesn't support. In my experience, this is a major reason that forking frustrates people so bad.
Braces are not always the answer. Did the programmer forget to indent the second line in the block or did he put the line in the wrong place?
if (x == 4)
{
x = 10;
y = 6;
}