Not quite right. You may only run the software on a computer which you have a maintainance contract for. So it is an initial $99 plus at best $899 for every 10 stations you want to run it on.
RTF web site. The $499 is for the maintainance program for 5 clients, not for any licenses of the included apps.
Maintenance Program for SuSE Linux Desktop for 1 year/5 clients US $ 499.00
The SuSE Linux Maintenance Web provides users of the SuSE Linux Maintenance Program with the latest information, tips and tricks, enhancements, and bug fixes for all current SuSE Linux products in a well-arranged, comprehensive, and topical form. Customers are promptly notified by e-mail about new bug fixes, functional enhancements, or product innovations.
It is impossible to introduce malicious code into an iso image while at the same time retaining its size and the checksum.
Can anyone provide details on how slim the chances actually are?
To answer your question: The concern is just non-existant and if I were in charge I would. The possibility of the mailman opening your package, exchanging the CDs and delivering it to you without you noticing is way higher than getting bad code that yields the same checksum as the good code.
It's simply a non-issue.
Nothing against healthy paranoia but this is just stupid.
I don't quite understand. A mirror provides a set of files which the vendor provides as well. Where is the problem taking the file from the mirror and comparing its MD5 sum to the one from the vendor?
And you can't trust vendor-supplied MD5 sums when you're dealing with new versions downloaded for bug fixes or critical features.
He wasn't talking about bugs. He was talking about bad/malicious code introduced by a maintainer of a mirror for example. 0 percent chance was meant as "no chance the data on the mirror differs from the data the vendor is offering for download".
If you really have enough in-house talent to not need Red Hat support why bother with Red Hat on a commercial level at all? Just download one of their ISOs (that is possible, right?) - or any other distribution for that matter - and do it all yourself. Correct me if I'm wrong but the number one reason to actually pay for a Linux distribution is the support that comes with it, isn't it?
What problem are you referring to? I googled for "bundirty" and all I could find were code snippets. You did mail the problem to one of the lists, didn't you? I'm not trying to deny that you actually had a problem. I'm merely interested in details as I couldn't find any myself. Thanks.
You mean their interfaces were capable of transferring 66MB/s and 100MB/s respectively. The maximum a current IDE drive can sustain is around 50-60MB/s and then only at the outer edge of the platter. Anything above ATA100 only helps burst transfers from the drive's cache and doesn't really do anything for real world performance (except maybe for those 8MB cache drives).
Because computing OGR nodes is done in a relatively small loop, involving hardly any OS calls AFAIK. Things like OGR and RC5 depend more on the processor than on the OS.
I have tried to use the Distributed.net client on an AMD Athlon 1600 XP running Linux 2.4.10 and a G4 864 Mhz using Mac OS X 10.2. It seems that in terms of raw processing power, the G4 was actually more powerful, at over 10,260,280 nodes/sec, while the Athlon was only at 8,160,200 nodes/sec, and that's with no backgrounds processes running (besides the OS)
It's kind of naive to equate OGR performance with "raw processing power". Computing OGR nodes is a very special case of computing something. There may be other cases where the Athlon is better.
Disclaimer: I'm neither an Athlon nor PowerPC fanatic.
I guess it's the capitalisation. "ihre" is "their" while "Ihre" is mostly "your" in a more formal way. Babelfish seems to have trouble with the capitalised "Ihre" and not noticing/knowing what to do with it at the beginning of a sentence.
Slashdot Mirror
How about just rm(1)? Moving to /dev/null looks like abuse. :)
usage: mv [-f | -i] [-v] source target ... directory
mv [-f | -i] [-v] source
Not quite right. You may only run the software on a computer which you have a maintainance contract for. So it is an initial $99 plus at best $899 for every 10 stations you want to run it on.
See here.
Where do you get 5 boxes for $600? This is what you buy here, software that's licensed to run on 5 seats concurrently.
Obviously, I was wrong.
The installation kit may only be installed on clients for which a maintenance agreement was closed. Please refer to the license terms for details.
Sorry.
RTF web site. The $499 is for the maintainance program for 5 clients, not for any licenses of the included apps.
Maintenance Program for SuSE Linux Desktop for 1 year/5 clients US $ 499.00
The SuSE Linux Maintenance Web provides users of the SuSE Linux Maintenance Program with the latest information, tips and tricks, enhancements, and bug fixes for all current SuSE Linux products in a well-arranged, comprehensive, and topical form. Customers are promptly notified by e-mail about new bug fixes, functional enhancements, or product innovations.
No. 1*$99 + $499 for the support of 5 clients which you have to take to get the install media.
The SuSE Linux Desktop installation kit can only be obtained together with a maintenance agreement for at least 5 clients.
It is impossible to introduce malicious code into an iso image while at the same time retaining its size and the checksum.
Can anyone provide details on how slim the chances actually are?
To answer your question: The concern is just non-existant and if I were in charge I would. The possibility of the mailman opening your package, exchanging the CDs and delivering it to you without you noticing is way higher than getting bad code that yields the same checksum as the good code.
It's simply a non-issue.
Nothing against healthy paranoia but this is just stupid.
Didn't think of slashdot eating it. I meant tag, duh.
Just prepend a proper tag. :)
I don't quite understand. A mirror provides a set of files which the vendor provides as well. Where is the problem taking the file from the mirror and comparing its MD5 sum to the one from the vendor?
And you can't trust vendor-supplied MD5 sums when you're dealing with new versions downloaded for bug fixes or critical features.
That's the part I don't get here.
He wasn't talking about bugs. He was talking about bad/malicious code introduced by a maintainer of a mirror for example. 0 percent chance was meant as "no chance the data on the mirror differs from the data the vendor is offering for download".
A matching MD5 checksum together with matching file sizes is as good as a 0 percent chance of any bad data.
Not even the worst paranoia is a reason not to use a mirror together with a vendor-provided md5sum.
If you really have enough in-house talent to not need Red Hat support why bother with Red Hat on a commercial level at all? Just download one of their ISOs (that is possible, right?) - or any other distribution for that matter - and do it all yourself. Correct me if I'm wrong but the number one reason to actually pay for a Linux distribution is the support that comes with it, isn't it?
What problem are you referring to? I googled for "bundirty" and all I could find were code snippets. You did mail the problem to one of the lists, didn't you? I'm not trying to deny that you actually had a problem. I'm merely interested in details as I couldn't find any myself. Thanks.
bash is the bourne again shell. the bourne shell is simply sh(1), which is included of course.
compression comes to mind as well
You mean their interfaces were capable of transferring 66MB/s and 100MB/s respectively. The maximum a current IDE drive can sustain is around 50-60MB/s and then only at the outer edge of the platter. Anything above ATA100 only helps burst transfers from the drive's cache and doesn't really do anything for real world performance (except maybe for those 8MB cache drives).
Because computing OGR nodes is done in a relatively small loop, involving hardly any OS calls AFAIK. Things like OGR and RC5 depend more on the processor than on the OS.
I have tried to use the Distributed.net client on an AMD Athlon 1600 XP running Linux 2.4.10 and a G4 864 Mhz using Mac OS X 10.2. It seems that in terms of raw processing power, the G4 was actually more powerful, at over 10,260,280 nodes/sec, while the Athlon was only at 8,160,200 nodes/sec, and that's with no backgrounds processes running (besides the OS)
It's kind of naive to equate OGR performance with "raw processing power". Computing OGR nodes is a very special case of computing something. There may be other cases where the Athlon is better.
Disclaimer: I'm neither an Athlon nor PowerPC fanatic.
The Linux kernel is a shell script? :)
Perhaps General Protection Fault holds him back.
Someone had to do it..
I guess it's the capitalisation. "ihre" is "their" while "Ihre" is mostly "your" in a more formal way. Babelfish seems to have trouble with the capitalised "Ihre" and not noticing/knowing what to do with it at the beginning of a sentence.
Whatever..
.. can you run one before you need to recharge?