If you do dual-license your OSS, you just made it damn impossible for anyone to contribute back.
Not necessarily. You can just pay them for any of their code you want to integrate. Given that you are going to make money off of it (through the non-OSS license), it's only fair if you give the contributors their share, isn't it?
I don't see any way how you having a soal should keep hackers from hacking the prosthetics attached to your body. After all, the prosthetics are nothing but machines; we know that because we build them.
About the mind-wiping: The memory clearly is saved in the brain, not in the soul, or otherwise it could not be affected e.g. by drugs (unless the soul can be affected that way, too, but then the hackers could affect your soul as well). But even if the memory were stored in the soul, and could not be affected, it wouldn't really help you, because all it would mean is that you'd helplessly watch how someone else controls your body.
My intent was to give an example that would calculate (j+k)!/j! but I screwed up and the code actually calculates (j+k-1)!/j!. If j=1, you'll see that the code calculates k!.
No, I don't see that. I see that the code has undefined behaviour, and that what it actually will calculate may depend on the compiler, the optimization flags, the code around it, and whatever else may affet the generated code.
In the first example, the test occurs prior to entering the loop and the comparison is against k. With most compilers, the resulting assembly code (written as a generic assembly language) would be something akin to:
move i,#0
jump test loop:
multiply j,j,j
increment j test:
increment i
compare i,k
branch_if_less_than loop
The compiler may generate code like this. However, it might also generate something like this between loop: and test:
mov reg1, j increment j multiply j, reg1, j
which is equivalent to j*=j+1 Or something like this:
mov reg1, j increment j multiply j, reg1, reg1
which is equivalent to j*=j.
Note that in the latter case, the increment may even be completely optimized out, because its result is immediatly overwritten by the multiply result. Which means the result may just be
multiply j, j, j
BTW, note that your second and third loop are only equivalent if k>0. And looking at the generated assembly for gcc-4.2.0 (I used j*=j as the loop body, though) I see that the generated code for both loops indeed is identical except for an extra test for zero before entering the loop (that test is not part of the loop, but jumps over it). In other words, the performance difference between the second and third loop is likely negligible (I didn't make any measurements, though). Since the second form is more idiomatic and therefore more readable, this means you almost certainly should not use the third loop. Note that if the compiler could determine that k>0, the extra test/jump would likely be optimized out, giving the exact same code for loops 2 and 3.
However, I'd like optimizers to also optimize the first version to the second (after all, it shouldn't be hard to detect that i is never used outside of the loop control; and if both i and k are signed types, the compiler is allowed to assume k>=0, because otherwise you would overflow a signed int, which is undefined behaviour).
If you know assembly, you can much more easily understand the trade-offs between different, functionally identical, high level constructs. As a simple example, consider the follow three slighly contrived snippets of C code. In all three examples, k > 0:
for (i=0 ; i<k ; i++) j = j*(j++);
versus:
for (i=k ; i ; i--) j = j*(j++);
versus:
i = k ; do { j = j*(j++) ; i--; } while (i);
On most architectures, the first will generally be least efficient and the third will generally be most efficient (often by as much as 20%), why ?
Since all of them have undefined behaviour, it doesn't make sense to reason about their efficiency. Indeed, I'm curious as of what your code is intended to do. Should it be equivalent to j*=j? Or to j*=j+1?
Ok, but just looking at the question of doing something k times (ignoring the exact thing done in the loop), your question is easily answered: Because the optimizer obviously isn't yet good enough to determine that i isn't used except for counting loop iterations, and generating optimal code for that
Alternatively, you could argue that C isn't expressive enough: You should be able to say "do this k times" without caring how exactly this is done (expecting the most efficient code for the target platform).
Having said that, I do agree that knowing assembly language is useful. Especially for understanding what can or cannot be implemented efficiently.
If you have a good understanding of assembly language, you view high level languages differently. Instead of viewing high level languages as an abstract syntax, you view them in terms of how they translate to the underlying machine code. This actually makes it easier to learn new languages because you must more easily understand the rationale behind many choices that were made in defining the language.
To view them in terms of how they translate to the underlying machine code instead of thinking about it at a high abstraction level can be very dangerous, too. Because modern optimizers mean that your thinking model of what the assembly may look like can easily turn out wrong. A prime example for this are the strict aliasing rules of C. The trick is to know both views, and to know when to apply which.
Well, when they invented the acronym DVD, it indeed stood for Digital Video Disk. Then they changed it from "Video" to "Versatile" to emphasize that you can store more on it than just video. I somehow doubt that they would have used that name if there had not been the desire to keep the acronym the same.
A web server can be used to display the output from FireFox?
The X Server should be called "daemon" or "service", not "server"
Since a web server is not a display server, it cannot be used to display. Just as the file server cannot be used to print, and the print server cannot be used to store files.
Another way to view it is to see that there's typically far less servers than clients. There are few file servers (often just one) managing the files for many clients working with the files. There are a few (maybe just one) print servers managing the printers for many clients who want to print. And there's typically one display server per desktop computer managing the display for many client programs which want to use that display.
Well for everything other than X we use 'daemon' on *nix and 'service' on Windows so why not just stick with that?
While probably all servers are run as daemons, not every daemon is a server. For example, it makes sense to run an NTP client as daemon, so that you can automatically keep your computer's clock synchronised with a remote NTP server.
And no, I haven't yet heared of "web daemons", "NNTP daemons" or "IRC daemons".
What this does do is stop a random remote app getting to root on your workstation but any local exploit of the X server gets them your user account and that can cause a lot of mischief and only needs a different local root exploit to get the rest of the way to 0wn1ng your local desktop machine.
To your user account? I'd expect the non-root X server to usually run on its own user account.
Ok, so every time you start a new GUI program, you have to immediatly tell your local display client that you have started a new display server, whose services you want to see? Doesn't sound like an environment I'd like to work in (although I admit it would be more secure).
To make an example how this would look like:
Step 1: You start a display server program (e.g. firefox). Step 2: You ask your display client (the program managing the screen) to connect to the newly started display server (firefox). To do so, you would have to know how to connect to that program (e.g. firefox writes the port to use to stdout, and you tell your display manager to connect to this port). Only then the window appears, and you can start interacting with firefox.
At least in the setups I'm used to, no client program may be run on dedicated server machines (if that is what you mean with "server"). After all, you don't want e.g. to get all computers unusable because some program runs wild on the central file server. When running X client software remotely, it's on another "client" machine, that is, on another of those machines not restricted for a certain purpose. In many cases it's a machine which you could in principle go to and work direcly on it, but why bother if you can as well log in remotely.
Now the server is traditionally the side which manages the ressource, and the client is the side which uses the ressource. With a file server, the server is running on the computer with the files, and the clients are the programs running elsewhere. And with the X server, the server is running on the computer with the display (i.e. your computer), and the client may run elsewhere. Note that if your remote X program also accesses files from a file server, the client is again your program running on the remote computer (your local computer isn't involved at all in that case, unless it happens to be the file server).
If you are doing this you are basically stating that you trust that application as much as you trust the kernel, because if there are any exploitable bugs in it, you've just given all your users complete root access.
Actually, I think I've read somewhere that there's another barrier, so that even root cannot do everything the kernel can. Of course if you enabled loadable modules it's easy to get into the kernel once you are root.
Yes. Great minds know not to waste their mental abilities on something as unimportant as jokes. But making jokes is fun anyway, so they make stupid jokes. As a bonus, stupid jokes are usually understood also by stupid people. Which is a big advantage if those stupid people get mod points.
ASCII characters are also graphics. It's just a very restricted form of graphics. But roguelike games definitely depend on the graphic-aspect of the display (i.e. the relative position of different characters on the screen).
Having said that, there are games which don't need graphics: Text adventures. While they also write text as ASCII characters, that's not a necessary part of them. You could easily imagine the text being read to you through the speakers, and the commands given through speech recognition instead of the keyboard. Then you'd need absolutely no display device (you could switch your screen off).
They had to chance a code base from around 5+ years only because they didn't things right 5+ years ago. Remember, back then they were doing a complete code rewrite anyway.
And no, the true reason to do this is not multicore. That it also gets faster on multicore is just a nice side effect. The true reason to do it is stability. If one page makes problems, you don't lose all the others. This was indeed even more important back when browser and mail was the same program, because it meant that a page crashing your browser could destroy your almost-completed email, too (yes, this has happened to me, although I'm not sure if it was still old Netscape or already new Mozilla). Of course, today it's quite possible that your browser is your mail client again because you're using webmail.
Note that if it were just a performance thing, they could have gone multithreaded instead. This would probably get even better performance.
Slashdot Mirror
And he was successful: He got a Slashdot story.
Not necessarily. You can just pay them for any of their code you want to integrate. Given that you are going to make money off of it (through the non-OSS license), it's only fair if you give the contributors their share, isn't it?
I don't see any way how you having a soal should keep hackers from hacking the prosthetics attached to your body. After all, the prosthetics are nothing but machines; we know that because we build them.
About the mind-wiping: The memory clearly is saved in the brain, not in the soul, or otherwise it could not be affected e.g. by drugs (unless the soul can be affected that way, too, but then the hackers could affect your soul as well). But even if the memory were stored in the soul, and could not be affected, it wouldn't really help you, because all it would mean is that you'd helplessly watch how someone else controls your body.
So they finally found the duct tapes keeping together the original rockets? :-)
No, I don't see that. I see that the code has undefined behaviour, and that what it actually will calculate may depend on the compiler, the optimization flags, the code around it, and whatever else may affet the generated code.
The compiler may generate code like this. However, it might also generate something like this between loop: and test:
which is equivalent to j*=j+1
Or something like this:
which is equivalent to j*=j.
Note that in the latter case, the increment may even be completely optimized out, because its result is immediatly overwritten by the multiply result. Which means the result may just be
BTW, note that your second and third loop are only equivalent if k>0. And looking at the generated assembly for gcc-4.2.0 (I used j*=j as the loop body, though) I see that the generated code for both loops indeed is identical except for an extra test for zero before entering the loop (that test is not part of the loop, but jumps over it). In other words, the performance difference between the second and third loop is likely negligible (I didn't make any measurements, though). Since the second form is more idiomatic and therefore more readable, this means you almost certainly should not use the third loop. Note that if the compiler could determine that k>0, the extra test/jump would likely be optimized out, giving the exact same code for loops 2 and 3.
However, I'd like optimizers to also optimize the first version to the second (after all, it shouldn't be hard to detect that i is never used outside of the loop control; and if both i and k are signed types, the compiler is allowed to assume k>=0, because otherwise you would overflow a signed int, which is undefined behaviour).
It was not claimed that you curse more often in your dominant language. Neither directly, nor indirectly (as in "all bilinguals").
In other words, if you need more effective relief. Fits the speculation perfectly.
Since all of them have undefined behaviour, it doesn't make sense to reason about their efficiency. Indeed, I'm curious as of what your code is intended to do. Should it be equivalent to j*=j? Or to j*=j+1?
Ok, but just looking at the question of doing something k times (ignoring the exact thing done in the loop), your question is easily answered: Because the optimizer obviously isn't yet good enough to determine that i isn't used except for counting loop iterations, and generating optimal code for that
Alternatively, you could argue that C isn't expressive enough: You should be able to say "do this k times" without caring how exactly this is done (expecting the most efficient code for the target platform).
Having said that, I do agree that knowing assembly language is useful. Especially for understanding what can or cannot be implemented efficiently.
To view them in terms of how they translate to the underlying machine code instead of thinking about it at a high abstraction level can be very dangerous, too. Because modern optimizers mean that your thinking model of what the assembly may look like can easily turn out wrong. A prime example for this are the strict aliasing rules of C. The trick is to know both views, and to know when to apply which.
Wouldn't payed advertising for illegal stuff be illegal anyway? I'd be surprised if not. No need to invoke trademark protection, then.
Well, when they invented the acronym DVD, it indeed stood for Digital Video Disk. Then they changed it from "Video" to "Versatile" to emphasize that you can store more on it than just video.
I somehow doubt that they would have used that name if there had not been the desire to keep the acronym the same.
You mean: So there are reasonably reasonable reasons reasonably reasonable people do it.
Microsoft seems to have taken "cloud computing" a bit too literal.
Now I am confused!
A web server can be used to display the output from FireFox?
The X Server should be called "daemon" or "service", not "server"
Since a web server is not a display server, it cannot be used to display. Just as the file server cannot be used to print, and the print server cannot be used to store files.
Another way to view it is to see that there's typically far less servers than clients. There are few file servers (often just one) managing the files for many clients working with the files. There are a few (maybe just one) print servers managing the printers for many clients who want to print. And there's typically one display server per desktop computer managing the display for many client programs which want to use that display.
Well for everything other than X we use 'daemon' on *nix and 'service' on Windows so why not just stick with that?
While probably all servers are run as daemons, not every daemon is a server. For example, it makes sense to run an NTP client as daemon, so that you can automatically keep your computer's clock synchronised with a remote NTP server.
And no, I haven't yet heared of "web daemons", "NNTP daemons" or "IRC daemons".
To your user account? I'd expect the non-root X server to usually run on its own user account.
Ok, so every time you start a new GUI program, you have to immediatly tell your local display client that you have started a new display server, whose services you want to see? Doesn't sound like an environment I'd like to work in (although I admit it would be more secure).
To make an example how this would look like:
Step 1: You start a display server program (e.g. firefox).
Step 2: You ask your display client (the program managing the screen) to connect to the newly started display server (firefox). To do so, you would have to know how to connect to that program (e.g. firefox writes the port to use to stdout, and you tell your display manager to connect to this port).
Only then the window appears, and you can start interacting with firefox.
The client applications run on the server?
At least in the setups I'm used to, no client program may be run on dedicated server machines (if that is what you mean with "server"). After all, you don't want e.g. to get all computers unusable because some program runs wild on the central file server. When running X client software remotely, it's on another "client" machine, that is, on another of those machines not restricted for a certain purpose. In many cases it's a machine which you could in principle go to and work direcly on it, but why bother if you can as well log in remotely.
Now the server is traditionally the side which manages the ressource, and the client is the side which uses the ressource. With a file server, the server is running on the computer with the files, and the clients are the programs running elsewhere. And with the X server, the server is running on the computer with the display (i.e. your computer), and the client may run elsewhere. Note that if your remote X program also accesses files from a file server, the client is again your program running on the remote computer (your local computer isn't involved at all in that case, unless it happens to be the file server).
Actually, I think I've read somewhere that there's another barrier, so that even root cannot do everything the kernel can.
Of course if you enabled loadable modules it's easy to get into the kernel once you are root.
Just remember that you want to have a Controlled eXit, and you want to Control it Completely.
Yes. Great minds know not to waste their mental abilities on something as unimportant as jokes. But making jokes is fun anyway, so they make stupid jokes.
As a bonus, stupid jokes are usually understood also by stupid people. Which is a big advantage if those stupid people get mod points.
There, fixed that for you.
There, fixed that for you.
But won't your cat starve if it doesn't get a single mouse?
ASCII characters are also graphics. It's just a very restricted form of graphics. But roguelike games definitely depend on the graphic-aspect of the display (i.e. the relative position of different characters on the screen).
Having said that, there are games which don't need graphics: Text adventures. While they also write text as ASCII characters, that's not a necessary part of them. You could easily imagine the text being read to you through the speakers, and the commands given through speech recognition instead of the keyboard. Then you'd need absolutely no display device (you could switch your screen off).
They had to chance a code base from around 5+ years only because they didn't things right 5+ years ago. Remember, back then they were doing a complete code rewrite anyway.
And no, the true reason to do this is not multicore. That it also gets faster on multicore is just a nice side effect. The true reason to do it is stability. If one page makes problems, you don't lose all the others. This was indeed even more important back when browser and mail was the same program, because it meant that a page crashing your browser could destroy your almost-completed email, too (yes, this has happened to me, although I'm not sure if it was still old Netscape or already new Mozilla). Of course, today it's quite possible that your browser is your mail client again because you're using webmail.
Note that if it were just a performance thing, they could have gone multithreaded instead. This would probably get even better performance.
If you look at a shorter time period, you'll be shocked even more!
But currently, Apple seems to be better at marketing.