Nice proggy, though...
1) it often seems to block, especially with the interface probing and the iptables rules listing
2) heavily lacks documentation and (perhaps even more important) a rapid online set of tips. If I am to remember the entire iptables man by heart, I can't see much of a utility for a graphical frontend.
3) perhaps there could be a "wizzard" to load a pretty much generic set of rules to be further customized. That could save users a lot of hard time, trying to figure out how to get a working firewall without blocking just about every single packet over the network. No, I'm not a user-friendly freak, nor do I consider acceptable idiotic
autoconfigurations ala "low-medium-high-paranoid" that many distros try to promote. What I intend is much like the firestarter's (a gnome prog.) configuration. However the latter as a whole program has a lot of inadequacies as it isnt as flexible nor as stable as knetfilter.
In any case, nice work!
Re: Most of the time, it _IS_ the users fault.
> Bullshit. Please get a clue before
> making these blind comments. You
> obviously know absolutely nothing about
> the hardware in question, and thus have
> no valid basis for your utterly
> misinformed and inaccurate comments.
> Yeah, being able to probe attached panel
> information from the device would be
> nice, and would save headaches when
> dealing with inept users.. but this
> isn't a dream world, and not all
> hardware works in such a nice fashion..
> this particular controller especially
> does not. Next you'll be telling me that
> non-pnp ISA devices can deal with their
> own resource management because you
> think it *can* be done. Please get a
> clue. Write some code, and stop talking
> out of your ass about things you know
> nothing about.
This is pure ACID! You should step down from that throne of kernel kingdom for a while and listen to (not necessarely follow) some advice by those humble humans.
So my ignorant advice is: remember XF86Setup? If the configuration does not work out the prog falls back. That is, you setup a console configuration tool (if without the driver you cant run even console, then you MUST fork the driver in 4 different ones making less confusion among users). This tool starts the configuration (modprobe was very well prompted by someone) if does not recieve user confirmation within a certain timeout passes over to the next one up to 4, if it still didn't get no confirmation it exits failing and printing an error message repaiting that the user should confirm upon success or consider the fact that the driver might be inapropriate. No hardware probing needed anytime...
Now flame me...
I've got plenty of room down here at /dev/null