Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Comment Re:Hardening (Score 1) 261

Look, c has "real strings." They're trivially easy to deal with; if such management is actually beyond a programmer's skills, they're working in the wrong field. Starting with the basic 0-terminated model, you can create any kind of string management / data structure you want. That's the beauty of c. You can do anything you think you need to.

If only we could clone you millions of times, we wouldn't have buffer overflow vulernabilities, but I doubt people would be able to stand so many elitist pricks.

Comment Re:Hardening (Score 1) 261

Look, c has "real strings." They're trivially easy to deal with; if such management is actually beyond a programmer's skills, they're working in the wrong field. Starting with the basic 0-terminated model, you can create any kind of string management / data structure you want. That's the beauty of c. You can do anything you think you need to.

malloc() is a crutch. If you can't write your own allocator, you don't deserve to call yourself a programmer.

Comment Re:By the looks of that vehicle.... (Score 1) 232

The Heemeyer Bulldozer had a very different purpose, which was to allow Heemeyer to continue destroying buildings while the police tried to stop him. Neither offensive firepower nor maneuverability was a priority, but protection was. This vehicle is probably meant to protect those inside while it's going somewhere, implying a need for more maneuverability at the cost of protection. It is also apparently intended to be used against enemy soldiers. It's clearly far from an ideal design, but even an ideal one likely wouldn't be as well-protected as the Heemeyer Bulldozer.

Comment Re:Not a tank (Score 1) 232

That is not a tank. That's an armored car.

A tank requires three things: heavy armor, a turret-mounted gun capable of anti-tank combat, and the use of tracks instead of wheels.

This arguably fails all three. It's a wheeled vehicle, and that 7.62mm gun may as well be paintballs to other tanks - it's a common caliber for the coax gun on modern tanks, for use when you don't want to waste your expensive ammo against mere infantry. The armor is definitely insufficient to handle modern tanks, but it would have been enough for 20's and '30s tanks (or perhaps WW2-era Italian or Japanese tanks), so you could probably squeeze it in.

That said, as long as the rebels use it intelligently, an armored car is a very useful tool. Keep it in the cities, where tanks have difficulty maneuvering, but use its mobility to outflank infantry. It will be interesting to see how long it lasts - it doesn't look like it could handle modern anti-tank missiles, but it *might* stand up to an RPG-7 or so.

It's certainly true that this does not come close to the commonly accepted definition of "tank" since the 1930s. However, it's interesting to note that the term evolved quite a bit from its first use. The original tanks in WWI did have tracks, but they did not have turrets, anti-tank guns or thick armor. There were designed to protect the crew from enemy machine gun and artillery fire, which is probably all this vehicle is intended for. The RPG-7 can penetrate at least 260mm of steel, more than ten times the thickness on this vehicle.

Comment Re:Your driving I'm watching. (Score 1) 232

So I did some more looking and it really is a death trap. The wheels are still exposed, and the steel is at most 1/4 to 1/2 inch thick, which would easy be penetrated by an AK-47 or an Nato 556 round. It is really just a death trap.

You may be right about it being a death trap, but TFA says it has 25mm armor (about one inch). That would certainly not be easily penetrated by most small arms.

Comment Re:Rich Stevens' approach (Score 1) 536

W. RIchard Stevens had a pretty good approach to error-handling in "Advanced Programming in the UNIX Environment". In most cases, he wrapped system calls or library calls in wrappers that would test for errors and abort with an error message on failure. These wrappers meant that the main program could forget about error-checking.

In the relatively rare cases in which the main program felt it could recover from an error, it would call the system call directly and handle the error itself. This led to pretty clean but still very safe code.

Naturally, this approach is inappropriate for authors of library code, but it's great for the main body of an application.

That just sounds like a crippled version of the exception system in many modern languages. It'll throw exceptions but offers no way to catch them.

Comment Re:Problem with Exceptions (Score 1) 536

The biggest problem with exceptions is that they get thrown too far, changing them into comefroms (the opposite of a goto). And like gotos, they encourage spaghetti code. The best way to deal with them is to limit them to thrown exceptions only to their callers. That way, all exceptions become part of the subroutine's interface. Remember, for a programmer, out of sight is out of mind. If it's not part of the interface, it will be forgotten. For those who are interested, you can read my blog for details and an example.

Yeah, writing five exception handlers, each just throwing the exception again is so much better than handling it once.

Comment Re:There is no such thing as an error. (Score 1) 536

It doesn't matter whether we use exceptions or error codes to signal the errors as long as the program is designed to accurately interpret the errors that do occur. In some sense, exceptions may be easier to implement in today's event-driven interactive interfaces. Regardless, though, the design must not allow errors to be lost.

Good luck anticipating every error condition possible during your program's run time.

Comment Re:Why do we need a desktop client? (Score 1) 464

Personally I've had terrible luck with IMAP.

Ultimately while I'm not usually a fan of web apps in general, they are a perfect solution for email (which is probably why webmail is so popular).

What exactly have you had terrible luck with? What IMAP servers or services have you used? I use Thunderbird to access my mail both on the company's IMAP server (running Dovecot) as well as Gmail all the time. Since I discovered IMAP in the late 90's, I never looked back. Of course, there have been buggy servers and clients, but I've had far more success than failure.

Comment Re:Resistance is Futile. You Will be Assimilated. (Score 1) 464

So far the state of standalone clients compared to webmail is pretty dismal. I'm using Thunderbird now but I really miss a search function that works, as well as an addressbook that doesn't have arbitrary limitations such as a maximum of two email addresses per contact.

Thunderbird's search certainly works, but it's not as good as Gmail's. Its conversations are also useful but not as nice as Gmail's. Those are the areas it could really stand to improve.

Comment Re:Why do we need a desktop client? (Score 1) 464

I really haven't used a desktop client for email in years. Where's the gain for the user?

I want my mail and calendar wherever I am. So why keep multiple copies of gigabytes of mail on multiple machines. I just don't see the gain for the average user. I think the lack of demand from users who are moving to webmail is why the Thunderbird is getting less developer attention.

What I'd really like to see is improvement in the webmail interfaces available to us. Gmail is fast, but I find the interface limiting and clunky. The best I have experienced was Zimbra, but it really prefers to be run on a standalone machine and is pretty resource intensive.

Perhaps you're not aware of a little thing called IMAP. You may be able to run your own web mail server, but that's not realistic for the vast majority of users. For some people, Gmail or another hosted web mail system is good enough. For everybody else, email clients are still important.

Slashdot Top Deals

Kleeneness is next to Godelness.

Working...