Thanks,it’s very helpful for me.

Floola has been great for me since I often travel between multiple computers. I can connect, access, and modify music without worrying that I’ll screw up my collection. Thanks for stopping by, and for the comment!

great software. it’s the only one witch already works with the latest i pod nano.

-Ray Gomez

Gripe number 1) I’m not a huge fan of web interfaces. I know they are the hip thing, but I don’t want the webserver to break when it involves configuring my box. Moreover, I don’t want to be the one breaking the web interface (see Gripe 2). That being said, the interface is very clean and reminds me a lot of a great piece of software called Tomato which we had a post on.

Gripe number 2) The idea of building off of a standard distribution like Debian or Ubuntu is fantastic because it gives access to the latest and greatest software and security fixes. This is a double edged sword because the idea of being able to bring in these bleeding edge updates can also break a box.

As a personal preference, I would lean toward Untangle because they control the whole workings of the system. Meaning, I’m a little more reassured that their regression tests would incorporate all of the features I use most, and limit the potential of breaking my setup if and when I need to update. The downside is loss of customization and configuration (Ubuntu standard installation directories and files, etc).

Gripes aside, eBox has a great configuration backup utility, and some other great features like the ability to have eBox installations “communicate and coordinate with each other without bothering the system administrator.” If you are a Perl programmer and have a need to communicate with other eBox servers (say for reacting to certain security situations) this might be a good option for you.

In the end, it usually boils down to how much control you want over the system. Having a full blown Ubuntu or Debian install with the eBox layer could definitely give you that. If you want an all-in-one system where you sacrifice control for a more stability, and tighter integration, Untangle is certainly an option.

I hope this helps. Thanks for the comment, and for stopping by!

For your first question, I’m assuming you mean that you are behind a router or firewall. If this is the case you need to make sure that your router or firewall will allow port 22 access to the box running the NXServer. Meaning you will have to open port 22 to the net, and possibly forward it to your server. Currently I have a Linux box setup on my network with a local static ip, and use my router to forward external port 22 connects directly to my NXServer box. For additional security, I restrict access to my box by only allowing IP’s I trust using the /etc/hosts.allow file.

For your second question, of course! The beauty of NoMachines product is that you can grab a client for any major operating system (Windows, Mac OS X, Solaris, and of course Linux). You can grab the latest NXClient for Windows here.

I hope this helps, thanks for stopping by!

Very interesting topic, I have two Quetions:

1. Do I need “real ip” on my PC to login remotely?
2. Can I access with my PC from Windows OS?

Also, the word is spelled ‘putz.’

Otherwise, a nice, clear explanation.

Thanks for the Comment!!

$gmcs fib.cs -out:fib.o

or for something nostalgic…

$gmcs fib.cs -out:a.out

That is much better. Thanks for your comment!!

I hope that helps! Please let us know if you have any more questions!

(Looking back at my comment, I didn’t mean “halt execution”, I mean halt execution of that transaction so the application could continue cleanly).

So I think the pattern you’re actually using is just hiding the internal implementation of your message handler — which makes sense because the calling code has no interest in the specific implementation of each handler, so that shouldn’t be a part of that external interface.

Curious: is your “XYZHandlerException” a checked exception?

@Michael: absolutely — the checked reflection errors are annoying because that’s pretty much guaranteed to be programmer error, and the error just needs to bubble up to the top level and be reported. I have a simple reflection utility wrapper that basically just wraps those errors in an unchecked exception with good debugging detail if something does break.

@Litty: agreed, don’t show your user a big stack trace with all of your internal debugging info. They generally won’t get anything from that info, and it could be exploited. I generally have two error displays (talking webapps for the moment), one for development/testing (which shows all error info plus dumps the current request, session, cookies, etc. to the screen), and another for production (which just says there was an internal error that has been reported automatically, they can try again or contact technical support if it keeps happening).

@Tracy: I agree you shouldn’t have to think about exceptions in most of the code — generally they’d indicate a coding error, and should just halt execution, because something has failed. Put in “try-finally” blocks to make sure resources get cleaned up where needed and otherwise let exceptions bubble up. But what do you mean you wrap them at higher levels? Won’t they just reach the top and get trapped/logged/handled?

I vary in how I handle IO and database connection issues… IO in a client application probably should be checked, because actions that use IO will quite probably fail occasionally (the network is down, the file is locked by another process, etc.) and need to be handled better than just a generic error. On the server… I go back and forth. At the moment my webapps mostly have checked exceptions for database access, because they *do* get caught and wrapped (with all details of the query included) and to remind developers that resources must be cleaned up as part of error handling. That wrapper that’s rethrown could logically be unchecked, though.

@Riyad: No special libraries; I do have a set of standard error handling code & approaches that I reuse from project to project, but it’s hard to encapsulate that kind of thing into a separate utility. I used to have custom wrapper exceptions, until the JDK added that feature.

@Michael/Dimitris,
That is *exactly* what I was looking for and curious about. My gut told me that working with checked exceptions (atleast when I did it) drove me nuts, try-catching even the smallest operation was really slowing me down, because then you run into the situation where you need to decide how granular you want your try-catch and detailed handling to be and that can turn into an art-form or a nightmare just in and of itself.

@Litty/Tracy/Parth,
An even higher level take that I wasn’t considering but can be just as important: what to do with the exceptions. I appreciate you weighing in.

Now I suppose a followup question would be:

Does anyone have any favorite exception handling/logging libraries out there that fit their work flow like a glove?

I like to throw exceptions at the lower level and will track it in my calling code (using some DB status etc…which can be used to notify users etc.. ).Main thing is,we should log it so properly(in log and DB both if possible) that the developer/System Admin can track down the error easily while digging into the huge log file :).Because i had been through this situation a lot more times, i know how important to track exceptions if you want to keep you app. running up.

I mostly use checked exceptions,and mostly use diff. statuses for my business logic processes which can give me a proper indication.

regards,
http://www.techlads.com

The theory is that exceptions, under normal circumstances, should not happen. If they do happen though, it should be justifiable to halt the execution flow. A good API should offer all its functionality without requiring a single try / catch around it.