Ok, let's see. Someone else said that Canadian votes have a single box to check. OK, in the recent election here, there were no fewer the 40 different votes to make on my ballot -- in addition to the presidential vote there were congressmen, senators, local officials, local/regional judges, ballot initiatives, etc.
Ok, add to that a population roughly 10 times as large as Canada's. Now we've got a voting problem about 400 times as complex as Canada's. When will we get the results of an election? In a couple of years?
Seriously, hand ballots are good, but that don't scale worth crap.
If you have a web browser, it is more efficient to access the servers via HTTP, as you don't use a process that sits idle during the time you're not downloading something as is the case with FTP.
I read your message that was scrawled with a crayon and sent on a carrier pigeon. These "web browser" things sound great. What are they? How can I get one?
If someone is trying to "revisit" the games they used to enjoy, wouldn't that mean that they have them for an older computer but don't have a computer to play them on any more? If so, then how is that possibly a copyright violation? Don't they still own the game?
I have the original Zork, on an 8" floppy, for an old CP/M machine. If I could figure out some way to get it transferred, then it should be perfectly legal for me to play it under a Z-80/CPM emulator, right? (The answer is "of course")
Hmmmm.... there's an old blues song by Willie Dixon called "Twenty-nine ways" ("twenty-nine ways to get to my baby's door") where he lists the ways. Maybe someone with more musical talent than me could make this into a song ("Twenty-nine ways to get to my DeCSS")!
Neither will binaries compiled with 2.95.2, so I don't see your point here.
The GCC Steering Committe have declared that gcc 3.0 matters are still subject to change - so both 2.95.2- and
2.96-compiled stuff won't necessarily work with 3.0. So the "gcc 3.0" compability argument is moot.
The point is that 2.96 is a very temporary thing, compatible only with itself, and soon to be replaced by something incompatible. So RedHat has decided to go with something experimental, meaning that there will have to be different binaries for the small amount of time that RedHat 7.0 is the "new thing." So now you have to have 3 versions of binaries instead of 2 (which would have been necessary for the upgrade to gcc 3.0). Why? For what benefit? It seems completely pointless to me.
Sometimes things have to change in order to move forward, and this often breaks backwards compatibility. When that happens, you just have to deal with it, but taking a temporary version that has a designed-in obsolescence is just very unwise. They should have stuck with the old version (for backward compatibility) until the new version had ironed out the way it was going to work. That way you'd have one upgrade to deal with rather than two.
From the gcc steering committee statement, I think you're wrong about gcc 3.0 -- binaries compiled with 2.96 will not necessarily work with 3.0. So when one of your valued customers gets his special binary from you for 7.0, and later decides to upgrade to 7.1 (say) which includes gcc 3.0, then he'll have to go back to you, or any other vendor he's gotten binaries from, and get another binary to upgrade.
That's a serious problem, and that's why it was a very bad idea for RedHat to ship with 2.96...
I don't have much basis to talk about the overall bugginess of RH7.0 because we've had such a hard time getting it to install on anything. Our experience: the local ACM chapter had an "installfest" last Friday with the new RH 7.0. On the 4 machines that we tried to install RH7.0 (before we got fed up with it), it only installed on one of them. The installation process hung on the other 3 machines. Using RH6.2 worked perfectly on 2 of those machines, and we never managed to get anything installed on the 3rd (repeated signal 11 aborts on that one -- perhaps flakey hardware).
1 out of 4 machines is not a good record (or even 1 out of 3, if you exclude the last one).
Secondly, the gcc thing was, I think, a clear mistake on RedHat's part. It's not binary-compatible with previous or future compilers for C++. So I guess you're going to have to recompile or obtain fresh binaries for lots of stuff when the official 3.0 compiler comes out. Great. Maybe that's not too bad for the standard GNU utilities, and the gnome stuff, which is all overwhelmingly C code. But KDE code is almost exclusively C++. That's going to be a serious bother. And despite what someone else here said, it's not just a problem with.o files. It's a problem with binaries that are dynamically linked with libraries (in other words, pretty much every executable binary in existence).
Pushing the future is an admirable goal, but they screwed up in how to do it: in the 7.0 distribution there is a separate place for "preview technologies" (it's got a 2.4 kernel preview, and stuff like that). That is where a temporary, experimental version of the compiler should have gone. Not in the default installation.
Anyway, enough ranting for now. I'm staying away from 7.0 after my experiences. I'll upgrade when I see something a little more stable that sticks with official (or at least compatible) releases of important software like gcc.
Actually, lots of bands give away music. I realize that radio is paid for by advertisements, but that money doesn't go to the artists; the publicity does.
Actually, you're wrong on this point. Radio stations do pay for playing music, and the money does go to the artists...
I know someone who was in a relatively popular band about 25 years ago, and he still gets royalty checks from the airtime that his music gets (classic rock stations are doing a lot to support aging musicians!:-) )
Ok, I know I should check out the actual features rather than jump on things based on just screenshots, but why the hell is there such an emphasis on making things "pretty"?
I look at the screen shot for listing installed packages, and my first thought is how terribly inefficient and information-light the screen is. By putting in large icons and lots of whitespace, it might look pretty but you've only got 6 packages listed on a full screen!! You could easily use a tabular form, with small icons if you really must, and get at least 20 packages on a screen. Surely I'm not the only one that thinks having to scroll all around a bunch of useless crap and whitespace is a major usability problem...
Like I said, I may be jumping the gun since I just saw the screenshots. Hopefully there's an option somewhere that lets you adjust the view... right? please?
"The General Motors Research Laboratories are credited with implementing the first operating system in the early 1950s for their IBM 701. In 1955, GM and North American Aviation cooperated on an operating system for the IBM 704. The IBM user organization, SHARE, fostered discussion on operating systems, and by 1957 many home-grown operating systems for the 704 had been developed."
"Home-grown" OSes were popular at the beginning and now are popular again (would you call Linux "home-grown"?) -- I guess history does repeat itself!
Actually, in the mid 80's there was an O'Charlie's restaurant in Nashville that made a drink called a "Pan-galactic Gargle-Blaster" in honor of the HHG series. They even had a (unofficial) contest going on who drank the most. We got into some serious trouble one night when I tied the previous record (5) and a friend beat it with 6. Ever see anyone do a slow-motion sideways fall from a high barstool? At least it seemed slow-motion to me at that time!:-)
I think some of the people I hung out with at the time snarfed the drink recipe, but I wouldn't have a clue where it is now....:-(
I selected this book for my undergraduate class in crypto and security this semester, and have been mostly happy with it. I think everyone can find nits to pick with any book, but you've got to determine how well it served your particular purpose.
My purpose was a good gentle introduction to crypto and security issues, and it was mostly ok for that. Personally, I would have like some other security issues discussed such as protocol failures in basic TCP/IP (SYN flooding and consequences, like how you can spoof IP addresses between mutually trusting systems, etc.), but it seems like if it didn't involve crypto it wasn't in the book (there's a lot to network security beyond crypto, after all).
I also would have liked some system security issues discussed at least a little bit -- basics of Bell-Lapuda or BAN logic, or something like that. But again that wasn't really the author's goal here -- so I can just supplement with outside material.
The omission of OAEP is a little more troublesome. He does talk about HMAC, but glosses over the idea of using crypto primitives to make higher-level functionality, and the proofs associated with it. With the direction of crypto research these days, I would hope that maybe in the 3rd edition he'd devote a chapter to such issues.
Anyway, my bottom line is that it served my purpose as a textbook very well, and I simply supplemented with outside material when necessary. For the purpose of a textbook, frankly I think Schneier's book would be terrible -- very little substance on the "whys" and the "hows", and too much on the cookbook approach. That's certainly not what I want to teach -- I want to teach the thinking behind the ideas, not recipes. I'm not sure if I'd use Stallings' book for a grad course because even it doesn't go too much into the whys and the current research topics. Or perhaps I'd just supplement with more research papers and outside material...
Wow. Look at the takeover by non-US teams. This contest has been going on for a very long time, and I was involved for a couple of years a while back. Came in 5th one year, and 8th the other, if I remember correctly. And almost all of the top teams were US universities at the time (I think Eindhoven was there and was the only foreign team that did consistently well).
So what has changed? Several things that I can think of: it was always an international competition, but I don't remember this many non-US teams in the past. In particular, when I was competing, the Berlin wall was still up, so we didn't have any eastern European or Russian teams! But even the non-US teams that were there were typically not very strong -- in particular, at that time many schools outside the US simply didn't have the facilities for people to be as experienced as people from US schools. I would imagine that has changed substantially, and non-US teams are now getting plenty of experience before coming to the competition.
Lastly, is it really that the non-US teams are getting that much better, or have the US teams lost something along the way? Cal Tech has always been good (beat my team both years I went, anyway), and they only got 4 problems, while the winner got 7? That's just not at the same standard they used to work at. Is the education failing these days, or are we not getting as many strong students in Computer Science as we used to?
Think again! A process can access and modify the memory of any other process running by the same user (how do you think debuggers work?)! So yes, a process can go change environment variables or other things in the user's shell. Do this -- start a new shell running, and find the PID of that shell, say it's 3451. Now go into/proc/3451 and look at the file "mem" -- who is the owner and what are the permissions? That's the memory of that process! Open it and go to town!
Now you can't access other user's processes of course, so you can't "promote" yourself to root or anything like that, but you can still cause some havoc for that one user. And if they ever do an "su" then all bets are off!
I agree that different ways to load things into a register (online, QIF, whatever) can certainly wait until after the register itself is stable. However, it's much harder to change the record structure after it's been initially developed, and for some odd reason the GnuCash people have left out a core bit of functionality. There's no category for transactions, so it's impossible to do things like budgeting, etc. Without that, it's just something that I wouldn't use, and I'm stuck running Quicken under Wine (which works marginally, at best).
Maybe I'm wrong, and they have some type of extensible record format that makes this change easy later (I haven't looked), but it seems like a pretty bad design right now....
First of all, I'm absolutely no security expert, the only thing I know is that finding large primes is very hard.
No, you're wrong. Finding large primes is quite easy. If it weren't, we'd have an awful hard time doing many of the current encryption algorithms.
What's hard is factoring large composite numbers that are the product of two large primes.
It's not clear what you're saying your program does: does it factor numbers, or is it a program that searches for prime numbers? It would be pretty hard to believe that you've got anything efficient for the first, and the second is just not too hard to do (although to be blunt it doesn't sound like you know enough math to make something efficient for this one either...).
How about a free service, so you don't have to worry about an ISP subscription for a single month? I've used freei.net for a little while, and it's pretty good. They use sliprock for their dialin access, and they have tons of local access points.
I think having separate policies for a childrens area, while not restricting other terminals, is a perfectly reasonable compromise.
If anyone would listen, I would also propose an improved system. The problem is that robots and automatic classification don't work very well at all. In my experience, most librarians are in fact quite good about free access to information, and would have easily cleared any of those wrongly-blocked sites listed in the letter. What if some blocking company (surfwatch, or whoever) offered a discounted rate to librarians who would devote at least a small amount of time to check blocked sites for suitability. If it's widely adopted, the number of "false blocks" should go down drastically, and the libraries would save some money in the process.
Think of it like the Open Source model (with commercial incentive) applied to filtering software: with enough eyes looking at the problem, all falsely blocked sites are obvious!
It's true that C2 requires ACLs, but I don't believe that alternate id mechanisms are required.
Furthermore, the statement that higher than C2 must be internally developped within the government is totally wrong. There are plenty of privately developed B-grade systems (even secure variants of Unix!), and even an A1 system or two that were privately developed (the A1 was by Unisys maybe?).
C2 certification requires (among lots of other things, of course!) the ability to assign file access rights to the granularity of a single user. In other words, access lists (ACLs).
NT has this, but the standard linux filesystem (ext2) does not. This is certainly the biggest problem with a "standard" linux setup going for C2 certification. Without a different filesystem, it doesn't stand a chance.
In fact, from the standpoint of real security, and not just meeting some somewhat meaningless security label, the lack of ACLs in Linux is a real problem. Is this going to be fixed in ext3? Does anyone know?
I know how to win! How about a plugin to monitor a user's listening habits, and transparently send that information back to a central site that can keep a big database of all user's listening habits?
Why should the commercial people have all of the fun of selling purloined user information? I think it's about time that the open source community got in on the action!
So that's my proposal: the Open Source User Exploitation (OSUE) plugin. Let's act like all those "professionals" out there at commercial software companies!
That's unfair. The GPL simply says "we want this software to remain free, so we must ask you not to restrict other people's freedoms by making it proprietary".
No, that's not what the GPL says. There are a zillion ways of making sure software remains free. Basically, just say "this is free", and it's free. What GPL does is say that other people who do anything using or extending (or even just linking in the case of libraries that are GPL instead of LGPL) must make their code free. It adds absolutely nothing to the freedom of the software that is covered by the license -- the only difference is in trying to restrict what other people do with their own code. And again, it's what the other people do with their code -- they still don't have the right to take the original free software and make it un-free. To claim that this somehow makes the original software now "un-free" is just plain silly...
I don't have a problem with people using GPL, or whatever license they care to use for their own software. However, to hold up GPL as a shining example of free software is just plain bas-ackwards wrong. And when there's a license conflict and people automatically jump on the other license (Qt in this case) just makes people look like zealots (defined as "do it my way or else...")
The GPL or a BSD-style license would not have these issues.
Actually, the problem was because of GPL, in my opinion. The license that purports to be the "free" one is the one that's being the most demanding and dictatorial here. The idea of being free (as in freedom) is good, and should be along the lines of "use this software to enable other good software, in whatever way the person writing the new software desires." Meaning that people should be free to extend with other free and/or open source software, with slightly modified licenses like Qt, as shareware, or as full-blown commercial software. That would be a truly free license.
The GPL "freedom" is like saying "sure, you're free as long as you do things exactly like we want you to." Sorry, but that just doesn't get it.
Excellent advice. And the other person who said to be very careful with you selection of a graduate advisor is very, very correct.
On a practical note, you really need to do anything you can to get a feel for research and different research areas before you hit grad school. That will help you in untold numbers of ways: it will help you make an informed decision of what field you want to go into (which helps select a school); it will get you more involved with the professors' work, which will result in better recommendation letters; and it will help you write a good statement of purpose. Those last two are looked at very closely if you apply to top schools.
My own experience: I went to a good (say, top 40 or 50) school as an undergrad, did really well (top of the class and all that), but my idea of what was hot research was what I read about in Byte (hey, Slashdot didn't exist then...) -- I don't think I had ever really picked up a research journal. I applied to top-to-medium grad schools, and partially because I wrote what I see now was a really goofy statement of purpose, I was rejected by MIT, Stanford, and Berkeley. I ended up at a very good school though (easilly top 20), and quickly discovered that C.S. research wasn't about the new technologies in the trade mags.
I was going to do a M.S. and then reapply to the top schools for a Ph.D. -- I don't doubt I could have gotten in after the research I had done and published by that time, but my advisor convinced me to stay on at that school. Sometimes I regret that decision, but overall things have turned out ok...
So bottom line: find out about research! Talk to professors in your area of interest and find out what the good research journals and conferences are in that area. Find out who is doing that research and where they're doing it. And if you can't do a top-tier school in the first try, consider doing a Masters and then "moving up"!
As odd coincidence would have it, not 5 minutes before reading this question, I had done a "blind test" of the only 3 free Linux coders that I know of: bladeenc, 8hz, and lame. I had a few samples with pretty good dynamic range, encoded each with each of the encoders, and then set up random links to them so I wouldn't know which was which.
The result? bladeenc was clearly the best overall. Despite some of the hype I had heard about L.A.M.E., it was definitely the worst in one case, and overall it was pretty consistently at the bottom.
Incidentally, I was using bladeenc v0.82, and it seems quite a bit faster than the last version I had tried (0.76, maybe?). On a P166-MMX it took about 30 seconds to encode my 10 second samples.
As for other supporting software, I use cdparanoia for ripping, and either Krabber or mp3c to coordinate the ripping, encoding, labeling process. The nice thing about mp3c is that you can make it create a batch file for you -- I nice the script, and nohup it (or use at) and let it go. Then I can log out, and my wife can log in and use the computer, or it can work while I'm asleep.
Ok, let's see. Someone else said that Canadian votes have a single box to check. OK, in the recent election here, there were no fewer the 40 different votes to make on my ballot -- in addition to the presidential vote there were congressmen, senators, local officials, local/regional judges, ballot initiatives, etc.
Ok, add to that a population roughly 10 times as large as Canada's. Now we've got a voting problem about 400 times as complex as Canada's. When will we get the results of an election? In a couple of years?
Seriously, hand ballots are good, but that don't scale worth crap.
I read your message that was scrawled with a crayon and sent on a carrier pigeon. These "web browser" things sound great. What are they? How can I get one?
If someone is trying to "revisit" the games they used to enjoy, wouldn't that mean that they have them for an older computer but don't have a computer to play them on any more? If so, then how is that possibly a copyright violation? Don't they still own the game?
I have the original Zork, on an 8" floppy, for an old CP/M machine. If I could figure out some way to get it transferred, then it should be perfectly legal for me to play it under a Z-80/CPM emulator, right? (The answer is "of course")
Hmmmm.... there's an old blues song by Willie Dixon called "Twenty-nine ways" ("twenty-nine ways to get to my baby's door") where he lists the ways. Maybe someone with more musical talent than me could make this into a song ("Twenty-nine ways to get to my DeCSS")!
The point is that 2.96 is a very temporary thing, compatible only with itself, and soon to be replaced by something incompatible. So RedHat has decided to go with something experimental, meaning that there will have to be different binaries for the small amount of time that RedHat 7.0 is the "new thing." So now you have to have 3 versions of binaries instead of 2 (which would have been necessary for the upgrade to gcc 3.0). Why? For what benefit? It seems completely pointless to me.
Sometimes things have to change in order to move forward, and this often breaks backwards compatibility. When that happens, you just have to deal with it, but taking a temporary version that has a designed-in obsolescence is just very unwise. They should have stuck with the old version (for backward compatibility) until the new version had ironed out the way it was going to work. That way you'd have one upgrade to deal with rather than two.
That's a serious problem, and that's why it was a very bad idea for RedHat to ship with 2.96...
1 out of 4 machines is not a good record (or even 1 out of 3, if you exclude the last one).
Secondly, the gcc thing was, I think, a clear mistake on RedHat's part. It's not binary-compatible with previous or future compilers for C++. So I guess you're going to have to recompile or obtain fresh binaries for lots of stuff when the official 3.0 compiler comes out. Great. Maybe that's not too bad for the standard GNU utilities, and the gnome stuff, which is all overwhelmingly C code. But KDE code is almost exclusively C++. That's going to be a serious bother. And despite what someone else here said, it's not just a problem with .o files. It's a problem with binaries that are dynamically linked with libraries (in other words, pretty much every executable binary in existence).
Pushing the future is an admirable goal, but they screwed up in how to do it: in the 7.0 distribution there is a separate place for "preview technologies" (it's got a 2.4 kernel preview, and stuff like that). That is where a temporary, experimental version of the compiler should have gone. Not in the default installation.
Anyway, enough ranting for now. I'm staying away from 7.0 after my experiences. I'll upgrade when I see something a little more stable that sticks with official (or at least compatible) releases of important software like gcc.
Actually, you're wrong on this point. Radio stations do pay for playing music, and the money does go to the artists...
I know someone who was in a relatively popular band about 25 years ago, and he still gets royalty checks from the airtime that his music gets (classic rock stations are doing a lot to support aging musicians! :-) )
Ok, I know I should check out the actual features rather than jump on things based on just screenshots, but why the hell is there such an emphasis on making things "pretty"?
I look at the screen shot for listing installed packages, and my first thought is how terribly inefficient and information-light the screen is. By putting in large icons and lots of whitespace, it might look pretty but you've only got 6 packages listed on a full screen!! You could easily use a tabular form, with small icons if you really must, and get at least 20 packages on a screen. Surely I'm not the only one that thinks having to scroll all around a bunch of useless crap and whitespace is a major usability problem...
Like I said, I may be jumping the gun since I just saw the screenshots. Hopefully there's an option somewhere that lets you adjust the view... right? please?
Here's a relevant quote from Dietel's OS book:
"The General Motors Research Laboratories are credited with implementing the first operating system in the early 1950s for their IBM 701. In 1955, GM and North American Aviation cooperated on an operating system for the IBM 704. The IBM user organization, SHARE, fostered discussion on operating systems, and by 1957 many home-grown operating systems for the 704 had been developed."
"Home-grown" OSes were popular at the beginning and now are popular again (would you call Linux "home-grown"?) -- I guess history does repeat itself!
Actually, in the mid 80's there was an O'Charlie's restaurant in Nashville that made a drink called a "Pan-galactic Gargle-Blaster" in honor of the HHG series. They even had a (unofficial) contest going on who drank the most. We got into some serious trouble one night when I tied the previous record (5) and a friend beat it with 6. Ever see anyone do a slow-motion sideways fall from a high barstool? At least it seemed slow-motion to me at that time!
I think some of the people I hung out with at the time snarfed the drink recipe, but I wouldn't have a clue where it is now....
I selected this book for my undergraduate class in crypto and security this semester, and have been mostly happy with it. I think everyone can find nits to pick with any book, but you've got to determine how well it served your particular purpose.
My purpose was a good gentle introduction to crypto and security issues, and it was mostly ok for that. Personally, I would have like some other security issues discussed such as protocol failures in basic TCP/IP (SYN flooding and consequences, like how you can spoof IP addresses between mutually trusting systems, etc.), but it seems like if it didn't involve crypto it wasn't in the book (there's a lot to network security beyond crypto, after all).
I also would have liked some system security issues discussed at least a little bit -- basics of Bell-Lapuda or BAN logic, or something like that. But again that wasn't really the author's goal here -- so I can just supplement with outside material.
The omission of OAEP is a little more troublesome. He does talk about HMAC, but glosses over the idea of using crypto primitives to make higher-level functionality, and the proofs associated with it. With the direction of crypto research these days, I would hope that maybe in the 3rd edition he'd devote a chapter to such issues.
Anyway, my bottom line is that it served my purpose as a textbook very well, and I simply supplemented with outside material when necessary. For the purpose of a textbook, frankly I think Schneier's book would be terrible -- very little substance on the "whys" and the "hows", and too much on the cookbook approach. That's certainly not what I want to teach -- I want to teach the thinking behind the ideas, not recipes. I'm not sure if I'd use Stallings' book for a grad course because even it doesn't go too much into the whys and the current research topics. Or perhaps I'd just supplement with more research papers and outside material...
Wow. Look at the takeover by non-US teams. This contest has been going on for a very long time, and I was involved for a couple of years a while back. Came in 5th one year, and 8th the other, if I remember correctly. And almost all of the top teams were US universities at the time (I think Eindhoven was there and was the only foreign team that did consistently well).
So what has changed? Several things that I can think of: it was always an international competition, but I don't remember this many non-US teams in the past. In particular, when I was competing, the Berlin wall was still up, so we didn't have any eastern European or Russian teams! But even the non-US teams that were there were typically not very strong -- in particular, at that time many schools outside the US simply didn't have the facilities for people to be as experienced as people from US schools. I would imagine that has changed substantially, and non-US teams are now getting plenty of experience before coming to the competition.
Lastly, is it really that the non-US teams are getting that much better, or have the US teams lost something along the way? Cal Tech has always been good (beat my team both years I went, anyway), and they only got 4 problems, while the winner got 7? That's just not at the same standard they used to work at. Is the education failing these days, or are we not getting as many strong students in Computer Science as we used to?
Now you can't access other user's processes of course, so you can't "promote" yourself to root or anything like that, but you can still cause some havoc for that one user. And if they ever do an "su" then all bets are off!
I agree that different ways to load things into a register (online, QIF, whatever) can certainly wait until after the register itself is stable. However, it's much harder to change the record structure after it's been initially developed, and for some odd reason the GnuCash people have left out a core bit of functionality. There's no category for transactions, so it's impossible to do things like budgeting, etc. Without that, it's just something that I wouldn't use, and I'm stuck running Quicken under Wine (which works marginally, at best).
Maybe I'm wrong, and they have some type of extensible record format that makes this change easy later (I haven't looked), but it seems like a pretty bad design right now....
No, you're wrong. Finding large primes is quite easy. If it weren't, we'd have an awful hard time doing many of the current encryption algorithms.
What's hard is factoring large composite numbers that are the product of two large primes.
It's not clear what you're saying your program does: does it factor numbers, or is it a program that searches for prime numbers? It would be pretty hard to believe that you've got anything efficient for the first, and the second is just not too hard to do (although to be blunt it doesn't sound like you know enough math to make something efficient for this one either...).
How about a free service, so you don't have to worry about an ISP subscription for a single month? I've used freei.net for a little while, and it's pretty good. They use sliprock for their dialin access, and they have tons of local access points.
If anyone would listen, I would also propose an improved system. The problem is that robots and automatic classification don't work very well at all. In my experience, most librarians are in fact quite good about free access to information, and would have easily cleared any of those wrongly-blocked sites listed in the letter. What if some blocking company (surfwatch, or whoever) offered a discounted rate to librarians who would devote at least a small amount of time to check blocked sites for suitability. If it's widely adopted, the number of "false blocks" should go down drastically, and the libraries would save some money in the process.
Think of it like the Open Source model (with commercial incentive) applied to filtering software: with enough eyes looking at the problem, all falsely blocked sites are obvious!
It's true that C2 requires ACLs, but I don't believe that alternate id mechanisms are required.
Furthermore, the statement that higher than C2 must be internally developped within the government is totally wrong. There are plenty of privately developed B-grade systems (even secure variants of Unix!), and even an A1 system or two that were privately developed (the A1 was by Unisys maybe?).
C2 certification requires (among lots of other things, of course!) the ability to assign file access rights to the granularity of a single user. In other words, access lists (ACLs).
NT has this, but the standard linux filesystem (ext2) does not. This is certainly the biggest problem with a "standard" linux setup going for C2 certification. Without a different filesystem, it doesn't stand a chance.
In fact, from the standpoint of real security, and not just meeting some somewhat meaningless security label, the lack of ACLs in Linux is a real problem. Is this going to be fixed in ext3? Does anyone know?
I know how to win! How about a plugin to monitor a user's listening habits, and transparently send that information back to a central site that can keep a big database of all user's listening habits?
Why should the commercial people have all of the fun of selling purloined user information? I think it's about time that the open source community got in on the action!
So that's my proposal: the Open Source User Exploitation (OSUE) plugin. Let's act like all those "professionals" out there at commercial software companies!
No, that's not what the GPL says. There are a zillion ways of making sure software remains free. Basically, just say "this is free", and it's free. What GPL does is say that other people who do anything using or extending (or even just linking in the case of libraries that are GPL instead of LGPL) must make their code free. It adds absolutely nothing to the freedom of the software that is covered by the license -- the only difference is in trying to restrict what other people do with their own code. And again, it's what the other people do with their code -- they still don't have the right to take the original free software and make it un-free. To claim that this somehow makes the original software now "un-free" is just plain silly...
I don't have a problem with people using GPL, or whatever license they care to use for their own software. However, to hold up GPL as a shining example of free software is just plain bas-ackwards wrong. And when there's a license conflict and people automatically jump on the other license (Qt in this case) just makes people look like zealots (defined as "do it my way or else...")
Actually, the problem was because of GPL, in my opinion. The license that purports to be the "free" one is the one that's being the most demanding and dictatorial here. The idea of being free (as in freedom) is good, and should be along the lines of "use this software to enable other good software, in whatever way the person writing the new software desires." Meaning that people should be free to extend with other free and/or open source software, with slightly modified licenses like Qt, as shareware, or as full-blown commercial software. That would be a truly free license.
The GPL "freedom" is like saying "sure, you're free as long as you do things exactly like we want you to." Sorry, but that just doesn't get it.
Excellent advice. And the other person who said to be very careful with you selection of a graduate advisor is very, very correct.
On a practical note, you really need to do anything you can to get a feel for research and different research areas before you hit grad school. That will help you in untold numbers of ways: it will help you make an informed decision of what field you want to go into (which helps select a school); it will get you more involved with the professors' work, which will result in better recommendation letters; and it will help you write a good statement of purpose. Those last two are looked at very closely if you apply to top schools.
My own experience: I went to a good (say, top 40 or 50) school as an undergrad, did really well (top of the class and all that), but my idea of what was hot research was what I read about in Byte (hey, Slashdot didn't exist then...) -- I don't think I had ever really picked up a research journal. I applied to top-to-medium grad schools, and partially because I wrote what I see now was a really goofy statement of purpose, I was rejected by MIT, Stanford, and Berkeley. I ended up at a very good school though (easilly top 20), and quickly discovered that C.S. research wasn't about the new technologies in the trade mags.
I was going to do a M.S. and then reapply to the top schools for a Ph.D. -- I don't doubt I could have gotten in after the research I had done and published by that time, but my advisor convinced me to stay on at that school. Sometimes I regret that decision, but overall things have turned out ok...
So bottom line: find out about research! Talk to professors in your area of interest and find out what the good research journals and conferences are in that area. Find out who is doing that research and where they're doing it. And if you can't do a top-tier school in the first try, consider doing a Masters and then "moving up"!
As odd coincidence would have it, not 5 minutes before reading this question, I had done a "blind test" of the only 3 free Linux coders that I know of: bladeenc, 8hz, and lame. I had a few samples with pretty good dynamic range, encoded each with each of the encoders, and then set up random links to them so I wouldn't know which was which.
The result? bladeenc was clearly the best overall. Despite some of the hype I had heard about L.A.M.E., it was definitely the worst in one case, and overall it was pretty consistently at the bottom.
Incidentally, I was using bladeenc v0.82, and it seems quite a bit faster than the last version I had tried (0.76, maybe?). On a P166-MMX it took about 30 seconds to encode my 10 second samples.
As for other supporting software, I use cdparanoia for ripping, and either Krabber or mp3c to coordinate the ripping, encoding, labeling process. The nice thing about mp3c is that you can make it create a batch file for you -- I nice the script, and nohup it (or use at) and let it go. Then I can log out, and my wife can log in and use the computer, or it can work while I'm asleep.