Cutting into their profits is not stealing from them, any more so than grilling my own hamburgers is stealing from McDonald's. A business does not have a right to make a profit. See previous rant.
So are you saying that you have the absolute right to listen to my cellphone (assuming I had one) conversations?
Yes. And how would you stop someone from doing that, anyway? If you're crazy enough to send private/sensitive information over a public phone line (let alone a cellular phone!), you're likely to get a rude surprise one day.
Take photographs of me through my windows? (My image is traveling onto your property....)
Oh, this one's the killer. You see, this already happens all the time. There was a famous case a few years ago (which, regrettably, I cannot find now) in which a Florida couple were arrested for having sex in their own home with the blinds closed. Apparently, someone snuck up to their window and videotaped them through a hole in the blinds. Because their home was within a certain distance of a public school, it was felt that the children at the school could have seen them. (And that somehow, seeing people having sex is wrong... but that's a different rant.)
Use shotgun mikes to record everything that goes on in my house?
I don't feel qualified to answer that one, as I don't know anything about these "shotgun mikes". Is their use permitted by law? If so, then I'd say yes.
why should descrambling (stealing) unpaid-for content be any different?
Suppose I hand you a piece of paper on which there is some writing (6 paragraphs). I tell you, "You are allowed to read the first two paragraphs, but not the third paragraph. You are also allowed to read the fourth paragraph and the last paragraph, but not the fifth paragraph."
Do you really think I have a right to tell you which paragraphs may read, and which you may not? Do you really think that, if I learned you had read one of the "forbidden" paragraphs, I could win a lawsuit against you?
If I don't want you to read something, I'd better not hand you a paper with those words on it.
If I don't want you to watch a video stream, I'd better not broadcast that video stream into your house.
Nobody can steal that which you have given them for free.
Just because you came up with some "clever" business model that involves charging people money for services, that does not entitle you to compensation from people who figure out how to provide this service for themselves.
I am deeply disturbed to see this bullshit perpetuated by someone outside the US. Previously, I had been operating on the assumption (obviously false) that "the right of a business to make money" was confined to the US.
Once again, for the slow ones: you do not have a right to make a profit, no matter how clever you may think you are, and no matter how long you've been making a profit in the past. If someone out there catches on to your scheme and bypasses it, you lose.
(With all that said, I have to applaud the hackers who work for DirecTV. Unlike certain other industries, they didn't resort to dirty tricks or underhanded legislation -- they simply used what they had, and ingeniously too. I'm not ranting against DirecTV here -- I'm ranting against all those who thought that the H-card hackers were "stealing".)
The Blowfish version of crypt has 128 bits of salt in order to make
building dictionaries of common passwords space consuming. The initial
state of the Blowfish cipher is expanded using the salt and the password
repeating the process a variable number of rounds, which is encoded in
the password string. The maximum password length is 72. The final Blow-
fish password entry is created by encrypting the string ``OrpheanBehold-
erScryDoubt'' with the Blowfish state 64 times.
There is no "blowfish key" to keep secret. The password and the random salt are the key. If there were some "secret key", it wouldn't stay a secret very long -- the passwd(1) source would have to contain it, and you'd get it straight from the CVS server (or the CVS snapshot on the CDs).
A more interesting question, then, is whether it's possible to launch a known-plaintext attack to retrieve the key (and thus the password). The plaintext is in the man page that I quoted above, and the cyphertext is in the master password file. But I'm no cryptographer (I don't even pretend to be one), so I can't speculate on how feasible such a feat would be.
It's not the same as the States, where (to my knowledge) you're locally represented in the Federal Government by 2 elected officials (Senator and Rep), and you chose your president separately.
Each state has 2 Senators, which are elected directly by the voters of that state. (They serve overlapping terms, so only one of them can be running for re-election at a time.)
Each state has a variable number of Representatives, based on its population. If the state has more than 1 Rep, it's divided into districts geographically, and each district elects one Rep.
We have the illusion that we vote for the President directly, but in reality that's not quite true. The popular vote is simply used as an indicator, and the electoral college actually determines who will be President.
(Of course, that's somewhat of a simplification. Each state has a variable number of electoral college representatives based on its population. The popular vote in each state decides who will be in the electoral college this time 'round; but the trick is, each state gets a solid block of electoral college reps for whichever party gets the plurality of the popular vote. So for example, if Gore gets 47% of the vote in California, and Bush gets 45%, and Nader gets 6%, and Browne gets 2%, then Gore (or rather, the Democratic Party for whom Gore is the candidate) gets ALL of California's electoral college seats.
If you watch the TV coverage of the US presidential elections, you'll probably see a computer-generated map of the continental US, with each state colored red or blue as exit poll results come in. This is a realistic representation of how the presidential election works -- instead of getting X number of votes, you get whole states at a time.)
MP3[.com] is paying for the rights to license the songs for a limited time, so that they can stream them like one would stream a radio station. However, Napster is licensing in a different way - they are allowing people to download the songs, and keep them permanently.
There's no difference between the MP3 that you can download and the one that's streamed over TCP.
If you want to download (save a copy of) an MP3 that mp3.com doesn't have a download link for, all you have to do is tell your MP3 player to save it.
Example using mp3.com and xmms: click the "hi-fi play" button in the web browser; wait for xmms to get the URL; click the PL button in xmms; hold down the Load List button in the lower-right corner of the new window, and drag the mouse up to select Save List; in the resulting dialog, type some file name. The file name that you just typed will now contain the URL for the 128 kbps MP3 file -- you can do wget `cat file` or whatever.
The simple fact is, you can't prevent people from saving copies of things that you send them. If you have a web page, you can't prevent people from reading its source, because you send them the source every time they request the page. (CGI is different; you're sending the output of a program instead of a static file). The same applies to audio streams, video streams, etc. If you send the data to someone, that person has the data. Even if my xmms example didn't work, it would still be possible to use a wrapper program that writes the incoming MP3 encoded audio stream to a file and also sends that audio stream to the real xmms.
(I changed the IP address to XX's to protect the identify of the person who made that last request.)
503 mp3 file transfers (some of which are partials and resumes, of course) in 124 hours -- or about 4 per hour. And that's a very small number compared to the activity I get on OpenNap (which I don't log, currently, but trust me -- it's much more than 4 per hour).
Those of us who share may be in the minority, but we definitely exist.
Do it yourself. Get a static IP, a reliable Unix installation and a UPS. Host your own mail. You'll have your own mail, domain name, ssh access, shell account, you name it.
You don't have to be on a mailing list to submit bug reports or review them. The bug submission process uses email, but there are front-end programs that can help you (reportbug and bug).
The bug tracking system's page is http://www.debian.org/Bugs/.
You can search bug reports there, anonymously.
What aspect of BNL's actions even begins to enter the realm of problematic, or even unethical, for that matter?
They're misrepresenting the files they're offering -- mislabeling them intentionally. This is generally called "lying", and most people consider that unethical.
It seems someone would rather have vigilante justice than clean-cut law.
You must be using some definition of "clean" with which I'm not familiar.
Would you buy their music if they sold you MP3s online?
I would not. However, if I downloaded free MP3 recordings of their music and liked them, then I might be willing to give them money (e.g., via fairtunes).
I've written in more detail on the Fairtunes forums about this, so I'll keep this one brief. I refuse to pay money for intangible "content". If I buy something, I expect to get fair value for my money. Paying for downloads is not fair value, because it doesn't take into account modem disconnections, data corruption (whoops,/home was full... lemme delete some stuff and try again), or simple data loss due to human error or hard drive failures. On the other hand, if I can just download a copy for free any time I like, then I can make a voluntary payment once, and I don't have to worry about keeping backup copies of the song on separate physical media, etc.
If someone doesn't want to let their music be passed around, they have every right not to let it be.
The song writer has the ultimate power -- she can choose not to write the song. The performer has the second-highest amount of power -- he can choose not to perform the song.
Once the song has been "written" (that is, shared with another person), the cat's out of the bag. You can't unwrite the song, any more than you can unspeak words that someone else has heard, or undraw a picture that someone else has seen.
Once the song has been performed, and recorded in some physical medium, it can be shared infinitely many times. There's no way, short of physical force, to prevent someone from duplicating information.
Beyond that, all we have is a bunch of legal traditions backed up by military power. There is no ethical reason why a songwriter or musical performer should be able to tell me what I can and cannot do with a copy of a song. There is no "divine right of authors" to tell the rest of the world what can be done with a story. The only reason the record companies can boss me around right now derives from legal and military power, not moral authority.
To summarize: you've got no right to tell me I can't share music, Mr. Federal Agent, and if you'd kindly put that gun away we could get on with our lives and do something productive (like making sure musicians get paid).
But really, what is this technology going to be used for primarily? Probably something illegal.
Since when is it wrong to do things that are illegal?
people are going to view this as is a system that will be able to thwart Big Brother, aka the government and big business.
Well, that is one of the things that it can do. "It's a feature, not a bug!"
Ofcourse we need to protect the freedom of speech, especially in a medium like the Internet. I just hope it's done legally.
This is an oxymoron. When laws are created that constrain individual freedom, and when court decisions prohibit people even from talking about these issues, it's not possible for individuals to "protect freedom of speech... legally". We must break the law, or live as sheep.
I have never programmed in Smalltalk. I have no comments about the development environment, since I've never used it... but I've installed and maintained IBM's Visual Age for Smalltalk on AIX. I have some comments that I need to make, lest people actually use it.
IBM's Visual Age for Smalltalk is, hands down, the worst piece of shit commercial program I've ever laid eyes or hands on.
Let's start with the name. "Visual Age for Smalltalk". It sounds like an add-on product -- something that you'd install after you've installed Smalltalk, to add a GUI, right? Wrong. It is the Smalltalk compiler. And it is the GUI. And it is the runtime interpreter thingy. They're all inextricably entwined. (And yes, I'm pissed about the name because I wasted a good 30 minutes one day trying to find "Smalltalk", not realizing that "Foo for Smalltalk" is "Smalltalk".)
Right, then. Let's move on to the installation.
You cannot install it from a command line. The installation is GUI. So you can't dial in from home for the installation -- you have to drive to where the computer is! Wow, just like Winders!
But wait, there's more! You can't install it if your X $DISPLAY is pointing to a Linux workstation! If your X display isn't pointing to an AIXwindows display, the Smalltalk installer goes into an infinite loop and spews an unending stream of incomprehensible error messages! Nifty, eh?
Oh, but wait! You thought AIXwindows would be enough? Wrong-O! You have to be running The Common Desktop Environment(TM) on the AIX display! If your X display points to an AIXwindows workstation that's just running plain old twm or fvwm or something, you get the unending stream of incomprehensible error messages all over again! So now you get to dig up an AIX CD set and install a whole bunch of crap you didn't want, just so you can begin the Smalltalk installation. Thank you sir, may I have another!
Now, to appreciate the Smalltalk installation in its full glory, be sure to open an AIXterm(TM) and run top (which AIX doesn't include, but which can be found with a few web searches). When you fire up the graphical installation program, the first thing you'll notice is that it runs a program called es. That's the Smalltalk runtime interpreter thingy which Smalltalk programs can't live without. More on that below. The second thing you're likely to notice (once you've typed in all the passwords to unlock the proprietary software) is that the es program goes into a busy loop and sucks up all the CPU time while it's not doing anything at all! (The Smalltalk installation uses the standard AIX package management software -- which is pretty decent (comparable to RPM in power, not as good as dpkg/apt-get) -- to install a few packages. The Smalltalk program busy-loops while it waits for the package installer to finish.) Wow, impress me some more!
OK, so it's installed, kinda. But it's not running yet. So how do you start it up? First you've gotta run a program that spits out a magical "device number". This is a simple two-digit number in square brackets, in the middle of a line of text. You need to extract that number and then feed it to another program as a command-line parameter. Why couldn't they automate this? Any sysadmin who's ever picked up a copy of O'Reilly's Sed and Awk could automate this in less than a minute! But could IBM's brilliant programmers figure this out? Hell no!
And wait... what's this? Why am I being prompted for my root password in order to shut down the Smalltalk daemons? Hello?!? I'm already root! I've been authenticated by AIX, as you can see by calling geteuid()! So why do I have to embed the root password in a shell script if I want to shut down Smalltalk gracefully at reboot time? Fuck it, let it die.
Oh, but you haven't seen the best parts yet! Smalltalk doesn't use the AIX/Unix file system! Not at all! You can't open a file! You can't transfer your source code from one machine to another! All of your source code is contained within a gigantic (hundreds of MB) binary file along with everyone else's source code! If you need to install Smalltalk on a different computer, and transfer the source code, you get to copy this nearly-half-a-gigabyte binary file that you can't read. It's all or nothing.
And since Smalltalk uses a runtime interpreter thingy, you can't build native applications. If you want to build a Smalltalk program to run on another machine, you have to ship a copy of es (remember him? the one that busy-loops during an install? and requires CDE? and can't exit gracefully if CDE isn't there?) with your program. And I have no idea what sort of license this es guy is under. I don't think I want to know. If I wanted to use a scripting language, I'd use sh or perl!
Let's see... what else is there.... Oh yeah, the bugs! Despite the fact that Smalltalk's installer uses the standard AIX packaging system, the bug fixes are distributed as either tarballs, or replacement copies of the executable files. So much for the integrity of the packaging system! (And don't go thinking you can use it without those patches, either. Out of the box, Smalltalk is completely broken on SMP systems. And don't even bother to ask me why it cares how many CPUs are in the box. It's probably an embedded operating system or something. That would certainly explain why it has its own fucking file system and its own internal concept of device numbers (which have nothing to do with Unix major & minor device numbers), and why its developers can't master sed.)
The good news is, I'm no longer assigned to that site. But when I see someone mentioning Smalltalk, it still brings back the horrible memories.
Wanna know why I don't wanna learn Smalltalk? This is why!
I can understand why you'd hate fags. I hate them too. They're full of noxious chemicals and they cause health problems in innocent bystanders. And they reek -- horribly so.
Yet, if you believe in a creator-deity, it seems kinda silly to say "god hates fags", since according to your own beliefs, it was this same god who created the tobacco plant in the first place. Why would god create something and then hate it? If god hates it, why doesn't god just remove it from creation?
(You were talking about the kind of fags that are smoked to satisfy a physical drug dependency, right?)
I mean if your going to have a dl around 160mg. Why not slip it into 5 or so voluems so ppl who dont have cable can play it.
What difference does it make? You're still downloading the same amount of data.
Download wget. Read its man page, especially the part about -c. Get the URL of the file you want to download, and feed it to wget with the -c option. When your modem disconnects, reconnect and type the command again.
What should I do fix the holes in the default installation?
The first thing you should do is subscribe to the debian-security-announce mailing list. That way you will be informed whenever a security fix is made available. (Don't worry, it's not often enough to flood your mailbox!)
The second thing you should do is make sure you fetch those updates. You can always get them by hand (the instructions are in the announcements made on the mailing list). An easier way, if your machine can reach the World Wide Web, is to use apt. Put this into the/etc/apt/sources.list file:
deb http://security.debian.org/ potato/updates main
(Make any other changes to your sources.list at this time.) Then run apt-get update, and apt-get upgrade. You can run those commands any time you like, to get the most recent updated packages. Now that potato is stable, there will not be updated packages very often, but it doesn't hurt to check.
The third thing you should do is review what's installed on your system and delete anything you don't want. This is tedious and time-consuming. You also won't be able to make too many informed decisions at first, since you probably don't know what everything does yet.
I haven't installed the newest version of Debian from scratch yet (my Debian boxes are a couple years old), so I don't know how much "cruft" there is in the default tasks. But if it's anything like the previous version (slink) there's probably a whole lot of cruft.
So run dpkg -l | less and actually read through the output. You will probably see some things that look vitally important (like "dpkg" or "libc6"), some things that look terribly unimportant (like "bsdgames"), and a whole lot of things where you can't decide.
Start by removing all the things that you know you don't want. If this is your desktop system and it's behind a firewall, you probably don't need to run a name server or have the Apache web server development kit installed... on the other hand, if this is your firewall, you probably don't want xbill installed.;-)
Once you've done all of those, take a look at some of the individual packages. You can use "dpkg --status packagename" to see all the meta-information about the package, including its long description. (You can also see this in "dselect" if you use that program.) Then try removing some of them. Remember two things here:
If you try to remove something that's "Essential" to the system, you won't be able to do it without explicitly overriding the error messages.
If you remove something that it turns out you wanted to have, you can just reinstall it. By default, when you "dpkg --remove" a package (or do the equivalent in dselect or apt-get), all the config files are left on the system. When you reinstall that same package, it will keep your old config files. (Read the dpkg man page for more info.)
The fourth thing to do is to look at the system from the outside point of view. Try port-scanning your box from somewhere else on your network (another Linux box running nmap is a good way). If you see a port that's open, find out why. (Hint: lsof -i:25 will show you the processes listening on port 25. Or, fuser -n tcp 25 will give you the process numbers, which you can then look up with ps.)
At first, you may not know what each of these services is, so you'll have to do some research to figure out whether you want to keep them. Find people you trust and ask them, or hit the docs.
When you find services you want to disable, find out how to do it. The methods vary with the service -- some services run as a standalone process (like sshd on tcp port 22). Some run under the control of inetd (like telnetd on tcp port 23). Some may run either way, depending on which program is implementing that service and how the program's configured. (E.g., sendmail runs as a standalone daemon and offers smtp service (tcp port 25), whereas qmail-smtpd could run from either inetd or under control of a separate program called tcpserver.)
Each service is different, so you will have to do some investigation to figure out whether you want to disable them, and if so, how to do it.
By the time you've done all that, you won't be a newbie any more.;-)
The fifth thing you should do isn't specific to Linux or Debian. You should make regular backups of your important data. I'm constantly amazed at how many people fail to do this. The most important things to back up are your personal data (/home) and your system configuration files (/etc). (Note that Debian policy requires all configuration files to be under/etc.) If you've got more room, you should probably back up/var and, if you use it,/usr/local. If you still have more room, back up the whole file system hierarchy.
Also, make sure you have more than 1 backup. Don't just reuse the same tape every time -- have at least two tapes (or Zip disks, or whatever) and alternate between them. Better yet, have a lot of them and rotate them (use the oldest one each time). If you're doing this on an important system (not just your personal toy), you should ship some of those backups off-site in case of a major disaster.
Can you name the things that I need to change passwords on?
There isn't anything you need to change passwords on -- but you might want to set a few passwords.
Your user accounts (most especially root!) should all have good passwords. That's absolutely essential.
Beyond that, it depends on how paranoid you are, and how much the data on your system is worth to an attacker. It will also depend on external factors (e.g., is the computer locked in a room to which only you and your boss have keys?).
You can set a password in LILO (assuming you use LILO to boot), which will prevent users from passing boot parameters to the kernel. But in order to pass boot parameters to the kernel to LILO in the first place, they have to be physically present at the keyboard, and they have to be able to cause the machine to reboot (e.g., by disrupting its electrical power).
A user with physical access to the machine has other options, however, besides LILO. They could insert a floppy disk and cause the system to boot. You can prevent this by telling your computer not to boot from floppy diskettes (in its BIOS), and then setting a BIOS password which prevents the user from changing the BIOS back to its defaults. (This has nothing to do with Debian or even Linux.)
The problem with this is that it's still possible to override the BIOS password, either by changing a motherboard jumper, or by temporarily removing the battery, or by stealing the hard drives. This requires access to the inside of the machine, which is why some people here have been talking about locks on the computer's case.
Personally, I don't bother with any of that stuff. If a system has to be secure against the kinds of things discussed in the preceding few paragraphs, then it should be in a secured room.
I agree this could be cool though I have not seen many un-tagged MP3 files.
*blink* *boggle*
Huh? Man, please tell me where you're getting all these tagged MP3 files from! The vast majority of the MP3 files I've found on Napster/OpenNap/mp3.com are untagged -- and of the rest, a significant number don't even have the "sync" (whatever that is) that mp3info wants, so I can't even add the tags myself!
To allow this, Napster (or any other) will have to download the MP3 and compute the fingerprint. Downloading all MP3s which are exchanged via Napster will need a huge bandwidth update.
It would take a lot more than that! Right now, MP3 files on Napster are traded peer-to-peer, with only the filename/duration/bitrate/MD5sum being transmitted to Napster. If Napster wants to get, say, a 10-second sample of each of the songs on my hard drive through my 56k modem (33.6 maximum uplink), it would take something like 10 s/file * 128kbps (approx) * 1700 files (approx) / 33.6kbps = 64761 s (or about 18 hours). And that's under ideal upload conditions!
And since I don't actually use Napster (I use OpenNap) that makes it even harder.:-)
Also, what about files that are incomplete? One of my pet peeves about Napster (and OpenNap) right now is that there are still a substantial number of incomplete files out there. I hate downloading a file and discovering that it's cut off halfway through the song. If you fingerprint a file based on a sample, then this does nothing at all to combat the incomplete file problem -- a partial song would potentially have the same fingerprint as a complete song.
Another similar point: sometimes (rarely) I intentionally omit the first few seconds of a track when I rip from CD, because I don't enjoy sitting through 3-30 seconds of silence. (And I omitted the first couple seconds of Depeche Mode's "I Feel For You" because it's a horrible screeching sound, which I assumed was some kind of joke to scare vinyl users.) If you try to fingerprint the first few seconds of a song, then either (a) you end up fingerprinting silence, or (b) you get misleading results if those first seconds are stripped.
Likewise, if you try to fingerprint, say, from 30s to 40s into a song, then you fail for any song that's less than 30 seconds long.
I know you're just trolling, but I can't resist a coherent response.
(you can forget all the second rate ramblin' noise that 'independent artists' make in daddy's basement)
I'm sorry if your quest for independent music has not yielded the results you hoped for. Here are some of the mp3.com artists and songs that I enjoy. You might find them tolerable.
My guess is mp3.com will have to move away from mp3s.
No, the MP3 file format isn't the problem. And the legal MP3 files that mp3.com distributes aren't the problem.
All this fuss came about when mp3.com started offering a service that let you download MP3-encoded versions of songs from CDs that you had purchased. Essentially, they were trying to save you the time and effort of ripping and encoding them yourself. (From my perspective, this would've been a loss of time -- it's faster for me to rip and encode than to download.)
As I understand it (never having used the service in question), they gave you an MP3 under either of two conditions:
You inserted a CD-ROM that you owned, and special software (Windoze only at first, though I think they may have introduced a Linux version later) did a CDDB-style checksum of the CD and then permitted you to access the MP3 versions of your CD's songs on mp3.com.
You purchased a CD online (through mp3.com maybe -- I'm unclear on this part), but hadn't received it yet; mp3.com allowed you to download the tracks in MP3 format so you could listen to the music you had purchased even though you hadn't received the physical media yet.
I think this was an extremely gutsy move on mp3.com's part. If I had been them, I wouldn't have dared to try it. But I guess it was one of the ways they were trying to probe the boundaries of the copyright laws and see what could and could not be done.
Know what? You don't have to use it. As of Debian 2.1, there's a new package management tool called apt-get. (Eventually there will be a front-end called apt or something, but it's not ready yet.) While apt-get doesn't do everything that dselect does, it's a whole lot less painful.
For example, to check for new packages and then upgrade all your existing packages, you can use the following commands:
Slashdot Mirror
Cutting into their profits is not stealing from them, any more so than grilling my own hamburgers is stealing from McDonald's. A business does not have a right to make a profit. See previous rant.
So are you saying that you have the absolute right to listen to my cellphone (assuming I had one) conversations?
Yes. And how would you stop someone from doing that, anyway? If you're crazy enough to send private/sensitive information over a public phone line (let alone a cellular phone!), you're likely to get a rude surprise one day.
Take photographs of me through my windows? (My image is traveling onto your property....)
Oh, this one's the killer. You see, this already happens all the time. There was a famous case a few years ago (which, regrettably, I cannot find now) in which a Florida couple were arrested for having sex in their own home with the blinds closed. Apparently, someone snuck up to their window and videotaped them through a hole in the blinds. Because their home was within a certain distance of a public school, it was felt that the children at the school could have seen them. (And that somehow, seeing people having sex is wrong... but that's a different rant.)
Use shotgun mikes to record everything that goes on in my house?
I don't feel qualified to answer that one, as I don't know anything about these "shotgun mikes". Is their use permitted by law? If so, then I'd say yes.
why should descrambling (stealing) unpaid-for content be any different?
Suppose I hand you a piece of paper on which there is some writing (6 paragraphs). I tell you, "You are allowed to read the first two paragraphs, but not the third paragraph. You are also allowed to read the fourth paragraph and the last paragraph, but not the fifth paragraph."
Do you really think I have a right to tell you which paragraphs may read, and which you may not? Do you really think that, if I learned you had read one of the "forbidden" paragraphs, I could win a lawsuit against you?
If I don't want you to read something, I'd better not hand you a paper with those words on it.
If I don't want you to watch a video stream, I'd better not broadcast that video stream into your house.
You have no right to make a profit.
Nobody can steal that which you have given them for free.
Just because you came up with some "clever" business model that involves charging people money for services, that does not entitle you to compensation from people who figure out how to provide this service for themselves.
I am deeply disturbed to see this bullshit perpetuated by someone outside the US. Previously, I had been operating on the assumption (obviously false) that "the right of a business to make money" was confined to the US.
Once again, for the slow ones: you do not have a right to make a profit, no matter how clever you may think you are, and no matter how long you've been making a profit in the past. If someone out there catches on to your scheme and bypasses it, you lose.
(With all that said, I have to applaud the hackers who work for DirecTV. Unlike certain other industries, they didn't resort to dirty tricks or underhanded legislation -- they simply used what they had, and ingeniously too. I'm not ranting against DirecTV here -- I'm ranting against all those who thought that the H-card hackers were "stealing".)
Don't forget the Digital Titanium Water Cooler!
From crypt(3) (OpenBSD 2.6):
The Blowfish version of crypt has 128 bits of salt in order to makebuilding dictionaries of common passwords space consuming. The initial
state of the Blowfish cipher is expanded using the salt and the password
repeating the process a variable number of rounds, which is encoded in
the password string. The maximum password length is 72. The final Blow-
fish password entry is created by encrypting the string ``OrpheanBehold-
erScryDoubt'' with the Blowfish state 64 times.
There is no "blowfish key" to keep secret. The password and the random salt are the key. If there were some "secret key", it wouldn't stay a secret very long -- the passwd(1) source would have to contain it, and you'd get it straight from the CVS server (or the CVS snapshot on the CDs).
A more interesting question, then, is whether it's possible to launch a known-plaintext attack to retrieve the key (and thus the password). The plaintext is in the man page that I quoted above, and the cyphertext is in the master password file. But I'm no cryptographer (I don't even pretend to be one), so I can't speculate on how feasible such a feat would be.
It's not the same as the States, where (to my knowledge) you're locally represented in the Federal Government by 2 elected officials (Senator and Rep), and you chose your president separately.
Each state has 2 Senators, which are elected directly by the voters of that state. (They serve overlapping terms, so only one of them can be running for re-election at a time.)
Each state has a variable number of Representatives, based on its population. If the state has more than 1 Rep, it's divided into districts geographically, and each district elects one Rep.
We have the illusion that we vote for the President directly, but in reality that's not quite true. The popular vote is simply used as an indicator, and the electoral college actually determines who will be President.
(Of course, that's somewhat of a simplification. Each state has a variable number of electoral college representatives based on its population. The popular vote in each state decides who will be in the electoral college this time 'round; but the trick is, each state gets a solid block of electoral college reps for whichever party gets the plurality of the popular vote. So for example, if Gore gets 47% of the vote in California, and Bush gets 45%, and Nader gets 6%, and Browne gets 2%, then Gore (or rather, the Democratic Party for whom Gore is the candidate) gets ALL of California's electoral college seats.
If you watch the TV coverage of the US presidential elections, you'll probably see a computer-generated map of the continental US, with each state colored red or blue as exit poll results come in. This is a realistic representation of how the presidential election works -- instead of getting X number of votes, you get whole states at a time.)
MP3[.com] is paying for the rights to license the songs for a limited time, so that they can stream them like one would stream a radio station. However, Napster is licensing in a different way - they are allowing people to download the songs, and keep them permanently.
There's no difference between the MP3 that you can download and the one that's streamed over TCP.
If you want to download (save a copy of) an MP3 that mp3.com doesn't have a download link for, all you have to do is tell your MP3 player to save it.
Example using mp3.com and xmms: click the "hi-fi play" button in the web browser; wait for xmms to get the URL; click the PL button in xmms; hold down the Load List button in the lower-right corner of the new window, and drag the mouse up to select Save List; in the resulting dialog, type some file name. The file name that you just typed will now contain the URL for the 128 kbps MP3 file -- you can do wget `cat file` or whatever.
The simple fact is, you can't prevent people from saving copies of things that you send them. If you have a web page, you can't prevent people from reading its source, because you send them the source every time they request the page. (CGI is different; you're sending the output of a program instead of a static file). The same applies to audio streams, video streams, etc. If you send the data to someone, that person has the data. Even if my xmms example didn't work, it would still be possible to use a wrapper program that writes the incoming MP3 encoded audio stream to a file and also sends that audio stream to the real xmms.
Ratios... points... offering services to earn virtual currency which you can spend to download information... sounds like a pretty good idea, eh?
That's what the Mojo Nation folks thought, too.
How much is being shared? A whole hell of a lot. Where do you think all the people who "take, take, take" are taking from?
Here's some stats for my MP3 sharing over HTTP only. This doesn't count what I share on OpenNap.
dwarf:/var/log/apache$ head -1 access.log127.0.0.1 - - [22/Oct/2000:06:26:35 -0400] "GET
dwarf:/var/log/apache$ tail -1 access.log
XX.XX.XX.XX - - [27/Oct/2000:10:27:36 -0400] "GET
dwarf:/var/log/apache$ grep -v '^127.0.0.1' access.log | grep '\.mp3' | wc -l
503
(I changed the IP address to XX's to protect the identify of the person who made that last request.)
503 mp3 file transfers (some of which are partials and resumes, of course) in 124 hours -- or about 4 per hour. And that's a very small number compared to the activity I get on OpenNap (which I don't log, currently, but trust me -- it's much more than 4 per hour).
Those of us who share may be in the minority, but we definitely exist.
Do it yourself. Get a static IP, a reliable Unix installation and a UPS. Host your own mail. You'll have your own mail, domain name, ssh access, shell account, you name it.
Napster is a way to discover and share music, but as the only way we have to support artists we like is to buy their CD, thats what we do.
You could also support these artists by going to their live shows, or buying their merchandise, if they have any.
Or you could send money directly to them with Fairtunes.
You don't have to be on a mailing list to submit bug reports or review them. The bug submission process uses email, but there are front-end programs that can help you (reportbug and bug).
The bug tracking system's page is http://www.debian.org/Bugs/. You can search bug reports there, anonymously.
What aspect of BNL's actions even begins to enter the realm of problematic, or even unethical, for that matter?
They're misrepresenting the files they're offering -- mislabeling them intentionally. This is generally called "lying", and most people consider that unethical.
It seems someone would rather have vigilante justice than clean-cut law.
You must be using some definition of "clean" with which I'm not familiar.
Would you buy their music if they sold you MP3s online?
I would not. However, if I downloaded free MP3 recordings of their music and liked them, then I might be willing to give them money (e.g., via fairtunes).
I've written in more detail on the Fairtunes forums about this, so I'll keep this one brief. I refuse to pay money for intangible "content". If I buy something, I expect to get fair value for my money. Paying for downloads is not fair value, because it doesn't take into account modem disconnections, data corruption (whoops, /home was full... lemme delete some stuff and try again), or simple data loss due to human error or hard drive failures. On the other hand, if I can just download a copy for free any time I like, then I can make a voluntary payment once, and I don't have to worry about keeping backup copies of the song on separate physical media, etc.
If someone doesn't want to let their music be passed around, they have every right not to let it be.
The song writer has the ultimate power -- she can choose not to write the song. The performer has the second-highest amount of power -- he can choose not to perform the song.
Once the song has been "written" (that is, shared with another person), the cat's out of the bag. You can't unwrite the song, any more than you can unspeak words that someone else has heard, or undraw a picture that someone else has seen.
Once the song has been performed, and recorded in some physical medium, it can be shared infinitely many times. There's no way, short of physical force, to prevent someone from duplicating information.
Beyond that, all we have is a bunch of legal traditions backed up by military power. There is no ethical reason why a songwriter or musical performer should be able to tell me what I can and cannot do with a copy of a song. There is no "divine right of authors" to tell the rest of the world what can be done with a story. The only reason the record companies can boss me around right now derives from legal and military power, not moral authority.
To summarize: you've got no right to tell me I can't share music, Mr. Federal Agent, and if you'd kindly put that gun away we could get on with our lives and do something productive (like making sure musicians get paid).
But really, what is this technology going to be used for primarily? Probably something illegal.
Since when is it wrong to do things that are illegal?
people are going to view this as is a system that will be able to thwart Big Brother, aka the government and big business.
Well, that is one of the things that it can do. "It's a feature, not a bug!"
Ofcourse we need to protect the freedom of speech, especially in a medium like the Internet. I just hope it's done legally.
This is an oxymoron. When laws are created that constrain individual freedom, and when court decisions prohibit people even from talking about these issues, it's not possible for individuals to "protect freedom of speech... legally". We must break the law, or live as sheep.
I have never programmed in Smalltalk. I have no comments about the development environment, since I've never used it... but I've installed and maintained IBM's Visual Age for Smalltalk on AIX. I have some comments that I need to make, lest people actually use it.
IBM's Visual Age for Smalltalk is, hands down, the worst piece of shit commercial program I've ever laid eyes or hands on.
Let's start with the name. "Visual Age for Smalltalk". It sounds like an add-on product -- something that you'd install after you've installed Smalltalk, to add a GUI, right? Wrong. It is the Smalltalk compiler. And it is the GUI. And it is the runtime interpreter thingy. They're all inextricably entwined. (And yes, I'm pissed about the name because I wasted a good 30 minutes one day trying to find "Smalltalk", not realizing that "Foo for Smalltalk" is "Smalltalk".)
Right, then. Let's move on to the installation.
OK, so it's installed, kinda. But it's not running yet. So how do you start it up? First you've gotta run a program that spits out a magical "device number". This is a simple two-digit number in square brackets, in the middle of a line of text. You need to extract that number and then feed it to another program as a command-line parameter. Why couldn't they automate this? Any sysadmin who's ever picked up a copy of O'Reilly's Sed and Awk could automate this in less than a minute! But could IBM's brilliant programmers figure this out? Hell no!
And wait... what's this? Why am I being prompted for my root password in order to shut down the Smalltalk daemons? Hello?!? I'm already root! I've been authenticated by AIX, as you can see by calling geteuid()! So why do I have to embed the root password in a shell script if I want to shut down Smalltalk gracefully at reboot time? Fuck it, let it die.
Oh, but you haven't seen the best parts yet! Smalltalk doesn't use the AIX/Unix file system! Not at all! You can't open a file! You can't transfer your source code from one machine to another! All of your source code is contained within a gigantic (hundreds of MB) binary file along with everyone else's source code! If you need to install Smalltalk on a different computer, and transfer the source code, you get to copy this nearly-half-a-gigabyte binary file that you can't read. It's all or nothing.
And since Smalltalk uses a runtime interpreter thingy, you can't build native applications. If you want to build a Smalltalk program to run on another machine, you have to ship a copy of es (remember him? the one that busy-loops during an install? and requires CDE? and can't exit gracefully if CDE isn't there?) with your program. And I have no idea what sort of license this es guy is under. I don't think I want to know. If I wanted to use a scripting language, I'd use sh or perl!
Let's see... what else is there.... Oh yeah, the bugs! Despite the fact that Smalltalk's installer uses the standard AIX packaging system, the bug fixes are distributed as either tarballs, or replacement copies of the executable files. So much for the integrity of the packaging system! (And don't go thinking you can use it without those patches, either. Out of the box, Smalltalk is completely broken on SMP systems. And don't even bother to ask me why it cares how many CPUs are in the box. It's probably an embedded operating system or something. That would certainly explain why it has its own fucking file system and its own internal concept of device numbers (which have nothing to do with Unix major & minor device numbers), and why its developers can't master sed.)
The good news is, I'm no longer assigned to that site. But when I see someone mentioning Smalltalk, it still brings back the horrible memories.
Wanna know why I don't wanna learn Smalltalk? This is why!
Thank you.
Don't say you would pay if you could. You won't.
We can, and we have.
www.fairtunes.com, $2500 (combined US & Canadian) and counting.
www.paylars.com, $500 and counting.
I can understand why you'd hate fags. I hate them too. They're full of noxious chemicals and they cause health problems in innocent bystanders. And they reek -- horribly so.
Yet, if you believe in a creator-deity, it seems kinda silly to say "god hates fags", since according to your own beliefs, it was this same god who created the tobacco plant in the first place. Why would god create something and then hate it? If god hates it, why doesn't god just remove it from creation?
(You were talking about the kind of fags that are smoked to satisfy a physical drug dependency, right?)
I mean if your going to have a dl around 160mg. Why not slip it into 5 or so voluems so ppl who dont have cable can play it.
What difference does it make? You're still downloading the same amount of data.
Download wget. Read its man page, especially the part about -c. Get the URL of the file you want to download, and feed it to wget with the -c option. When your modem disconnects, reconnect and type the command again.
Fscking common sense huh
Indeed.
What should I do fix the holes in the default installation?
The first thing you should do is subscribe to the debian-security-announce mailing list. That way you will be informed whenever a security fix is made available. (Don't worry, it's not often enough to flood your mailbox!)
The second thing you should do is make sure you fetch those updates. You can always get them by hand (the instructions are in the announcements made on the mailing list). An easier way, if your machine can reach the World Wide Web, is to use apt. Put this into the /etc/apt/sources.list file:
deb http://security.debian.org/ potato/updates main(Make any other changes to your sources.list at this time.) Then run apt-get update , and apt-get upgrade . You can run those commands any time you like, to get the most recent updated packages. Now that potato is stable, there will not be updated packages very often, but it doesn't hurt to check.
The third thing you should do is review what's installed on your system and delete anything you don't want. This is tedious and time-consuming. You also won't be able to make too many informed decisions at first, since you probably don't know what everything does yet.
I haven't installed the newest version of Debian from scratch yet (my Debian boxes are a couple years old), so I don't know how much "cruft" there is in the default tasks. But if it's anything like the previous version (slink) there's probably a whole lot of cruft.
So run dpkg -l | less and actually read through the output. You will probably see some things that look vitally important (like "dpkg" or "libc6"), some things that look terribly unimportant (like "bsdgames"), and a whole lot of things where you can't decide.
Start by removing all the things that you know you don't want. If this is your desktop system and it's behind a firewall, you probably don't need to run a name server or have the Apache web server development kit installed... on the other hand, if this is your firewall, you probably don't want xbill installed. ;-)
Once you've done all of those, take a look at some of the individual packages. You can use "dpkg --status packagename" to see all the meta-information about the package, including its long description. (You can also see this in "dselect" if you use that program.) Then try removing some of them. Remember two things here:
The fourth thing to do is to look at the system from the outside point of view. Try port-scanning your box from somewhere else on your network (another Linux box running nmap is a good way). If you see a port that's open, find out why. (Hint: lsof -i :25 will show you the processes listening on port 25. Or, fuser -n tcp 25 will give you the process numbers, which you can then look up with ps.)
At first, you may not know what each of these services is, so you'll have to do some research to figure out whether you want to keep them. Find people you trust and ask them, or hit the docs.
When you find services you want to disable, find out how to do it. The methods vary with the service -- some services run as a standalone process (like sshd on tcp port 22). Some run under the control of inetd (like telnetd on tcp port 23). Some may run either way, depending on which program is implementing that service and how the program's configured. (E.g., sendmail runs as a standalone daemon and offers smtp service (tcp port 25), whereas qmail-smtpd could run from either inetd or under control of a separate program called tcpserver.)
Each service is different, so you will have to do some investigation to figure out whether you want to disable them, and if so, how to do it.
By the time you've done all that, you won't be a newbie any more. ;-)
The fifth thing you should do isn't specific to Linux or Debian. You should make regular backups of your important data. I'm constantly amazed at how many people fail to do this. The most important things to back up are your personal data (/home) and your system configuration files (/etc). (Note that Debian policy requires all configuration files to be under /etc.) If you've got more room, you should probably back up /var and, if you use it, /usr/local. If you still have more room, back up the whole file system hierarchy.
Also, make sure you have more than 1 backup. Don't just reuse the same tape every time -- have at least two tapes (or Zip disks, or whatever) and alternate between them. Better yet, have a lot of them and rotate them (use the oldest one each time). If you're doing this on an important system (not just your personal toy), you should ship some of those backups off-site in case of a major disaster.
Can you name the things that I need to change passwords on?
There isn't anything you need to change passwords on -- but you might want to set a few passwords.
Your user accounts (most especially root!) should all have good passwords. That's absolutely essential.
Beyond that, it depends on how paranoid you are, and how much the data on your system is worth to an attacker. It will also depend on external factors (e.g., is the computer locked in a room to which only you and your boss have keys?).
You can set a password in LILO (assuming you use LILO to boot), which will prevent users from passing boot parameters to the kernel. But in order to pass boot parameters to the kernel to LILO in the first place, they have to be physically present at the keyboard, and they have to be able to cause the machine to reboot (e.g., by disrupting its electrical power).
A user with physical access to the machine has other options, however, besides LILO. They could insert a floppy disk and cause the system to boot. You can prevent this by telling your computer not to boot from floppy diskettes (in its BIOS), and then setting a BIOS password which prevents the user from changing the BIOS back to its defaults. (This has nothing to do with Debian or even Linux.)
The problem with this is that it's still possible to override the BIOS password, either by changing a motherboard jumper, or by temporarily removing the battery, or by stealing the hard drives. This requires access to the inside of the machine, which is why some people here have been talking about locks on the computer's case.
Personally, I don't bother with any of that stuff. If a system has to be secure against the kinds of things discussed in the preceding few paragraphs, then it should be in a secured room.
I agree this could be cool though I have not seen many un-tagged MP3 files.
*blink* *boggle*
Huh? Man, please tell me where you're getting all these tagged MP3 files from! The vast majority of the MP3 files I've found on Napster/OpenNap/mp3.com are untagged -- and of the rest, a significant number don't even have the "sync" (whatever that is) that mp3info wants, so I can't even add the tags myself!
To allow this, Napster (or any other) will have to download the MP3 and compute the fingerprint. Downloading all MP3s which are exchanged via Napster will need a huge bandwidth update.
It would take a lot more than that! Right now, MP3 files on Napster are traded peer-to-peer, with only the filename/duration/bitrate/MD5sum being transmitted to Napster. If Napster wants to get, say, a 10-second sample of each of the songs on my hard drive through my 56k modem (33.6 maximum uplink), it would take something like 10 s/file * 128kbps (approx) * 1700 files (approx) / 33.6kbps = 64761 s (or about 18 hours). And that's under ideal upload conditions!
And since I don't actually use Napster (I use OpenNap) that makes it even harder. :-)
Also, what about files that are incomplete? One of my pet peeves about Napster (and OpenNap) right now is that there are still a substantial number of incomplete files out there. I hate downloading a file and discovering that it's cut off halfway through the song. If you fingerprint a file based on a sample, then this does nothing at all to combat the incomplete file problem -- a partial song would potentially have the same fingerprint as a complete song.
Another similar point: sometimes (rarely) I intentionally omit the first few seconds of a track when I rip from CD, because I don't enjoy sitting through 3-30 seconds of silence. (And I omitted the first couple seconds of Depeche Mode's "I Feel For You" because it's a horrible screeching sound, which I assumed was some kind of joke to scare vinyl users.) If you try to fingerprint the first few seconds of a song, then either (a) you end up fingerprinting silence, or (b) you get misleading results if those first seconds are stripped.
Likewise, if you try to fingerprint, say, from 30s to 40s into a song, then you fail for any song that's less than 30 seconds long.
I know you're just trolling, but I can't resist a coherent response.
(you can forget all the second rate ramblin' noise that 'independent artists' make in daddy's basement)
I'm sorry if your quest for independent music has not yielded the results you hoped for. Here are some of the mp3.com artists and songs that I enjoy. You might find them tolerable.
My guess is mp3.com will have to move away from mp3s.
No, the MP3 file format isn't the problem. And the legal MP3 files that mp3.com distributes aren't the problem.
All this fuss came about when mp3.com started offering a service that let you download MP3-encoded versions of songs from CDs that you had purchased. Essentially, they were trying to save you the time and effort of ripping and encoding them yourself. (From my perspective, this would've been a loss of time -- it's faster for me to rip and encode than to download.)
As I understand it (never having used the service in question), they gave you an MP3 under either of two conditions:
I think this was an extremely gutsy move on mp3.com's part. If I had been them, I wouldn't have dared to try it. But I guess it was one of the ways they were trying to probe the boundaries of the copyright laws and see what could and could not be done.
I feel your pain. I hate dselect, too.
Know what? You don't have to use it. As of Debian 2.1, there's a new package management tool called apt-get. (Eventually there will be a front-end called apt or something, but it's not ready yet.) While apt-get doesn't do everything that dselect does, it's a whole lot less painful.
For example, to check for new packages and then upgrade all your existing packages, you can use the following commands:
apt-get updateapt-get upgrade