You are pretty out of touch to compare relgious fundamentalism in the US with islamic fundamentalism...When was the last time someone had their throat slit for Jesus?
It was just a few years ago that abortion clinics and doctors were being firebombed and shot in order to protect the sanctity of human life.
Singletons in the J2EE framework. Compare this monstrosity [theserverside.com] with a sigleton implementation in any sane language, including the simple, non-J2EE Java. Mind you, I'm not bashing J2EE here , the singleton issue is the price you pay for scalability.
I think you misunderstand what the singleton is trying to do. The J2EE singleton is trying to make sure only a single instance is running even if a cluster of machines is running the application logic. This means that the singleton needs to instantiate once in the cluster which is slightly different and more difficult then making sure your singleton only instantiates once in your application instance.
I'm not sure why this concept never caught on but I wish some designer would start making such watches again. Maybe it died when clocks started showing up on dashboards...but i still want one anyway!
You can get Timex OVA and maybe Nike watches with a similar design. However, they are digital watches designed for runners and other athletes needing to time their workouts. They probably wouldn't work in a formal setting.
I figure with a large UPS and some sort of redundant power-supply, you could feed a number of computers with 12V lines and a picoPSU-120 12V DC-DC ATX power supply. Has anyone tried this yet? I've never worked with high-density hardware (like blades) but I'd imagine that each blade is certainly not using its own PSU.
Check out the specs on telco equipment. A lot of them run on 48 vdc with special 48vdc power supplies. You can get a lot of networking gear that come with 48vdc power supplies. I think there are probably computers that have the same ability.
Of course this is all pretty expensive since it's intended for telco companies.
What is to say that we don't have a lot of very tiny explosions all the time? Cosmic/background radiation, anyone?
The direction that cosmic radiation comes from can be identified. If election -> positron conversions happened, we would be seeing 1 MeV xray/gamma radiation coming from everywhere. People aren't dying of radiation sickness in large numbers, therefore rotating an electron 360 degrees doesn't result in its conversion to a positron.
An electron has 720' rotational symmetry (see: Brief History of Time) so if they spin it too far, it'll become a positron. Since they've no way of detecting the rotation of an electron (it's a point charge) other than seeing if it explodes when it strikes another electron, this could definitely be an interesting - if short-lived - storage mechanism.
If this happened, you'd see random explosions all the time. Electron - positron conversion hasn't been detected yet so a simple rotation is definitely not going to be converting electrons to positrons. Hell, if it did we'd have antimatter bombs floating around all over the place.
The Red Cross emblem is one of the easiest ones to program. Hence it wide use. It is also why the Nazi symbol is used alot too. Not because of its meaning but because of how easy it is to program. Like using the Snake on the Pike is pretty tough to program, but a Red Cross. Thats easy.
I don't think anyone's really programmatically created the red cross emblem in any recent game. It's just another texture in the game and can get switched out for the caduceus without too many problems. Maybe 10 years ago games were generating based on code but it's been all textures for a very long time.
Why "outsource" when you can decompile Jad, change a few variable names and viola! Project Complete.
I've used Jad to decompile source code and produce a compilable code base. It's not that easy and frankly it's easier to just rewrite the code for simple applications. Jad produced code with all the variable, class, and method names going in alphabetic order (e.g. method A, method B,..., method Z, method Aa, etc.). Add in the places where it got confused and dumped vm opcodes and it's easier to rewrite the code from scratch for small programs.
Pakistan does not have near enough resources to compete with India, and China really is pretty indifferent to India. China is focussing on economic development and economic expansion, politacally speaking; though they are building their military, that is more in response to the US.
Pakistan may not have enough resources but enough nukes and they have a credible deterrent. True they may not be able to go offensive in a war but they can encourage action in Kashmir & Jammu which is the point of contention right now.
The Chinese and Indians have fought a border war in 1962-1963 and the border regions are still contested. There have been talks but no resolution. Things have been quiet but without a resolution, the dispute could heat up again.
The biggest potential point of conflict is the need for energy and strategic materials by both India and China. Both sides want access to the Central Asian gas and oil resources for their economies. How much friction this causes remains to be seen.
It is extremely hard to suggest anything here unfortunately. Most mathematical research in this area requires a very strong background, and students generally just don't have the experience. The best thing you can do is point her at relatively new areas. Along those lines, I suggest quantum computing. Very few people "get" quantum computing right now, and its relatively easy to get started. From the description of the other course I gather she can program in some sort of language.
Just because it's a new field doesn't mean that it's easy. In fact, given that quantum computing looks at intersections betweeen regular computing and quantum mechanics, it requires a solid understanding of the standard computing theory and the physics of quantum mechanics that is being used.
I don't see how anyone can do meaningful work in quantum computing without understanding the mathematics of quantum mechanics (Hilbert spaces, group theory, vector spaces, algebras), the physical applications of those mathematics and how that can be applied to computing theory and algorithms.
This is probably not something that a high school student would be able to do even an advanced one.
Indeed, that's an excellent reason why armored vehicles (like tanks) are no longer used in modern armies: a single hit into a vulnerable part can disable them. You don't use anything that is not completely, 100% perfect. Never mind that a single land-bound tank, while it lasts, can break through defenses that otherwise would be impenetrable. There simply would be no military value in a tank that can run, climb, jump - even if it has some limited flight capability. Just think of it, what if it gets destroyed while doing its job?
Did I hit a nerve there? I guess you're a battletech / giant robot fan boy. Let's put it this way, we're talking about a robot that's 20+ feet tall. It's going to be a huge target on most battlefields. It's not like it's going to be unobtrusive.
It's not going to be as mobile as you think either. A M1A1 tank weighs about 60 tons. In comparision a fully loaded F-16 is about 19 tons ( 5 tons for weapons, 8 for the airframe and 6 for fuel). Your battlemech thing is going to weigh at least as much as the M1A1 and probably a lot more. So you're going to need a huge engine to give it any sort of limited flight capacity. Don't forget the fuel for this engine as well.
It certainly won't be climbing anything either. Even if it could have enough dexterity to grab handholds and footholds, not much is going to support its weight.
As for walking or running, getting hit by enemy fire while doing either has a good chance of taking it down. When walking, a good portion of the time is spent on a single leg. Running is even worse since a part of the time when running is spent totally in the air. Getting hit when no or just one leg is supporting the thing would probably knock it off balance and take it down.
So now, you're left with a large easily seen battlemech that can only walk or run when it's not likely to come under fire. How is this any better or equivalent to a tank? It's more vulnerable, more easily seen and probably not any faster. It might be able to have more weapons but that won't do much good if the battlemech gets knocked out of comission before it can use them.
What exactly is it supposed to be achieving anyway? A hit from the main gun on a M1A1 will take pretty much anything out right now. Anything that needs more firepower can be taken out by artillery or air support both which can be out of visual sight but still effective.
BTW, a MechWarrior Battletech Battlemech, or WTH ever it is called, also goes by another name: sitting duck. In physics as is currently known, penetrating missle-bombs are way, way ahead of armor. In fact, the only viable defense against them are anti-missle missles.
Forget the anti-armor missiles, a good hit in the upper portion of the thing would probably be enough to knock it down even if the round doesn't penetrate the armor. Once it's down, you could probably pick it apart pretty easily.
Does Brook's Law:
"Adding manpower to a late software project makes it later"
not apply in the least bit to semiconductor shrinking?
Brook's Law doesn't even apply to software all the time. Consider a project with a single person working on writing a full featured OS. Adding another person should reduce the time needed to get the thing done even if it's late.
Part of the work needed is actually building the fab and getting the physical stuff done. Adding more people would speed things up there up to a point. Besides, a large part of the time lag is getting the funding in place and paying for ongoing expenses. Having more companies involved would help here.
But OTOH, Seriously, if this were a bomb and they had a 24 hour time limit, do you think they could do something similar? The article leads me to believe not, which is what concerns me. This should be a situation that they can deal with EASILY in under 3 weeks.
If this were a bomb, do you seriously think they would be shuttling it around in a pneumatic air tube? They were working with a sample about the size of a mouse and the air tube was probably the quickest way of delivering the sample without exposing people to the radiation or having to worry about in the delivery electronics failing due to radiation exposure.
Reading the CNN story about the IBM graffitis that's also linked at the top of this thread, the IBM graffitis were really inconspicious, and sprayed on the sidewalks which certainly aren't as critical as building walls. Most importantly though, they were made from chalk: "It washes right off, so it will be removed the next time it rains." Total non-issue.
I still see some of the IBM linux graffiti here in Chicago. The rain and snow that it's experienced in the last 4 years doesn't seem to have washed it off.
So I finally got a chance to go with some friends last Friday, day after Thanksgiving. Unfortunately, the park rangers had closed the trail a mile and a half from the lava flow, saying that a bench had collapsed into the ocean several months ago, taking 14 hikers with it, who were never found. I can only imagine that they either drowned, were incinerated, or were buried alive by the landslide, or some ungodly combination of the three.
They were suffered a combination of being boiled alive and drowning. The water around where the lava hits the ocean is boiling and since there are active lava flows in the bench, there's a good chance any water the hikers hit was very hot. Hopefully they became unconcious and didn't feel much. I can't imagine being scalded to death is pleasant.
The rock face of Kilauea didn't collapse. A shelf on the coastline formed by lava flows from Kilauea collapsed. Kilauea is located fairly far inland and has no chance of collapsing without taking a decent portion of the island of Hawai'i with it.
Oh, well, if the site is only intended to preach to the converted then that's fair enough of course. I was somehow under the mistaken impression that, as someone who is paid to work on Windows more often than I am paid to work on Linux, the site could be useful for me to keep up to date with "the latest major developments in technology", rather than a pre-existing knowledge of "the latest major developments in technology" being essential before attempting to understand the site.
Virtualization has been talked about for at least 6 months now. Microsoft has been moving towards this with it's virtual server software, sun and ibm have had it for years and been talking it up for a while, and even intel and amd are introducing hardware support for it in their next chip series. Virtualization isn't really the latest major development in technology anymore, especially since IBM has been doing it for at least 20 years now.
However the chemicals in ZipLock bags are acceptable to be next to our food. I doubt they will be a problem for DVDs and CDs.
Vinegar is acceptable as a food substance. Keeping your dvd or cd media in contact with vinegar would probably end up oxiding the metal layer over time and making it useless.
Take a electrical cord and cut it in half. Take an ethernet cord and do the same. Connect the live and ground wires from the electrical cord to any of the wires in the ethernet cord. Plug the ethernet cord into your switch and then plug the electrical cord into your router. You'll quickly get a screwed up network.
P.S. If you actually do this, don't blame me for any of the consequences.
We invented, we govern it. Simple. If they want to
create their own version and write the bridges, they
can go ahead, but it was our tax dollars (DARPA) that
developed it in the first place.
Well, I guess we can just wish the web goodbye since it was created by people at CERN (Center for European Nuclear Research). I think other bits and portions of the net were created by others as well so your argument doesn't fly.
Why on earth did Cisco not release this earlier? It would save people alot of trouble.
If you read TFA, the bug involved system timers and how they were handled. Given that this probably affects most of the system functions, it's not surprising that it would take a while to make the changes and test it. Think about how long it took to fix the VM bugs in linux 2.4, this probably a change of similar magnitude.
So mod_perl can only be used for high volume traffic if it uses an unstable caching system. If we follow this strange premise to its inevitable end, we must conclude that there exists an unstable caching algorithm, that can be programmed in Perl, that is exponencially faster than the fastest known stable caching algorithm. After all, this theoretical unstable algorithm cannot just be, say, twice as fast - as one could just double or triple the hardware - for a stable caching algorithm to be realistically impractical, our unstable caching algorithm needs to be exponentially faster.
Okay, now you're just making up a strawman arguments to knock down. Where did I say that mod_perl can only handle high volume traffic if it uses an unstable caching system? I made an argument that the missing features in the software framework that slashdot uses may have led to it's developers getting too aggressive with caching and optimization and thus resulting in an errors in it's functioning. How you get from there to requiring an exponentially faster caching doesn't make sense.
Let's take your requirement for the unstable exponentially faster caching algorithm. From looking at queues, I'm sure you will agree that a linear increase in rate of requests can result in a condition were the queue will keep increasing in size. Now, you assert that you can simply double or triple the hardware speed to handle this.
Although this is theoretically true, in real life this is not. Consider the situation where you have a 64 processor x86 machine, you can't simply double this to get a 128 processor system since such a system doesn't exist aside from possibly in a lab. Although the web portion can be parallelizable, the database isn't easily so. Establishing and maintaining a coherent database over a cluster isn't easy and can't just be handwaved away. More significantly, anyone has budgetary constraints. Slashdot couldn't simply plunk down more cash to purchase newer hardware at will during most of its existence earlier existence and that is probably also true to some extent now.
In several years of programming, I don't think I've ever come across a situation where stability has to be sacrificed for speed.
Such a scenario is certainly possible. Imagine a race condition that occurs once every few months on average and doesn't do much harm. However guarding against this race condition requires putting a mutex around a variable that is used everywhere. Given a situation where you are trying to get all the speed you can, I can see developers deciding to live with the race condition.
If I understand your argument correctly, you're saying that even if an unstable piece of software can serve up 30 pages per second, a stable piece of software cannot do the same. I must confess to being puzzled by this; why does speed imply a greater risk of instability? I cannot think of a single 'trick' related to scalability that would inherently increase instability of the overall system.
No, my argument is that the errors in slashdot illustrate that some frameworks aren't suitable for high volumne usage. The mod_perl and software framework used by slashdot doesn't offer much scalability. Therefore, the developers were forced to implement an ad-hoc caching system that doesn't work well. A better software framework would have better scalability and builtin caching that gives the same performance without the bugs.
In regards to your question of speed vs. stability, there's often a tradeoff between the two. Take the simple example of mutexes in multithreaded software. Leaving out the mutexes and their associated controls would let the software run more quickly but leaves the possibility that every once in a while threads interfere with each other. With caching, it's easy to get a little too aggressive and end up caching stale information or writing that stale information to persistent storage.
Slashdot Mirror
It was just a few years ago that abortion clinics and doctors were being firebombed and shot in order to protect the sanctity of human life.
I think you misunderstand what the singleton is trying to do. The J2EE singleton is trying to make sure only a single instance is running even if a cluster of machines is running the application logic. This means that the singleton needs to instantiate once in the cluster which is slightly different and more difficult then making sure your singleton only instantiates once in your application instance.
You can get Timex OVA and maybe Nike watches with a similar design. However, they are digital watches designed for runners and other athletes needing to time their workouts. They probably wouldn't work in a formal setting.
Check out the specs on telco equipment. A lot of them run on 48 vdc with special 48vdc power supplies. You can get a lot of networking gear that come with 48vdc power supplies. I think there are probably computers that have the same ability.
Of course this is all pretty expensive since it's intended for telco companies.
The direction that cosmic radiation comes from can be identified. If election -> positron conversions happened, we would be seeing 1 MeV xray/gamma radiation coming from everywhere. People aren't dying of radiation sickness in large numbers, therefore rotating an electron 360 degrees doesn't result in its conversion to a positron.
If this happened, you'd see random explosions all the time. Electron - positron conversion hasn't been detected yet so a simple rotation is definitely not going to be converting electrons to positrons. Hell, if it did we'd have antimatter bombs floating around all over the place.
I don't think anyone's really programmatically created the red cross emblem in any recent game. It's just another texture in the game and can get switched out for the caduceus without too many problems. Maybe 10 years ago games were generating based on code but it's been all textures for a very long time.
I seriously doubt geek anythings but especially geek government officials would be getting tapped on a regular basis.
I've used Jad to decompile source code and produce a compilable code base. It's not that easy and frankly it's easier to just rewrite the code for simple applications. Jad produced code with all the variable, class, and method names going in alphabetic order (e.g. method A, method B, ..., method Z, method Aa, etc.). Add in the places where it got confused and dumped vm opcodes and it's easier to rewrite the code from scratch for small programs.
Pakistan may not have enough resources but enough nukes and they have a credible deterrent. True they may not be able to go offensive in a war but they can encourage action in Kashmir & Jammu which is the point of contention right now.
The Chinese and Indians have fought a border war in 1962-1963 and the border regions are still contested. There have been talks but no resolution. Things have been quiet but without a resolution, the dispute could heat up again.
The biggest potential point of conflict is the need for energy and strategic materials by both India and China. Both sides want access to the Central Asian gas and oil resources for their economies. How much friction this causes remains to be seen.
Just because it's a new field doesn't mean that it's easy. In fact, given that quantum computing looks at intersections betweeen regular computing and quantum mechanics, it requires a solid understanding of the standard computing theory and the physics of quantum mechanics that is being used.
I don't see how anyone can do meaningful work in quantum computing without understanding the mathematics of quantum mechanics (Hilbert spaces, group theory, vector spaces, algebras), the physical applications of those mathematics and how that can be applied to computing theory and algorithms.
This is probably not something that a high school student would be able to do even an advanced one.
Did I hit a nerve there? I guess you're a battletech / giant robot fan boy. Let's put it this way, we're talking about a robot that's 20+ feet tall. It's going to be a huge target on most battlefields. It's not like it's going to be unobtrusive.
It's not going to be as mobile as you think either. A M1A1 tank weighs about 60 tons. In comparision a fully loaded F-16 is about 19 tons ( 5 tons for weapons, 8 for the airframe and 6 for fuel). Your battlemech thing is going to weigh at least as much as the M1A1 and probably a lot more. So you're going to need a huge engine to give it any sort of limited flight capacity. Don't forget the fuel for this engine as well.
It certainly won't be climbing anything either. Even if it could have enough dexterity to grab handholds and footholds, not much is going to support its weight.
As for walking or running, getting hit by enemy fire while doing either has a good chance of taking it down. When walking, a good portion of the time is spent on a single leg. Running is even worse since a part of the time when running is spent totally in the air. Getting hit when no or just one leg is supporting the thing would probably knock it off balance and take it down.
So now, you're left with a large easily seen battlemech that can only walk or run when it's not likely to come under fire. How is this any better or equivalent to a tank? It's more vulnerable, more easily seen and probably not any faster. It might be able to have more weapons but that won't do much good if the battlemech gets knocked out of comission before it can use them.
What exactly is it supposed to be achieving anyway? A hit from the main gun on a M1A1 will take pretty much anything out right now. Anything that needs more firepower can be taken out by artillery or air support both which can be out of visual sight but still effective.
Forget the anti-armor missiles, a good hit in the upper portion of the thing would probably be enough to knock it down even if the round doesn't penetrate the armor. Once it's down, you could probably pick it apart pretty easily.
Brook's Law doesn't even apply to software all the time. Consider a project with a single person working on writing a full featured OS. Adding another person should reduce the time needed to get the thing done even if it's late.
Part of the work needed is actually building the fab and getting the physical stuff done. Adding more people would speed things up there up to a point. Besides, a large part of the time lag is getting the funding in place and paying for ongoing expenses. Having more companies involved would help here.
If this were a bomb, do you seriously think they would be shuttling it around in a pneumatic air tube? They were working with a sample about the size of a mouse and the air tube was probably the quickest way of delivering the sample without exposing people to the radiation or having to worry about in the delivery electronics failing due to radiation exposure.
I still see some of the IBM linux graffiti here in Chicago. The rain and snow that it's experienced in the last 4 years doesn't seem to have washed it off.
They were suffered a combination of being boiled alive and drowning. The water around where the lava hits the ocean is boiling and since there are active lava flows in the bench, there's a good chance any water the hikers hit was very hot. Hopefully they became unconcious and didn't feel much. I can't imagine being scalded to death is pleasant.
The rock face of Kilauea didn't collapse. A shelf on the coastline formed by lava flows from Kilauea collapsed. Kilauea is located fairly far inland and has no chance of collapsing without taking a decent portion of the island of Hawai'i with it.
Virtualization has been talked about for at least 6 months now. Microsoft has been moving towards this with it's virtual server software, sun and ibm have had it for years and been talking it up for a while, and even intel and amd are introducing hardware support for it in their next chip series. Virtualization isn't really the latest major development in technology anymore, especially since IBM has been doing it for at least 20 years now.
Vinegar is acceptable as a food substance. Keeping your dvd or cd media in contact with vinegar would probably end up oxiding the metal layer over time and making it useless.
Take a electrical cord and cut it in half. Take an ethernet cord and do the same. Connect the live and ground wires from the electrical cord to any of the wires in the ethernet cord. Plug the ethernet cord into your switch and then plug the electrical cord into your router. You'll quickly get a screwed up network.
P.S. If you actually do this, don't blame me for any of the consequences.
Well, I guess we can just wish the web goodbye since it was created by people at CERN (Center for European Nuclear Research). I think other bits and portions of the net were created by others as well so your argument doesn't fly.
If you read TFA, the bug involved system timers and how they were handled. Given that this probably affects most of the system functions, it's not surprising that it would take a while to make the changes and test it. Think about how long it took to fix the VM bugs in linux 2.4, this probably a change of similar magnitude.
Okay, now you're just making up a strawman arguments to knock down. Where did I say that mod_perl can only handle high volume traffic if it uses an unstable caching system? I made an argument that the missing features in the software framework that slashdot uses may have led to it's developers getting too aggressive with caching and optimization and thus resulting in an errors in it's functioning. How you get from there to requiring an exponentially faster caching doesn't make sense.
Let's take your requirement for the unstable exponentially faster caching algorithm. From looking at queues, I'm sure you will agree that a linear increase in rate of requests can result in a condition were the queue will keep increasing in size. Now, you assert that you can simply double or triple the hardware speed to handle this.
Although this is theoretically true, in real life this is not. Consider the situation where you have a 64 processor x86 machine, you can't simply double this to get a 128 processor system since such a system doesn't exist aside from possibly in a lab. Although the web portion can be parallelizable, the database isn't easily so. Establishing and maintaining a coherent database over a cluster isn't easy and can't just be handwaved away. More significantly, anyone has budgetary constraints. Slashdot couldn't simply plunk down more cash to purchase newer hardware at will during most of its existence earlier existence and that is probably also true to some extent now.
Such a scenario is certainly possible. Imagine a race condition that occurs once every few months on average and doesn't do much harm. However guarding against this race condition requires putting a mutex around a variable that is used everywhere. Given a situation where you are trying to get all the speed you can, I can see developers deciding to live with the race condition.
No, my argument is that the errors in slashdot illustrate that some frameworks aren't suitable for high volumne usage. The mod_perl and software framework used by slashdot doesn't offer much scalability. Therefore, the developers were forced to implement an ad-hoc caching system that doesn't work well. A better software framework would have better scalability and builtin caching that gives the same performance without the bugs.
In regards to your question of speed vs. stability, there's often a tradeoff between the two. Take the simple example of mutexes in multithreaded software. Leaving out the mutexes and their associated controls would let the software run more quickly but leaves the possibility that every once in a while threads interfere with each other. With caching, it's easy to get a little too aggressive and end up caching stale information or writing that stale information to persistent storage.