Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Similar effect on Slashdot (Score 1) 37

by tool462 (#46268123) Attached to: Facebook Analyzes the Impact of Love On Their Business

If you run out the time axis long enough, you'll see it more reflects a bathtub curve than 1/x. I.e., in a long enough relationship, there will inevitably be a dramatic rise in posting frequency. Usually this is an indicator of a pending failure. When you see the onset of this increase, it's best to implement some redundancy. It may accelerate the failure of the first component, but ensures no disruption in service.

Comment: Easy (Score 4, Funny) 514

by tool462 (#45902601) Attached to: Weapons Systems That Kill According To Algorithms Are Coming. What To Do?

Wear a tshirt with a message written in a carefully formatted font so it causes a buffer overflow, giving your tshirt root privileges.
Mine would have the decss code on it, so the drone starts shooting pirated DVDs at everybody. The RIAA will make short work of the problem at that point.

Comment: Communication is easy (Score 1) 361

by tool462 (#45403615) Attached to: Ask Slashdot: Communication Skills For Programmers?

Most engineers follow UDP protocol. Spewing a bunch of packets into the ether. In light traffic, this isn't a big problem. Plenty of bandwidth and sufficiently capable endpoints that they can reconstruct missing packets, or at least identify when they're missing something. However as traffic increases, packet loss can reach intolerable levels and communication breaks down entirely. If the engineer doesn't adjust to the network load, they can have an adverse effect on the entire network performance. In extreme cases the network admin (your boss) may need to remove the offending device from the network altogether.

They'd be better served to use TCP. Establish a connection. Send information in well defined packets. Confirm receipt. Re-transmit if necessary. Yes, it's slower and more overhead, but reliable information transfer is a must in a robust and useful network.

Oh, and always ACK with a smile :)

There are new messages.

Working...