Since there is no authority on english (no central government body who issues standards of the language, like some eueopean groups), the only authority is common usage. Dictionaries attempt to document standard usage, and do not prescribe. As a result, the common usage of the word "acronym" to describe contracted all-first-initial terms, such as TCP/IP is correct by virtue of it being the common accepted usage.
Certainly the term "initialism" may be useful in contexts where it is important to distinguish between such terms that are pronounced like words versus those that are not. In other contexts, "acronym" is clearly the more reasonble term because it is accepted in english and it will be more readily understood.
However, in practice all hotspot does is compiles the most-used regions to native code, minimizing the cost of the compilation and maximizing the benefit.
Yes, I understand there are theoretical advantages to native code. However, I don't believe any such optimizations are actually available for use.
The faster-than-C++ cases I've seen have nearly always been compile time optimizations that had to do with numerical programming, where the limitation for C++ is the pointers. This is a limitation for C++, but not for native code. The equivalent fortran, for example, will run faster.
Not really. Win32 is fairly well abstracted away. Even Microsoft know win32 is dangerous and must die.
Let's start with
Dirwatcher class uses win32 glob expressions which aren't defined anywhere.
You can't have daemons, but rather 'services'?
File handle semantics are straight out of win32 to the point where there's a hair-brained handler-daemon in Mono which breaks unix PID semantics (which makes the services junk more annoying), which also defeats cross-version mono interaction.
All of these are caused by win32 semantics bleed. I could dig up a lot more if i had to.
Certainly calling Sun names for being closed while they are making serious noise about opening Java seems ill timed from a tact perspective. However, NFS was never usefully open sourced. It was a well-specified protocol that was reimplemented by everyone. The historical Sun was generally not a creator of open code, but did believe in open interfaces as a tactical market weapon.
They may be changing their stripes, but the deliberate GPL incompatibility of the CDDL makes me wary. I'll believe it when I see it.
Java on the server runs as fast, and occasionaly faster than native code.
I would like to hear some justification as to how java can run faster than native code, where native code is specified (as here) in a general sense. That is, do not tell me how some java code can run faster than some native code, since it's obvious you could create pathological native code to run arbitrarily slow.
I have not talked with you since 1997 or so. Mini-Impulse hoo-boy!
On topic, however, it seems you've missed the last 8 years or so of Java on Linux. The reason Java was generally not distributed as part of the various Linux distributions for so many years, is that Sun did not make it legally permissable for them to do so.
There are some additional issues like Linux folks wanting to be able to provide security and bug fixes as appropriate for such a core component. The failure of Sun to make Java truly Open Source prevents these issues from being able to be addressed. These and other problems with closed software, both ideological and practical mean that many distributions will not ship Java directly with their core distribution until it is Open Source.
So, it is a big improvement, if you care about using Java on Linux, or if you care about Java getting adopted. If you don't care about these things, then I suppose it doesn't matter.
C# may just be a language, but much of the.Net library (I forget the official terms) is really just a paper-thin wrapper over win32. This means that writing C# on other platforms you are stuck catering to a wide variety of win32 idiom bleeds. This means that writing a C# runtime for other platforms, you stuck reimplementing significant numbers of Microsoft DLLs. I'm not clever enough to know if any of this leaves anyone exposed to potential legal issues, but it certainly sucks from a use and technical perspective.
This whole situations puts a big fly in the ointment of the ECMA specification, in that much of the language behavior in effect is outside the specification and in the win32 API and in some cases the implementation. Certainly you are free to create a C# implementation which is 100% compliant with the published specification. I don't know if there are issues like with Java where the compliance test is kept hidden. Aside from that, however, your 100% specification compliant implemention may not be capable of running code which was written to Microsoft's implementation, nor code which was written to the specification, due to the missing dark corners.
As for my personal opinion, C# avoids many of the medium to small grain mistakes in Java, while maintaining (for better and for worse) a more C++/C developer friendly set of syntax and idioms. On the very large scale, however, it repeats the same list of glaring productivity problems that plague C, C++, and Java: too verbose, too inflexible, too unproductive.
As for patents, I don't think it's FUD to say that there are potential patent issues, certainly it is not FUD to consider that it is quite likely that there are submarine patents which would affect C#. This situation applies to any software system of reasonable complexity. It might be FUD to claim that it specially affects C# and C# implementations more than other complex software systems.
The answer, which is explicitly given in the referenced article by the article (two clicks, not one), is that commercial calculators operate with three digits of precision greater than those that they display, so that for operations which are available on the calculator, the imprecision is hidden. Typically calculators will display ten digits, but calculate using 13.
It's worse than that. In some kinds of calculations, the error can be so large that the result is entirely meaningless. That is, for example when doing a subtraction between two nearly equal floating point values, both of which were approximated, the result may have more noise than signal. This isn't the usual case, but when writing general code that cares about precise values, you can code yourself a beartrap that only springs in rare circumstances.
I disagree. I think the biggest reason for 64bit is that the 64 bit x86 arch variant just happens to be quite a lot faster, for reasons somewhat unrelated to its 64 bitness (larger number of registers, mostly). Of course this _only_ applies to x86-64, and not powerpc, alpha, sparc, etc, which all had more reasonable arches all along, but it is the most significant user-visible change at this time for any 64 bit upgrade.
As a 32 year old who as attended far too many loud concerts, I can hear that crap loud and clear and it's annoying. Please don't follow the hype and engage super annoying ringtones, okay?
Real remains poor. Helix is open source, but it is half a program. Software even capable of handling the enclosure formats (not the codecs) of openly specified formats is not included in the free software component of the player. In reality, Helix Player is an open toolkit one could use to build a player, but the total functional player is a proprietary program.
This sort of half-truth, a supposedly open player that does not work, is the kind of shady thing I would expect, and still do expect from Real.
Well, I live across the bay from you in Oakland, and do not drive. My encounters with the constabulary are generally of the opposite relationship. The police are already doing something completely unreasonable when I encounter them.
I could be "nice" and "polite", but that's never going to encourage the police to say, stop raiding people's yards, threatening them in the process on scheduled 2AM "manhunts". In short, I go out of my way to let the police know that their actions are unreasonable. I do not harass or challenge them, I just let them know that their actions have crossed into unreasonable territory.
For example, one time I was bicycling home at 11 from a party. The police had set up a barricade with a helicopter circling overhead. There was no activity. I asked what was going on, since this was my neighborhood, and not one that usually has any significant amount of crime. I was told there was "a bad man". Thanks for keeping me well informed of the real situation in my neighborhood. Then they refused to let me bicycle in either of the the two directions that would get closer to my apartment, encircling me and using intimindating behavior.
They said that I would be going close to the "armed bad man".
I said "This man is not attempting to intimidate me, and all of you are. There is apparently only one of him, so he is far less threatening. Further, I doubt he will care about a random bicyclist going home. You scare me far more."
After this I was compelled to bicycle home a very long route which passed just as close to the "crime scene" but took 2 extra miles.
You just changed the scenario. Your original example included spaces, numbers, alphas, the hyphen, the period, and a comma. These are all legal FAT characters. I was curious what kind of an error this produced for you.
Your response is an error that is for a filename including alpha, question mark, apostrophe/single quote, backslashes (unsure here), and most importantly, a colon. Colons are not FAT-legal characters on DOS (and derivatives), so you get an error.
It's possible to mount fat filesystems in such a way as to allow linux to store colons, and other characters, in filenames but as you point out this would make DOS (and derivatives) unhappy, and so the default is to disallow them. So yes, your new scenario will fail, but your original scenario should succeed. However, I am no longer as interested in the problem encountered.
No unix ever has or ever will support the use of the forward slash '/' character in filenames.
The slash character represents a directory separation in strings which are known as paths. Programs are fully expected and _must_ interpret these strings themselves in userspace in order to resolve them as a chain of directory names and a filename. Because it is required that programs interpret these strings, the slash character must represent a separation, and therefore may not be used inside a filename. This is a fundamental part of the UNIX api, and allowing slashes in filenames would require rewriting the way that programs refer to and describe paths, invalidating the majority of existing unix software.
There are no escape characters used in paths as encountered by programs, and a good thing too because that would just make it more complicated and introduce bugs.
Both IFF files containing ILBM chunks (image chunks) and 8svx chunks (sound chunks) were IFF files with internal metadata describing their contents. You could have both types in one file if you liked or had a reason for it.
I am specifically commenting on your failure to clarify that you were, in that original post, using the term "religion" significantly differently than the norm. Then everyone blithely continued to argue back and forth without ever clarifying.
- fully documented
- dependable
- much better performance
It's not a big list, but those are some important items. That said, I'm not sure Windows could work on NTFS. No streams, different metadata, inodes. I don't know if you can reasonably glue all the needed windows semantics on ext3.
As usual, tabbers emptily claim their behavior is considerate, when it is not.
I can definitely reindent (spaces or tabs), your entire document if I wish to review it differently, but alignment and subtleties will be broken. However, if I receive a tab-indented document I will have no idea how to displaying to view the intended alignment.
Slashdot Mirror
In my version of english "national rollouts" would suggest rollouts on a national scale, not that all rollouts would be limited to a single nation.
Since there is no authority on english (no central government body who issues standards of the language, like some eueopean groups), the only authority is common usage. Dictionaries attempt to document standard usage, and do not prescribe. As a result, the common usage of the word "acronym" to describe contracted all-first-initial terms, such as TCP/IP is correct by virtue of it being the common accepted usage.
Certainly the term "initialism" may be useful in contexts where it is important to distinguish between such terms that are pronounced like words versus those that are not. In other contexts, "acronym" is clearly the more reasonble term because it is accepted in english and it will be more readily understood.
I meant "Yes, I understand there are theoretical advantages to dynamic execution."
However, in practice all hotspot does is compiles the most-used regions to native code, minimizing the cost of the compilation and maximizing the benefit.
Yes, I understand there are theoretical advantages to native code. However, I don't believe any such optimizations are actually available for use.
The faster-than-C++ cases I've seen have nearly always been compile time optimizations that had to do with numerical programming, where the limitation for C++ is the pointers. This is a limitation for C++, but not for native code. The equivalent fortran, for example, will run faster.
Let's start with
All of these are caused by win32 semantics bleed. I could dig up a lot more if i had to.
Certainly calling Sun names for being closed while they are making serious noise about opening Java seems ill timed from a tact perspective. However, NFS was never usefully open sourced. It was a well-specified protocol that was reimplemented by everyone. The historical Sun was generally not a creator of open code, but did believe in open interfaces as a tactical market weapon.
They may be changing their stripes, but the deliberate GPL incompatibility of the CDDL makes me wary. I'll believe it when I see it.
I would like to hear some justification as to how java can run faster than native code, where native code is specified (as here) in a general sense. That is, do not tell me how some java code can run faster than some native code, since it's obvious you could create pathological native code to run arbitrarily slow.
Hello Moby Disk,
I have not talked with you since 1997 or so. Mini-Impulse hoo-boy!
On topic, however, it seems you've missed the last 8 years or so of Java on Linux. The reason Java was generally not distributed as part of the various Linux distributions for so many years, is that Sun did not make it legally permissable for them to do so.
There are some additional issues like Linux folks wanting to be able to provide security and bug fixes as appropriate for such a core component. The failure of Sun to make Java truly Open Source prevents these issues from being able to be addressed. These and other problems with closed software, both ideological and practical mean that many distributions will not ship Java directly with their core distribution until it is Open Source.
So, it is a big improvement, if you care about using Java on Linux, or if you care about Java getting adopted. If you don't care about these things, then I suppose it doesn't matter.
C# may just be a language, but much of the .Net library (I forget the official terms) is really just a paper-thin wrapper over win32. This means that writing C# on other platforms you are stuck catering to a wide variety of win32 idiom bleeds. This means that writing a C# runtime for other platforms, you stuck reimplementing significant numbers of Microsoft DLLs. I'm not clever enough to know if any of this leaves anyone exposed to potential legal issues, but it certainly sucks from a use and technical perspective.
This whole situations puts a big fly in the ointment of the ECMA specification, in that much of the language behavior in effect is outside the specification and in the win32 API and in some cases the implementation. Certainly you are free to create a C# implementation which is 100% compliant with the published specification. I don't know if there are issues like with Java where the compliance test is kept hidden. Aside from that, however, your 100% specification compliant implemention may not be capable of running code which was written to Microsoft's implementation, nor code which was written to the specification, due to the missing dark corners.
As for my personal opinion, C# avoids many of the medium to small grain mistakes in Java, while maintaining (for better and for worse) a more C++/C developer friendly set of syntax and idioms. On the very large scale, however, it repeats the same list of glaring productivity problems that plague C, C++, and Java: too verbose, too inflexible, too unproductive.
As for patents, I don't think it's FUD to say that there are potential patent issues, certainly it is not FUD to consider that it is quite likely that there are submarine patents which would affect C#. This situation applies to any software system of reasonable complexity. It might be FUD to claim that it specially affects C# and C# implementations more than other complex software systems.
Sorry, I didn't read the full context. Yes of course my comments apply to any kind of floating point number.
The answer, which is explicitly given in the referenced article by the article (two clicks, not one), is that commercial calculators operate with three digits of precision greater than those that they display, so that for operations which are available on the calculator, the imprecision is hidden. Typically calculators will display ten digits, but calculate using 13.
It's worse than that. In some kinds of calculations, the error can be so large that the result is entirely meaningless. That is, for example when doing a subtraction between two nearly equal floating point values, both of which were approximated, the result may have more noise than signal. This isn't the usual case, but when writing general code that cares about precise values, you can code yourself a beartrap that only springs in rare circumstances.
h tml
There is an excellent article about all of this detail, linked from TFA at sun: http://docs.sun.com/source/806-3568/ncg_goldberg.
Granted, I have never written any code where this matters, but I had never realized really just how bad some of the implications are in some cases.
I disagree. I think the biggest reason for 64bit is that the 64 bit x86 arch variant just happens to be quite a lot faster, for reasons somewhat unrelated to its 64 bitness (larger number of registers, mostly). Of course this _only_ applies to x86-64, and not powerpc, alpha, sparc, etc, which all had more reasonable arches all along, but it is the most significant user-visible change at this time for any 64 bit upgrade.
As a 32 year old who as attended far too many loud concerts, I can hear that crap loud and clear and it's annoying. Please don't follow the hype and engage super annoying ringtones, okay?
Real remains poor. Helix is open source, but it is half a program. Software even capable of handling the enclosure formats (not the codecs) of openly specified formats is not included in the free software component of the player. In reality, Helix Player is an open toolkit one could use to build a player, but the total functional player is a proprietary program.
This sort of half-truth, a supposedly open player that does not work, is the kind of shady thing I would expect, and still do expect from Real.
Well, I live across the bay from you in Oakland, and do not drive. My encounters with the constabulary are generally of the opposite relationship. The police are already doing something completely unreasonable when I encounter them.
I could be "nice" and "polite", but that's never going to encourage the police to say, stop raiding people's yards, threatening them in the process on scheduled 2AM "manhunts". In short, I go out of my way to let the police know that their actions are unreasonable. I do not harass or challenge them, I just let them know that their actions have crossed into unreasonable territory.
For example, one time I was bicycling home at 11 from a party. The police had set up a barricade with a helicopter circling overhead. There was no activity. I asked what was going on, since this was my neighborhood, and not one that usually has any significant amount of crime. I was told there was "a bad man". Thanks for keeping me well informed of the real situation in my neighborhood. Then they refused to let me bicycle in either of the the two directions that would get closer to my apartment, encircling me and using intimindating behavior.
They said that I would be going close to the "armed bad man".
I said "This man is not attempting to intimidate me, and all of you are. There is apparently only one of him, so he is far less threatening. Further, I doubt he will care about a random bicyclist going home. You scare me far more."
After this I was compelled to bicycle home a very long route which passed just as close to the "crime scene" but took 2 extra miles.
Kowtowing to the police is not always productive.
You just changed the scenario. Your original example included spaces, numbers, alphas, the hyphen, the period, and a comma. These are all legal FAT characters. I was curious what kind of an error this produced for you.
Your response is an error that is for a filename including alpha, question mark, apostrophe/single quote, backslashes (unsure here), and most importantly, a colon. Colons are not FAT-legal characters on DOS (and derivatives), so you get an error.
It's possible to mount fat filesystems in such a way as to allow linux to store colons, and other characters, in filenames but as you point out this would make DOS (and derivatives) unhappy, and so the default is to disallow them. So yes, your new scenario will fail, but your original scenario should succeed. However, I am no longer as interested in the problem encountered.
The outlined scenario by the grandparent clearly indicates his system has gone deeply into swap. Apparently your system has not.
The end.
I copy such filenames to my fat-based music player all the time. What happens when you try it?
No unix ever has or ever will support the use of the forward slash '/' character in filenames.
The slash character represents a directory separation in strings which are known as paths. Programs are fully expected and _must_ interpret these strings themselves in userspace in order to resolve them as a chain of directory names and a filename. Because it is required that programs interpret these strings, the slash character must represent a separation, and therefore may not be used inside a filename. This is a fundamental part of the UNIX api, and allowing slashes in filenames would require rewriting the way that programs refer to and describe paths, invalidating the majority of existing unix software.
There are no escape characters used in paths as encountered by programs, and a good thing too because that would just make it more complicated and introduce bugs.
Both IFF files containing ILBM chunks (image chunks) and 8svx chunks (sound chunks) were IFF files with internal metadata describing their contents. You could have both types in one file if you liked or had a reason for it.
What was your point again?
I am specifically commenting on your failure to clarify that you were, in that original post, using the term "religion" significantly differently than the norm. Then everyone blithely continued to argue back and forth without ever clarifying.
Blame: shared.
Err, I'm not sure It could work on ext3. I meant. (I did preview, but..)
Ext3 advantages over ntfs:
- fully documented
- dependable
- much better performance
It's not a big list, but those are some important items. That said, I'm not sure Windows could work on NTFS. No streams, different metadata, inodes. I don't know if you can reasonably glue all the needed windows semantics on ext3.
As usual, tabbers emptily claim their behavior is considerate, when it is not.
I can definitely reindent (spaces or tabs), your entire document if I wish to review it differently, but alignment and subtleties will be broken. However, if I receive a tab-indented document I will have no idea how to displaying to view the intended alignment.
Hard tabs in source are wrong.