But, it seems to me that if SNOsoft was merely acting altruistically, they shouldn't need to "build a relationship" in order to "transfer the information privately."
The point in question was whether "third party" (read CERT) would have to be in on the information sharing. Many people feel that CERT is just piggybacking on the efforts of real security researchers.
I'd love to hear what, exactly, you consider to be ``power user'' features in, say, a word processor. Printing, maybe? Spell-checking? Style sheets? Table of contents and index generation? Change control?
All these are present in the standard office suites in Linux. And they are atmost a menu deep. How many different ways do you think are there for spell checking? Or printing? Do you really think your coworkers can't figure it out if the print option in sthe fifth entry in the file menu instead of the fourth?
To us, these aren't ``power user'' features. They're basic tools.
What you have described are basic tools and shouldn't require retraining.
Maybe the problem, here, is that the developers (or at least advocates) of open source office software don't actually use office software themselves.
And where did you dig that one up? While it is true that many people don't want to waste their time with "productivity" software, most of the develpers and users do use them.
Driving a car? No. The gas is on the right and the brake is in the middle. The one on the left is the clutch. The big round thing in the middle is for turning. In front of you is a gauge that tells you how fast you're going.
Which is exactly the same for all office suites. The only change will be for those so called "power" users who use 90% of the features of the packages. I would like to see some research on what the fraction of such users are. My guess is it would be pretty small.
It is unlikely Sun will GPL their JVM implementation
More than likely they want to maintain control over the code. If they have a competing (complete)GPLed implementation, people might be tempted to use that instead.
If this thing relies almost solely (if not completely) on voice recognition, how accurate are the results?
I think with the current technology you will have to put some thought into your cell phone naming conventions. For starters you may not want to use the first names. I use the initials in mine and it seems to work fine.
I was aware that write support is extremely dubious, but I thought that read support was pretty safe - am I wrong ?
Well, if the code is not reliable, all bets are off when it is mounted, although in the config it says that read support is just experimental and not dangerous. I don't think RedHat would want to take that chance.
That would work, except the money they spend would be taken out of "honest" people's wallets too, as prices for CDs go up.
Then the honest people can just stop buying CDs from RIAA et al.
Fortunately, this is still an option for people in the US (Canadians and Germans are not that lucky).
I am tired of posts and articles that point out file sharing increses profits. Even if that's true, it's still against what the RIAA wanted when they put it out.
It is not just RIAA's music.
After the restrictions imposed by RIAA is put into place, you will no longer be able to hear any non-RIAA music.
Looks like the default RH kernel isn't built with this enabled.
They don't have anything on their kernel which is marked experimental/dangerous in the config. Of course, write support is really dangerous. FWIW, they don't have UDF support either.
For the floppies just use mtools. It is much simpler and provides all the commands that you would expect. Also has the advantage (?) that it is similar to windows commands. No need to mount/umount.
As for CDs, put the CD in eject -t and then mount/mnt/cdrom followed by eject which will autmatically umount it. I think you don't even need the initial eject -t command.
It does look like he is trying to be "cool". Too bad we can't make fun of him and take his lunch money :-D.
Oh, this would have been soooo much fun to watch on Court TV!
Too bad it would be torn to shreds in a real court. There would be all sorts of inadmissible evidence.
Appreciate your note and concern... committed to finding and fixing any security ...appreciate your concern and
feedback..
Did anyone else feel that that was a contentless form letter? I don't think it says anything at all.
But, it seems to me that if SNOsoft was merely acting altruistically, they shouldn't need to "build a relationship" in order to "transfer the information privately."
The point in question was whether "third party" (read CERT) would have to be in on the information sharing. Many people feel that CERT is just piggybacking on the efforts of real security researchers.
I'd love to hear what, exactly, you consider to be ``power user'' features in, say, a word processor. Printing, maybe? Spell-checking? Style sheets? Table of contents and index generation? Change control?
All these are present in the standard office suites in Linux. And they are atmost a menu deep. How many different ways do you think are there for spell checking? Or printing? Do you really think your coworkers can't figure it out if the print option in sthe fifth entry in the file menu instead of the fourth?
To us, these aren't ``power user'' features. They're basic tools.
What you have described are basic tools and shouldn't require retraining.
Maybe the problem, here, is that the developers (or at least advocates) of open source office software don't actually use office software themselves.
And where did you dig that one up? While it is true that many people don't want to waste their time with "productivity" software, most of the develpers and users do use them.
If you have to purchase VMWare and windows, why bother running linux at all?
You won't have to purchase all the programs for your windows setup (it is assumed that you have replaced some of them with Linux equivalents).
Driving a car? No. The gas is on the right and the brake is in the middle. The one on the left is the clutch. The big round thing in the middle is for turning. In front of you is a gauge that tells you how fast you're going.
Which is exactly the same for all office suites. The only change will be for those so called "power" users who use 90% of the features of the packages. I would like to see some research on what the fraction of such users are. My guess is it would be pretty small.
It is unlikely Sun will GPL their JVM implementation
More than likely they want to maintain control over the code. If they have a competing (complete)GPLed implementation, people might be tempted to use that instead.
If this thing relies almost solely (if not completely) on voice recognition, how accurate are the results?
I think with the current technology you will have to put some thought into your cell phone naming conventions. For starters you may not want to use the first names. I use the initials in mine and it seems to work fine.
I was aware that write support is extremely dubious, but I thought that read support was pretty safe - am I wrong ?
Well, if the code is not reliable, all bets are off when it is mounted, although in the config it says that read support is just experimental and not dangerous. I don't think RedHat would want to take that chance.
That would work, except the money they spend would be taken out of "honest" people's wallets too, as prices for CDs go up.
Then the honest people can just stop buying CDs from RIAA et al. Fortunately, this is still an option for people in the US (Canadians and Germans are not that lucky).
Wasn't that Einstein?
I am tired of posts and articles that point out file sharing increses profits. Even if that's true, it's still against what the RIAA wanted when they put it out.
It is not just RIAA's music. After the restrictions imposed by RIAA is put into place, you will no longer be able to hear any non-RIAA music.
This depends on the drive of course (constant angular velocity vs. speed)
In that the disc itself can't handle being spun at more than a certain RPM before it comes apart.
This is most likely an urban legend.
Has anyone examined the long-term data retention of CDs burned at 48X in what was a 32X burner?
:-D
I suppose this will have to do with the media properties rather than the drive.
Has anyone looked into the error rates of hot-rodded drives vs. those drives sold to operate at the higher speeds?
It would be a simple matter to check the md5sums. dd if=/dev/cdrom | md5sum -
If your time is so valuable that you need to upgrade from 32X to 48X burning, you can afford a new CD writer.
So you think not so wealthy should be stuck in boring repetitive tasks?
Looks like the default RH kernel isn't built with this enabled.
They don't have anything on their kernel which is marked experimental/dangerous in the config. Of course, write support is really dangerous. FWIW, they don't have UDF support either.
For the floppies just use mtools. It is much simpler and provides all the commands that you would expect. Also has the advantage (?) that it is similar to windows commands. No need to mount/umount.
/mnt/cdrom followed by eject which will autmatically umount it. I think you don't even need the initial eject -t command.
As for CDs, put the CD in eject -t and then mount
Just my $0.02
You can use this in Oz to get a copy of DeCSS :-)