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


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment nuclear accelerator (Score 3, Interesting) 351

So how about a nuclear accelerator ring as a propulsion device. Instead of the two proton beams colliding, they would be projected from each edge of the accelerator ring. The ring should be lighter than an earth based one because a vacuum is already present. A nuclear power plant would be required to power the ring, and a tank of hydrogen would be required as a proton source (Unless hydrogen or protons can be harvested from the solar wind).

The perfect engine would generate 1G of acceleration over a multiple year period.

With this engine, a trip to Mars should be a rather shorter endeavour.

Anybody have any idea what it would take to build such a thing, Or how fast such a thing could get to Mars at it's closest approach assuming 1G of acceleration?

Comment Re:1G engine (Score 1) 662


Why the 19 years at 0 G? I know that is the speed of light, but if you are are going nearly that fast, and you measure the speed of light, in any direction, it would still be 299792458 m/s which means you can still accelerate at 1g and never reach that speed.

Then of course, we would have to have two times. One time for the astronauts on the spaceship, and another as observed from earth.

Any ideas on what those times would be?

Comment 1G engine (Score 1) 662

Ok, if we had an engine that could produce 1G of accelleration over a large number of years.

Does anybody how long would it take to get there?

Half the trip would be accelerating, and the other half decelerating. (Actually it's accelerating the whole time, just in the opposite direction at some point.

1G of acceleration should solve the muscles atrophying problem as well.

Comment Re: Make Only the spammers pay. (Score 1) 198

Maybe a little more description is in order
Any email that is not digitaly signed with postage would be blocked automaticaly for the users that use that choose to use the sevice. So the mail from spammers would never get through.
For a spammer to send send e-mail, they would have to use an API to contact the signing server, passing the credentials for an account to transfer postage from, as well as the sha sum of the email to be signed, plus a recipient list. A signiture would be returned from the signing sever that would be attached to the end of the mail before using standard methods to send.
Each send then costs the spammer ( or some poor sap who used week credentials on there account) or its blocked by the recipents client.

Comment Make Only the spammers pay. (Score 1) 198

How about this take on e-mail postage. We know spammers/phishers send lots of e-mail, but receive very little or none. We use that to our advantage

Before sending e-mail, a sender buys postage, and it goes into their account. Maybe a penny a stamp give or take. When an e-mail is send, a stamp is taken out of the sender account and put into an escrow for each recipient. The e-mail is digitally signed for the escrow id, and sent like normal, but all spam filtering services then check the signature along the way.

When a recipient opens an e-mail, The escrow stamp set assigned for them is transfered to their account (e-mail client, or service provides this). Note: it can only be collected once for each person per e-mail, and it only goes to the account associated with the e-mail.

So after an initial stamp purchase, postage will transfer back and forth, and a normal user should never have to purchase postage again. A person, or company that sends lots of e-mail will have to keep buying postage to send. PHishing and spamming becomes economically difficult.

More reputable spammers/companies will have to buy postage to stay in business.

One last thing, users will be able to sell back stamps when there account starts to fill up, but at less of a price, to pay for the service and keep the validation servers running. So stamps are purchased at retail prices, and sold back at whole sale prices. Spammers/Hammers that stay in business end up paying for the service.

There is much more details, and ideas that can go along with this, but for the sake of brevity, I'll keep int at that.

Comment UID's (Score 4, Interesting) 569

One of the annoying things about User ID's is that most Distros user utilities start at some number and count up. Then when you use nfs or removable media you find that the files are now owned by another user.

It would be nice if the default was to pick a random arbitrary and large UID so the chance of UID clashes would be remote.

Comment Re:Just Say No to Native Form Widgets. (Score 1) 375

I'm a Linux and OS X user, and having to look at those ugly widgets that are very out of place is very irritating. The only reason I don't switch to Camino on OS X or Konqueor on Linux (I'm a GNOME user, btw) is due to extensions. It's also quite annoying having Firefox be the only application that doesn't follow your icon theme. Those default icons look very out of place.

True that it is annoying that it Firefox Doesn't follow the theme. And I'm not saying the the widgets shouldn't look like the ones for the OS.

What I'm saying is Firefox should stick to one graphic toolkit on every platform. Right now that is GTK+

Native widgets are a good thing.

If that is true than Firefox should us QT widgets when I'm in KDE, and EFL when I'm in Enlightenment and Motif when I'm on Aix, and Whatever sun uses in the Openwin Evironment. And then on Windows the select box can float above all other widgets no matter what zlayer it is on just like IE.

And then new releases can take longer as they try to work the bugs out of all supported toolkits.

And then we can test our web applications agains't all versions in case the different widgets don't function the same.

Sound like a lot of fun!

Operating Systems

Journal Journal: Musings about Linux #1

Musing about Linux.
These are just Ideas that I think would be cool if implimented. They are ideas for Linux, but probably would apply to any Unix like OS. I didn't spend a huge amount of time considering all the ramifications. They are just Ideas, and not always complete idea's at that. I would like to try and impliment some of these in the future, but don't have the time or the skill right now. So it might never happen.

Slashdot Top Deals

Surprise due today. Also the rent.