Strict liability for loss of customer information.
It may work only if the liability is prohibitively high. Otherwise, once we put a price tag on privacy, corporations will simply calculate the cost of protection and expected liability (by doing some probability maths). Turns out that people may find it less costly overall by sticking with a minimal protection scheme.
IBM hires people with any kind of degree. They seem to look for the quality of your mind rather than knowledge and then stuff u with all needed knowledge through OJT.
On the contrary I got that problem on Mandrake (around 8.x) and I suspect it had something to do with the particular video driver which couldn't cleanly switch video modes on certain hardware.
I was NOT saying that Apache/Squid are safe to be auto-updated. I quote them to illustrate that software without the blessing by Patrick are not any riskier to use.
What Pat has done is to kind of 'mark' things as stable (and I do think he's done a good job), but software without his chop are not necessarily unstable.
btw, swaret uses the vanilla pkgtool for package handling.
Since my first encounter of Slackware 10 years ago I never need to seek specific help from the community. Either Slackware just works, or my problems have been addressed and google-able. For other problems its always easy to trace through how Slackware is doing stuff e.g. by reading the doc or following straight-forward shell scripts.
On the other hand, with mdk or rh I often found myself overwhelmed by a mess of auto configuration tools which subtly fiddle with scattered, obscure config files and soft-links. Recent versions seemed to have more standardized and consistent tools but I still prefer getting my hands dirty to make things just work.
Yes they ain't official. But over the past 6 months of using swaret I found it to work extremely well once you know how to properly configure it (e.g. not to auto update kernel packages when you're using a self-compiled kernel). The important thing is that, as long as you know what it's doing and what u're doing, the risk is low no matter it's official or not.
There're many good software that are not 'official' by ur definition (e.g. Apache 2 and Squid). Do they also deserve this big 'USE AT YOUR OWN RISK' sign that scares off potential users?
The best way to learn the truth about the quality and reliability of any software is to test it yourself.
The distributions we encourage our customers to use are Redhat/Fedora because this distro family is easy to support. Those other distros may or may not have real (technical) advantages over Redhat, but none of them scale as well as Redhat does. SuSE may scale equally well but due to Redhat's popularity we simply haven't had much call to try and work on SuSE systems.
I don't see how one distro is easier or more difficult to support than another one. On any Linux machine you can almost alway assume to have a similar set of troubleshooting tools installed which work exactly the same across distro. The exception may be that the support guys' skillset are narrowed to RedHat/Suse specific stuff. But I think a good *nix technician should have (and should be trained to have) the skills to perform similarly on any kind of *nix.
The reason why we push Redhat/Fedora and not some other distro is because we don't want to have to install packages by hand or compile stuff from source all the time...but that just doesn't work when you're trying to support several hundred systems.
What make you think that using other distro translate to installing/compiling packages by hand? There're numerous tools that automates package upgrade and installation on large scale (for large shops they would have usually made their own tools). And even on Redhat/Fedora we may sometimes unable to find a package that perfectly suit our needs (e.g. not the same version we want, not compiled with flags that we need,...). RPM-based distros do not always save us from getting ur hands dirty. Sometimes they turned out to be less convenient when we really have to roll something by hand.
The beauty of Linux is that we can always achieve what we desire, just by different means. I totally agree with the parent that we should never chooses ideology over technology. But I want to add that good Linux admins should also avoid being locked in to any type of distro/technology.
Actually, one can start to get a statistically significant result at around as little as 30 data points depending on a few factors.
Yes, but doesn't it require a random set of samples? This assumption no longer holds when people typically buy CPUs from their favorite retailers, who in turn get stuff from their favorite...
And regarding the original post about having 3 AMD CPUs dead, I'd highly suspect it's due not to the chip themselves (e.g. motherboard, cooling, bad retailer...). But anyway we can never draw any meaningful conclusion with that kind 'statistics'.
Agree that we need to differentiate between tgz source tar-ball vs tgz binary package.
Just also want to point out that on Slackware there is a utility 'checkinstall' which turns source install(i.e. './configure; make install') to become like a binary package install. Thereafter you can easily manage it as a package (i.e. removepkg, upgradepkg).
In fact the distro itself contains most of the stuff I need (for production server as well as my workstation). It even comes with Sun's latest JDK. In case I can't find some specific stuff, here is a good place for me. I can also use rpm2tgz to install RPM packages, or in the worst case, I can use 'checkinstall' to install from source while still making it like a package install (which means I can uninstall it with 'removepkg', or upgrade it once there is official tgz package available using 'upgradepkg').
I think that's because Konquerer is not just a hardisk file browser, but a more generalized browser that is network transparent. You can browse local stuff with location file:/xxx, remote stuff with ftp://xxx or a webpage with http://xxx, and more...
ya, most ppl out there that I met don't know what's 'Mozilla' nor its relation with Netscape the browser. Most companies still build IE only websites, some better ones build IE+Netscape, but Mozilla still remains to be the 'underground'.
More promotions, either by the press or by us/. readers are important.
I need 'Linux-certified' applications that works on MY choosen distro.
But more and more mega-corps are going the other way around, by supporting only one distro. This is exactly what I really don't want to see happening where only one distro dominates because of mega-corps backing it up. That would just help create another Micro$oft in the Linux distribution market. (corp supporting distro XXX -> more people use XXX -> more corp stick only to XXX ->...)
Why must we stick to redhat to run Oracle (or any other big guy's) apps? Why didn't they design their apps in the first place to minimize the dependency on specific Linux distro and allow customers to have choices? I can accept they stick their design and testing to certain kernel versions, libraries (e.g. threading), etc. And if they can just state it clearly then I can make my, say Slackware, to meet the requirements and should still be official supported.
The often used 'cost-saving' argument doesn't hold strong to me. Testing on various flavours of Linux should be trivial, compared to the whole testing process (which include testing on all types of OSes). It's like doing testing on WinME in addition to Win98. Plus I think there are many customers and hobbyists out there who are more then happy to help testing the apps on their preferred platform and provide feedback.
The 'certified platform' thing is even more ridiculous. I think it's more a strategic tool used by big guys to exert their dominant power and force others to comply with them, in order to re-inforce their dominant power or get rich. (Just see how much $$ Cisco, Microsoft, Oracle, Sun made just by certifying and its related businesses e.g. training). Do we want the apps we buy to be 'Linux-certified' and distro-independent, or do we want to be limited to only 'Oracle(or whoever)-certfied' Linux distro?
Ok, It doesn't run Duke Nukem 3D Forever. It does run Duke Nukem 3D however. It can run Duke Nukem 3D forever. It won't run Duke Nukem 3D smooth or fast or whatever
Slashdot Mirror
It may work only if the liability is prohibitively high. Otherwise, once we put a price tag on privacy, corporations will simply calculate the cost of protection and expected liability (by doing some probability maths). Turns out that people may find it less costly overall by sticking with a minimal protection scheme.
In xpdf you can drag around with the middle button.
no problem...dual-core = 32bit * 2 = 64bit
IBM hires people with any kind of degree. They seem to look for the quality of your mind rather than knowledge and then stuff u with all needed knowledge through OJT.
Sun switched to PointBase in their recent J2EE SDK.
On the contrary I got that problem on Mandrake (around 8.x) and I suspect it had something to do with the particular video driver which couldn't cleanly switch video modes on certain hardware.
I was NOT saying that Apache/Squid are safe to be auto-updated. I quote them to illustrate that software without the blessing by Patrick are not any riskier to use.
What Pat has done is to kind of 'mark' things as stable (and I do think he's done a good job), but software without his chop are not necessarily unstable.
btw, swaret uses the vanilla pkgtool for package handling.
Since my first encounter of Slackware 10 years ago I never need to seek specific help from the community. Either Slackware just works, or my problems have been addressed and google-able. For other problems its always easy to trace through how Slackware is doing stuff e.g. by reading the doc or following straight-forward shell scripts.
On the other hand, with mdk or rh I often found myself overwhelmed by a mess of auto configuration tools which subtly fiddle with scattered, obscure config files and soft-links. Recent versions seemed to have more standardized and consistent tools but I still prefer getting my hands dirty to make things just work.
Yes they ain't official. But over the past 6 months of using swaret I found it to work extremely well once you know how to properly configure it (e.g. not to auto update kernel packages when you're using a self-compiled kernel). The important thing is that, as long as you know what it's doing and what u're doing, the risk is low no matter it's official or not.
There're many good software that are not 'official' by ur definition (e.g. Apache 2 and Squid). Do they also deserve this big 'USE AT YOUR OWN RISK' sign that scares off potential users?
The best way to learn the truth about the quality and reliability of any software is to test it yourself.
The distributions we encourage our customers to use are Redhat/Fedora because this distro family is easy to support. Those other distros may or may not have real (technical) advantages over Redhat, but none of them scale as well as Redhat does. SuSE may scale equally well but due to Redhat's popularity we simply haven't had much call to try and work on SuSE systems.
...). RPM-based distros do not always save us from getting ur hands dirty. Sometimes they turned out to be less convenient when we really have to roll something by hand.
I don't see how one distro is easier or more difficult to support than another one. On any Linux machine you can almost alway assume to have a similar set of troubleshooting tools installed which work exactly the same across distro. The exception may be that the support guys' skillset are narrowed to RedHat/Suse specific stuff. But I think a good *nix technician should have (and should be trained to have) the skills to perform similarly on any kind of *nix.
The reason why we push Redhat/Fedora and not some other distro is because we don't want to have to install packages by hand or compile stuff from source all the time...but that just doesn't work when you're trying to support several hundred systems.
What make you think that using other distro translate to installing/compiling packages by hand? There're numerous tools that automates package upgrade and installation on large scale (for large shops they would have usually made their own tools). And even on Redhat/Fedora we may sometimes unable to find a package that perfectly suit our needs (e.g. not the same version we want, not compiled with flags that we need,
The beauty of Linux is that we can always achieve what we desire, just by different means. I totally agree with the parent that we should never chooses ideology over technology. But I want to add that good Linux admins should also avoid being locked in to any type of distro/technology.
just to show the efficiency of RPN for lengthy calculation:
algebraic : (2 + 1) * (4 + 3) + 5 =
(14 key strokes)
RPN: 2 [ENTER] 1 + 4 [ENTER] 3 + * 5 +
(11 key strokes)
Slackware has been (for 10 yrs) and is still a major distro.
a jo r
http://www.distrowatch.org/dwres.php?resource=m
You should wait for the iPod Micro Edition. So small it fits in your anus and uses a methane-powered fuel cell.
oh, that would really be a pain the ass to install...
obvious, ATI engineers were waiting for their Gentoo to...
Actually, one can start to get a statistically significant result at around as little as 30 data points depending on a few factors.
Yes, but doesn't it require a random set of samples? This assumption no longer holds when people typically buy CPUs from their favorite retailers, who in turn get stuff from their favorite...
And regarding the original post about having 3 AMD CPUs dead, I'd highly suspect it's due not to the chip themselves (e.g. motherboard, cooling, bad retailer...). But anyway we can never draw any meaningful conclusion with that kind 'statistics'.
Slackware 9.1 comes pre-installed with Sun's JDK 1.4....is it in violation or what?
Agree that we need to differentiate between tgz source tar-ball vs tgz binary package.
Just also want to point out that on Slackware there is a utility 'checkinstall' which turns source install(i.e. './configure; make install') to become like a binary package install. Thereafter you can easily manage it as a package (i.e. removepkg, upgradepkg).
Is apt-get the only reason that caused you to switch? You can do similar security updates and software upgrades with swaret.
I really want to know what other things does Debian offer which Slackware doesn't? (as I use solely Slackware at home and at work now)
And in my experience security fixes from Slackware are pretty quick, most of the time coming out earlier than, say, RedHat.
In fact the distro itself contains most of the stuff I need (for production server as well as my workstation). It even comes with Sun's latest JDK. In case I can't find some specific stuff, here is a good place for me. I can also use rpm2tgz to install RPM packages, or in the worst case, I can use 'checkinstall' to install from source while still making it like a package install (which means I can uninstall it with 'removepkg', or upgrade it once there is official tgz package available using 'upgradepkg').
I think that's because Konquerer is not just a hardisk file browser, but a more generalized browser that is network transparent. You can browse local stuff with location file:/xxx, remote stuff with ftp://xxx or a webpage with http://xxx, and more...
ya, most ppl out there that I met don't know what's 'Mozilla' nor its relation with Netscape the browser. Most companies still build IE only websites, some better ones build IE+Netscape, but Mozilla still remains to be the 'underground'.
/. readers are important.
More promotions, either by the press or by us
I need 'Linux-certified' applications that works on MY choosen distro.
...)
But more and more mega-corps are going the other way around, by supporting only one distro. This is exactly what I really don't want to see happening where only one distro dominates because of mega-corps backing it up. That would just help create another Micro$oft in the Linux distribution market. (corp supporting distro XXX -> more people use XXX -> more corp stick only to XXX ->
Why must we stick to redhat to run Oracle (or any other big guy's) apps? Why didn't they design their apps in the first place to minimize the dependency on specific Linux distro and allow customers to have choices? I can accept they stick their design and testing to certain kernel versions, libraries (e.g. threading), etc. And if they can just state it clearly then I can make my, say Slackware, to meet the requirements and should still be official supported.
The often used 'cost-saving' argument doesn't hold strong to me. Testing on various flavours of Linux should be trivial, compared to the whole testing process (which include testing on all types of OSes). It's like doing testing on WinME in addition to Win98. Plus I think there are many customers and hobbyists out there who are more then happy to help testing the apps on their preferred platform and provide feedback.
The 'certified platform' thing is even more ridiculous. I think it's more a strategic tool used by big guys to exert their dominant power and force others to comply with them, in order to re-inforce their dominant power or get rich. (Just see how much $$ Cisco, Microsoft, Oracle, Sun made just by certifying and its related businesses e.g. training). Do we want the apps we buy to be 'Linux-certified' and distro-independent, or do we want to be limited to only 'Oracle(or whoever)-certfied' Linux distro?
Ok,
It doesn't run Duke Nukem 3D Forever.
It does run Duke Nukem 3D however.
It can run Duke Nukem 3D forever.
It won't run Duke Nukem 3D smooth or fast or whatever
I'm curious to know what are those 16 bytes in the ROM...must have been highly optimized :)