So you mean that Microsoft can lobby No votes to become Yes votes after meeting the issues raised in their comments?
Indeed they can; in fact, turning "no with comments" votes into "yes" votes is the whole purpose of the BRM--though normally the no's will be "no, because there are a few things that need tweaking", not "no, this is a POS that shouldn't be a standard in the first place".
On the other hand, "yes" votes can turn into "no" votes as well. I imagine the national boards that were fooled by Microsoft's "yes with comments" spiel will not be amused . ..
TFA itself talks about "not approving the fast-track", which isn't quite the same as "not fast-tracking" OOXML period but is still misleading. (Fancy little Preview button down there. I wonder what it does?)
The fast-track process isn't over yet; all ISO has decided is that OOXML didn't pass the initial vote. There's still (probably, unless Microsoft backs down at the last minute) a Ballot Resolution Meeting to come, where the committee looks at all the comments received with the votes and tries to resolve them. If the various national boards decide that the result is good enough and vote for OOXML, it can still become a standard in the near future.
In a multitasking system, you can read and write the same memory space at the same time! . . . Oh, I guess it's not news after all.
Seriously, this is just Yet Another Race Condition. As long as you follow the rules of multithreaded programming (which for syscall wrappers means copying your arguments, since you can't negotiate mutexes with the caller), this is a non-issue.
OOXML could be the best thing since sliced bread, and I still wouldn't accept it. Not because I hate Microsoft; I most certainly do hate Microsoft, but I also recognize the technical contributions they've made to computing. I'd reject OOXML because Microsoft has ruined its (both OOXML's and Microsoft's own) credibility with its gaming of the standards process.
I'll set aside for the moment the problems I see in the draft as it is. If Microsoft believed its format was good enough to be an international standard--as opposed to simply a de facto "standard"--why did it then try to mislead ISO members around the world with demonstrably false information? Conversely, if Microsoft didn't think its format was good enough to be an international standard, why did it submit the format to ISO in the first place? And what will Microsoft do to make amends for its improper actions? (I'm not asking you for answers to these questions, but I suspect most people in the anti-OOXML camp will want satisfactory answers before they're willing to focus on the merits.)
I'm currently developing a collaboration system for a client which will (among other things) input and output spreadsheets in an XML-based file format. I was considering OOXML for a while, since its technical issues don't impact this particular application; but with the shenanigans Microsoft has pulled to try and force OOXML through ISO, I've settled on ODF. I simply can't support a company which engages in such unethical behavior.
Of course,.doc/.xls outnumber XML documents by some ridiculous factor--and there's a good chance those will naturally shift to OOXML as Microsoft pushes it over the old formats. They've already got an OOXML update for Office 2003, so they don't even need to convince people to learn ribbons instead of switching to OO.o.
Don't get me wrong, I'd love for ODF to get itself firmly established . . . but looking at Microsoft's recent shenanigans, I'm rapidly losing hope.
The problem Microsoft (potentially) faces isn't that it suddenly won't be able to distribute certain software; that very "or any later version" ensures that Microsoft can continue to apply GPL2 to their distribution of the software, no matter how much the author might wish otherwise. The problem occurs when new versions of such software are released, because with a new version, the author can change the license freely (since nobody has a copy of it yet). Once this happens, at least according to the GPL3-owns-Microsoft camp, Microsoft will be faced with a dilemma: either it has to accept the GPL3's terms, or it has to stay with the old, GPL2 software, which will no longer be updated unless Microsoft does so itself.
I haven't flown JAL in the last couple of years, so I wouldn't know, but I guess their troubles aren't limited to ignoring air traffic controllers. ANA, on the other hand, has been consistent for the 8 years I've used them. Consistently mediocre, that is, but growing up in the US, I learned to never count on the edibility of airline food anyway.
Both of the major Japanese carriers, JAL and ANA, have given me excellent service. I fly ANA when I go back to the States (mostly because JAL doesn't fly NRT-IAD), and aside from the consistent professionalism of their employees, the flight amenities are good as well; they put seat TVs in coach several years back, and they had Boeing's Internet access service (Connexion, was it?) installed as well until it was discontinued. I've come to dread the rare occasions when I have to fly a domestic US route.
I'll definitely have to remember Qantas when I go vacation in Australia, though.
Thanks for the correction. I'd gone with strict when I switched to XHTML to try and help myself keep the code as clean as possible, but maybe I'll switch back to transitional, since strict seems to be counterproductive in that sense.
First, you shouldn't be underlining non-link text in a web page anyways, as it's a cruel thing to do to computer lab attendants.
I figured somebody would say that. That doesn't make you any less wrong, though. (Hint: not everybody underlines links these days, and not all HTML is intended to be read by ignorant users.)
I have no argument with most of your post, but:
Seriously, the b, u, i and big tags are _exactly the same_ in XHTML. My XHTML validator seems to disagree with you:
$ cat >test.html <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.d td"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head><title></title></head><body> <p><u>test</u></p></body> </html> ^D $ validate test.html *** Errors validating test.html: *** Error at line 4, character 40: element "u" undefined
Which is a pain, because I have to go to the trouble of writing <span style="font-decoration: underline"> instead.
Judging from the decision, it looks like the defendant may have been overcharged by her lawyers, in the sense of being billed for more time than was reasonable. The judge makes several disparaging remarks about the defense lawyers block-billing time rather than keeping accurate records of exactly how much time was spent doing what, and about "almost frenetic" activity once they knew they would be recovering costs.
It's not that Japan "just banned" the use of web sites; it's that the law as written doesn't allow it, and hasn't been changed (in relevant part) since the web came about. Or rather, it's that the law is believed not to allow web sites; a few candidates that tried it got a warning that it "might" break the law, and none of them were willing to actually take it to the courts. (Interestingly enough, in this election the political parties have started posting their non-candidate members' speeches, arguing that they're allowed as descriptions of party activities rather than restricted candidate activities. We'll have to see how that holds up.)
Incidentally, a similar problem with videos of campaign speeches was discussed here in April.
Mea culpa. I saw the part about two video cards, but I never imagined that a single video card could use more than 100W. (What do you do with 175W per card, anyway?)
Is that why people don't blink at PS3s and X360s that eat 150-200W when they're idle? I guess that locks me and my 100W/system power budget out of gaming . ..
Seriously, what is it that uses up so much power? I've got a pretty standard dual-core system that idles at about 65W, and I can't push it beyond 150W even when I try.
Or just set the tabstop to 2, so developers can use whatever indentation size pleases them.
Until somebody decides that two spaces really isn't enough for a visible indent, sets their tab size to 4, and all of a sudden all the lines go over 80 columns.
Not necessarily. There's only so many variations on relative sensory organ placement, and many of them will not work as well in a variety of environments as ours does. If your eyes are below your nose, for example, then your breathing passage has to go down past the eyes, while your optic nerve has to wend around the breathing passage.
This is, of course, assuming the presence of a head with the brain at the top of the head. Why not, for example, stick all the critical stuff in the middle? Like a big central mass with some number of appendages sticking out. That would have the additional advantage of reducing worst-case neural lag. (Ever misstep, realize you're about to stub your toe, and not be able to stop your foot in time? I hate that.)
Hmm, fluffy balls with limbs. Now where have I seen those before . . .
The Milky Way Galaxy is thought, according to the best available scientific evidence, to be at least 13.5 billion years of age. If we assume that there has been intelligent life somewhere in the galaxy, not necessarily one continuous civilization or species, for at least half of that time and that at some point one of these species developed a barely practicable interstellar drive, able to travel at say 1/1000 light speed, then the fact that we are not already part of some vast galactic empire tends to suggest, with high probability, that such travel is simply not possible or at best not practicable
Or that somebody came here, saw life, and left us alone (Prime Directive). Or they didn't leave us alone (ancient astronauts). Or there's just so many goddamn planets out there that nobody's gotten out to our neck of the woods yet. (Would you like to be charged with maintaining an umpteen-billion planet database?)
Or, you know, your assumption could be wrong . . .
Just finished reading the decision (here, as mentioned in my other post). Some interesting points:
The case was not an actual infringement case; it was brought by the service provider itself, asking for a declaration of non-infringement, and the court said no, there's a potential for infringement so you don't get your declaration.
The act of converting audio files to 3G2 format (for sending to mobile phones) on the server is an act of the server operator, even if it was initiated by the user, so it has the potential to infringe copyright (pages 27-33).
Making data available online to users counts as broadcasting to the public, so it has the potential to infringe copyright--even if you implement access control (pages 33-35).
That last one is the biggie, and the part I don't get (or rather, I think the court didn't get). They say in 3(1) that the server operator is responsible for the act of sending the data, which is at least consistent with how they handled the file conversion/storage issue, if nothing else; but then in 3(2), they go on to say that the users to which the data is sent qualify as "the public" under copyright law, which defines "public" as "one or many unspecified individuals". The service provider naturally argued that sending data to the same user who uploaded it shouldn't count as sending it to the public, but here's what the court said to that (3(3)A, page 35, roughly translated):
However, as found in 3(1), the server operators are responsible for the act of transmission of the data. Since transmission to the public has the purpose of being received directly by the public (Copyright Law 2.1.7(2)), if the direct recipients are one or many unspecified individuals, the act of transmission qualifies as transmission to the public. And the users of the service qualify as the public, as found in 3(2). Even if access to data is restricted to the user who uploaded that data, that is only because the computer, mobile phone, and server storage area are tied together using a mail address, password, access key, and subscriber ID, and because the server is designed not to allow access by other devices; this does not change the fact that the sender of the data is Plaintiff, and the recipient is an unspecified individual.
If that last bit didn't make sense to you, you're not alone. As I see it, the whole point of that kind of access control is to identify the individual receiving the data, so the "unidentified individual" thing shouldn't apply. I could see an argument that the server doesn't go far enough to ensure that it really is the same person, but "unidentified"? I don't think so.
This is still just a district court ruling, so it doesn't set any "precedent" in the sense of binding other courts. It may influence how other district courts consider similar cases, but then again it may not; my impression is courts at the same level generally act rather independently. (There was a pair of high-profile cases late last year on privacy rights vs. government databases, where two separate high courts came to completely opposite conclusions for essentially the same circumstances.)
IANAL, of course. I just live here.
For the curious, the decision itself (PDF, in Japanese) can be found here.
I was referring to the server side. So using FS does keep the file data in an easily accessible format? I'd been under the impression that it didn't. Thanks for the tip.
(I'm not so worried about the client side--if your CVS or.svn or whatever control directory gets messed up, you can always save your changed files away somewhere and pull a new copy of the repository to clean that up.)
Slashdot Mirror
Indeed they can; in fact, turning "no with comments" votes into "yes" votes is the whole purpose of the BRM--though normally the no's will be "no, because there are a few things that need tweaking", not "no, this is a POS that shouldn't be a standard in the first place".
On the other hand, "yes" votes can turn into "no" votes as well. I imagine the national boards that were fooled by Microsoft's "yes with comments" spiel will not be amused . . .
TFA itself talks about "not approving the fast-track", which isn't quite the same as "not fast-tracking" OOXML period but is still misleading. (Fancy little Preview button down there. I wonder what it does?)
The fast-track process isn't over yet; all ISO has decided is that OOXML didn't pass the initial vote. There's still (probably, unless Microsoft backs down at the last minute) a Ballot Resolution Meeting to come, where the committee looks at all the comments received with the votes and tries to resolve them. If the various national boards decide that the result is good enough and vote for OOXML, it can still become a standard in the near future.
In a multitasking system, you can read and write the same memory space at the same time! . . . Oh, I guess it's not news after all.
Seriously, this is just Yet Another Race Condition. As long as you follow the rules of multithreaded programming (which for syscall wrappers means copying your arguments, since you can't negotiate mutexes with the caller), this is a non-issue.
Neeext!
OOXML could be the best thing since sliced bread, and I still wouldn't accept it. Not because I hate Microsoft; I most certainly do hate Microsoft, but I also recognize the technical contributions they've made to computing. I'd reject OOXML because Microsoft has ruined its (both OOXML's and Microsoft's own) credibility with its gaming of the standards process.
I'll set aside for the moment the problems I see in the draft as it is. If Microsoft believed its format was good enough to be an international standard--as opposed to simply a de facto "standard"--why did it then try to mislead ISO members around the world with demonstrably false information? Conversely, if Microsoft didn't think its format was good enough to be an international standard, why did it submit the format to ISO in the first place? And what will Microsoft do to make amends for its improper actions? (I'm not asking you for answers to these questions, but I suspect most people in the anti-OOXML camp will want satisfactory answers before they're willing to focus on the merits.)
I'm currently developing a collaboration system for a client which will (among other things) input and output spreadsheets in an XML-based file format. I was considering OOXML for a while, since its technical issues don't impact this particular application; but with the shenanigans Microsoft has pulled to try and force OOXML through ISO, I've settled on ODF. I simply can't support a company which engages in such unethical behavior.
I've had people seriously make that argument to me. Whatever happened to pride in workmanship?
Of course, .doc/.xls outnumber XML documents by some ridiculous factor--and there's a good chance those will naturally shift to OOXML as Microsoft pushes it over the old formats. They've already got an OOXML update for Office 2003, so they don't even need to convince people to learn ribbons instead of switching to OO.o.
Don't get me wrong, I'd love for ODF to get itself firmly established . . . but looking at Microsoft's recent shenanigans, I'm rapidly losing hope.
The problem Microsoft (potentially) faces isn't that it suddenly won't be able to distribute certain software; that very "or any later version" ensures that Microsoft can continue to apply GPL2 to their distribution of the software, no matter how much the author might wish otherwise. The problem occurs when new versions of such software are released, because with a new version, the author can change the license freely (since nobody has a copy of it yet). Once this happens, at least according to the GPL3-owns-Microsoft camp, Microsoft will be faced with a dilemma: either it has to accept the GPL3's terms, or it has to stay with the old, GPL2 software, which will no longer be updated unless Microsoft does so itself.
I haven't flown JAL in the last couple of years, so I wouldn't know, but I guess their troubles aren't limited to ignoring air traffic controllers. ANA, on the other hand, has been consistent for the 8 years I've used them. Consistently mediocre, that is, but growing up in the US, I learned to never count on the edibility of airline food anyway.
Both of the major Japanese carriers, JAL and ANA, have given me excellent service. I fly ANA when I go back to the States (mostly because JAL doesn't fly NRT-IAD), and aside from the consistent professionalism of their employees, the flight amenities are good as well; they put seat TVs in coach several years back, and they had Boeing's Internet access service (Connexion, was it?) installed as well until it was discontinued. I've come to dread the rare occasions when I have to fly a domestic US route.
I'll definitely have to remember Qantas when I go vacation in Australia, though.
Thanks for the correction. I'd gone with strict when I switched to XHTML to try and help myself keep the code as clean as possible, but maybe I'll switch back to transitional, since strict seems to be counterproductive in that sense.
I figured somebody would say that. That doesn't make you any less wrong, though. (Hint: not everybody underlines links these days, and not all HTML is intended to be read by ignorant users.)
Which is a pain, because I have to go to the trouble of writing <span style="font-decoration: underline"> instead.
Judging from the decision, it looks like the defendant may have been overcharged by her lawyers, in the sense of being billed for more time than was reasonable. The judge makes several disparaging remarks about the defense lawyers block-billing time rather than keeping accurate records of exactly how much time was spent doing what, and about "almost frenetic" activity once they knew they would be recovering costs.
It's not that Japan "just banned" the use of web sites; it's that the law as written doesn't allow it, and hasn't been changed (in relevant part) since the web came about. Or rather, it's that the law is believed not to allow web sites; a few candidates that tried it got a warning that it "might" break the law, and none of them were willing to actually take it to the courts. (Interestingly enough, in this election the political parties have started posting their non-candidate members' speeches, arguing that they're allowed as descriptions of party activities rather than restricted candidate activities. We'll have to see how that holds up.)
Incidentally, a similar problem with videos of campaign speeches was discussed here in April.
Mea culpa. I saw the part about two video cards, but I never imagined that a single video card could use more than 100W. (What do you do with 175W per card, anyway?)
Is that why people don't blink at PS3s and X360s that eat 150-200W when they're idle? I guess that locks me and my 100W/system power budget out of gaming . . .
Seriously, what is it that uses up so much power? I've got a pretty standard dual-core system that idles at about 65W, and I can't push it beyond 150W even when I try.
Until somebody decides that two spaces really isn't enough for a visible indent, sets their tab size to 4, and all of a sudden all the lines go over 80 columns.
Fair enough. I didn't consider eye mobility, but I guess it would be pretty inconvenient to have to swing your whole body around to look behind you.
This is, of course, assuming the presence of a head with the brain at the top of the head. Why not, for example, stick all the critical stuff in the middle? Like a big central mass with some number of appendages sticking out. That would have the additional advantage of reducing worst-case neural lag. (Ever misstep, realize you're about to stub your toe, and not be able to stop your foot in time? I hate that.)
Hmm, fluffy balls with limbs. Now where have I seen those before . . .
Or that somebody came here, saw life, and left us alone (Prime Directive). Or they didn't leave us alone (ancient astronauts). Or there's just so many goddamn planets out there that nobody's gotten out to our neck of the woods yet. (Would you like to be charged with maintaining an umpteen-billion planet database?)
Or, you know, your assumption could be wrong . . .
Just finished reading the decision (here, as mentioned in my other post). Some interesting points:
That last one is the biggie, and the part I don't get (or rather, I think the court didn't get). They say in 3(1) that the server operator is responsible for the act of sending the data, which is at least consistent with how they handled the file conversion/storage issue, if nothing else; but then in 3(2), they go on to say that the users to which the data is sent qualify as "the public" under copyright law, which defines "public" as "one or many unspecified individuals". The service provider naturally argued that sending data to the same user who uploaded it shouldn't count as sending it to the public, but here's what the court said to that (3(3)A, page 35, roughly translated):
If that last bit didn't make sense to you, you're not alone. As I see it, the whole point of that kind of access control is to identify the individual receiving the data, so the "unidentified individual" thing shouldn't apply. I could see an argument that the server doesn't go far enough to ensure that it really is the same person, but "unidentified"? I don't think so.
This is still just a district court ruling, so it doesn't set any "precedent" in the sense of binding other courts. It may influence how other district courts consider similar cases, but then again it may not; my impression is courts at the same level generally act rather independently. (There was a pair of high-profile cases late last year on privacy rights vs. government databases, where two separate high courts came to completely opposite conclusions for essentially the same circumstances.)
IANAL, of course. I just live here.
For the curious, the decision itself (PDF, in Japanese) can be found here.
s/now/not/
Though I like the parent's suggestion better . . .
I was referring to the server side. So using FS does keep the file data in an easily accessible format? I'd been under the impression that it didn't. Thanks for the tip.
(I'm not so worried about the client side--if your CVS or .svn or whatever control directory gets messed up, you can always save your changed files away somewhere and pull a new copy of the repository to clean that up.)