Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Comment Re:Nooooooooo (Score 2) 144

Your suggested fix to disable bounce messages with the side affect that the sender then has no way to know that the mail never arrived? Not going to happen. If I ever did something that stupid, my clients would drop me.

In the meantime I've switched to Postfix which manages to do things correctly by refusing the message in the initial connection if the user doesn't exist so the sending mail server gets to generate the bounce message instead. And yes I know there are now patches and Qmail forks that cause Qmail to do things correctly but there really weren't at the time and my point remains that DJB never cared that his software could be misused this way.

Comment Re:Nooooooooo (Score 1) 144

It "worked" only as long as you don't care about the problems DJB had no interest in solving. It is true that you can't use Qmail to break into the host system, but unfortunately you can use it as a reflector and annoy the crap out of pretty much everyone else.

I was a Qmail fan and installed it everywhere I worked right up until the day several of my servers got blacklisted.

Comment Re:Helping the poor (Score 1) 320

You're wrong.

Once they're comfortable in their current state they can work on improving it. You can't focus on learning new skills or searching for a job if you have to find a blanket for tonight or you'll freeze to death. Almost everyone isn't going to hire a homeless bum, so they need enough stuff to make themselves not look homeless. They get those things as handouts on the street, from picking through the trash, or from robbing people.

The problem is that when we give them money for begging, they go use that money for a little bit of food and a whole lot of whatever it is they are self medicating with. Change is uncomfortable and doubly so for someone who is a substance abuser. There are charities who help people who want to get off the street and your money is much better spent there since they can help more effectively by providing food, clean clothing, a place to stay and help for whatever emotional problems or mental illness that made them end up on the streets to begin with.

Comment Re:Linux kernel (Score 2) 373

1 Handles errors gracefully.

This statement always hits me as mind numbingly stupid. In general try / catch and other error managing statements are for the lazy that don't want to understand the environment and inputs well enough to write the proper code to manage them. You want rock solid code that will last for years, eliminate the errors, don't "handle them gracefully". The only exception to this rule should be when the native environment forces it upon you or there is a lack of some proper check "doesThisReallyExist()".

By errors I meant where paths and files don't exist, the user or external software sends bad info or someone runs or the machine runs out of resources. Case in point: someone edited one of our databases in a place I used to work and some software crashed hard when it grabbed a NULL value from the database leaving me to check the core dump to discover the problem.

2. Only reinvents the wheel when there is a measurable benefit in doing so..

I learn more reinventing the wheel and there is no substitute to working with code you are sure of and know how it's going to perform.

I agree with the rest.

I can see wanting to learn.. I can't see duplicating system libraries in a project. Some libraries (Libc in particular) have whole groups of programmers who are rather good at squeezing every last drop of speed out of the implementation, there are also things such as leap year handling that look simple but end up being harder than they look.

Comment Re:Linux kernel (Score 1) 373

Library bugs would equate to a "measurable benefit" to reinventing the wheel. I am not saying you should never replace a library function only that it shouldn't be your first reflex. I would only suggest that you document why you created your alternative routine in your code somewhere so someone (or possibly you years down the road) can easily spot why it was used instead of the existing library function so there is not time wasted later rediscovering the bug.

Comment Re:Linux kernel (Score 5, Insightful) 373

I strongly disagree with this. While I admit that elegant code can have ugly portions refactoring will often be an improvement but the trick is to learn when refactoring will help and when it will be a waste of time. The worst programmers I know are the ones who say that "I don't have time to go back through my code". I have cleaned projects where the original coder did the same thing three different times or reinvented the wheel when there were better libraries. In fact, I have been also guilty of this and even in my own projects I have come across places where the requirements changed out from under me mid project or I simply see better ways of doing things as I gain experience.

Elegant code:
1 Handles errors gracefully
2. Only reinvents the wheel when there is a measurable benefit in doing so.
3. Has consistent naming conventions.
4. Has comments around ugly code explaining why it is ugly.
5. Compiles (or runs if interpreted) without warnings.

Comment Re:Time = Money (Score 2) 101

Groupe Telecom used to be like that since they considered themselves too big to fail (or rather too big to be taken down). I had a decent job until the final months of the job where my boss (Leo Kuvayev before his infamous spammer days) decided to team up with Alan Ralsky and Spam the crap out of some porn sites. Before they started they were assured by their account manager that all complaints would be ignored. After trying to talk them out of it I quit and moved on to another job.

A few months later I ran into my replacement in an elevator while he was searching for new hosting. It seems Group "Were a billion dollar company" Telecom were forced to change their policy thanks to multiple blacklists that did a lot of damage to their business.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...