Checkpoint's products run on Red Hat Linux as well as they have their own customized Linux distro which I must say is very easy and best of all, it's (the OS, not their software) free and open source!
And I have a business line. Check out this page or this page. My experiences with them have been utterly horrible and it's all due solely to their incompetence. The links above are both to the same page, a page that contains logs of six (yes, SIX!!) months of problems and them not calling back, not knowing what they're doing, etc. etc.
Oh puh-leeze. RedHat will not be sending out people that will be able to answer the extremely complex questions surrounding databases sized for extremely large enterprises -- the oracle market. They will send out someone that knows something about the operating system with maybe some cursory RDBMS experience. Make no mistake, these WILL NOT be terribly seasoned individuals.
Check out their "About digibid.com" part:
Digibid protects both sellers and buyers . At the close of auction, the seller is notified to ship the item only after we have secured payment. The payment to the seller is released only after the item is accepted by the buyer.
This is exactly the way it should be... If ebay expects to continue as an auction house, they should act like one, or Visa and MasterCard should cut them off..
(Another part I like about digibid.com: Unlike other auctions, you can have complete confidence in your purchases because everything on Digibid is covered by a 100% money back guarantee!)
Are you kidding? Here in Minneapolis/St. Paul + Suburbs (where most of the broadband sales are in the MN, ND, and SD market) there are plenty of other options... Just for DSL there are: Visi, Agiliti, Onvoy, and more.. Plus all the Cable Modem companies, including AT&T (formerly Mediaone). It is NOT a monopoly.// dijit
dijit-at-interactiveinfosec.com
http://uswest.sucksass.com/
Unfortunately the person posting this comment doesn't know what RFC stands for.. Request For Comments. This means that people must adhere to the requirements to make them interoperable at a basic level -- Example IPSEC. Unfortunately, there are plenty of ways that companies interpreted this "standard" and guess what -- most of the implementations didn't work together. Hence the rewrite of the RFC. To make sure that the standards are trusted, they must be very specific so that not only the code can be verified to be secure, but also the assumptions and the ideas.
Here's an example that debunks both philosophies: Secure Computing's OS incorporated with their firewall product Sidewinder. There has been no Open-Source involved, no security problems, and guess what -- They have an excellent development methodology. Their development adhered to a strict set of guidelines and the product was not released until it was ready.
Just because you open-source code and/or have a publicly defined set of criteria to match doesn't mean that it's good or secure. Unfortunately, most companies release software before doing rigorous testing and hire cheap Comp-Sci graduates with no experience to write their software. Just because it works doesn't mean it works well. If we want good and/or secure software, we have to convince software companies that it's what we actually want and we can wait. Trusted systems (Like Trusted Solaris or Sidewinder) just have to prove that they adhere to their development methodologies and the criteria set forth by the certifying party. Trusted doesn't necessarily mean secure.
I had this problem a while back with USWest. Unfortunately, even though I dealt with only them, they had three separate areas within the company that did not work together at all and found the same problems.
In fact, according to a professor of mine less than a year ago who was a VP for Musicland, they actually lose money every quarter on record/cd/cassette sales except the fourth quarter where they make up their losses in christmas sales. Take a look at musicland's earnings per share up until 1999. With the exception of 1999, they would lose money each quarter except Q4. In 1999 their initiatives made them profitable, but their Q1 profits were not even close to 1/4 their total profit from 1999.
// dijit tobkin-at-tobkin.com
"Nothing great was ever achieved without enthusiasm." - Ralph Waldo Emerson, poet, writer, and philosopher
Re:Correct me if I'm wrong but . . .
on
Linux Appliances
·
· Score: 1
Show me one Sun machine that you can just pop it out of the box and lets users work of it..
Buy any sun computer nowadays and you will find the OS preinstalled. The patches you need to install are not required for new hardware. Only on revolutionary third party software will you need to install patches or add files to/etc/. You may have to configure the device to make it work (i.e. setting an IP address on an ethernet card) but that should be expected.
"boot -r" or "reboot -- -r" will rebuild the devices. Almost all devices that are made for the Sparc platform make the physical devices conform to a strict list of instructions for compatability. This is pretty much the same with Macintosh. The drivers are bundled with the OS, and the vendors adhere to those specifications.
The problems are not in the software, they are in the legacy hardware that does not have specified instructions to use for most types of devices. The hardware vendors for the x86 platform are expected to product their own drivers and distribute them with the hardware.
// dijit dijit@half-truth.com
"Always check your facts before speaking like an expert."
This is a quite absurd statement. This isn't a bug, it's a philosophical decision. When weighing the security against ease of use, you chose the latter. Period. There's nothing else to be said. The only way this could be considered a "bug" is that you have a "bug" in your development philosophy. After all the whining and bitching on Bugtraq for years about how nearly every *nix distro has a ton of services that end up exploitable and are turned on by default, and I know some of you @redhat.com people are on that list, you should have considered it a long time ago.
Now this has put Linux, because it will take some of the heat in the media, but more specifically RedHat, in a sticky situation. Everyone that has a version of Linux (up to but possibly not including the current beta) has a version that is vulnerable to at least two or three well-known exploits. Now they are being mass-owned by script-kiddies. If you would have changed your distro a long time ago, while all the security experts were calling for it from all vendors, then you wouldn't have this problem. I suppose your solution is "just upgrade to the newest version" -- a very MSFT-like statement. You can't expect everyone that's a half-moron installing Linux to a) keep up with the patches and problems, or b) keep up with the newest release.
Here's a thought for all the community: SECURITY AS AN AFTERTHOUGHT DOES NOT WORK WELL IN THIS REALITY!
// dijit tobkin-at-half-truth.com
P.S. FYI, for security bugs or whatever you'd like to call problems like this, Microsoft does have a place to submit them, security@microsoft.com, which has a decent turnaround time.
This is a quite absurd statement. This isn't a bug, it's a philosophical decision. When weighing the security against ease of use, you chose the latter. Period. There's nothing else to be said. The only way this could be considered a "bug" is that you have a "bug" in your development philosophy. After all the whining and bitching on Bugtraq for years about how nearly every *nix distro has a ton of services that end up exploitable and are turned on by default, and I know some of you @redhat.com people are on that list, you should have considered it a long time ago.
Now this has put Linux, because it will take some of the heat in the media, but more specifically RedHat, in a sticky situation. Everyone that has a version of Linux (up to but possibly not including the current beta) has a version that is vulnerable to at least two or three well-known exploits. Now they are being mass-owned by script-kiddies. If you would have changed your distro a long time ago, while all the security experts were calling for it from all vendors, then you wouldn't have this problem. I suppose your solution is "just upgrade to the newest version" -- a very MSFT-like statement. You can't expect everyone that's a half-moron installing Linux to a) keep up with the patches and problems, or b) keep up with the newest release.
Here's a thought for all the community: SECURITY AS AN AFTERTHOUGHT DOES NOT WORK WELL IN THIS REALITY!
// dijit
tobkin-at-half-truth.com
P.S. FYI, for security bugs or whatever you'd like to call problems like this, Microsoft does have a place to submit them, security@microsoft.com, which has a decent turnaround time.
I personally don't think that it would be bad having the software industry be responsible for carelessly written or insecure software. Maybe it would make Microsoft stop and rethink their development strategy of "write it, get it out the door and in peoples' offices, and then fix it so that it works." (I'm picking on Microsoft, but there are many others out there that do the same thing.)
Security is almost always an afterthought in software design. And in almost all of these cases, the afterthought of closing the holes a) doesn't get done until someone publicizes it; b) is written/patched by a junior programmer because the more senior ones are busy getting the next version out -- and the good programmers you don't want to lose won't stand for a job doing maintenance; or c) "will be fixed in the next version" (i.e. you'll have to upgrade to Window 98)
I believe that if I install some software that I pay a bundle for (maybe not AOL in this case, but this is how the precedent will be set) that it should be relatively bug-free. This means that the companies will have to prove that they did due dilegence to look for, and fix, the problems in their code. If you didn't pay for the software, I'm sure that you'd expect it to be full of holes (i.e. you can't really blame anyone for problems in open-sourced software -- but someone like RedHat may have some serious problems).
The correct way to block ads is to blackhole their entire zone on your DNS server. For example:
in/etc/named.conf add:
zone "doubleclick.net" { type master; file "db.blackhole"; };
and in db.blackhole it could just contain: @ IN SOA nowhere. hostmaster.nowhere. ( 1999083000; 10800; 3600 ; 86400 ; 43200 ) ;
That's it. This will stop any packets looking for that image from ever being transmitted. If you want to only block one host or subdomain, just add that instead of the "doubleclick.net" in/etc/named.conf. If you can't do it, email your admins and ask them to. (Note: dilbert.com comes up a lot faster this way.)
If your machine is reaching such a load, grab another machine, separate SMTP and POP/IMAP services between the machines, and have the SMTP server NFS mount the drive the POP/IMAP server stores the mail folders on. Slowness in getting the mail from SMTP to the user's mailbox is a minimal problem.. It's bursty by nature. You'll have to rsync the passwd file or use NIS (eew) and make sure you filter all the ports you just opened up at the router. We have successfully used this to drop the load down to a dull roar on a sparc 20 used for POP and have an E150 to handle SMTP (which idles at a load of 0.02 or so). You'll want to understand DNS and MX records first, but it's not that hard to wrap your head around. Many of these Linux bigots think just getting faster hardware is always the solution.. Distribution of load and quality of hardware and service make up a lot when you have a lot of people depending on it.
You'll probably want to investigate whether or not it's your disk I/O that's actually causing your problem. If it is, (and I know I'm going to look like the antichrist of/. because I reccomend this) you may want to look into the Sun Storage Solutions since you made the right decision to get a Sun in the first place. http://www.sun.com/storage/disk.html The MultiPack (http://www.sun.com/storage/multipack/) works very well. The disk I/O speed is plenty for a fairly heavily used Oracle server we have.
I've paged through most of the ~500 comments on this topic and seen that everyone is just pissed off that thre are rumors that companies are forbidding OSS. I'm amazed at how high the average rank of/. probably is, but how shortsighted people are. Put aside your biases and religious following and think "Why would someone decide that OSS software may hurt them?" Well, I have an idea. If you can get the source, you can make changes, recompile it, and then extend the vanilla installation. This is good right? Well, it is if you have a good, well practiced and followed policy for 1) keeping the modified source around, 2) CVSing it, 3) making sure that people are aware of what's been changed, how, and why it's been changed.
Let's say your business hinges on a piece of software.. lets make it Apache... to make it work (luckily it's OSS) you have to patch it to do something it wasn't designed to do. You decide to save space on the server because you're running out of it and delete the modified source. Of course, you know what you did and can do it again if you need to.. No big deal. Well, a month later you decide that this great job offer somewhere else is too good to pass up and you move on. Three months later a new version of Apache comes out and the company tries to upgrade to it.. (there was a security problem in the old version or something... they just need to upgrade...) They upgrade and it doesn't work.. Why? "What did we do to make it work before?" they ask. Well, they have to start from square one and develop the patch for it all over again. On the other hand, if you had not had the source, you wouldn't have patched it, you'd just have made a program outside of it to handle the special feature that you required. When the new version comes out, it's backwards compatible with what the original Apache group made before. If you start patching kernels and doing special stuff, the company starts to hinge around the people that know what's been changed, how it was changed, and why. With the high turnover in Techies, companies are leery about putting that much responsibility on an employee that could just up and walk out without so much as 'goodbye'.
Actually, a lot of people still DO run IIS3 because there are constant problems with IIS4 and, as we have found, it introduces more problems than it solves. Also, IIS4 has proven to us to have a huge performance hit in comparison to IIS3. All the hotfixes and service packs applied don't even help it. We tried it with very complex code and very simple code.. same thing each time. If you don't have a good reason to upgrade to IIS4, you may not want to.. If you do, have a good backup ready.
Honestly, If you are going to say "I work for such and such" then provide an email address.. I could say that I work for anyone.. Your "Anonymous Coward" gives your statements a lot less credibility. In my experience with MSSQL 6.5 and 7 versus Oracle 7 and 8, they are both great database packages... However, Oracle has allowed us to do a lot of custom things that MSSQL did not. I've got to say that a large part of it, however, is how trained your admins are. If you get a real oracle certified admin, he/she can make that server run circles around your ms certified mssql dba's.
BTW, I really doubt that your server has been up since 1997, since you would either be a) not running the current service packs or b) not running the current software. You may be correct that the database software has not required a reboot, but I'd bet the OS requires it at least once a month.. That's the longest I've ever seen a production NT machine stay up.. especially if you are keeping up with the most recent hotfixes..
Also, If your UNIX admins are not able to get sleep because of problems with the desktops, you should get some new admins or maybe send them to LISA. They obviously don't know enough about the OS that they're using.. Has dell started to hire linux admins to run solaris machines now too?
Slashdot Mirror
Check Point's Website
dijit-at-half-truth.com
Oh puh-leeze. RedHat will not be sending out people that will be able to answer the extremely complex questions surrounding databases sized for extremely large enterprises -- the oracle market. They will send out someone that knows something about the operating system with maybe some cursory RDBMS experience. Make no mistake, these WILL NOT be terribly seasoned individuals.
// dijit
Check out their "About digibid.com" part:
Digibid protects both sellers and buyers . At the close of auction, the seller is notified to ship the item only after we have secured payment. The payment to the seller is released only after the item is accepted by the buyer.
This is exactly the way it should be... If ebay expects to continue as an auction house, they should act like one, or Visa and MasterCard should cut them off..
(Another part I like about digibid.com: Unlike other auctions, you can have complete confidence in your purchases because everything on Digibid is covered by a 100% money back guarantee!)
Are you kidding? Here in Minneapolis/St. Paul + Suburbs (where most of the broadband sales are in the MN, ND, and SD market) there are plenty of other options... Just for DSL there are: Visi, Agiliti, Onvoy, and more.. Plus all the Cable Modem companies, including AT&T (formerly Mediaone). It is NOT a monopoly. // dijit
dijit-at-interactiveinfosec.com
http://uswest.sucksass.com/
// dijit
dijit-at-half-truth.com
CCSA,MCP
Just because you open-source code and/or have a publicly defined set of criteria to match doesn't mean that it's good or secure. Unfortunately, most companies release software before doing rigorous testing and hire cheap Comp-Sci graduates with no experience to write their software. Just because it works doesn't mean it works well. If we want good and/or secure software, we have to convince software companies that it's what we actually want and we can wait. Trusted systems (Like Trusted Solaris or Sidewinder) just have to prove that they adhere to their development methodologies and the criteria set forth by the certifying party. Trusted doesn't necessarily mean secure.
dijit-at-half-truth.com
I wrote this up on my website at http://www.half-truth.com/uswest if you'd care to read about it in detail.
dijit-at-half-truth.com
tobkin-at-tobkin.com
"Nothing great was ever achieved without enthusiasm."
- Ralph Waldo Emerson, poet, writer, and philosopher
Buy any sun computer nowadays and you will find the OS preinstalled. The patches you need to install are not required for new hardware. Only on revolutionary third party software will you need to install patches or add files to /etc/. You may have to configure the device to make it work (i.e. setting an IP address on an ethernet card) but that should be expected.
"boot -r" or "reboot -- -r" will rebuild the devices. Almost all devices that are made for the Sparc platform make the physical devices conform to a strict list of instructions for compatability. This is pretty much the same with Macintosh. The drivers are bundled with the OS, and the vendors adhere to those specifications.
The problems are not in the software, they are in the legacy hardware that does not have specified instructions to use for most types of devices. The hardware vendors for the x86 platform are expected to product their own drivers and distribute them with the hardware.
dijit@half-truth.com
"Always check your facts before speaking like an expert."
This is a quite absurd statement. This isn't a bug, it's a philosophical decision. When weighing the security against ease of use, you chose the latter. Period. There's nothing else to be said. The only way this could be considered a "bug" is that you have a "bug" in your development philosophy. After all the whining and bitching on Bugtraq for years about how nearly every *nix distro has a ton of services that end up exploitable and are turned on by default, and I know some of you @redhat.com people are on that list, you should have considered it a long time ago.
Now this has put Linux, because it will take some of the heat in the media, but more specifically RedHat, in a sticky situation. Everyone that has a version of Linux (up to but possibly not including the current beta) has a version that is vulnerable to at least two or three well-known exploits. Now they are being mass-owned by script-kiddies. If you would have changed your distro a long time ago, while all the security experts were calling for it from all vendors, then you wouldn't have this problem. I suppose your solution is "just upgrade to the newest version" -- a very MSFT-like statement. You can't expect everyone that's a half-moron installing Linux to a) keep up with the patches and problems, or b) keep up with the newest release.
Here's a thought for all the community: SECURITY AS AN AFTERTHOUGHT DOES NOT WORK WELL IN THIS REALITY!
tobkin-at-half-truth.com
P.S. FYI, for security bugs or whatever you'd like to call problems like this, Microsoft does have a place to submit them, security@microsoft.com, which has a decent turnaround time.
This is a quite absurd statement. This isn't a bug, it's a philosophical decision. When weighing the security against ease of use, you chose the latter. Period. There's nothing else to be said. The only way this could be considered a "bug" is that you have a "bug" in your development philosophy. After all the whining and bitching on Bugtraq for years about how nearly every *nix distro has a ton of services that end up exploitable and are turned on by default, and I know some of you @redhat.com people are on that list, you should have considered it a long time ago.
Now this has put Linux, because it will take some of the heat in the media, but more specifically RedHat, in a sticky situation. Everyone that has a version of Linux (up to but possibly not including the current beta) has a version that is vulnerable to at least two or three well-known exploits. Now they are being mass-owned by script-kiddies. If you would have changed your distro a long time ago, while all the security experts were calling for it from all vendors, then you wouldn't have this problem. I suppose your solution is "just upgrade to the newest version" -- a very MSFT-like statement. You can't expect everyone that's a half-moron installing Linux to a) keep up with the patches and problems, or b) keep up with the newest release.
Here's a thought for all the community: SECURITY AS AN AFTERTHOUGHT DOES NOT WORK WELL IN THIS REALITY!
// dijit
tobkin-at-half-truth.com
P.S. FYI, for security bugs or whatever you'd like to call problems like this, Microsoft does have a place to submit them, security@microsoft.com, which has a decent turnaround time.
With Cablemodems and xDSL becoming more of the standard, having larger amounts of bandwidth is becoming the standard, not the exception.
Security is almost always an afterthought in software design. And in almost all of these cases, the afterthought of closing the holes a) doesn't get done until someone publicizes it; b) is written/patched by a junior programmer because the more senior ones are busy getting the next version out -- and the good programmers you don't want to lose won't stand for a job doing maintenance; or c) "will be fixed in the next version" (i.e. you'll have to upgrade to Window 98)
I believe that if I install some software that I pay a bundle for (maybe not AOL in this case, but this is how the precedent will be set) that it should be relatively bug-free. This means that the companies will have to prove that they did due dilegence to look for, and fix, the problems in their code. If you didn't pay for the software, I'm sure that you'd expect it to be full of holes (i.e. you can't really blame anyone for problems in open-sourced software -- but someone like RedHat may have some serious problems).
// dijit
tobkin-at-half-truth.com
tobkin-at-half-truth.com
in /etc/named.conf add:
zone "doubleclick.net" {
type master;
file "db.blackhole";
};
and in db.blackhole it could just contain: ; ;
@ IN SOA nowhere. hostmaster.nowhere. (
1999083000
10800
3600 ;
86400 ;
43200 ) ;
That's it. This will stop any packets looking for that image from ever being transmitted. If you want to only block one host or subdomain, just add that instead of the "doubleclick.net" in /etc/named.conf. If you can't do it, email your admins and ask them to. (Note: dilbert.com comes up a lot faster this way.)
dijit at half-truth.com
You'll probably want to investigate whether or not it's your disk I/O that's actually causing your problem. If it is, (and I know I'm going to look like the antichrist of /. because I reccomend this) you may want to look into the Sun Storage Solutions since you made the right decision to get a Sun in the first place. http://www.sun.com/storage/disk.html The MultiPack (http://www.sun.com/storage/multipack/) works very well. The disk I/O speed is plenty for a fairly heavily used Oracle server we have.
Let's say your business hinges on a piece of software.. lets make it Apache... to make it work (luckily it's OSS) you have to patch it to do something it wasn't designed to do. You decide to save space on the server because you're running out of it and delete the modified source. Of course, you know what you did and can do it again if you need to.. No big deal. Well, a month later you decide that this great job offer somewhere else is too good to pass up and you move on. Three months later a new version of Apache comes out and the company tries to upgrade to it.. (there was a security problem in the old version or something... they just need to upgrade...) They upgrade and it doesn't work.. Why? "What did we do to make it work before?" they ask. Well, they have to start from square one and develop the patch for it all over again. On the other hand, if you had not had the source, you wouldn't have patched it, you'd just have made a program outside of it to handle the special feature that you required. When the new version comes out, it's backwards compatible with what the original Apache group made before. If you start patching kernels and doing special stuff, the company starts to hinge around the people that know what's been changed, how it was changed, and why. With the high turnover in Techies, companies are leery about putting that much responsibility on an employee that could just up and walk out without so much as 'goodbye'.
Thoughts?
-- dijit
tobkin@tobkin.com
Actually, a lot of people still DO run IIS3 because there are constant problems with IIS4 and, as we have found, it introduces more problems than it solves. Also, IIS4 has proven to us to have a huge performance hit in comparison to IIS3. All the hotfixes and service packs applied don't even help it. We tried it with very complex code and very simple code.. same thing each time. If you don't have a good reason to upgrade to IIS4, you may not want to.. If you do, have a good backup ready.
BTW, I really doubt that your server has been up since 1997, since you would either be a) not running the current service packs or b) not running the current software. You may be correct that the database software has not required a reboot, but I'd bet the OS requires it at least once a month.. That's the longest I've ever seen a production NT machine stay up.. especially if you are keeping up with the most recent hotfixes..
Also, If your UNIX admins are not able to get sleep because of problems with the desktops, you should get some new admins or maybe send them to LISA. They obviously don't know enough about the OS that they're using.. Has dell started to hire linux admins to run solaris machines now too?