Not my point. My point is that, as a part of how the program works, it displays substantial parts of itself. That's also true of, for instance, Bison. (Bison includes a special exemption for that reason.) The fact that it happens to operate over a client-server protocol is irrelevant to that issue.
Sure, it's output, but the output incorporates part of the program. The clause you originally stated makes it clear that the output may be covered.
I'm pretty sure there should be a line break after the dnl. In m4, dnl is like C++'s// comment marker: it causes the rest of the line to be ignored. It's typically put after lines in the.mc file to suppress a blank newline from being emitted in the.cf file (which is a purely cosmetic issue).
The same goes for the block of defines under "Settings".
The biggest assumptions it makes would be that macs break down at the same rate PCs do and that mac users require the same amount of technical support PC users do.
The second biggest assumption is that users are properly identifying themselves. Mac users long ago learned that a large number of support techs slam on the brakes as soon as you say the word "Mac". (Even the ones who say they support Apples.) I use FreeBSD on my primary workstation, and OS X on my laptop. If asked by a support tech, I typically just say that I'm using Windows 98 and translate their instructions in my head.
I'm not intentionally trolling, it all sucks to varying degrees.
I haven't been happy with an OS since Genera. And not really even then.
Let me make one thing perfectly clear. All OSs suck. All processor architectures suck. I have strong feelings about which suck less, but I will happily proclaim that they all suck.
All OSs and all architectures will probably continue to suck until long after you, I, and every person with a/. uid under 131072 are dead and buried.
Also, it might be nice to have a "trust once" button, to temporarily trust a site for a single visit.
This is rife for abuse. Remember that once you trust a site, its ActiveX can change all the entire rules for trust.
Sure, you run without ActiveX on, even for trusted sites. But J. Random Luser who sees the "Trust Once" option doesn't. And he doesn't realize that by trusting a site once, he's giving them the ability to take control his computer forever.
Try running Jordy's and qtcomponents' plugins against ogg files. Look at the stack traces when they crash; you'll notice that they're the same. I seriously doubt that Jordy just happened to use the same function names and line numbers, so I figure he's adapted the qtcomponents code to use CoreAudio, and fixed some of the more glaring bugs. (The original was BSD licensed, so it's his perogative to not release his source.)
But it looks like the interface that QuickTime uses into the component changed somehow. (It's likely that the original author was unknowingly using an undocumented quirk.) If you look at the forums on qtcomponents, you'll see that somebody found that the sample count being sent into the component was 0. I played around with the qtcomponents source, but haven't yet gotten anywhere useful.
Since I did that, I saw the analysis from Apple in the qtcomponents bug #1144430. It looks like there's probably some significant work to be done here, rather than a simple patch. I did ask Jordy to open his source, but I don't know if he'll do it.
Well, I've been looking for a Mac coding project; maybe this is the thing. But it's probably over my head.
So no, Mac OS X is not now and has never been Unix. But neither is it something entirely different from Unix with a Unix-compatitbility layer bolted on.
Well, the OS X Summary Service won't cut apart sentences, so it returns what it feels is the best summary sentence, although it's 75 words. However, since you did ask for 50 words or less, I've hand-altered the result to meet your request. Enjoy!
Since the major ingredient for the success of a worm or virus is some ability to spread, witness the fact that there is no way with anything built into Mac OS X to perform automated propagation of a virus, and no current known ways
I was interviewing one guy, and asked if he knows Lisp. He didn't. So I handed him a short bit of Lisp code and asked him to make a particular change. I wasn't interested in if he did it right (he didn't), but rather how he handled the situation (very well). I've been working side-by-side with him for years now, and am very happy to do so. Next time I'm interviewing a programmer, I'll do the same thing.
But even there, some basic technical questions can be good for a quick bit of preliminary screening. Consider this: my old roommate was interviewing for a Unix sysadmin. He had applicants with "X years of Unix experience" on their resume, but couldn't tell him what ls does. Sure, phone screening won't catch everybody who doesn't meet the basic qualifications. It won't even catch half of them. It certainly won't tell you who the diamond in the rough is. But it's a quick way to weed out some people who are blatanly unsuited for the job, without the time and expense of an interview.
Maybe the guy could have learned Unix well. But he said he already had, and clearly hadn't. Would you want him as your sysadmin? What about when he tells you, "yes, I've automated backups"? Could you believe it? Would you know to assign him tasks that let him self-train, or would you just throw him at the server like an experienced sysadmin?
The article says that he used to give kids $2 bills as lunch money. It's an uncommon item, and the kids thought it was neat. A source of some amusement.
Now his son doesn't want to take them, because of the trouble it caused. What's the lesson? Straying from the norm gets you in trouble. A little uniqueness used to be a source of amusement, now it's a source of fear. I feel sad about this.
It reminds me of the Harry Chapin song, "Flowers Are Red".
I don't give a rat's ass what the advertisers paid for, or what their business model is.
But remember that the only reason that TV show is showing, is because of the advertisers. If their model fails, then they don't have any incentive to make the show.
Them adapting to show you ads while you fast-forward lets them continue to provide content when their normal advertising model becomes less relevant. They're adapting to the newer technology. We've been after the RIAA to adapt, rather than fight, new technologies. Why should we expect anything less from TV advertisers?
What I want is to walk into a store and pick up a digital recorder that records on a HD that I don't have the idiotic monthly fee. Just give me a recording device that..you know...comes on at 8pm, records an hour, then goes off at 9pm.
That's what the TiVo does if you don't pay the monthly fee.
One problem with the "official" names is that none of them are good in casual conversation.
Most of them are at least four syllables and sound stilted. "X11" doesn't just liltingly trip over your tongue. (I blame the syllable transition "ee-leh".)
But plain "X" doesn't really lend itself to ideal conversation either: it's the prefix to a lot of terms used in such conversation (xterm, xfree86, etc), and so there's a desire-- and a good one-- to append something to close off the term, so somebody isn't listening for the rest of the word anymore.
That's why "X Windows", I feel, is such a common term. It fills a need that the officially-sanctioned terms don't.
No, I received a collection of bits. What I bought was a song. If Apple marketed this as "Buy a collection of bits for 99 cents! (PS: It might happen to play a song on some device you own.)" then I would have bought a collection of bits. But Apple markets this as "99 cents a song!" So, as far as I'm concerned, I'm buying a song. It just happens to be transferred as a collection of bits.
Besides, if I bought a collection of bits, then there should be no problem if I decrypt it to make an entirely different collection of bits, and give that to my friends. But because these two entirely different collection of bits form the same song, the copyright holders get upset.
IANAL.
Re:Good LORD it's got some useless stuff!
on
KDE 3.4 Released
·
· Score: 1
It's also useful for predicting software completion target dates. Am I the only one that read the pom manpage?
When I started working for my employer several years ago I signed an IP agreement that states anything I think while working for them is theirs, as well as anything I've ever thought in the past if it enters their building; dumb, but I needed a job.
When I start a job that wants such an agreement, I always add a rider that anything I do in my own time, on my own equipment, is mine, not theirs. The FSF also requires a copyright assignment from your employer or university before accepting changes, to prevent this sort of problem.
In some states (such as California), it's a moot issue: anything you do on your own time, on your own equipment, is yours. Period. The employer can't usurp that with a blanket statement. (I'm not a lawyer, and this isn't legal advice.) So you may have an out through your state law.
So far, so good, but I'd really appreciate it if the gcc guys would get it right before releasing stuff.
The gcc guys are often better about this than the Red Hat guys. Red Hat has gained a certain amount of notoriety by releasing broken patches to the compiler toolchain.
Just to clarify, The Way Things Go was by Peter Fischli and David Weiss. I actually own a copy, and it's much different than what Rube Goldberg produced. He made comics that featured those sorts of contraptions, but with a much more humerous style.
Most of Rube's stuff wouldn't actually work (too many variables, like the reactions of animals), but was funny to look at. Fiscli and Weiss's work wasn't funny, but it is amazing that it actually worked.
just as a side-note: it is possible to publish a description of a vulnerability/weakness without publishing example code that exploits said weakness.
This causes a couple of problems.
First, the sysadmins of the world can't tell if they're vulnerable. I've had many times when I couldn't tell from the description (from the vendor or the original report) whether the systems I'm responsible for are vulnerable or not.
When you get a security patch (from a closed-source vendor), it rarely says which specific security issues it addresses. More often, it's "Changes to the FOO module" or something equally vague. So the sysadmins still can't tell whether or not they're vulnerable.
Sometimes, patches-- if applied in a particular order-- can fail to close vulnerabilites. (Some Microsoft hotfixes worked this way: if you applied hotfix A before you installed subsystem B, but later installed subsystem B, then the vulnerability that hotfix A was meant to fix is still in subsystem B, but hotfix A won't install because it's been applied once already.)
That's the first problem. The second problem is one of denial. I'm going to pick on MS again, not just because it's so fun to do so (although that's part of it), but also because it's easy.
Last year, MS was told-- by a reputable security group-- of a vulnerability. I believe it was the DCOM vuln that another reply to you mentioned, but I could be mistaken. MS said, "It's only a theoretical problem" and said that they wouldn't be addressing it. The security group created exploit code. "It's not in the wild... we won't address it." Etc, etc... in short, MS refused to acknowledge that it was even a vulnerability until it was too late-- ie, until lots of people had viruses.
Public disclosure became commonplace because vendors refused to address-- or sometimes even acknowledge-- bugs unless they were made publicly known. (Why should they? It's not harming the company until they start losing consumer confidence. Remember, boys and girls, effective capitalism requires consumer knowledge about products!) Nowdays, we see the situation in which vendors refuse to acknowledge bugs that are only described; until it can be demonstrated, it doesn't exist. And unless it's in the public eye, it doesn't exist. So you have to demonstrate the vulnerability, in a public manner: ie, publish the exploit.
Here's the irony. Vendors are against public disclosure of vulnerabilities, and say that responsible people shouldn't publish their findings; it's irresponsible to make vulns known. But public disclosure only became commonplace because the vendors were irresponsible about fixing vulns. If they had been fixing them in a timely fashion, without needing public disclosure, then we wouldn't have set up things like BugTraq and the like.
Re:XSLT is a piece of cake?
on
Effective XML
·
· Score: 1
Not sure I agree. I had to convert the XML log from subversion into an RSS feed (which is also XML) but while I did use XSLT for 99% of the transformation, I still had to pipe it through perl to do a few things that XSLT couldn't, since it doesn't even do simple string replacements (only translation from one character to another).
You may want to check out EXSLT, in your case the str:replace function.
Slashdot Mirror
Not my point. My point is that, as a part of how the program works, it displays substantial parts of itself. That's also true of, for instance, Bison. (Bison includes a special exemption for that reason.) The fact that it happens to operate over a client-server protocol is irrelevant to that issue.
Sure, it's output, but the output incorporates part of the program. The clause you originally stated makes it clear that the output may be covered.
IANAL.
I'm not saying that it would be a copyright problem; I'm just saying that the "output" clause of the GPL does not cause screenshots to be exempted.
I have heard nothing of the eugenics program of which you speak. Where can I learn more?
I'm pretty sure there should be a line break after the dnl. In m4, dnl is like C++'s // comment marker: it causes the rest of the line to be ignored. It's typically put after lines in the .mc file to suppress a blank newline from being emitted in the .cf file (which is a purely cosmetic issue).
The same goes for the block of defines under "Settings".
The biggest assumptions it makes would be that macs break down at the same rate PCs do and that mac users require the same amount of technical support PC users do.
The second biggest assumption is that users are properly identifying themselves. Mac users long ago learned that a large number of support techs slam on the brakes as soon as you say the word "Mac". (Even the ones who say they support Apples.) I use FreeBSD on my primary workstation, and OS X on my laptop. If asked by a support tech, I typically just say that I'm using Windows 98 and translate their instructions in my head.
I'm not intentionally trolling, it all sucks to varying degrees.
I haven't been happy with an OS since Genera. And not really even then.
Let me make one thing perfectly clear. All OSs suck. All processor architectures suck. I have strong feelings about which suck less, but I will happily proclaim that they all suck.
All OSs and all architectures will probably continue to suck until long after you, I, and every person with a /. uid under 131072 are dead and buried.
Also, it might be nice to have a "trust once" button, to temporarily trust a site for a single visit.
This is rife for abuse. Remember that once you trust a site, its ActiveX can change all the entire rules for trust.
Sure, you run without ActiveX on, even for trusted sites. But J. Random Luser who sees the "Trust Once" option doesn't. And he doesn't realize that by trusting a site once, he's giving them the ability to take control his computer forever.
Well, here's the deal as far as I've noticed.
Try running Jordy's and qtcomponents' plugins against ogg files. Look at the stack traces when they crash; you'll notice that they're the same. I seriously doubt that Jordy just happened to use the same function names and line numbers, so I figure he's adapted the qtcomponents code to use CoreAudio, and fixed some of the more glaring bugs. (The original was BSD licensed, so it's his perogative to not release his source.)
But it looks like the interface that QuickTime uses into the component changed somehow. (It's likely that the original author was unknowingly using an undocumented quirk.) If you look at the forums on qtcomponents, you'll see that somebody found that the sample count being sent into the component was 0. I played around with the qtcomponents source, but haven't yet gotten anywhere useful.
Since I did that, I saw the analysis from Apple in the qtcomponents bug #1144430. It looks like there's probably some significant work to be done here, rather than a simple patch. I did ask Jordy to open his source, but I don't know if he'll do it.
Well, I've been looking for a Mac coding project; maybe this is the thing. But it's probably over my head.
So no, Mac OS X is not now and has never been Unix. But neither is it something entirely different from Unix with a Unix-compatitbility layer bolted on.
For that, the user is referred to A/UX.
Well, the OS X Summary Service won't cut apart sentences, so it returns what it feels is the best summary sentence, although it's 75 words. However, since you did ask for 50 words or less, I've hand-altered the result to meet your request. Enjoy!
I was interviewing one guy, and asked if he knows Lisp. He didn't. So I handed him a short bit of Lisp code and asked him to make a particular change. I wasn't interested in if he did it right (he didn't), but rather how he handled the situation (very well). I've been working side-by-side with him for years now, and am very happy to do so. Next time I'm interviewing a programmer, I'll do the same thing.
But even there, some basic technical questions can be good for a quick bit of preliminary screening. Consider this: my old roommate was interviewing for a Unix sysadmin. He had applicants with "X years of Unix experience" on their resume, but couldn't tell him what ls does. Sure, phone screening won't catch everybody who doesn't meet the basic qualifications. It won't even catch half of them. It certainly won't tell you who the diamond in the rough is. But it's a quick way to weed out some people who are blatanly unsuited for the job, without the time and expense of an interview.
Maybe the guy could have learned Unix well. But he said he already had, and clearly hadn't. Would you want him as your sysadmin? What about when he tells you, "yes, I've automated backups"? Could you believe it? Would you know to assign him tasks that let him self-train, or would you just throw him at the server like an experienced sysadmin?
They say, "It just works".
I sit with skepticism.
Microsoft go home.
Uh, that's what the "patent" bit was referring to.
The article says that he used to give kids $2 bills as lunch money. It's an uncommon item, and the kids thought it was neat. A source of some amusement.
Now his son doesn't want to take them, because of the trouble it caused. What's the lesson? Straying from the norm gets you in trouble. A little uniqueness used to be a source of amusement, now it's a source of fear. I feel sad about this.
It reminds me of the Harry Chapin song, "Flowers Are Red".
I don't give a rat's ass what the advertisers paid for, or what their business model is.
But remember that the only reason that TV show is showing, is because of the advertisers. If their model fails, then they don't have any incentive to make the show.
Them adapting to show you ads while you fast-forward lets them continue to provide content when their normal advertising model becomes less relevant. They're adapting to the newer technology. We've been after the RIAA to adapt, rather than fight, new technologies. Why should we expect anything less from TV advertisers?
What I want is to walk into a store and pick up a digital recorder that records on a HD that I don't have the idiotic monthly fee. Just give me a recording device that..you know...comes on at 8pm, records an hour, then goes off at 9pm.
That's what the TiVo does if you don't pay the monthly fee.
One problem with the "official" names is that none of them are good in casual conversation.
Most of them are at least four syllables and sound stilted. "X11" doesn't just liltingly trip over your tongue. (I blame the syllable transition "ee-leh".)
But plain "X" doesn't really lend itself to ideal conversation either: it's the prefix to a lot of terms used in such conversation (xterm, xfree86, etc), and so there's a desire-- and a good one-- to append something to close off the term, so somebody isn't listening for the rest of the word anymore.
That's why "X Windows", I feel, is such a common term. It fills a need that the officially-sanctioned terms don't.
You BOUGHT a collection of BITs
No, I received a collection of bits. What I bought was a song. If Apple marketed this as "Buy a collection of bits for 99 cents! (PS: It might happen to play a song on some device you own.)" then I would have bought a collection of bits. But Apple markets this as "99 cents a song!" So, as far as I'm concerned, I'm buying a song. It just happens to be transferred as a collection of bits.
Besides, if I bought a collection of bits, then there should be no problem if I decrypt it to make an entirely different collection of bits, and give that to my friends. But because these two entirely different collection of bits form the same song, the copyright holders get upset.
IANAL.
It's also useful for predicting software completion target dates. Am I the only one that read the pom manpage?
When I started working for my employer several years ago I signed an IP agreement that states anything I think while working for them is theirs, as well as anything I've ever thought in the past if it enters their building; dumb, but I needed a job.
When I start a job that wants such an agreement, I always add a rider that anything I do in my own time, on my own equipment, is mine, not theirs. The FSF also requires a copyright assignment from your employer or university before accepting changes, to prevent this sort of problem.
In some states (such as California), it's a moot issue: anything you do on your own time, on your own equipment, is yours. Period. The employer can't usurp that with a blanket statement. (I'm not a lawyer, and this isn't legal advice.) So you may have an out through your state law.
One data point you can use is the mplayer FAQ.
So far, so good, but I'd really appreciate it if the gcc guys would get it right before releasing stuff.
The gcc guys are often better about this than the Red Hat guys. Red Hat has gained a certain amount of notoriety by releasing broken patches to the compiler toolchain.
Most of Rube's stuff wouldn't actually work (too many variables, like the reactions of animals), but was funny to look at. Fiscli and Weiss's work wasn't funny, but it is amazing that it actually worked.
just as a side-note: it is possible to publish a description of a vulnerability/weakness without publishing example code that exploits said weakness.
This causes a couple of problems.
First, the sysadmins of the world can't tell if they're vulnerable. I've had many times when I couldn't tell from the description (from the vendor or the original report) whether the systems I'm responsible for are vulnerable or not.
When you get a security patch (from a closed-source vendor), it rarely says which specific security issues it addresses. More often, it's "Changes to the FOO module" or something equally vague. So the sysadmins still can't tell whether or not they're vulnerable.
Sometimes, patches-- if applied in a particular order-- can fail to close vulnerabilites. (Some Microsoft hotfixes worked this way: if you applied hotfix A before you installed subsystem B, but later installed subsystem B, then the vulnerability that hotfix A was meant to fix is still in subsystem B, but hotfix A won't install because it's been applied once already.)
That's the first problem. The second problem is one of denial. I'm going to pick on MS again, not just because it's so fun to do so (although that's part of it), but also because it's easy.
Last year, MS was told-- by a reputable security group-- of a vulnerability. I believe it was the DCOM vuln that another reply to you mentioned, but I could be mistaken. MS said, "It's only a theoretical problem" and said that they wouldn't be addressing it. The security group created exploit code. "It's not in the wild... we won't address it." Etc, etc... in short, MS refused to acknowledge that it was even a vulnerability until it was too late-- ie, until lots of people had viruses.
Public disclosure became commonplace because vendors refused to address-- or sometimes even acknowledge-- bugs unless they were made publicly known. (Why should they? It's not harming the company until they start losing consumer confidence. Remember, boys and girls, effective capitalism requires consumer knowledge about products!) Nowdays, we see the situation in which vendors refuse to acknowledge bugs that are only described; until it can be demonstrated, it doesn't exist. And unless it's in the public eye, it doesn't exist. So you have to demonstrate the vulnerability, in a public manner: ie, publish the exploit.
Here's the irony. Vendors are against public disclosure of vulnerabilities, and say that responsible people shouldn't publish their findings; it's irresponsible to make vulns known. But public disclosure only became commonplace because the vendors were irresponsible about fixing vulns. If they had been fixing them in a timely fashion, without needing public disclosure, then we wouldn't have set up things like BugTraq and the like.
Not sure I agree. I had to convert the XML log from subversion into an RSS feed (which is also XML) but while I did use XSLT for 99% of the transformation, I still had to pipe it through perl to do a few things that XSLT couldn't, since it doesn't even do simple string replacements (only translation from one character to another).
You may want to check out EXSLT, in your case the str:replace function.