Regardless, porting the CP GUI to Linux is great because its so well emulated on other platforms. Solaris,Open/Net/FreeBSD all can run Linux X86 binaries. I'd still rather have a native binary, but any binary is better than none.
There will almost certainly be a kernel module involved with the firewall port itself, since the Inspect Engine runs as a module on all the other UN*X platforms VPN-1/FW-1 supports. I don't know for certain, but I can't see how the binary emulation will work with kernel modules.
See my previous comments with regards to the GUI.
(Again, yes, I work for Check Point. No, this is not official Check Point Gospel. I speak for me, not Check Point.)
I'm not a GUI programmer but we allready have a solaris motif GUI now, I guess it would just be library or two to make it work.
The Solaris GUI is a port of the Windows GUI, sitting on top of some compatability toolkit. I don't know which toolkit, but it's not something like GTK+ or wxWindows or Java. For the GUI to run on Linux, that toolkit would have to exist for Linux. If it doesn't, then no GUI for Linux.
Also, the Solaris GUI only runs under Solaris Sparc, not Solaris x86.
PeeWee
(Yes, I work for Check Point. No, I don't speak for the company. If you think what I'm saying is official Check Point Gospel, you're insane.)
Pretty interesting. Could you give a hint where to look? My company would be very interested in a device like this.
Most likely, he was referring to the VPN-1 appliances. The OS in these devices was based on FreeBSD, but has been highly customized. Look at http://www.checkpoint.com/prod ucts/vpn1/applianceds.html for more information.
Check your rsize and wsize options that you use on Linux to mount the NFS stuff.
My reads are fine, so I've left rsize at 8192.
I have played with the wsize. I've tried 1024, 2048, 4096 and 8192. I've been through the NFS HOWTO and the Ethernet HOWTO. I've been through DejaNews many times and all I've really found is that I'm not the only one having problems with Solaris NFS servers. This isn't a new problem for me, every Linux box I've set up seems to have it, from kernels back in the 1.2.x days. I'm a Solaris admin for a living, so all of my NFS servers have been Solaris, including the Ultra 5 I use as my home server.
Playing on my home systems after writing my original post, I made some progress. If I specify the 'tcp' option to mount, my writes get noticably faster, but are still slower than I think that they should be. So far, my best performance seems to come from these mount options: rw,rsize=8192,wsize=1024,tcp.
I'm not dissing Linux or its NFS implementation, by the way. I've been adminning UN*X servers for living for about five years and I've been using UN*X for about four years longer than that, so I'm used to quirks and interoperability glitches. I expect them. They're OK. It just happens that none of the Linux boxes I've deployed in production environments have depended on NFS for anything more than my convenience, so I've never been terribly motivated to fix it.
BTW, thank you for your suggestion. I do appreciate it, even if I did seem to tear it down.
PeeWee
P.S. And no, I won't run Linux on the Ultra 5, in case someone was going to suggest that.;)
Both have "cachefs", and support NFS version 3. Linux' NFS is one of its weakest points - it is dead, bog slow compared to my Solaris servers.
If the filesystem you're mounting changes frequently, as I presume the/. filesystems do, then cachefs will probably slow things down. In my testing, using Solaris clients and Solaris servers, it worked best on read-only, rarely changed filesystems and then it worked very well.
That said, I'm not too happy with Linux's client NFS performance, but my problems seem to only occur when I try and use a Linux client with a Solaris server and I haven't actually figured out which side the problem is on. Hopefully, I'll have time over this weekend to try the NFSv3 patches.
People should be able to do anything they want as long as it doesnt hurt other people OR THEMSELVES.
While I agree with this, mostly, I can't agree with the rest of what you said. I mean, you say that the goverment is fine the way that it is, but you also say that we should be able to do what we want as long as we don't harm anyone??
What about, say drugs? Who would be harmed if someone grew some weed in his back yard, didn't sell any and used it all himself? I believe that there's no victim there and thus should be legal like most other "victimless crimes. You might say that this person's "stupidity" might harm him but don't forget that the government, or at least certain elements within it are also trying to make it illegal to discuss or link to information regarding drug use and/or manufacture.
It seems to me that the U.S. goverment doesn't necessarily want you to be stupid, merely uniformed.
PeeWee
Re:First drugs then what ???
on
New Cyberlaws
·
· Score: 1
Watch out for the day it'll be a felony to link to Slashdot !
If the link law passes, then it'll be illegal to link to this discussion.
PeeWee
Re:why are drugs illegal in the US anyway?
on
New Cyberlaws
·
· Score: 1
Why are we still wasting money on these pointless laws? Who benefits from the war on drugs?
I tend to believe that drugs are illegal because they might expose someone to facets of reality which aren't broadcast on the officially sanctioned reality channels (ie, television). That might lead to individuality and free thought and we sure can't have that, now can we?
Slashdot Mirror
Untrue.
Both the OpenLook GUI (the older style GUI from the 1.x and 2.x days) and the Motif GUI (the port of the Windows GUI) run under Solaris.
PeeWee
There will almost certainly be a kernel module involved with the firewall port itself, since the Inspect Engine runs as a module on all the other UN*X platforms VPN-1/FW-1 supports. I don't know for certain, but I can't see how the binary emulation will work with kernel modules.
See my previous comments with regards to the GUI.
(Again, yes, I work for Check Point. No, this is not official Check Point Gospel. I speak for me, not Check Point.)
PeeWee
The Solaris GUI is a port of the Windows GUI, sitting on top of some compatability toolkit. I don't know which toolkit, but it's not something like GTK+ or wxWindows or Java. For the GUI to run on Linux, that toolkit would have to exist for Linux. If it doesn't, then no GUI for Linux.
Also, the Solaris GUI only runs under Solaris Sparc, not Solaris x86.
PeeWee
(Yes, I work for Check Point. No, I don't speak for the company. If you think what I'm saying is official Check Point Gospel, you're insane.)
Most likely, he was referring to the VPN-1 appliances. The OS in these devices was based on FreeBSD, but has been highly customized. Look at http://www.checkpoint.com/prod ucts/vpn1/applianceds.html for more information.
PeeWee
Well said. Based on what I see being posted, I'd say a lot of posters here would eat the menu and leave the meal.
PeeWee
My reads are fine, so I've left rsize at 8192.
I have played with the wsize. I've tried 1024, 2048, 4096 and 8192. I've been through the NFS HOWTO and the Ethernet HOWTO. I've been through DejaNews many times and all I've really found is that I'm not the only one having problems with Solaris NFS servers. This isn't a new problem for me, every Linux box I've set up seems to have it, from kernels back in the 1.2.x days. I'm a Solaris admin for a living, so all of my NFS servers have been Solaris, including the Ultra 5 I use as my home server.
Playing on my home systems after writing my original post, I made some progress. If I specify the 'tcp' option to mount, my writes get noticably faster, but are still slower than I think that they should be. So far, my best performance seems to come from these mount options: rw,rsize=8192,wsize=1024,tcp.
I'm not dissing Linux or its NFS implementation, by the way. I've been adminning UN*X servers for living for about five years and I've been using UN*X for about four years longer than that, so I'm used to quirks and interoperability glitches. I expect them. They're OK. It just happens that none of the Linux boxes I've deployed in production environments have depended on NFS for anything more than my convenience, so I've never been terribly motivated to fix it.
BTW, thank you for your suggestion. I do appreciate it, even if I did seem to tear it down.
PeeWee
P.S. And no, I won't run Linux on the Ultra 5, in case someone was going to suggest that. ;)
If the filesystem you're mounting changes frequently, as I presume the /. filesystems do, then cachefs will probably slow things down. In my testing, using Solaris clients and Solaris servers, it worked best on read-only, rarely changed filesystems and then it worked very well.
That said, I'm not too happy with Linux's client NFS performance, but my problems seem to only occur when I try and use a Linux client with a Solaris server and I haven't actually figured out which side the problem is on. Hopefully, I'll have time over this weekend to try the NFSv3 patches.
PeeWee
While I agree with this, mostly, I can't agree with the rest of what you said. I mean, you say that the goverment is fine the way that it is, but you also say that we should be able to do what we want as long as we don't harm anyone??
What about, say drugs? Who would be harmed if someone grew some weed in his back yard, didn't sell any and used it all himself? I believe that there's no victim there and thus should be legal like most other "victimless crimes. You might say that this person's "stupidity" might harm him but don't forget that the government, or at least certain elements within it are also trying to make it illegal to discuss or link to information regarding drug use and/or manufacture.
It seems to me that the U.S. goverment doesn't necessarily want you to be stupid, merely uniformed.
PeeWee
If the link law passes, then it'll be illegal to link to this discussion.
PeeWee
I tend to believe that drugs are illegal because they might expose someone to facets of reality which aren't broadcast on the officially sanctioned reality channels (ie, television). That might lead to individuality and free thought and we sure can't have that, now can we?
PeeWee