As long as they don't live off tax money, they are in no way restricted in the source of their research.... reason being, Bush's constituency resents embryos being used for productive science rather than just rotting in medical waste containers.
yeah but there's no license agreement when you buy music. you're buying a piece of physical media which has copyrighted material on it, copyright of which belongs to some record company which typically "reserves all rights" leaving you (legally) unable to copy it except for fair use. no EULA involved.
Okay, sorry for being short and smug in my reply, but really I don't think the two words mean different things at all. If m-w suggests some difference in nuance between theft and stealing, it doesn't represent common usage at all and is a much more well-hidden suggestion than all the suggestions that they're the same.
Theft is removing property, so that every part of the property is removed from it's former position. Steal is to take without right or leave the property of another.
Did you find those in a dictionary, or just make them up for your own convenience? Theft: 1 a : the act of stealing
It should be left up to each worker whether or not to participate. For these workers, the strike might mean that they lose the job permanently. This might be OK with some workers, but not others.
The whole idea of the union is that if the whole union strikes, an employer can't fire the strikers cause there won't be anyone to do the work. In a sufficiently widespread strike, every individual is much better off breaking the strike; the point of the union is that individuals aren't allowed to break the strike if it is decided that it's in the general interest of the union. This means you sign away some rights when you join a union, like the right not to strike when it'd be to your disadvantage. So if you want to be able to choose whether or not to strike, then don't join a union, and find out what kind of power you have when you have only your own work to bargain with.
The total number of drives sold has nothing to do with the accuracy of a statistic based on a sample. 1/sqrt(40)=0.158 so the error's about 16%. So if anywhere near 100% of the 40 drives is failing, they're still doing pretty badly.
Yeah but the $50 is peanuts, as is the money they drop. It'd take forever to make any money that way; much faster to keep running around to all your shady businesses and collecting protection money, or else (if you've beaten the plot of the game) steal the Apache helicopter and use it to blow lots of shit up on the vigilante missions, that shit is more fun than punching the random petit criminals. (Besides, if you do anything besides punch them the cop will come after you too. what a crock of shit.)
wow... hostility. Firstly there's no conspiracy of geeks to keep unix hard. Second it's not that hard to use the unix CLI... ever tried? Third, it sounds as though you don't know much about the unix filesystem and you want it simplified so that you won't have to learn it - which is fine, but the basics aren't that difficult to begin with. It's true, the three-letter directory names don't make much sense, but that's just maybe four more word-to-concept mappings to memorize; not that big a deal. If you want to propose improvements to the unix system please do, but make sure you actually understand the pros and cons of the existing one, cause if all you do is rant about how it sucks then nobody will take you seriously.
case in point: the/etc thing isn't that hard./etc is used for system-wide and user-overridable-default config files. Per-user config files go in the user's home directory./usr/lib is definitely not used for config files; it's used for libraries. I'm not formally trained in unix - i learned by doing - but this much is clear to me. Also, 'usr' isn't short for 'users' (I believe it's [something] system resources?)... and it wouldn't make any sense if it was. Nothing per-user goes there at all, because nothing under the/usr hierarchy is writable by users. Sure, it's counterintuitive - but now you know. Was it that hard?
Re:Knoppix -- note: we were talking about Knoppix
on
Libranet 2.8 Review
·
· Score: 1
The SCO lawsuit isn't a software patent one, rather it's copyright-related. If there actually is infringing code in linux then it's prosecutable in Europe too.
Where did you hear that libavcodec is better (I assume you mean for encoding) than xvid? It's widely used as a decoder - probably the best option for mplayer, and also gaining a lot of ground with ffdshow in windows - but I've never heard that it's a particularly high-quality mpeg4 encoder compared to divx or xvid. It's possible (since I've never tried it as an encoder) but one would think if it was better than xvid that you'd see more pirated ffmpeg-encoded stuff floating around. Where did you get your info?
it's true you can view sorenson on mplayer, and even get most of the common audio codecs to work, but good luck getting a good A/V sync. Be prepared to play with your keypad + and - keys for a good long time while watching that Animatrix episode.
In at least some of the cases (haven't looked into all of them), the students themselves sharing files wasn't the issue. See this for details. The guy was running an SMB share indexing service; a search engine, more or less. Nothing was indexed that people weren't already sharing. Of course most things indexed were probably illegal for the individual students on the network to be sharing, but they were shared independently of the existence of the search engine. The slippery-slope argument of course goes directly to Google being responsible for the same sort of contributory (rather than direct) copyright infringement.
I really would've liked to see another good precedent like the one that came out of the grokster/streamcast suit, especially since from the descriptions I've heard these cases don't seem to be about actual copyright infringement but yet more dubious "contributory" infringement by people running search services. I think when people hear the words "student" and "file sharing" together in a sentence they think something illegal must be going on - and it is, but the illegal activity isn't running the Phynd service. I hate to rehash the same old slippery-slope argument that appears in every YRO-type article, but what's really the difference between the Phynd service and Google? The practical argument is that almost all the indexed shares were illegal, whereas most things found on the web are legal these days - but that's a function of what protocol is popular for what. If people had discovered that it was easy to set up a web server on their own personal computers, share what they wanted, and have it indexed on google in among the rest of the web, and if HTTP rather than SMB/napster/kazaa then becamse the biggest file sharing medium, the RIAA would have to prosecute individual sharers rather than indexers. (Instead most people put websites on ISP servers or Geocities/etc. where they are shut down quickly if they have illegal content.)
Basically there's yet another line being crossed when a general-purpose search service - whatever its scope and whatever the protocol it uses - is called a piracy tool and shut down. Was Phynd more akin to Napster or Google, and why? Questions like that aren't lately being determined in a reasonable or even legalistic way, but rather by way of intimidation.
that's not the spammers' website, goddamnit. notice the filename is "slapp.pdf" == "Strategic Lawsuit Against Public Participation" == not something that the plaintiff calls his lawsuit.
slashdot effect's bad enough without it being used maliciously on the wrong targets.
would you buy a new (expensive) Apple computer or set up a new (complicated) OS in order to play doom III, if you were the average windows-only gamer? no.
ain't it the truth. The JDK and the fact that I can get at the (comprehensive, well-linked) API javadocs on the web anywhere, anytime are what make java worth using. Mod the man up.
I installed 3.1 (i believe) a couple months ago and it's what I'm running now. Installation is mostly easy; the only problem I ran into was with the bootloader and I'm pretty sure that was just cause I thought I was smart enough to configure LILO myself rather than letting the install script do it.
Once it's installed it seems to me the only potential problem is that it's a mix of different debian stability-levels so you can run into some dependency issues with the packaging system. Maybe that happens anyway; I wouldn't know cause I never ran a debian system before, and it's certainly usable anyway.
I know about video encoding, not necessarily capture, but there's really no comparison between the Windows and Linux offerings as things stand today. One thing I really admire Ars Technica for is that they most always choose the right tool for the job, and for video encoding (and, I could speculate, capture as well) the right OS at this point is Windows. The competitors, as far as encoding is concerned, are VirtualDub on Windows vs. mencoder and transcode on Linux. I find VirtualDub not only much more user-friendly but I also find I am much more confident that an encoding job will come out as planned using VirtualDub. Transcode/mencoder are indeed powerful tools and also have the advantage of batch encoding using shell scripts, but VDub has its own job-queueing system that has its own advantages (configurable with a GUI) as well as easy interfacing with AviSynth and many other helfpul utilities which more than make up for any capabilities it lacks itself. If someone writes a good GUI for Transcode which manages to hide all the quirks of its command line interface the situation will improve quite a bit; video encoding setup seems to me to be an area where one really should have a graphical tool (including still-frame previews and so on) to assist in getting the parameters right before starting the 4-hour encoding job.
If Ars posted an article like you suggest it would be about Linux advocacy instead of video capture. There's a huge community around video capture/encoding which is quite Windows-centric which is a resource of its own as well. Furthermore, the simple fact is that most people - even most Ars readers (and even most Slashdot readers) - run Windows; they have no responsibility for pointing out Linux's videocoding capabilities.
also -- don't just write me off as being windows-centric myself. I'm posting this from Linux right now -- Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030314 Phoenix/0.5. Perhaps not as hardcore as Lynx but that's how it goes.
Slashdot Mirror
As long as they don't live off tax money, they are in no way restricted in the source of their research. ... reason being, Bush's constituency resents embryos being used for productive science rather than just rotting in medical waste containers.
yeah but there's no license agreement when you buy music. you're buying a piece of physical media which has copyrighted material on it, copyright of which belongs to some record company which typically "reserves all rights" leaving you (legally) unable to copy it except for fair use. no EULA involved.
Okay, sorry for being short and smug in my reply, but really I don't think the two words mean different things at all. If m-w suggests some difference in nuance between theft and stealing, it doesn't represent common usage at all and is a much more well-hidden suggestion than all the suggestions that they're the same.
you only get Santorum if they use lube.
Theft is removing property, so that every part of the property is removed from it's former position. Steal is to take without right or leave the property of another.
Did you find those in a dictionary, or just make them up for your own convenience?
Theft:
1 a : the act of stealing
Actually I think education in the U.S. would be much improved if teaching was a higher-paying, higher-status job.
It should be left up to each worker whether or not to participate. For these workers, the strike might mean that they lose the job permanently. This might be OK with some workers, but not others.
The whole idea of the union is that if the whole union strikes, an employer can't fire the strikers cause there won't be anyone to do the work. In a sufficiently widespread strike, every individual is much better off breaking the strike; the point of the union is that individuals aren't allowed to break the strike if it is decided that it's in the general interest of the union. This means you sign away some rights when you join a union, like the right not to strike when it'd be to your disadvantage. So if you want to be able to choose whether or not to strike, then don't join a union, and find out what kind of power you have when you have only your own work to bargain with.
The total number of drives sold has nothing to do with the accuracy of a statistic based on a sample. 1/sqrt(40)=0.158 so the error's about 16%. So if anywhere near 100% of the 40 drives is failing, they're still doing pretty badly.
Yeah but the $50 is peanuts, as is the money they drop. It'd take forever to make any money that way; much faster to keep running around to all your shady businesses and collecting protection money, or else (if you've beaten the plot of the game) steal the Apache helicopter and use it to blow lots of shit up on the vigilante missions, that shit is more fun than punching the random petit criminals. (Besides, if you do anything besides punch them the cop will come after you too. what a crock of shit.)
wow... hostility. Firstly there's no conspiracy of geeks to keep unix hard. Second it's not that hard to use the unix CLI... ever tried? Third, it sounds as though you don't know much about the unix filesystem and you want it simplified so that you won't have to learn it - which is fine, but the basics aren't that difficult to begin with. It's true, the three-letter directory names don't make much sense, but that's just maybe four more word-to-concept mappings to memorize; not that big a deal. If you want to propose improvements to the unix system please do, but make sure you actually understand the pros and cons of the existing one, cause if all you do is rant about how it sucks then nobody will take you seriously.
/etc thing isn't that hard. /etc is used for system-wide and user-overridable-default config files. Per-user config files go in the user's home directory. /usr/lib is definitely not used for config files; it's used for libraries. I'm not formally trained in unix - i learned by doing - but this much is clear to me. Also, 'usr' isn't short for 'users' (I believe it's [something] system resources?) ... and it wouldn't make any sense if it was. Nothing per-user goes there at all, because nothing under the /usr hierarchy is writable by users. Sure, it's counterintuitive - but now you know. Was it that hard?
case in point: the
no, it's not.
The SCO lawsuit isn't a software patent one, rather it's copyright-related. If there actually is infringing code in linux then it's prosecutable in Europe too.
Where did you hear that libavcodec is better (I assume you mean for encoding) than xvid? It's widely used as a decoder - probably the best option for mplayer, and also gaining a lot of ground with ffdshow in windows - but I've never heard that it's a particularly high-quality mpeg4 encoder compared to divx or xvid. It's possible (since I've never tried it as an encoder) but one would think if it was better than xvid that you'd see more pirated ffmpeg-encoded stuff floating around. Where did you get your info?
it's true you can view sorenson on mplayer, and even get most of the common audio codecs to work, but good luck getting a good A/V sync. Be prepared to play with your keypad + and - keys for a good long time while watching that Animatrix episode.
In at least some of the cases (haven't looked into all of them), the students themselves sharing files wasn't the issue. See this for details. The guy was running an SMB share indexing service; a search engine, more or less. Nothing was indexed that people weren't already sharing. Of course most things indexed were probably illegal for the individual students on the network to be sharing, but they were shared independently of the existence of the search engine. The slippery-slope argument of course goes directly to Google being responsible for the same sort of contributory (rather than direct) copyright infringement.
I really would've liked to see another good precedent like the one that came out of the grokster/streamcast suit, especially since from the descriptions I've heard these cases don't seem to be about actual copyright infringement but yet more dubious "contributory" infringement by people running search services. I think when people hear the words "student" and "file sharing" together in a sentence they think something illegal must be going on - and it is, but the illegal activity isn't running the Phynd service. I hate to rehash the same old slippery-slope argument that appears in every YRO-type article, but what's really the difference between the Phynd service and Google? The practical argument is that almost all the indexed shares were illegal, whereas most things found on the web are legal these days - but that's a function of what protocol is popular for what. If people had discovered that it was easy to set up a web server on their own personal computers, share what they wanted, and have it indexed on google in among the rest of the web, and if HTTP rather than SMB/napster/kazaa then becamse the biggest file sharing medium, the RIAA would have to prosecute individual sharers rather than indexers. (Instead most people put websites on ISP servers or Geocities/etc. where they are shut down quickly if they have illegal content.)
Basically there's yet another line being crossed when a general-purpose search service - whatever its scope and whatever the protocol it uses - is called a piracy tool and shut down. Was Phynd more akin to Napster or Google, and why? Questions like that aren't lately being determined in a reasonable or even legalistic way, but rather by way of intimidation.
that's not the spammers' website, goddamnit. notice the filename is "slapp.pdf" == "Strategic Lawsuit Against Public Participation" == not something that the plaintiff calls his lawsuit.
slashdot effect's bad enough without it being used maliciously on the wrong targets.
more like 57 messages/user/day i'd think. way too much anyway, but seems more realistic.
not a bad idea, bring back the old Apple II days.
would you buy a new (expensive) Apple computer or set up a new (complicated) OS in order to play doom III, if you were the average windows-only gamer? no.
A much-better-than-any-linux-shell shell, I might add.
ain't it the truth. The JDK and the fact that I can get at the (comprehensive, well-linked) API javadocs on the web anywhere, anytime are what make java worth using. Mod the man up.
So your point is that if there's something to protest about, you shouldn't protest?
I installed 3.1 (i believe) a couple months ago and it's what I'm running now. Installation is mostly easy; the only problem I ran into was with the bootloader and I'm pretty sure that was just cause I thought I was smart enough to configure LILO myself rather than letting the install script do it.
Once it's installed it seems to me the only potential problem is that it's a mix of different debian stability-levels so you can run into some dependency issues with the packaging system. Maybe that happens anyway; I wouldn't know cause I never ran a debian system before, and it's certainly usable anyway.
I know about video encoding, not necessarily capture, but there's really no comparison between the Windows and Linux offerings as things stand today. One thing I really admire Ars Technica for is that they most always choose the right tool for the job, and for video encoding (and, I could speculate, capture as well) the right OS at this point is Windows. The competitors, as far as encoding is concerned, are VirtualDub on Windows vs. mencoder and transcode on Linux. I find VirtualDub not only much more user-friendly but I also find I am much more confident that an encoding job will come out as planned using VirtualDub. Transcode/mencoder are indeed powerful tools and also have the advantage of batch encoding using shell scripts, but VDub has its own job-queueing system that has its own advantages (configurable with a GUI) as well as easy interfacing with AviSynth and many other helfpul utilities which more than make up for any capabilities it lacks itself. If someone writes a good GUI for Transcode which manages to hide all the quirks of its command line interface the situation will improve quite a bit; video encoding setup seems to me to be an area where one really should have a graphical tool (including still-frame previews and so on) to assist in getting the parameters right before starting the 4-hour encoding job.
If Ars posted an article like you suggest it would be about Linux advocacy instead of video capture. There's a huge community around video capture/encoding which is quite Windows-centric which is a resource of its own as well. Furthermore, the simple fact is that most people - even most Ars readers (and even most Slashdot readers) - run Windows; they have no responsibility for pointing out Linux's videocoding capabilities.
also -- don't just write me off as being windows-centric myself. I'm posting this from Linux right now -- Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030314 Phoenix/0.5. Perhaps not as hardcore as Lynx but that's how it goes.