to make a truck-sized nuke. The one dropped on hiroshima was a gun type. Basically take a big piece of uranium and cut a wedge in it. Then take a matching wedge piece and mount it in a tube in front of high explosives. Detonate. When the two meet, assuming their combined mass is of the critical type, you have yourself a hiroshima sized explosion.
The hard part is of course, getting the enriched uranium necessary. You'd need a bit of specialized know-how in safely machining it as well, and of course, the proper amount you'd need to achieve critical mass. The last couple bits any nuclear physics student could tell you.
not to mention decent service. Local shops with hipsters wearing ironic t-shirts behind the counter tend to sneer, whereas the starbucks folks actually know my name, my brew, and give me free drinks now and then.
And I dont go in everyday. Only once or twice a week.
I have a cd changer in my car that uses the radio tuner at 89.1 to play. So today I switched to that, but instead of the usual static I heard actual music coming out of it - and not the fare you'd hear on the radio usually. Took me awhile to figure out where it came from, I figured someone had some kind of miniature broadcaster somewhere, and now I think I know where:)
The problem with web apps tends to be security design problems, as opposed to security by technical (ie buffer overflows).
For example, not checking for validity of POST data being sent. I can think of several holes I'd found on some webstore software that would allow a user to enter just about any price they wanted for products, because the store software didn't have a sanity check on incoming price fields.
You're pretty wrong on both counts. Maybe you're thinking of "obvious" applets. ActiveX applets and scripting are everywhere - try setting IE to "prompt" on them and many, many websites will generate the annoying "Do you want to run this?" boxes.
Same goes for java applets. They're usually small and well embedded in a page's content so you don't notice them loading.
Rarely will you see either in a page as a "must have" for functionality as activeX is becoming a dirty word, and since MS stopped shipping IE with java.
robotics and classical AI, while related, have diverged alot in the past 20 years. The future of practical AI will probably be found in robotics.
Classical AI has made little progress at all. Cyc is really a formal machine that is the epitome of classical AI, and all its bizarre limitations - and it doesn't do hardly anything. Autonomous robotics on the other has made leaps and bounds. If you think things like the QRIO and Asimo are impressive, wait till you see their platforms are merged with the latest navigation and communication abilities currently found in labs. Part of the point of the robocup is to show off the latest in teamwork abilities.
2050 is a reasonable estimate and a decent goal. You don't need a robot that will debate the meaning of life and philosophy with you to play good soccer. I somehow doubt many of those soccer players could do that very well, either:)
Consider how it wasn't all that long ago that assertions were being continously made that machines could never beat a human at chess...
And since fuel cells last 2-10 times longer than batteries... the future is bright indeed for them.
The only catch i see is the difficulty in recharging on the road. I mean, I can take my rechargable battery charger and plug it into any electrical outlet and keep batteries fresh. One would need to either a. Find a place that sells recharges or b. Carry some kind of portable recharger that holds a few ounces of methanol in it but has yet to be invented...
I can see bulk refills being sold in places like grocery stores or walmart. Eventually a refill adapter will be standardized, and I imagine you'll be able to purchase a refill machine. Attach a quart container of methanol to it, and with several refill plugs place your fuel cells of varying standard sizes on it.
Of course thats probably a few years away, but it seems like a fairy easy way to recharge them.
this flight was not part of the x-prize flights. It didnt have enough passengers or weight.
More of a 'proof of concept' flight. There was also talk of the rocket engine cutting off early that may be related to the buckling, though it still made it into official space.
Obviously the concept is proved, now to work the bugs out (like the buckling) and do the official x-prize flights.
True that. Google already stores their entire cache and index in RAM, I'm sure the same is true for gmail. Every user's email message being stored in ram makes for fast access.
I disagree. Imagine if you gave every person on the planet a gmail address. Thats only 6 billion * 1000 = 6 trillion. You can build a 6 terabyte array for a few thousand dollars.
Considering that google stores their *entire* webcache in *RAM* across 90-100,000 machines, 6 terabytes is nothing. I bet they store every gmail user's email in RAM as well.
I didn't mean to insult you, but I do have to point out that most of the people I see bitching about threads are usually older programmers used to the 1:1 input/output paradigm of yore.
I too have a CS degree and work in research. Nowadays, threading is commonplace and is taught much better than 10 years ago. More than just semaphores and monitors, proper overall design is (or at least should be) taught as well. Java's excellent thread implementation have helped in this respect.
Deadlocking isn't an issue if you design it right. Theres no good reason an app will deadlock.01% of the time if you know how to use your threading tools properly, and how to implement the threads.
The problem with putting everything in central loops is the OS is going to switch the process out in the middle of those extremely long loops. With threads, in many cases another thread will get the CPU time (assuming your OS is handling thread scheduling). This increases responsiveness of the program and potentially actual program speed.
And its a much more elegant way of doing things than giant monolithic distributor functions. What do you do when one part of the function needs to wait on another task to complete? I can only imagine the horrors of trying to deal with that in a consistant, bug free manner. At least with threading all you need to do is call your wait() and notify().
Simple, clean, and tight. There's no reason in the 21st century to still be using 1970s styled monolithic functions.
Don't fear the thread. Its your greatest ally in modern programming. Yes it can be hairy if you're not well versed in the design methodolgies behind it. But in the end, it is much cleaner and more reliable than what you've described to me.
All I know avoid threads like the plague, since it introduce a lot of synchronization problems and makes debugging very difficult since the program will in effect behave non-deterministic.
Maybe if you have no idea what you're doing or how to use threads properly... I will admit, one does need adequate training to use them correctly. Once you have this though, all other methods are downright ugly and much more bugridden.
It's true that a GUI application which will need to do some long calculations (like ray-trace an image, compile a source, translate a LaTeX document etc.) will often spawn a thread to do this, but a) how many modern GUI apps work like this? b) the main thread (running the GUI) will have close to no load and c) it spawns only one thread, so the task will not complete in shorter time.
In a modern GUI app, at the very least, input and display will be running in separate threads. That is, while its waiting for you to click on a button, and anything that causes a display change. If you add different ways of input (such as network), that will also run in its own thread.
Even an application like a browser could very well be single threaded and use select() to wait for socket activity, and then dispatch new data to the proper page-parser, image-decoder or similar, since the network is unlikely to provide data so fast that the cpu will get a 100% load.
The problem of the network not supplying data fast enough is exactly why threading is needed. Would you want your browser to be completely non-responsive (even in such tasks as displaying a menu or manipulating configuration options) while you wait for a page to download and display?
i'd say most people that post on slashdot know very little about the true nuts and bolts about languages and computers in general. No, writing a shell script does not mean you know a lot.
Sort of sad, considering the audience it tries to appeal to.
These kind of articles are trollish. Java is faster for some applications than C++, and for others C++ is faster. It depends on what you want to do with it.
I think java continues to improve its performance and feature set though, with every new version that comes out every couple of years. C++ is more or less into its mature, sunsetting years and not likely to have any revolutionary, or even major evolutionary, improvements.
im pretty sure UT is larger than.5 square miles:) From north to south it stretches from 19th to 27th street, and east to west is a bit wider than that.
a friend and i were driving among the streets of austin (not just downtown or near UT, but in and around other places) and it is possible to simply jump from hotspot to hotspot while waiting for the light at an intersection or while driving around.
They're everywhere. Virtually every decent pub, restaurant and coffee shop here has free wireless.
I wouldnt say the 68K's fell by the wayside...they were much, much more popular in embedded devices.
I think it could probably be argued that more 68K's were produced and sold than intel processors, just because of the sheer number of devices that used (and still use) them.
Slashdot Mirror
they are based in a country (the UK/EU) that actually UPHOLD it's competition laws
What, like DeBeers? If thats not a monopoly I don't know what is.
DeBeers can't operate offices in the US, as the justice dept has long been looking for a reason to tackle them.
to make a truck-sized nuke. The one dropped on hiroshima was a gun type. Basically take a big piece of uranium and cut a wedge in it. Then take a matching wedge piece and mount it in a tube in front of high explosives. Detonate. When the two meet, assuming their combined mass is of the critical type, you have yourself a hiroshima sized explosion.
The hard part is of course, getting the enriched uranium necessary. You'd need a bit of specialized know-how in safely machining it as well, and of course, the proper amount you'd need to achieve critical mass. The last couple bits any nuclear physics student could tell you.
the motherboard doesnt determine how much power you draw. Obviously, what components you have does.
Especially things with motors. Harddrives, CD, DVDs. After the processor and video card, they're your largest draw.
not to mention decent service. Local shops with hipsters wearing ironic t-shirts behind the counter tend to sneer, whereas the starbucks folks actually know my name, my brew, and give me free drinks now and then.
And I dont go in everyday. Only once or twice a week.
Probably for the same reason all the oxygen on earth hasn't.
I have a cd changer in my car that uses the radio tuner at 89.1 to play. So today I switched to that, but instead of the usual static I heard actual music coming out of it - and not the fare you'd hear on the radio usually. Took me awhile to figure out where it came from, I figured someone had some kind of miniature broadcaster somewhere, and now I think I know where :)
The problem with web apps tends to be security design problems, as opposed to security by technical (ie buffer overflows).
For example, not checking for validity of POST data being sent. I can think of several holes I'd found on some webstore software that would allow a user to enter just about any price they wanted for products, because the store software didn't have a sanity check on incoming price fields.
You're pretty wrong on both counts. Maybe you're thinking of "obvious" applets. ActiveX applets and scripting are everywhere - try setting IE to "prompt" on them and many, many websites will generate the annoying "Do you want to run this?" boxes.
Same goes for java applets. They're usually small and well embedded in a page's content so you don't notice them loading.
Rarely will you see either in a page as a "must have" for functionality as activeX is becoming a dirty word, and since MS stopped shipping IE with java.
robotics and classical AI, while related, have diverged alot in the past 20 years. The future of practical AI will probably be found in robotics.
:)
Classical AI has made little progress at all. Cyc is really a formal machine that is the epitome of classical AI, and all its bizarre limitations - and it doesn't do hardly anything. Autonomous robotics on the other has made leaps and bounds. If you think things like the QRIO and Asimo are impressive, wait till you see their platforms are merged with the latest navigation and communication abilities currently found in labs. Part of the point of the robocup is to show off the latest in teamwork abilities.
2050 is a reasonable estimate and a decent goal. You don't need a robot that will debate the meaning of life and philosophy with you to play good soccer. I somehow doubt many of those soccer players could do that very well, either
Consider how it wasn't all that long ago that assertions were being continously made that machines could never beat a human at chess...
My current record is 8 minutes they waited for me to return.
currently it runs about 81 cents / gallon.
And since fuel cells last 2-10 times longer than batteries... the future is bright indeed for them.
The only catch i see is the difficulty in recharging on the road. I mean, I can take my rechargable battery charger and plug it into any electrical outlet and keep batteries fresh. One would need to either a. Find a place that sells recharges or b. Carry some kind of portable recharger that holds a few ounces of methanol in it but has yet to be invented...
I can see bulk refills being sold in places like grocery stores or walmart. Eventually a refill adapter will be standardized, and I imagine you'll be able to purchase a refill machine. Attach a quart container of methanol to it, and with several refill plugs place your fuel cells of varying standard sizes on it.
Of course thats probably a few years away, but it seems like a fairy easy way to recharge them.
well SS1 did exit earth's atmosphere, but to exit earth's atmosphere and not fall back down somewhere, you're correct.
and then if you want to exit orbit, you need even more speed. Hence the massive moon rockets.
this flight was not part of the x-prize flights. It didnt have enough passengers or weight.
More of a 'proof of concept' flight. There was also talk of the rocket engine cutting off early that may be related to the buckling, though it still made it into official space.
Obviously the concept is proved, now to work the bugs out (like the buckling) and do the official x-prize flights.
True that. Google already stores their entire cache and index in RAM, I'm sure the same is true for gmail. Every user's email message being stored in ram makes for fast access.
I disagree. Imagine if you gave every person on the planet a gmail address. Thats only 6 billion * 1000 = 6 trillion. You can build a 6 terabyte array for a few thousand dollars.
Considering that google stores their *entire* webcache in *RAM* across 90-100,000 machines, 6 terabytes is nothing. I bet they store every gmail user's email in RAM as well.
actually a couple of weeks ago, half of ion storm austin was laid off.
I didn't mean to insult you, but I do have to point out that most of the people I see bitching about threads are usually older programmers used to the 1:1 input/output paradigm of yore.
.01% of the time if you know how to use your threading tools properly, and how to implement the threads.
I too have a CS degree and work in research. Nowadays, threading is commonplace and is taught much better than 10 years ago. More than just semaphores and monitors, proper overall design is (or at least should be) taught as well. Java's excellent thread implementation have helped in this respect.
Deadlocking isn't an issue if you design it right. Theres no good reason an app will deadlock
The problem with putting everything in central loops is the OS is going to switch the process out in the middle of those extremely long loops. With threads, in many cases another thread will get the CPU time (assuming your OS is handling thread scheduling). This increases responsiveness of the program and potentially actual program speed.
And its a much more elegant way of doing things than giant monolithic distributor functions. What do you do when one part of the function needs to wait on another task to complete? I can only imagine the horrors of trying to deal with that in a consistant, bug free manner. At least with threading all you need to do is call your wait() and notify().
Simple, clean, and tight. There's no reason in the 21st century to still be using 1970s styled monolithic functions.
Don't fear the thread. Its your greatest ally in modern programming. Yes it can be hairy if you're not well versed in the design methodolgies behind it. But in the end, it is much cleaner and more reliable than what you've described to me.
All I know avoid threads like the plague, since it introduce a lot of synchronization problems and makes debugging very difficult since the program will in effect behave non-deterministic.
Maybe if you have no idea what you're doing or how to use threads properly... I will admit, one does need adequate training to use them correctly. Once you have this though, all other methods are downright ugly and much more bugridden.
It's true that a GUI application which will need to do some long calculations (like ray-trace an image, compile a source, translate a LaTeX document etc.) will often spawn a thread to do this, but a) how many modern GUI apps work like this? b) the main thread (running the GUI) will have close to no load and c) it spawns only one thread, so the task will not complete in shorter time.
In a modern GUI app, at the very least, input and display will be running in separate threads. That is, while its waiting for you to click on a button, and anything that causes a display change.
If you add different ways of input (such as network), that will also run in its own thread.
Even an application like a browser could very well be single threaded and use select() to wait for socket activity, and then dispatch new data to the proper page-parser, image-decoder or similar, since the network is unlikely to provide data so fast that the cpu will get a 100% load.
The problem of the network not supplying data fast enough is exactly why threading is needed. Would you want your browser to be completely non-responsive (even in such tasks as displaying a menu or manipulating configuration options) while you wait for a page to download and display?
i'd say most people that post on slashdot know very little about the true nuts and bolts about languages and computers in general. No, writing a shell script does not mean you know a lot.
Sort of sad, considering the audience it tries to appeal to.
These kind of articles are trollish. Java is faster for some applications than C++, and for others C++ is faster. It depends on what you want to do with it.
I think java continues to improve its performance and feature set though, with every new version that comes out every couple of years. C++ is more or less into its mature, sunsetting years and not likely to have any revolutionary, or even major evolutionary, improvements.
heh, when my cell phone rings, or when im talking on it too close my computer speakers, they make a very loud buzzing sound.
Then again, when I bring my cordless landline phone near my PC the static makes it unbearable to use.
Anything multithreaded. Which is just about any modern GUI app.
im pretty sure UT is larger than .5 square miles :) From north to south it stretches from 19th to 27th street, and east to west is a bit wider than that.
a friend and i were driving among the streets of austin (not just downtown or near UT, but in and around other places) and it is possible to simply jump from hotspot to hotspot while waiting for the light at an intersection or while driving around.
They're everywhere. Virtually every decent pub, restaurant and coffee shop here has free wireless.
I wouldnt say the 68K's fell by the wayside...they were much, much more popular in embedded devices.
I think it could probably be argued that more 68K's were produced and sold than intel processors, just because of the sheer number of devices that used (and still use) them.