"they are only going through the candy shell to grab a little chocolate."
I don't see any problem with that. Chocolate tastes extremely well. Make sure to get the dark chocolate M&Ms. They are hard to find, but taste much better than the milk chocolate M&Ms.
If enough people stay alive in machines, then they can do all the thinking needed in the world. Talk about cheap and abundant labor. Supplemented with mechanized machines doing all the labor, then that means all people alive won't have to do anything.
So, people alive will either be unemployed and miserable, or puppets of the machinized brains, or will the people alive be the ones in control?
Who will have the power in such a society?
Will there be a 'war' like in that 'terminator' movie, but then where the 'machines' are really people who have downloaded themselves into machines? Or a 'matrix' where the matrix is controlled by and also inhabited by people without bodies?
> "Linux is what Linus Torvalds makes, and that is available on kernel.org."
"That is one meaning of the word, if you feel that is the only meaning you are a moron."
There is nothing ambiguous about the word "Linux" in the context of operating systems. Linux Torvalds is the person who owns the Linux trademark. He makes Linux and everybody who respects the GPL can use Linux. For a small fee, companies like RedHat can license the use of the word "Linux" to use in the name of their product. When they do so, that does not mean that their product is the same thing as Linux. Torvalds allows them to name their product such as to indicate a relationship to Linux, to show the world that the product is based on Linux. I will say it once more: That does not mean that the product and Linux are the same thing.
A Linux distribution is a software distribution that includes Linux, but also includes a lot of other software, such as the GNU C compiler, SUN's OpenOffice.org, etc. Linux does not include a C compiler, nor an office suite, but "Red Hat Linux" and "Suse Linux" do.
Back to your original post about dumping to disk, "Linux does it" is not correct, while "Some Linux distributions do it" would be correct.
Thanks for calling names, now I can ignore you. If you get it, congratulations, and if you choose to remain misinformed, good luck to you. Or just be mad at me, whatever. Goodbye.
Linux is what Linus Torvalds makes, and that is available on kernel.org.
RedHat is not a synonym for Linux. RedHat is a commercial company that uses Linux, RedHat does not control Linux, RedHat does not own Linux. Linux and RedHat are not the same thing. If RedHat does something, that doesn't mean Linux does it. What is so hard to understand about that?
If I make a Linux program that burps when then kernel oopses or crashes, does that then mean that it can be said that "Linux" burps when it crashes. No it doesn't, and since RedHat is not the same thing as Linux, neither does it dump to disk on crash.
So, while RedHat may be capable of doing it if you install a nonstandard RedHat tool for it, simlarly I'm sure there is the windows equivalent in shareware form with nag screen and $20 registration for the full version, or maybe there even is a developer tool for it hidden deep inside MSDN CDROMs.
But Linux does not save anything to disk when it encounters a kernel oops. Tell me which files on http://www.kernel.org/pub/linux/kernel/v2.6 contain the code and you have a point.
Actually, that may be true, especially since it's been many years since I last needed to use a goto.
The expected errors you list should never occur in speed-critical points, so the cost of throwing the exception doesn't matter (the cost of checking an exception is never more than that of checking any condition, such as an if()).
You may want to try putting your resources in classes, and let the destructors do the cleanups automatically as soon as you go out of context. imho, that is the c++ way (in plain C, it's not so clear though...).
I agree: Exceptions should be used as exceptions, not something that get caught 'like crazy'. Checks for common cases should not be done with exceptions.
Compiler perform many optimizations to loops, many of which will not be performed when a goto statement is possible, because the goto statement makes it difficult for the compiler to know which optimizations will result in a speedup without breaking the code.
If you often have code that needs to do 'cleanups' _and_ needs to check many sequential possible error conditions, such that a couple of "if(!failed) {}" sets make your function unreadable, you should probably consider splitting your function and/or rethink your resource allocations. Put all resources in an object of its own, and the compiler will clean them up for you when it goes out of context, just make a class where the destructor cleans things up, and instantiate the object in your function. Then you don't need nester if()'s, no exceptions, and more importantly, no goto's...
But then again, early returns are semi-evil too. But at least not as evil as a nest of goto's.
There are a million ways to make spaghetti, however a function hall has the advantage of giving the function a name (which should be descriptive), and the advantage of limiting the scope of operation to the arguments that are passed to it, plus the member vaiabled (if not declared const).
A simple run of a little tool like 'calltree' will show the relationships between functions, while gotos get no help from that camp.
When well done, using functions, even when called only once, is a good idea. Using gotos, imho, cannot be done well.
Dude, look up "throw()" and "try {} catch()", they don't need all that bloat you're talking about.
If you're throw()-ing an exception in the same context, to a catch() in the same function, you'll likely see a 'goto' in the assembly output of your compiler.
Local variables, when not placed in registers can be allocated on a stack, even in a basic block inside of a function, hence the goto can jump into another stack frame because many of them can exist inside of a single method.
btw: An expected error? What?
You're probably using goto's where you should be using a simple if().
In C++, you have exceptions: "throw()" and "try {} catch()" to do that without the ugly goto's and with information carryover (why did the exception happen) and with much better implicit protection, such as little things like object destruction when they go out of context.
Goto's to jump out of nested loops are not a good idea for another totally different reason: the compiler will not be able to optimize the code as well.
Because goto's are like roaches. You see one, there are bound to be many others. You kill one, and hundreds come to bury it.
'goto code' tends to turn in to the same well-organized structure as a plate of spaghetti.
And besides that, your code documentation becomes much harder to make/read, your tools (profiling, tracing, formal verification, etc) become much less effective, etc.
If you've maintained code that had gotos and was made by others, you probably know what I'm talking about.
There are some, but very rare occasions where using a goto is the best way to code something. Use them extremely sparingly.
Copyright protection does not exclude patent protection.
Why can the same algorithm be patentable when it's laid out in transistors, but not patentable if it's stored on the memory chip that is used as a program for a processor, which also is laid out in transistors.
When you say hardware is a thing and software is a free expression of ideas, then given that a patent covers an 'invention', that would make software be patentable if the ideas expressed in them are sufficiently novel and nonobvious to be an invention. As for hardware designs, the design may contain ideas good enough to be an invention, but the mass-production of the touchable hardware that is done from the design files does not contain any inventions to produce the end result.
The problem with patents is not that patents are granted on things that 'ought to be unpatentable', but that patents are granted on (simple) ideas or discoveries, while they should be granted only on actual inventions. The way to fix it is to teach people (both the uspto people and patent applicants) the difference between an invention and an idea, and the difference between an invention and a discovery.
My point is that patentability is not defined by whether or not it's performed in hardware or software, both are equally (non) patentable. If it's an invention for a function of a device, it is patentable. Software eventually results in a (sub)function of a device, hence is patentable.
If things written in a design file can not be patented, and the production of the silicon chip, pcb, sub-assembly, or such hardware is a straight-forward assembly-line type process. Then what is the invention that happens after creation of the design files that warrants a patent for the end product, but not for the design files?
Besides that, many pieces of hardware these days are just dead sand and plastic without the software that it comes with. How can dead sand and plastic be patentable?
Slashdot Mirror
Thanks to google images, this picture.
I see three things on top of that. Now which is the connexion antenna?
"they are only going through the candy shell to grab a little chocolate."
I don't see any problem with that. Chocolate tastes extremely well. Make sure to get the dark chocolate M&Ms. They are hard to find, but taste much better than the milk chocolate M&Ms.
I'm pressing ctrl-alt-del and nothing happens. Then again, I don't remember hiring a task manager.
Imagine a beowulf cluster of low quality web sites.
Freaky, that's what it is:
If enough people stay alive in machines, then they can do all the thinking needed in the world. Talk about cheap and abundant labor. Supplemented with mechanized machines doing all the labor, then that means all people alive won't have to do anything.
So, people alive will either be unemployed and miserable, or puppets of the machinized brains, or will the people alive be the ones in control?
Who will have the power in such a society?
Will there be a 'war' like in that 'terminator' movie, but then where the 'machines' are really people who have downloaded themselves into machines? Or a 'matrix' where the matrix is controlled by and also inhabited by people without bodies?
Hmm.
Exactly. It won't be exactly you. It will be a fork of you.
We both know we're not going to agree on this, and you probably have better things to do too.
Cheers.
> "Linux is what Linus Torvalds makes, and that is available on kernel.org."
"That is one meaning of the word, if you feel that is the only meaning you are a moron."
There is nothing ambiguous about the word "Linux" in the context of operating systems. Linux Torvalds is the person who owns the Linux trademark. He makes Linux and everybody who respects the GPL can use Linux. For a small fee, companies like RedHat can license the use of the word "Linux" to use in the name of their product. When they do so, that does not mean that their product is the same thing as Linux. Torvalds allows them to name their product such as to indicate a relationship to Linux, to show the world that the product is based on Linux. I will say it once more: That does not mean that the product and Linux are the same thing.
A Linux distribution is a software distribution that includes Linux, but also includes a lot of other software, such as the GNU C compiler, SUN's OpenOffice.org, etc. Linux does not include a C compiler, nor an office suite, but "Red Hat Linux" and "Suse Linux" do.
Back to your original post about dumping to disk, "Linux does it" is not correct, while "Some Linux distributions do it" would be correct.
Thanks for calling names, now I can ignore you. If you get it, congratulations, and if you choose to remain misinformed, good luck to you. Or just be mad at me, whatever. Goodbye.
Linux is what Linus Torvalds makes, and that is available on kernel.org.
RedHat is not a synonym for Linux. RedHat is a commercial company that uses Linux, RedHat does not control Linux, RedHat does not own Linux. Linux and RedHat are not the same thing. If RedHat does something, that doesn't mean Linux does it. What is so hard to understand about that?
You've got a point.
Even "Kramer", in his tv show "Mad Money" on CNBC played the death-march for FM-radio last week...
If I make a Linux program that burps when then kernel oopses or crashes, does that then mean that it can be said that "Linux" burps when it crashes. No it doesn't, and since RedHat is not the same thing as Linux, neither does it dump to disk on crash.
So, while RedHat may be capable of doing it if you install a nonstandard RedHat tool for it, simlarly I'm sure there is the windows equivalent in shareware form with nag screen and $20 registration for the full version, or maybe there even is a developer tool for it hidden deep inside MSDN CDROMs.
But Linux does not save anything to disk when it encounters a kernel oops. Tell me which files on http://www.kernel.org/pub/linux/kernel/v2.6 contain the code and you have a point.
"Linux does it"
No it doesn't.
'Remember, the "nest" of gotos always goes down, and they all hit the same point. And the name of the label is (almost always) the same.'
Sounds survivable, as long as it stays like that, and the jumps never cross, and it doesn't turn into a 'ladder' of jumps.
Either way, I haven't needed goto's in years.
"Compilers handle this correctly."
Actually, that may be true, especially since it's been many years since I last needed to use a goto.
The expected errors you list should never occur in speed-critical points, so the cost of throwing the exception doesn't matter (the cost of checking an exception is never more than that of checking any condition, such as an if()).
You may want to try putting your resources in classes, and let the destructors do the cleanups automatically as soon as you go out of context. imho, that is the c++ way (in plain C, it's not so clear though...).
I agree: Exceptions should be used as exceptions, not something that get caught 'like crazy'. Checks for common cases should not be done with exceptions.
Compiler perform many optimizations to loops, many of which will not be performed when a goto statement is possible, because the goto statement makes it difficult for the compiler to know which optimizations will result in a speedup without breaking the code.
If you often have code that needs to do 'cleanups' _and_ needs to check many sequential possible error conditions, such that a couple of "if(!failed) {}" sets make your function unreadable, you should probably consider splitting your function and/or rethink your resource allocations. Put all resources in an object of its own, and the compiler will clean them up for you when it goes out of context, just make a class where the destructor cleans things up, and instantiate the object in your function. Then you don't need nester if()'s, no exceptions, and more importantly, no goto's...
But then again, early returns are semi-evil too. But at least not as evil as a nest of goto's.
There are a million ways to make spaghetti, however a function hall has the advantage of giving the function a name (which should be descriptive), and the advantage of limiting the scope of operation to the arguments that are passed to it, plus the member vaiabled (if not declared const).
A simple run of a little tool like 'calltree' will show the relationships between functions, while gotos get no help from that camp.
When well done, using functions, even when called only once, is a good idea. Using gotos, imho, cannot be done well.
Dude, look up "throw()" and "try {} catch()", they don't need all that bloat you're talking about.
If you're throw()-ing an exception in the same context, to a catch() in the same function, you'll likely see a 'goto' in the assembly output of your compiler.
Local variables, when not placed in registers can be allocated on a stack, even in a basic block inside of a function, hence the goto can jump into another stack frame because many of them can exist inside of a single method.
btw: An expected error? What?
You're probably using goto's where you should be using a simple if().
In C++, you have exceptions: "throw()" and "try {} catch()" to do that without the ugly goto's and with information carryover (why did the exception happen) and with much better implicit protection, such as little things like object destruction when they go out of context.
Goto's to jump out of nested loops are not a good idea for another totally different reason: the compiler will not be able to optimize the code as well.
Because goto's are like roaches. You see one, there are bound to be many others. You kill one, and hundreds come to bury it.
'goto code' tends to turn in to the same well-organized structure as a plate of spaghetti.
And besides that, your code documentation becomes much harder to make/read, your tools (profiling, tracing, formal verification, etc) become much less effective, etc.
If you've maintained code that had gotos and was made by others, you probably know what I'm talking about.
There are some, but very rare occasions where using a goto is the best way to code something. Use them extremely sparingly.
I wasn't talking about the masks, creation of which is only a small step in the mass-production of the ICs.
But, whatever. I'm fed up now.
Copyright protection does not exclude patent protection.
Why can the same algorithm be patentable when it's laid out in transistors, but not patentable if it's stored on the memory chip that is used as a program for a processor, which also is laid out in transistors.
When you say hardware is a thing and software is a free expression of ideas, then given that a patent covers an 'invention', that would make software be patentable if the ideas expressed in them are sufficiently novel and nonobvious to be an invention. As for hardware designs, the design may contain ideas good enough to be an invention, but the mass-production of the touchable hardware that is done from the design files does not contain any inventions to produce the end result.
The problem with patents is not that patents are granted on things that 'ought to be unpatentable', but that patents are granted on (simple) ideas or discoveries, while they should be granted only on actual inventions. The way to fix it is to teach people (both the uspto people and patent applicants) the difference between an invention and an idea, and the difference between an invention and a discovery.
My point is that patentability is not defined by whether or not it's performed in hardware or software, both are equally (non) patentable. If it's an invention for a function of a device, it is patentable. Software eventually results in a (sub)function of a device, hence is patentable.
If things written in a design file can not be patented, and the production of the silicon chip, pcb, sub-assembly, or such hardware is a straight-forward assembly-line type process. Then what is the invention that happens after creation of the design files that warrants a patent for the end product, but not for the design files?
Besides that, many pieces of hardware these days are just dead sand and plastic without the software that it comes with. How can dead sand and plastic be patentable?
How are the electronic design files of a hardware component any different than software?
So, if software shouldn't be patentable, why should any part of the design of a hardware component be?
Actually, also put those jacks in the bacthroom. Together with a Toto Washlet, you will enjoy the bathroom evenso more.
I should have seen the 'should' in that sentence...
I think we agree. Undo that last posting...