I liked the Practical Guide. Down side, Leopard's out so some of the material's dated, but I think it was one of the first books to really talk at all about what launchd is and why you might care. I don't have one of my copies immediately handy, but I think it actually covered plutil.
Oh! I found a draft. Yes. It actually talks about plutil and launchd and such.
It was an interesting project, and I learned a lot from working with Mark Sobell on it.
I am familiar with a lot of the material in the book, presumably, but I'd like to see what he did for coverage of Ubuntu, especially now that I'm using it fairly regularly.
(Background; I was involved with the Practical Guide for OS X 10.4.)
Everyone still has to implement it, or they are not correctly implementing the standard for existing documents. Failure to implement that means failure to comply with the standard.
This is how we know OOXML is not a real standard. It's just a documentation of the state of MS software at a particular point. In a standard intended for actual use by more than one party, the historical things would not be a part of the standard at all; they would be extensions which most people wouldn't use.
Seriously, I went over this document not that long ago. It's still a joke. It's still not a technically viable standard. The "addressing" you point to doesn't come close to the minimal requirements we'd have imposed on one of the real standards.
I could be mistaken. I mean, hey, I only did about a decade of work on ISO C. Maybe nowadays we just slap any old thing together, and declare that it "fixes" a problem if we say that something is deprecated, and while everyone is absolutely required to implement it, we don't want people making it happen in new code anymore.
I don't think the C standard is going away over this. ISO's process is only as good as the participants, but the people working on C have been consistently excellent.
I used to have a fair amount of confidence in ISO. I spent roughly ten years involved with C standardization, and you know what? The process basically worked. We consistently ended up adopting things that really did work and had consensus, and rejecting things, sometimes even good ones, if we didn't have real consensus.
The OOXML "process" is a joke, and it reflects very, very, badly on ISO.
It's hard to express, in terms that non-standards-weenies would understand, just how absolutely, totally, ridiculous this is. This doesn't even loosely resemble the functioning of a real standards process. The proposed standard is utterly unusable, and furthermore, has no relationship at all to the normal scope of standardization.
Imagine, if you will, that the C99 standard had specified the exact set of allowed command-line options, and had explicitly defined behavior under dozens of circumstances of "undefined behavior" to precisely match the behavior of gcc. Only, it had versions for "gcc 1 compatibility" and "gcc 2 compatibility". Imagine that the standard dictated the precise form and text of every error message, and required total compatibility with gcc. Furthermore, imagine that it specifically required that the source of your compiler must be distributed under the GPL v2, and must make use of the libgcc glue code.
And then imagine that, instead of actually being approved by regular participants, this was rushed through at the last minute by a number of entities which had never shown the slightest interest in C standardization before.
That's pretty close to what's happening here, only it'd have been better, because at least it would be an open standard.
* I don't post to the chans, and never really got the point. * I think this is pretty lame behavior, and wouldn't do it. * I am active in protests and activism against the CoS.
I feel about this a little like I feel about the discovery that some Americans torture people to death. It's true, and I can hardly claim they're not really American, or that I'm not American. I also can't stop them or do anything about them, even though I really don't think they should do that.
I'm more inclined to blame it on the people who think they're "oldfags" (most of whom, it seems to me, are a bit newer to this than the people who wandered into the anti-CoS stuff) than on the CoS. It would be a very effective false flag attack, though, a great way to raise awareness that "Anonymous" is full of crazy-mean people.
On the other hand, it's also a way to remind people that there are things worse than even the worst Anonymous has to offer, and the CoS is one of them. There are thousands of folks out there who looked at the history of Anonymous doing stuff like this, looked at the CoS, and decided to show up with a mask and a sign for the protests.
I assume you're just pointing out the ludicrousness of imagining a second implementation, but even if there were two, I would still absolutely oppose it.
It is not a coherent technical standard. It is, ultimately, a description of the MS Office formats, wrapped in angle brackets. It's not an interchange format. It doesn't reflect the data space, it reflects the history of Microsoft.
No one claimed there were more ODF documents; only that OOXML was vanishingly small in adoption.
The difference is, it is reasonably practical for people other than Microsoft to write programs that will read and write ODF; it is absolutely impossible for anyone who is not Microsoft to write programs that will read and write arbitrary OOXML. (Without, say, stealing the VML library and all the other stuff.)
Compatibility with OOXML buys you nothing you couldn't do with one of the previously existing reverse-engineered DOC formats. Compatibility with ODF has at least some potential for future growth.
I was involved with the C committee during the work on C9X.
The process described here shows essentially no similarity to a real standardization process. We have established, conclusively, that OOXML is not ready to be called a standard; it needs serious revision and work. The only time a "fast-track" process makes sense is when a standard is widely implemented and in use as a de facto standard, and is known to be workable.
It does not make sense when the "standard" is known not to be workable, has been implemented at most once, and there are literally thousands of unresolved comments, questions, or concerns -- many of them, as reported previously, impossible to resolve without the addition of huge chunks of new text to the specification.
It took years to get the C standard, about a tenth the size of OOXML, to a state where we could in good conscience vote to adopt it as an actual standard.
This process is an insult to standardization, and that the Microsoft-paid folks are talking about it as though it were a success leaves me utterly stunned. I can't decide whether to ascribe such claims to malice, incompetence, or both.
You have an interesting point, and that is indeed the question I tried to answer.
You are right that good developers can pick up a new platform. However, if there are no developers using the platform, that may be a subtle indication that there is something wrong with the platform!
I like the BSDs better. My ideal world involves NetBSD and PostgreSQL, but I'll use just about any of them.
I suspect some of it is just baby duck syndrome, but the BSDs tend to feel a little more coherent to me. I think a lot of it is just the experience of watching the boot messages. BSD boot messages are consistently written according to predictable patterns. Linux boot messages are full of innovative new ways of passing on different pieces of information.
This makes me wonder about the architecture. I also don't trust documentation with grammatical errors, or even just inconsistent usage.
You could be talking about anything from RealBasic to perl. Without knowing, we can't even speculate on whether you can't find someone because demand is so high that they've all been snapped up, or because the product is dead.
In general, I tend to look for a healthy third-party community. If there are multiple third-party sites, well run, with competent spelling and grammar, and no legal affiliation with the primary vendor, that's a good sign.
None of them were even close to as good as D&D is at heroic fantasy.
They're often pretty good at "realism" for particular values of "realistic", but I don't really find much interest in a game that's built around being just like things I could just go do.
3.5e remains my favorite RPG, winning out over at least a dozen others I've played often enough that I can run games in them. 4e looks like I'll like it better in some ways and worse in others... But it looks like it has the potential to continue to do the thing D&D is best at: High fantasy, with epic battles.
Since that's mostly what I like in gaming, I'm sold.
Really, I mean, where's the hard part in understanding this? Reliability on a small scale is easy. Reliability on a large scale rapidly becomes much, much, more expensive.
Is it worth twice as much to me to have 99% instead of 95%? Is it worth 10x as much to me to have 99.5% instead of 99%?
Sooner or later, the answer is "no". The cost of those last bits of reliability quickly gets ludicrous, while their impact decays rapidly.
My phone probably fails-to-call one or two times in a hundred. I hit redial and I'm done. No, it would not be worth it to me to have a phone and phone service which cost twice as much to not have to hit that redial button.
Well, if nothing else, I think it's safe to say that there's been little to no clinical testing on drug interactions in the case you describe. Maybe if you quit combining untested neuroactive chemicals with the prescribed ones, they'd be more likely to work?
Slashdot Mirror
You realize that you just posted well-substantiated facts to Slashdot, don't you? What were you THINKING?
Try putting the tinfoil shiny-side out.
Pro-vaccination is about as revolutionary or controversial as pro-gravity, pro-evolution, or pro-carbon-based-life theories.
That's scary and abusive.
It costs here a huge amount of money and time to comply, all because some jerkoff lawyer didn't like something she said.
I liked the Practical Guide. Down side, Leopard's out so some of the material's dated, but I think it was one of the first books to really talk at all about what launchd is and why you might care. I don't have one of my copies immediately handy, but I think it actually covered plutil.
Oh! I found a draft. Yes. It actually talks about plutil and launchd and such.
It was an interesting project, and I learned a lot from working with Mark Sobell on it.
What he does is "epending" -- that is to say, trying to guess the "right" email address for someone who didn't give you that address.
Which is to say, providing dirty lists to spammers. You cannot do this right.
I am familiar with a lot of the material in the book, presumably, but I'd like to see what he did for coverage of Ubuntu, especially now that I'm using it fairly regularly.
(Background; I was involved with the Practical Guide for OS X 10.4.)
Nice flagrant lie.
Not about the deprecation. About its impact.
The impact of deprecation? ZERO.
Everyone still has to implement it, or they are not correctly implementing the standard for existing documents. Failure to implement that means failure to comply with the standard.
This is how we know OOXML is not a real standard. It's just a documentation of the state of MS software at a particular point. In a standard intended for actual use by more than one party, the historical things would not be a part of the standard at all; they would be extensions which most people wouldn't use.
Seriously, I went over this document not that long ago. It's still a joke. It's still not a technically viable standard. The "addressing" you point to doesn't come close to the minimal requirements we'd have imposed on one of the real standards.
I could be mistaken. I mean, hey, I only did about a decade of work on ISO C. Maybe nowadays we just slap any old thing together, and declare that it "fixes" a problem if we say that something is deprecated, and while everyone is absolutely required to implement it, we don't want people making it happen in new code anymore.
But I don't think so.
I don't think the C standard is going away over this. ISO's process is only as good as the participants, but the people working on C have been consistently excellent.
I used to have a fair amount of confidence in ISO. I spent roughly ten years involved with C standardization, and you know what? The process basically worked. We consistently ended up adopting things that really did work and had consensus, and rejecting things, sometimes even good ones, if we didn't have real consensus.
The OOXML "process" is a joke, and it reflects very, very, badly on ISO.
It's hard to express, in terms that non-standards-weenies would understand, just how absolutely, totally, ridiculous this is. This doesn't even loosely resemble the functioning of a real standards process. The proposed standard is utterly unusable, and furthermore, has no relationship at all to the normal scope of standardization.
Imagine, if you will, that the C99 standard had specified the exact set of allowed command-line options, and had explicitly defined behavior under dozens of circumstances of "undefined behavior" to precisely match the behavior of gcc. Only, it had versions for "gcc 1 compatibility" and "gcc 2 compatibility". Imagine that the standard dictated the precise form and text of every error message, and required total compatibility with gcc. Furthermore, imagine that it specifically required that the source of your compiler must be distributed under the GPL v2, and must make use of the libgcc glue code.
And then imagine that, instead of actually being approved by regular participants, this was rushed through at the last minute by a number of entities which had never shown the slightest interest in C standardization before.
That's pretty close to what's happening here, only it'd have been better, because at least it would be an open standard.
And I care why? I'm not anonymous. I'm just anti-CoS.
I'm no more required to hide my identity than I am required to participate in harassing epileptics.
I can't speak for the rest, but:
* I don't post to the chans, and never really got the point.
* I think this is pretty lame behavior, and wouldn't do it.
* I am active in protests and activism against the CoS.
I feel about this a little like I feel about the discovery that some Americans torture people to death. It's true, and I can hardly claim they're not really American, or that I'm not American. I also can't stop them or do anything about them, even though I really don't think they should do that.
I'm more inclined to blame it on the people who think they're "oldfags" (most of whom, it seems to me, are a bit newer to this than the people who wandered into the anti-CoS stuff) than on the CoS. It would be a very effective false flag attack, though, a great way to raise awareness that "Anonymous" is full of crazy-mean people.
On the other hand, it's also a way to remind people that there are things worse than even the worst Anonymous has to offer, and the CoS is one of them. There are thousands of folks out there who looked at the history of Anonymous doing stuff like this, looked at the CoS, and decided to show up with a mask and a sign for the protests.
I assume you're just pointing out the ludicrousness of imagining a second implementation, but even if there were two, I would still absolutely oppose it.
It is not a coherent technical standard. It is, ultimately, a description of the MS Office formats, wrapped in angle brackets. It's not an interchange format. It doesn't reflect the data space, it reflects the history of Microsoft.
There's virtually no OOXML documents out there.
No one claimed there were more ODF documents; only that OOXML was vanishingly small in adoption.
The difference is, it is reasonably practical for people other than Microsoft to write programs that will read and write ODF; it is absolutely impossible for anyone who is not Microsoft to write programs that will read and write arbitrary OOXML. (Without, say, stealing the VML library and all the other stuff.)
Compatibility with OOXML buys you nothing you couldn't do with one of the previously existing reverse-engineered DOC formats. Compatibility with ODF has at least some potential for future growth.
I was involved with the C committee during the work on C9X.
The process described here shows essentially no similarity to a real standardization process. We have established, conclusively, that OOXML is not ready to be called a standard; it needs serious revision and work. The only time a "fast-track" process makes sense is when a standard is widely implemented and in use as a de facto standard, and is known to be workable.
It does not make sense when the "standard" is known not to be workable, has been implemented at most once, and there are literally thousands of unresolved comments, questions, or concerns -- many of them, as reported previously, impossible to resolve without the addition of huge chunks of new text to the specification.
It took years to get the C standard, about a tenth the size of OOXML, to a state where we could in good conscience vote to adopt it as an actual standard.
This process is an insult to standardization, and that the Microsoft-paid folks are talking about it as though it were a success leaves me utterly stunned. I can't decide whether to ascribe such claims to malice, incompetence, or both.
You have an interesting point, and that is indeed the question I tried to answer.
You are right that good developers can pick up a new platform. However, if there are no developers using the platform, that may be a subtle indication that there is something wrong with the platform!
I like the BSDs better. My ideal world involves NetBSD and PostgreSQL, but I'll use just about any of them.
I suspect some of it is just baby duck syndrome, but the BSDs tend to feel a little more coherent to me. I think a lot of it is just the experience of watching the boot messages. BSD boot messages are consistently written according to predictable patterns. Linux boot messages are full of innovative new ways of passing on different pieces of information.
This makes me wonder about the architecture. I also don't trust documentation with grammatical errors, or even just inconsistent usage.
I endorse the above comment. pgsql is a delight to work with, perl is durable and well-understood, and freebsd shuts up and stays out of your face.
You could be talking about anything from RealBasic to perl. Without knowing, we can't even speculate on whether you can't find someone because demand is so high that they've all been snapped up, or because the product is dead.
In general, I tend to look for a healthy third-party community. If there are multiple third-party sites, well run, with competent spelling and grammar, and no legal affiliation with the primary vendor, that's a good sign.
Examples: Ruby, python, perl, C.
http://www.seebs.net/log/archives/000237.html
Hundreds of comments on that one. Gives you a pretty good picture of the nature and scope of the operation.
I've played a few of them, some at some length.
None of them were even close to as good as D&D is at heroic fantasy.
They're often pretty good at "realism" for particular values of "realistic", but I don't really find much interest in a game that's built around being just like things I could just go do.
3.5e remains my favorite RPG, winning out over at least a dozen others I've played often enough that I can run games in them. 4e looks like I'll like it better in some ways and worse in others... But it looks like it has the potential to continue to do the thing D&D is best at: High fantasy, with epic battles.
Since that's mostly what I like in gaming, I'm sold.
While I was not happy about the change in resolutions, going from a 1600x1200 display to a 1920x1200 display has been a big win.
News flash: My field of vision is wider than it is tall.
It costs more than it's worth to me.
Really, I mean, where's the hard part in understanding this? Reliability on a small scale is easy. Reliability on a large scale rapidly becomes much, much, more expensive.
Is it worth twice as much to me to have 99% instead of 95%? Is it worth 10x as much to me to have 99.5% instead of 99%?
Sooner or later, the answer is "no". The cost of those last bits of reliability quickly gets ludicrous, while their impact decays rapidly.
My phone probably fails-to-call one or two times in a hundred. I hit redial and I'm done. No, it would not be worth it to me to have a phone and phone service which cost twice as much to not have to hit that redial button.
This is like reporting that canes and walkers don't actually help most people move faster than they would without them.
Duh.
Well, if nothing else, I think it's safe to say that there's been little to no clinical testing on drug interactions in the case you describe. Maybe if you quit combining untested neuroactive chemicals with the prescribed ones, they'd be more likely to work?
Well, wait.
This is just OOXML without the angle brackets, isn't it?