Oh shut up. The government isn't banning the film because it speaks badly about the government. A distributor is choosing not to distribute it, for a myriad of reasons, the most obvious ones being political. The first ammendment gives you a right to expression; it doesn't promise you anyone will give you a bullhorn.
And in that particular case, it looks like another distributor is going to pick up the film anyway.
Yes, Mr. Lawyerman. Apparently, my heartbate rose, although at the time I was not aware of it. I can't speak with certainty about whether this was due to arousal in Ms. Hotbabe's presence. In any case, I was entirely in control of my faculties and at no point made any harrassing gestures or comment, nor did I take any inapropriate actions.
Please. This thing would potentially make more information available, but if you and I can easily see the falacy of jumping from one relatively useless fact to a conclusion, what makes you think the courts can't? I'm all for protection of privacy, but this is a straw-man argument.
And that is why trademark, by and large, really isn't a very sane concept - and even less so when ascribed to something as simple and obvious as a catch phrase.
Copyright law, arguably, makes sense when you're talking about complex, unique works that take substantial time to create - although I could put forth an argument that says you shouldn't be able to own ideas, period, no matter how complex their manifestation. But to apply that sort of protection to something as simple as a name or phrase is absurd.
It's not sane at all that any one person should be able to take monopoly rights over a simple phrase just because it's brought him some notoriety. If it's his reading of the phrase that's so special, he doesn't need to worry about whether anyone else will use it. It not, then what's so unique and special about the phrase that it deserves such protection?
I see your point about the scripts/executables being potentially malicious, but why not create a system that depends on similar scripts so long as they're human-readable? A security-concious admin could easily "more gaim-installer.sh" or whatever (this could be different if we're tlaking about a new package format and not traditional scripts, but you get the idea) and see what there is to see.
This may be happening now on some distros, but I'm not sure - I'd this we'd also see reasonable success if an installer worked like this:
double-click on a local package, possibly downloaded from a source without an apt (or similar) repository. a gui installer tool pops up, checks for any necessary dependencies (there shouldn't be any unless it really NEEDS an uncommon library or a bleeding edge versoin. Uncommon libraries should probably be included statically or at least available form the same source anyway). If it really needs another package, the gui tool tells you in plain english it's going to check on the internet to see if it's available, and somethng like apt goes looking. If it can find it, great. If not, it tells you in plain english what it needs - but common packaging practices should mean you get to this last step pretty rarely.
Much of that happens either via apt/up2date/whatever, but does it happen when you try to install a local package? I'm not sure - I'm limited in my experiece with some of the automated tools.
That's even better than what I was thinking. I was imagining a script-installer creation tool that would ask the packager a few quick questions about the files in the package, and generate appropriate scripts capable of addressing all the target distributions.
But that runs into the problem of neglecting minor distributions, or not anticipating new ones. The creation tool would need frequent updates ot keep up with all the new distros and revisions.
But with your idea - a standardized XMLish file detailing prefered file structure - the installer/package could jsut use that for a reference and do it's thing very nicely. elegant.
Why hasn't anyone developed a system that, from the End-user perspective, works similarly to MSI installations (which work very well). Point, click, next next next. In principal, DEBS/RPMs work similarly to MSIs, but the installation isn't as obvious a procedure to end-users.
And for that matter, why not make the installer intelligent about the distro? Use a single package/installer, but that includes all sorts of scripting information about installation in variosu circumstances. The installer checks to see if it's on RH9, and if so it puts files where RH9 expects them, editing any configurations and making RPM database entries as necessary. If it's on Debian, it takes the appropriate measures there. And so forth.
Why do we see such absurd dependencies that don't seem to happen in the windows and mac worlds? Install a new version of a KDE app, and you need the latest minor revision to the core KDE libs, which in turn requires a minor upgrade to the font server, etc. In the windows world, occasionally you need to update something big like DirectX to install a latest-and-greatest app, but even then the dependencies are often packaged with the app itself. Why isn't this practice more common in Linux/Unix (not counting Mac OS X)? I undestand that many of these apps are under CONSTANT quick-release development and are often tied to bleeding-edge versions of their libs, but why aren't major releases at least more dependency-friendly? Installing an app can be a real pain in the ass even with something like apt, if you don't have the dependencies in the repositories you've defined. And adding new respositories isn't exacly grandma-friendly.
He gives the Free software community a -bad- name? Hell, he's the one who gave it -A- name.
Yes, he's extreme in his vision of a software utopia. But if Free software is a good thing, it's not completely unreasonable to say an only Free software rule might be a great thing - and it's usefull to have someone around who insists that's the way things should be, if only to make the moderates look, well, more moderate.
Slashdot Mirror
So it's going to be posted four times in total?
Oh shut up. The government isn't banning the film because it speaks badly about the government. A distributor is choosing not to distribute it, for a myriad of reasons, the most obvious ones being political. The first ammendment gives you a right to expression; it doesn't promise you anyone will give you a bullhorn.
And in that particular case, it looks like another distributor is going to pick up the film anyway.
small nads are not efficient
Which does which?
THe greater crime, of course, is spreading Britney's music. With or without permission.
Yes, Mr. Lawyerman. Apparently, my heartbate rose, although at the time I was not aware of it. I can't speak with certainty about whether this was due to arousal in Ms. Hotbabe's presence. In any case, I was entirely in control of my faculties and at no point made any harrassing gestures or comment, nor did I take any inapropriate actions.
Please. This thing would potentially make more information available, but if you and I can easily see the falacy of jumping from one relatively useless fact to a conclusion, what makes you think the courts can't? I'm all for protection of privacy, but this is a straw-man argument.
Time is an illusion. Lunchtime doubly so.
Now there's just baiting the jokes.
Just imagine a Natalie Portman of these!
Hold on, let me bring up the Charlton Heston clip they showed on the news last night - TIVO recorded it for me - and its ...
What is this? Gay Porn? Tivo thinks I'm gay!
"'I, Robot' was the first *adult* (ie, no pictures in it) book I ever read as a kid, at the age of maybe 4 or 5."
.... All the *adult* books I read DO have pictures in them!
Hmmm
And that is why trademark, by and large, really isn't a very sane concept - and even less so when ascribed to something as simple and obvious as a catch phrase.
Copyright law, arguably, makes sense when you're talking about complex, unique works that take substantial time to create - although I could put forth an argument that says you shouldn't be able to own ideas, period, no matter how complex their manifestation. But to apply that sort of protection to something as simple as a name or phrase is absurd.
It's not sane at all that any one person should be able to take monopoly rights over a simple phrase just because it's brought him some notoriety. If it's his reading of the phrase that's so special, he doesn't need to worry about whether anyone else will use it. It not, then what's so unique and special about the phrase that it deserves such protection?
Anybody want a peanut?
"I don't think something with a 5.6 inch screen would fit vary comfortably in most anyones hand."
... hand ... must resist ... dirty joke ...
inches
... this could be used for the best game of Populous EVER.
apparently, several.
You and me, let's go redesign linux. Should be fun.
I see your point about the scripts/executables being potentially malicious, but why not create a system that depends on similar scripts so long as they're human-readable? A security-concious admin could easily "more gaim-installer.sh" or whatever (this could be different if we're tlaking about a new package format and not traditional scripts, but you get the idea) and see what there is to see.
This may be happening now on some distros, but I'm not sure - I'd this we'd also see reasonable success if an installer worked like this:
double-click on a local package, possibly downloaded from a source without an apt (or similar) repository. a gui installer tool pops up, checks for any necessary dependencies (there shouldn't be any unless it really NEEDS an uncommon library or a bleeding edge versoin. Uncommon libraries should probably be included statically or at least available form the same source anyway). If it really needs another package, the gui tool tells you in plain english it's going to check on the internet to see if it's available, and somethng like apt goes looking. If it can find it, great. If not, it tells you in plain english what it needs - but common packaging practices should mean you get to this last step pretty rarely.
Much of that happens either via apt/up2date/whatever, but does it happen when you try to install a local package? I'm not sure - I'm limited in my experiece with some of the automated tools.
That's even better than what I was thinking. I was imagining a script-installer creation tool that would ask the packager a few quick questions about the files in the package, and generate appropriate scripts capable of addressing all the target distributions.
But that runs into the problem of neglecting minor distributions, or not anticipating new ones. The creation tool would need frequent updates ot keep up with all the new distros and revisions.
But with your idea - a standardized XMLish file detailing prefered file structure - the installer/package could jsut use that for a reference and do it's thing very nicely. elegant.
Why hasn't anyone developed a system that, from the End-user perspective, works similarly to MSI installations (which work very well). Point, click, next next next. In principal, DEBS/RPMs work similarly to MSIs, but the installation isn't as obvious a procedure to end-users.
And for that matter, why not make the installer intelligent about the distro? Use a single package/installer, but that includes all sorts of scripting information about installation in variosu circumstances. The installer checks to see if it's on RH9, and if so it puts files where RH9 expects them, editing any configurations and making RPM database entries as necessary. If it's on Debian, it takes the appropriate measures there. And so forth.
Why do we see such absurd dependencies that don't seem to happen in the windows and mac worlds? Install a new version of a KDE app, and you need the latest minor revision to the core KDE libs, which in turn requires a minor upgrade to the font server, etc. In the windows world, occasionally you need to update something big like DirectX to install a latest-and-greatest app, but even then the dependencies are often packaged with the app itself. Why isn't this practice more common in Linux/Unix (not counting Mac OS X)? I undestand that many of these apps are under CONSTANT quick-release development and are often tied to bleeding-edge versions of their libs, but why aren't major releases at least more dependency-friendly? Installing an app can be a real pain in the ass even with something like apt, if you don't have the dependencies in the repositories you've defined. And adding new respositories isn't exacly grandma-friendly.
who is doing all the studying?
now that's funny.
anyone else notice he lumped EMACS in with the operating systems? I think we all know EMACS is much more substantial than that :)
He gives the Free software community a -bad- name? Hell, he's the one who gave it -A- name.
Yes, he's extreme in his vision of a software utopia. But if Free software is a good thing, it's not completely unreasonable to say an only Free software rule might be a great thing - and it's usefull to have someone around who insists that's the way things should be, if only to make the moderates look, well, more moderate.
He'll outgrow it. Mine used to do this too, but he stopped somewhere around the time he turned 24.
He said he doesn't like the videotapes as much, but then again he never did enjoy serial.