With this Vodafone one, "The device will support up to four voice calls, and users will register the handsets they want to use it on the web", so only you and your family/friends can use your picocell.
Because for maximum lift you need the maximum volume-to-surface-area ratio, which is a sphere (or as close as you can get to it, i.e. a cube is better than a tall thin oblong)
Given that it's an online game, with all the AI code implemented on the server side, even if he did release the source you would have to run the server side yourself, including providing your own data sets (maps, unit stats, graphics, etc.).
Navigation apps aren't directly dependent on the GPS hardware, they are dependent on the Location API which will still return a position based on cell tower triangulation. I can't comment on "and the like" as that's a bit of a broad question, but in general they will all be calling API functions that I guess will return a default or error value if the hardware doesn't support it.
I am absolutely astonished by the convoluted reasoning being used by astroturfers here to excuse this completely evil and devious scheme by Microsoft. You guys should be crowing to the skies about OpenOffice having a bug.
I never said I was happy with the OOo behaviour.
Here if the PROPER solution:
1. OpenOffice copies whatever the fuck Excel does with strings. Either the string is marked with the locale that it was loaded from, or the current locale is used,
That would require some kind of standard list of locale names, which does not exist. I already suggested that in the bug report.
They can thank Microsoft for their diligent bug search that located this bug, Microsoft must have put big bucks into this team that found as many bugs as they could.
This issue has been open and hot for 7 years.
3. When the programs handle formulas differently, you find out what the majority does, and you change the minority to match (unless the majority does something so stupid that you can convince the majority to change). This is how standards evolve.
I mostly agree, but OOo seems to be entirely entrenched in the no-string-conversion camp.
Once again, OpenOffice is doing the wrong thing. Other ODF programs act like Excel. OpenOffice must be fixed, and the best fix is to copy whatever Excel does.
That, apparently, is not going to happen. This is not a bug, this is a deliberate philosophy of "automatic string conversions considered harmful, they are the GOTO of spreadsheets". However, the namespace thing is a perfect way out! For Excel compatibility, all Excel spreadsheets should open with the formulae in namespace msoxl, and if you want to write formulae that use Excel semantics, then you can use that namespace as well. If you want to migrate your Excel spreadsheets over to native OOo, then you can search for the msolx namespace and debug the changeover process yourself, handling any string conversions.
If you are American, you probably don't have to deal with national preferences as much as we in Europe do. Continental Europeans use the comma as the decimal separator and dot as the thousands separator. That puts automatic string conversion in the "dangerous" corner.
If =A1+A2 should convert text to numbers, what should =SUM(A1:A2) do if A1 is a number stored as text? Try it on Google Docs. What should it do if A1 contains "1,234" and a French person opens your spreadsheet on their PC? This is not an easy issue, but I think that supporting the msoxl namespace with Excel-compatible semantics gives OOo the best of both worlds.
If you mean the string/numeric thing, I started out arguing that this is a bug, but now I'm not so sure. Like one of the devs says in that issue, "we handle the differnet data types stricter than excel does. This is a kind of philosophical question and we're the guys that represent the other position."
I'm kind of torn on this issue. Part of me wants to chant "M$ ARE EVIL!!!", but the other part of me looks at that quote in the standard, which effectively says "different semantics should be placed in different namespaces", OOo uses different semantics to Excel (i.e. no automatic string conversion), so Excel's formulae should be placed in a different namespace because of the incompatible semantics. OOo can still win this one, if they implement the msoxl namespace in an Excel-compatible way. In effect, Microsoft have handed them the solution to this long-standing interop issue!
To me, this is all whining by the anti-Microsoft folks. When Microsoft supports ODF 1.2, and if they goof up, then complain.
At which point you'll still be apologizing for them and say we should wait till 1.3 to complain?
1.1 does not specify formulae at all. OOo, Gnumeric, Symphony, Excel, all implement proprietary extensions of 1.1 by including formulae. Since OOo's formula language is fundamentally incompatible with Excel's, Microsoft decided to place Excel's formulae in a different namespece so that OOo and others would not incorrectly interpret them. If you open an Excel spreadsheet in OOo, which attempts to convert Excel formulae to OOo, you are likely to get different results.
Interoperability where different implementations evaluate formulae differently is impossible. Given that there is no standard that specifies how a formula is to be evaluated, formulae are meaningless according to the standard. So they put them in a different namespace, as they are essentially written in a different language. Excel formulae, OOo formulae, Gnumeric formulae, Lotus formulae, these are all very different formula languages with different rules. It's like expecting Perl to evaluate a Python formula, just because both can read CSV files. OOo chose to disallow automatic string conversion in their formula language, Excel does allow automatic string conversion, so Microsoft decided to put their formulae into a different namespace to avoid silent change of behaviour when switching between applications. See Bug 5658, that I have been very active on.
If you got your hands on and analyzed the sourcecode to most DVD' players, TV's (Panasonic runs linux!) and other devices that are complex you will discover that in order to ship it earlier the code is an utter mess.
It's entirely reasonable that code used in devices like this should be to a higher standard than most other code.
Programmers are not joking when we complain about the "It compiles? Ship it!" statement.
I've been under the same kinds of pressure, I've cranked out sloppy code with poor standards and documentation, I've said "It compiles? Ship it!", but I never really meant it, it seldom gets that bad.
Slashdot Mirror
With this Vodafone one, "The device will support up to four voice calls, and users will register the handsets they want to use it on the web", so only you and your family/friends can use your picocell.
When people attack your server, you find the responsible network block's admins abuse address, and report the IP and the problem.
But by reporting the IP address, you are recording and transmitting someone else's private information.
As a very young geek I spent many a night tucked in bed listening to my crystal (actually geranium) radio.
I used magnolias.
Because for maximum lift you need the maximum volume-to-surface-area ratio, which is a sphere (or as close as you can get to it, i.e. a cube is better than a tall thin oblong)
You just want a free game.
Given that it's an online game, with all the AI code implemented on the server side, even if he did release the source you would have to run the server side yourself, including providing your own data sets (maps, unit stats, graphics, etc.).
Navigation apps aren't directly dependent on the GPS hardware, they are dependent on the Location API which will still return a position based on cell tower triangulation. I can't comment on "and the like" as that's a bit of a broad question, but in general they will all be calling API functions that I guess will return a default or error value if the hardware doesn't support it.
I am absolutely astonished by the convoluted reasoning being used by astroturfers here to excuse this completely evil and devious scheme by Microsoft. You guys should be crowing to the skies about OpenOffice having a bug.
I never said I was happy with the OOo behaviour.
Here if the PROPER solution:
1. OpenOffice copies whatever the fuck Excel does with strings. Either the string is marked with the locale that it was loaded from, or the current locale is used,
That would require some kind of standard list of locale names, which does not exist. I already suggested that in the bug report.
They can thank Microsoft for their diligent bug search that located this bug, Microsoft must have put big bucks into this team that found as many bugs as they could.
This issue has been open and hot for 7 years.
3. When the programs handle formulas differently, you find out what the majority does, and you change the minority to match (unless the majority does something so stupid that you can convince the majority to change). This is how standards evolve.
I mostly agree, but OOo seems to be entirely entrenched in the no-string-conversion camp.
A Settlers sub-game classic
P.S. I salute your ID number.
Once again, OpenOffice is doing the wrong thing. Other ODF programs act like Excel. OpenOffice must be fixed, and the best fix is to copy whatever Excel does.
That, apparently, is not going to happen. This is not a bug, this is a deliberate philosophy of "automatic string conversions considered harmful, they are the GOTO of spreadsheets". However, the namespace thing is a perfect way out! For Excel compatibility, all Excel spreadsheets should open with the formulae in namespace msoxl, and if you want to write formulae that use Excel semantics, then you can use that namespace as well. If you want to migrate your Excel spreadsheets over to native OOo, then you can search for the msolx namespace and debug the changeover process yourself, handling any string conversions.
If you are American, you probably don't have to deal with national preferences as much as we in Europe do. Continental Europeans use the comma as the decimal separator and dot as the thousands separator. That puts automatic string conversion in the "dangerous" corner.
If =A1+A2 should convert text to numbers, what should =SUM(A1:A2) do if A1 is a number stored as text? Try it on Google Docs. What should it do if A1 contains "1,234" and a French person opens your spreadsheet on their PC? This is not an easy issue, but I think that supporting the msoxl namespace with Excel-compatible semantics gives OOo the best of both worlds.
If you mean the string/numeric thing, I started out arguing that this is a bug, but now I'm not so sure. Like one of the devs says in that issue, "we handle the differnet data types stricter than excel does. This is a kind of philosophical question and we're the guys that represent the other position."
My bad, boy do I feel dumb now! I thought this was just the new "you're not welcome here" meme.
I was contending the OP's translation of "non-populist" into "elitist".
I'm kind of torn on this issue. Part of me wants to chant "M$ ARE EVIL!!!", but the other part of me looks at that quote in the standard, which effectively says "different semantics should be placed in different namespaces", OOo uses different semantics to Excel (i.e. no automatic string conversion), so Excel's formulae should be placed in a different namespace because of the incompatible semantics. OOo can still win this one, if they implement the msoxl namespace in an Excel-compatible way. In effect, Microsoft have handed them the solution to this long-standing interop issue!
In the context of the OP, "elitist" is presented as synonymous with "non-populist", i.e. "refusing to reduce to the lowest common denominator".
You are missing one ENORMOUS detail: the formulas ARE defined, they are defined by Open Office and every other ODF user as "do what Excel does".
Oh no they aren't. (skip to the end to see my suggestion on how OOo should handle Excel interop)
You use the phrase "elitist" like it's a bad thing. Is it wrong to excel? To try to be better than average? To have something interesting to say?
TV series, see 3.
Did you actually watch the series? It was totally not like that.
To me, this is all whining by the anti-Microsoft folks. When Microsoft supports ODF 1.2, and if they goof up, then complain.
At which point you'll still be apologizing for them and say we should wait till 1.3 to complain?
1.1 does not specify formulae at all. OOo, Gnumeric, Symphony, Excel, all implement proprietary extensions of 1.1 by including formulae. Since OOo's formula language is fundamentally incompatible with Excel's, Microsoft decided to place Excel's formulae in a different namespece so that OOo and others would not incorrectly interpret them. If you open an Excel spreadsheet in OOo, which attempts to convert Excel formulae to OOo, you are likely to get different results.
Where as, all they had to do is look at a *document* that OO created and mimic it.
Why didn't OOo just look at what Excel did and mimic that?
Interoperability where different implementations evaluate formulae differently is impossible. Given that there is no standard that specifies how a formula is to be evaluated, formulae are meaningless according to the standard. So they put them in a different namespace, as they are essentially written in a different language. Excel formulae, OOo formulae, Gnumeric formulae, Lotus formulae, these are all very different formula languages with different rules. It's like expecting Perl to evaluate a Python formula, just because both can read CSV files. OOo chose to disallow automatic string conversion in their formula language, Excel does allow automatic string conversion, so Microsoft decided to put their formulae into a different namespace to avoid silent change of behaviour when switching between applications. See Bug 5658, that I have been very active on.
And it's got unlimited space.
The internet is actually nearly full, I hope there is eno
Yeah, that's a bit of a careless mistake, opens them up to pointless accusations of incompetence in their analysis.
If you got your hands on and analyzed the sourcecode to most DVD' players, TV's (Panasonic runs linux!) and other devices that are complex you will discover that in order to ship it earlier the code is an utter mess.
It's entirely reasonable that code used in devices like this should be to a higher standard than most other code.
Programmers are not joking when we complain about the "It compiles? Ship it!" statement.
I've been under the same kinds of pressure, I've cranked out sloppy code with poor standards and documentation, I've said "It compiles? Ship it!", but I never really meant it, it seldom gets that bad.