Unless you were frozen in th 50s, that comment can only be explained as a joke... if there is something of which there is plenty, that's window managers...
So what is the difference then between the Win7 distros? Because you seem to be saying there is none... as nothing will depend on something being present on one of them which is not present on the others.
Well, since the number of distros is used as an argument to explain the failure of linux in the desktop (I do believe that is simply a stupid argument, but, well...) then Win7 is doomed...
The idea is to be able to render to different media and under different circumstances (a braille reader, a text-to-speech browser, printed pages, small-screens, large screens, etc) and letting the client control rendering (just as you can choose the text font or size on any sensible browser, you can modify pretty much anything---see, for example, the user.css file in firefox)
That is why the whole thing is set up so as to be able to separate presentation from context, and why HTML deprecated the FONT tag, for example.
I have a better chance that LaTeX source code will compile properly in a Windows version of LaTeX than I have of HTML render properly across browsers, if the reports of people massaging HTML to work in Internet Explorer are correct.
HTML is easier for computers to parse than LaTeX is.
I have no idea what your point is.
Every latex file should result in the same output in all architectures: the whole system is designed with extraordinary care to guarantee that (assuming absence of bugs and proper font metrics). On the other hand, your expectation that HTML be rendered the same in different browsers is only born out of your ignorance of the what HTML wants to be: no one ever designed it in order to render in the same way everywhere, and in fact, it is designed with great care in order to allow it to be rendered differently.
On the other hand, HTML is easier to parse by design (and XHTML more so). In order to parse LaTeX you have to implement TeX itself, for it is not possible to "parse" LaTeX without actually executing it: "easy to parse" and LaTeX are simply not twothings that can be done at the same time.
No standard offers any guarantees that implementations will meet the spec.
HTML (and its ancillary technologies, like CSS, various scripting languages, etc) are designed to degrade gracefully. Most importantly, it was never the intention of the HTML spec to have HTML documents be rendered the same in different browsers, and, in fact, it is designed very, very carefully to allow documents to be rendered differently.
Well, ask with everything, you need to know what you are doing. Configuring a printer to default to A3 is not exactly rocket science using CUPS, for example...
So you can only contemplate two options: making a constant mess out of every single situation in the world, or retreating into the status of a hermit who throws stones at passers-by?
I don't know about the current one, but I can think of very few things related *less* to the Enlightenment movement that the last few US governments...
It is unhelpful to a lot of people, probably. But writing software to follow the particularly idiotic US law in this regard ends up being unhelpful for way more people. Reflect on the fact that the whole US population is, in a global perspective, only a very loud minority...
Maybe you should do something about whatever the cause for the constance fsck'ing is. You do realize it is quite abnormal to have a system have errors at each remount, don't you?
Even if you decide not to allow separate compilation (so that you can make decisions having *all* the relevant code available at compile time) doing this for C is very, very, very difficult.
One thing( I could never wrap my head around( is that functional languages consider that functions have no side effect.) Which is all fine( for mathematics), but in the real world( everything has a side effect: printf( is a side effect).
This only shows you are ignorant about the way purely functional languages deal with "the real world"...
Do buy a textbook on, say, Haskell. Read it. Play with the thing a bit. Then start to comment about things.
C (and even assembly) can't realize that the same inputs to a routine always cause the same output
I think the volatile keyword means an external agent can modify the contents of a variable, and if you don't specify volatile, no such agent can. So for all the non-volatile stuff, the compiler can perform the same static analysis that a Java/C# compiler does to decide whether a function has your specified behavior or not.
And if you're not happy with it, in GCC you can annotate your functions. Wrap the annotation in a portable macro (that does, say, nothing on non-gcc compilers) and Bob's your uncle.
The fact that you replied talking about volatile means either that you have no idea what you are replyting to, or that you completely missed the point.
Same input to a routine SOMETIMES cause the same output.
Well, the fact thatyoucan most of the time tell wheter a function ALWAYS causes the same output upon the same input is what makes functional languages orders of magnitude simpler to optimze...
Well, they do measure the outcome of having doing those changes, and have kept them because things have improved. I guess there are granmas in Norway, too, so it musthave not been as bad as you seem to think for them.
Sometimes a little danger can make things a little safer. I once heard of a study that showed some poorly painted and poorly lit roads had an increased accident rate when lighting was added and the yellow lines were re-painted.
That is actively done in Norway: there are some streats where they purposely remove all markings, even the separation between the street and the sidewalk.
memcpy_s's buffer size argument should be used for the actual size of the destination buffer. It shouldn't be variable based on user input / program flow, and can likely be determined at compile time.
Slashdot Mirror
Unless you were frozen in th 50s, that comment can only be explained as a joke... if there is something of which there is plenty, that's window managers...
Ironically though, SSH access to the box still typically works...
That is not ironic: it is good design...
So what is the difference then between the Win7 distros? Because you seem to be saying there is none... as nothing will depend on something being present on one of them which is not present on the others.
Well, since the number of distros is used as an argument to explain the failure of linux in the desktop (I do believe that is simply a stupid argument, but, well...) then Win7 is doomed...
It doesn't?
The idea is to be able to render to different media and under different circumstances (a braille reader, a text-to-speech browser, printed pages, small-screens, large screens, etc) and letting the client control rendering (just as you can choose the text font or size on any sensible browser, you can modify pretty much anything---see, for example, the user.css file in firefox)
That is why the whole thing is set up so as to be able to separate presentation from context, and why HTML deprecated the FONT tag, for example.
I have a better chance that LaTeX source code will compile properly in a Windows version of LaTeX than I have of HTML render properly across browsers, if the reports of people massaging HTML to work in Internet Explorer are correct.
HTML is easier for computers to parse than LaTeX is.
I have no idea what your point is.
Every latex file should result in the same output in all architectures: the whole system is designed with extraordinary care to guarantee that (assuming absence of bugs and proper font metrics). On the other hand, your expectation that HTML be rendered the same in different browsers is only born out of your ignorance of the what HTML wants to be: no one ever designed it in order to render in the same way everywhere, and in fact, it is designed with great care in order to allow it to be rendered differently.
On the other hand, HTML is easier to parse by design (and XHTML more so). In order to parse LaTeX you have to implement TeX itself, for it is not possible to "parse" LaTeX without actually executing it: "easy to parse" and LaTeX are simply not twothings that can be done at the same time.
No standard offers any guarantees that implementations will meet the spec.
HTML (and its ancillary technologies, like CSS, various scripting languages, etc) are designed to degrade gracefully. Most importantly, it was never the intention of the HTML spec to have HTML documents be rendered the same in different browsers, and, in fact, it is designed very, very carefully to allow documents to be rendered differently.
But that is by design: there is no expectation that HTML will be rendered the same on different browsers, as it is stated in the spec itself.
(La)TeX has a rather different set of requirements...
Well, ask with everything, you need to know what you are doing. Configuring a printer to default to A3 is not exactly rocket science using CUPS, for example...
For idle sessions, what you want is a sensible OS, lots of swap space and apps which do not tick a lot.
The ideology is simply unimportant in the grand scheme of things.
That is false both in this context and in all contexts.
So you can only contemplate two options: making a constant mess out of every single situation in the world, or retreating into the status of a hermit who throws stones at passers-by?
I don't know about the current one, but I can think of very few things related *less* to the Enlightenment movement that the last few US governments...
I am sure the FFmpeg people are taking into account the amount of money they are making from their US users when deciding things...
It is unhelpful to a lot of people, probably. But writing software to follow the particularly idiotic US law in this regard ends up being unhelpful for way more people. Reflect on the fact that the whole US population is, in a global perspective, only a very loud minority...
Maybe you should do something about whatever the cause for the constance fsck'ing is. You do realize it is quite abnormal to have a system have errors at each remount, don't you?
Even if you decide not to allow separate compilation (so that you can make decisions having *all* the relevant code available at compile time) doing this for C is very, very, very difficult.
One thing( I could never wrap my head around( is that functional languages consider that functions have no side effect.) Which is all fine( for mathematics), but in the real world( everything has a side effect: printf( is a side effect).
This only shows you are ignorant about the way purely functional languages deal with "the real world"...
Do buy a textbook on, say, Haskell. Read it. Play with the thing a bit. Then start to comment about things.
C (and even assembly) can't realize that the same inputs to a routine always cause the same output
I think the volatile keyword means an external agent can modify the contents of a variable, and if you don't specify volatile, no such agent can. So for all the non-volatile stuff, the compiler can perform the same static analysis that a Java/C# compiler does to decide whether a function has your specified behavior or not.
And if you're not happy with it, in GCC you can annotate your functions. Wrap the annotation in a portable macro (that does, say, nothing on non-gcc compilers) and Bob's your uncle.
The fact that you replied talking about volatile means either that you have no idea what you are replyting to, or that you completely missed the point.
Same input to a routine SOMETIMES cause the same output.
Well, the fact thatyoucan most of the time tell wheter a function ALWAYS causes the same output upon the same input is what makes functional languages orders of magnitude simpler to optimze...
Well, they do measure the outcome of having doing those changes, and have kept them because things have improved. I guess there are granmas in Norway, too, so it musthave not been as bad as you seem to think for them.
Sometimes a little danger can make things a little safer. I once heard of a study that showed some poorly painted and poorly lit roads had an increased accident rate when lighting was added and the yellow lines were re-painted.
That is actively done in Norway: there are some streats where they purposely remove all markings, even the separation between the street and the sidewalk.
memcpy_s's buffer size argument should be used for the actual size of the destination buffer. It shouldn't be variable based on user input / program flow, and can likely be determined at compile time.
No, it cannot.
Methinks someone has a sad story to tell...